Talk:Connect IOU with real networks or dynamips

From Internetworkpro

Jump to: navigation, search

Contents

[edit] Please explain this

"For more information about IOU or ioulive, ask your Cisco SE/AM that provided you with your copy of IOU"

Can you please tell me to whom are you reffering as Cisco SE/AM? Some email addresses or some link would be ok. SE = Sales Expert AM = Account Manager 

... e.g. whomever your sales expert or account manager is.  (--jlgaddis)

[edit] IOU socket file location

>These are created in the subdirectory "/tmp/netio1000", with >a numeric name that corresponds to <instance ID>. So far, i cannot >tell whether this directory is the same for anyone, anytime.

It seems to be UID, so I'd recommend to change your script:

my $socket_base = "/tmp/netio1000"; # looks like IOU always uses this directory for domain sockets

change to

my $socket_base = "/tmp/netio$<"; # looks like IOU always uses this directory for domain sockets

--

Yep, thanks. I had implemented a more complex way though, it seems that when using sudo, $< is not enough.

[edit] construction of IOU MAC address

I noticed that I was only getting broadcast traffic to/from the IOU interface, the filter that you have in-place hard wired it to 0e:00:03:e8 but my IOU instance uses 0e:00:01:f4, suppose it depends on the IOU version etc.

--

Thank you! Wrong assumption by me - after doing a closer look, the mac is constructed with the help of the users UID the iou binary is started with; mine was 1000 (0x03e8), yours is 500 (0x01f4). There is also a change in the first byte of the MAC every time the IOU instance ID crosses a byte boundary (256, 512 etc.).

I will come up with a smarter way to calculate the entire MAC correctly. For now, comment the filter binding to the pcap: 

 # Net::Pcap::setfilter($pcap, $pcap_filter) && die 'Unable to assign capture filter';

I hope its fixed with v0.3, please test!

--

It fails with an error about compiling the filter everytime now, I have checked and $macstring is fine however it needs to be in the xx:xx:xx:xx:xx:xx format rather than just xxxxxxxxxxxx, tested this by changing it to (ether dst xx:xx:xx:xx:xx:xx) and it compiled fine.

--

Sorry for the mess. A bugfix is included in v0.31 (reformatted $macstring). On the other hand, I did test the new version before pushing it out, and it was working on 2 systems (32/64 bit, both Net::Pcap v0.16, libpcap 1.1.1). Also, I tested this filter directly with tcpdump which didnt complain either. If you dont mind: what OS flavor, perl version, libpcap and Net::Pcap version do you use (and can you do a quick check with tcpdump too)?

--

It seems to me that the calculation of the MAC Address is not correct.Not entirely at least.

For the first router you spawn it is usually ( but not always) correct.But for subsequent routers the mac address of the interfaces changes and does not follow you calculation logic in the script.

This is what I get for example:

Ethernet0/0 is up, line protocol is up 

 Hardware is AmdP2, address is 0e00.03e8.0100 (bia 0e00.03e8.0100)

Ethernet0/1 is up, line protocol is up 

 Hardware is AmdP2, address is 0e00.03e8.0110 (bia 0e00.03e8.0110)

Ethernet0/2 is up, line protocol is up 

 Hardware is AmdP2, address is aabb.cc00.0120 (bia aabb.cc00.0120)

Ethernet0/3 is administratively down, line protocol is down 

 Hardware is AmdP2, address is aabb.cc00.0130 (bia aabb.cc00.0130)

And your script calculates: 0e:00:03:e8:01:00 e0/0 0e:00:03:e8:01:10 e0/1 0e:00:03:e8:01:20 e0/2 0e:00:03:e8:01:30 e0/3

Running on debian squeeze if it makes any difference

--

Please check if your NETMAP mappings for the interfaces in question have the "@hostname" suffix - for both source and destination. As far as i can tell, IOU uses a MAC with aabbcc OID for interfaces that are "internal" only (attaching to other IOU instances). MAC with 0e.... OID are required and used for interfaces that connect to real devices only.

--

You are absolutely right about that.It turns out I that during these tests on many occasions I edited the NETMAP file after starting the iou instance. But I have one more bug.For instance 1 interface e0/0 the mac address I get from the IOS and the output from your script is 0e:00:03:e8:01:00. But when I capture traffic on the interface with wireshark I get 01:00:0e:00:03:e8. And this happens only (as far as i know) for instance 1 and interface e0/0.Naturaly forwarding frames does not work for e0/0 instance 1 but works for the rest.

Any insights?

--

Thinking about the symptoms, it might be a formatting issue due to bad encoding. Its still unclear to me why it works for any interface but e0/0, i would expect that the encoding problem happens regardless of interface numbering. Anyway, see at the end of the discussion page for a potential fix - if possible, use the code at the very end of this page. Please report back whether this made the issue disappear (please also state $LANG) or not. I will incorporate this into the next iteration of the script then.

If it still does not work: do you mind putting the following information into the pastebin (http://inetpro.org/pastebin)?

Thanks!

--

So I tested the code at the bottom of the page.Does not seep to do any difference.Here is the output you requested http://inetpro.org/pastebin/10939

Oh and thank you so much for the original script and the additional effort to keep this one alive.Keep it up

--

Issue was isolated - caused by using string manipulation when stripping off IOU header. Should be fixed in v0.4. Many thanks for submitting this bug report.

[edit] packet capture

Have you any plans to adapt the script to instead of acting as a bridge have it be able to capture packets between IOU devices and pipe them out to a pcap file that could be read by wireshark? I had a go at adapting the script myself but Perl is sadly not my friend :P

--

Tough call :) Capturing traffic between IOU instances will not be possible, at least not in a straightforward fashion.

Let me explain: As far as I can tell, local IOU<->IOU communication is always done through Unix domain sockets. Its not possible for a new program to "attach" to an existing socket that was created by some program (IOU) before, with the intention to receive data simultaneous together with the program that created the socket (both acting as servers).

Of course, you can destroy the socket (unlink) that was created by IOU before and recreate it. By doing this, a sniffer program is able to retrieve data sent by another IOU instance. However, the IOU instance will not re-attach to this socket, because its still running. Since you cant send data to the IOU instance anymore, this approach is sort of useless :-) Launching IOU after you have started the sniffer will also not work, IOU will destroy and create the socket again. Catch 22...

To be useful, a packet capture feature has to be included in the IOU binary itself.

A possible workaround is to build a sniffer that acts as an independent IOU instance. You'd have to attach your real IOU instances to it via mappings in the NETMAP file. The sniffer will receive traffic from one IOU instance, make a copy of it (store it in pcap file etc.) and send it out to another port towards the final IOU instance. Think of it like a switch board, or like inline sniffer appliances. Because you have to define your mappings beforehand, it will not be a flexible solution that can be (re)configured during runtime.

[edit] Encoding

Hi, friends.

I've got some problems with this script. I doesn't delete IOU header from the outgoing packet. So, after few hours I have found possible solution:

  1. cut off IOU header (first 8 bytes)

-- $iou_recv_data =~ s/^.{8}//;

++ $iou_recv_data =~ s/\C{8}//;

Now it works for me! Maybe this info will be useful for anyone.

--

Thanks for the bug report. I understand your system uses a different encoding as system default; this was something I did not account for.

Encoding problems are hopefully fixed with v0.4.

[edit] Using iou2net.pl for L2IOU

Hello!

I was trying to use this script to interface with L2IOU instances, but it did not work at first. I've noticed that the MAC addresses in the L2iou ethernet interfaces were different.

From some experiments, I've concluded that the format described below applies to my case: 

aa:bb:cc:dd:ee:ff
^  ^  ^  ^^ ^  ^
|  |  |  || |  this byte is used just as before, to address major/minor interface identifiers
|  |  |  || |  
|  |  |  || this byte is the least significant part of the iou instance
|  |  |  |this nibble is used for the most significant part of the iou instance (>256)
|  |  |  |
|  |  |  I believe this nibble is used to identify the type of interface...
|  |  |  0=ethernet
|  |  |  8=vlan
|  |  |  
|  These two bytes are used for the UID
|
The first byte seems to always be equal to 0x02... I am not completely sure about this.

Therefore I've created an additional flag in my copy of the script to activate the l2iou mode. If this flag is activated, the macstring is assembled in the following way: 

	    $macstring = pack( "CH4H4C",
		0x02,
		unpack( "H4", pack( "n", 0x0000 ^ $uid ) ),
		unpack( "H4", pack( "n", 0x0000 ^ $iou_instance ) ),
		( $iou_interface_minor << 4 ) | $iou_interface_major );

The unpack/pack operations might be unnecessary, as I am new to perl and these functions.

So far I was able to establish IP connectivity, ospf and LDP neighbors with the real world. Maybe it can be useful to someone else.

Another remark: to communicate with the real world I had to enable a loopback parameter at the vlan interfaces, and I can only use switchport mode access. Anyone had any success?

Regards

--

Hi,

thank you for analyzing the l2iou mac address format. I did some experiments aswell, and I can confirm that most of your observations are equal to my findings. However, it seems that there is some more trickery going on behind the scenes :-)

Most noticeably, i found out that for SVIs, MAC addresses may change dynamically. This was observed under the following conditions:

, so basically for any SVI that you bridge externally.

For SVIs that will stay isolated within the IOU topology, the MAC is aa:bb:cc... If the SVI is going to be visible to the outside world, the MAC of the SVI will change to 02<uid> format. As stated before, this MAC change happens dynamically when the SVI is exposed externally (switchport with access/trunk comes up, SVI receives some frames).

Here is an example of this: 

(l2iou starts)
Router#sh int vl 1000
Vlan1000 is down, line protocol is down 
  Hardware is EtherSVI, address is aabb.cc80.0100 (bia aabb.cc80.0100)
[...]
*Aug 13 13:18:55.831: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1000, changed state to up
[...]
Router#sh int vl 1000
Vlan1000 is up, line protocol is up 
  Hardware is EtherSVI, address is 027d.7b00.0100 (bia 027d.7b00.0110)

As mentioned, only if the SVI is actually receiving frames, the MAC will change, like 

Router#sh int vl 500
Vlan500 is up, line protocol is up 
  Hardware is EtherSVI, address is aabb.cc80.0100 (bia aabb.cc80.0100)
[...]
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 packets output, 0 bytes, 0 underruns
     0 output errors, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out

(sending some stuff in the vlan)

Vlan500 is up, line protocol is up 
  Hardware is EtherSVI, address is 027d.7b00.0100 (bia 027d.7b00.0110)
[...]
     48 packets input, 6536 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 packets output, 0 bytes, 0 underruns
     0 output errors, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out

(SVI for VLAN 1000 - although not 'active' anymore - keeps its MAC address)
Router#sh int vl 1000
Vlan1000 is up, line protocol is up 
  Hardware is EtherSVI, address is 027d.7b00.0100 (bia 027d.7b00.0110)

Furthermore, physical interface MAC addresses seem to change aswell, for example 

Ethernet0/0 is up, line protocol is up (connected)
  Hardware is C6k 10Mb 802.3, address is 027d.7b00.0100 (bia 027d.7b00.0100)
Ethernet0/1 is up, line protocol is up (connected)
  Hardware is C6k 10Mb 802.3, address is 027d.7b00.0100 (bia 027d.7b00.0110)

By looking at the examples above, one can conclude that everything visible externally will always have a MAC associated according to the scheme 0x02 + uid + iou instance + 0x00 (first interface). Im not so sure about this, and from a practical perspective, I think this is only half of the truth.

With l3iou, the MAC pcap filter could easily implemented, because there were only routed links (did not care about IRB stuff). With l2iou, shared links are possible, where you can expose an entire VLAN with all its attached hosts externally. Host could be anything; IOU, dynamips, qemu, vmware and so on. And all with enough different MAC addresses that make a pcap filter a hopeless approach.

The filter is there to keep unrelated frames away, ultimatively to decrease processing load. The solution for l2iou 'bridging' is to rewrite this in a more efficient way (C and/or skip pcap filter and implement sort of MAC learning). As a quick workaround and with the MAC change stuff in mind, I think its also feasible to broaden the pcap filter in a way that any possible L2IOU frame is accepted. 

 Net::Pcap::compile( $pcap, \$pcap_filter,        
	'(ether[0] & 1 = 1) or 
	(ether dst ' . $macstring . ') or 	
	(ether[0] = 0x02 and ether[1:2] = 0x' . unpack( "H4", pack("n", $uid )) . ') or 
	(ether[0] = 0xaa and ether[1:2] = 0xbbcc)', 
	0, 0xFFFFFFFF )
 && die 'Unable to compile capture filter';

Of course, this has to be extended if there are non-IOU hosts attached behind the l2iou instance, like dynamips or qemu-emulated systems. Alternatively, if the network card to be pcap'd to is solely dedicated to labbing, the pcap filter could be entirely disabled with a command line flag.

For the additional remarks: I did not made any other configuration to SVIs or switchports. Trunks does not work because your network card may strip the 802.1Q tag off before it reaches the kernel/the pcap routine. It does work well for me, however there seems to be an issue with native vlan traffic. When sending ip traffic over the native vlan, most of it always gets tagged (what you get with dot1q tag native). Non-native VLAN traffic is ok though.

[edit] packet capture

How to make iou2net.pl packet capture to the file?

I tried iou2net.pl -f cap01.cap -p 101 and it doesnt work.

I need only to capture traffic between virtual instances, no action with physical interfaces.


update: I read previous post about what i ask. Very sad about nonavailability to capture traffic. :(

Retrieved from "http://www.inetpro.org/wiki/Talk:Connect_IOU_with_real_networks_or_dynamips"
Personal tools
Namespaces
Variants
Actions
Navigation
Categories
Toolbox