I'm seeing ARP resolution problems with my setup detailed below.

Debian "Wheezy" Linux with a Linux bridge that is assigned an IP address and GNS3 packaged by Debian.
I have GNS3 set up with a cloud and one router. { cloud } <--> { cisco }

{ Linux Ethernet bridge w/IP } <--> { cloud - nio_linux_eth } <--> { cisco }

I set the Cisco router to DHCP and it does manage to pull an IP address, but that process is broadcast traffic. I tried using Generic Ethernet NIO and found that DHCP doesn't function, so I switched back to Linux Ethernet NIO. I used the setcap instructions at [0] to restrict dynamips.

My Virtualbox VMs attached to the same Linux Ethernet bridge can ping the bridge host and Cisco router. ARP resolution between the bridge host and the Cisco router doesn't function properly. I see the ARP requests when packet sniffing on the bridge interface, but there aren't any ARP responses between bridge host and Cisco router.

I also noticed that I saw ICMP DUPs when pinging from one (Linux) Virtualbox VM to the Cisco router.


Does anyone have any ideas as to the root problem or a possible solution?
Many thanks.

~~~~~

I found a number of similar forum topics (below), but none that completely solved the problems I'm seeing with my current set up.

[0] topic6202.html
[1] post21700.html#p21700
[2] post23623.html#p23623
[3] post21614.html?hilit=cloud%20arp%20problem#p21614
[4] post14913.html?hilit=cloud%20arp%20problem#p14913

_________________
silvertip257

- GNS3 Premium Member
- Freenode IRC: #cisco
.:|:.:|:.

Meh, here I go replying to myself on a forum...




So I decided to stop being stubborn and just add more interfaces [tap interfaces this time] to my GNS3 lab machine (I already have eight physical interfaces and numerous bridge interfaces).

I added a tap interface, added it to the bridge that had my ISC DHCP Server running, and connected my Cloud to that tap interface. Lo and behold the Cisco router not only grabs an IP address via DHCP quickly, but I also see (!!!!!) ICMP packets trickle in on Wireshark (listening on the bridge interface) unlike the earlier set up.

I happened to take a glance at [0] before searching gns3.net and finding [1].

[0] http://www.blindhog.net/linux-bridging- ... nications/
[1] topic1950.html

_________________
silvertip257

- GNS3 Premium Member
- Freenode IRC: #cisco
.:|:.:|:.

Definitely TAP interfaces are the way to go. We should push their use more...

Thanks for sharing your experience :)

_________________
Jeremy, GNS3 Programmer & Benevolent Dictator for Life.

TAP interfaces are all right, most of the time.
I found a downside of their use ...

In my case I have VirtualBox VMs attached to my Linux Bridge, which also has the TAP interface as a bridge member. While things work peachy for the emulated Cisco device, things are insanely broken for the VirtualBox VMs. VMs who previously could pull addresses via DHCP (ISC DHCP listening on the bridge interface) no longer can.

I'm going to dig into this set up further and I'll provide further feedback in another thread when I have detailed repeatable scenario.

_________________
silvertip257

- GNS3 Premium Member
- Freenode IRC: #cisco
.:|:.:|:.

Sounds good. Let me know about your findings :)

_________________
Jeremy, GNS3 Programmer & Benevolent Dictator for Life.

A quick update here.

I replicated this problem on another GNS3 host ... so at least the behavior (with encapsulation failed) is consistent.


But ... I'm finding a few details that either have changed since I last dug into this problem or I plain missed.

1) While Layer2 Ethernet communication is possible between a GNS3 router (gen_eth cloud) and a VirtualBox VM attached to the same bridge ... it is not possible to communicate gns3<-->host, but vm<-->host works. Also from the GNS3 router, run "debug ip packet", then ping the VM, then ping the host node. You should find "encapsulation failed" when pinging the host node.

Time and again, I've found the Layer2 connectivity issues (to the host node) to be true with all cloud types except for TAP.
Not necessarily the "encapsulation failed" though.

2) As soon as I attach the tap interface to the Linux Ethernet Bridge, it causes that bridge to implement carrier detect. Meaning that if I want to detach that tap interface, I'll have to reboot to do so. The reboot is necessary because the bridge interface now looks for the tap interface (our virtual cable I guess). Much like if you were to attach a physical NIC to a Linux Ethernet bridge and had it unplugged ... it just plain wouldn't be useful because the bridge would be in NO-CARRIER state. ip link show br0

At this point I'm seeing that DHCP does work for VBox VMs booted after attaching the tap interface and having the GNS3 router connected.
Plus I was able to have the GNS3 router pull an IP via DHCP.
And VBox VMs and GNS3 router can all ping the host node (IP on bridge interface).

So I believe I have a few options here,
A) choose #1 and use the VM to masquerade traffic for GNS3
B) choose #2 and deal with keeping the tap interface connected/up
C) choose #2 and augment it so I have br0<-->VM<-->br1<-->tap0<-->GNS3 ... that way I can have multiple VMs on the br0 and not have tap0 make it wonky for everyone (just GNS3)

I'm leaning towards Opt B unless it doesn't work, in which case I'd probably go for Opt C next.

-----

EDIT: As soon as I shutdown the GNS3 router, the Linux bridge goes into NO-CARRIER state. And my VMs can no longer hit its bridge interface.

* Heh, maybe Opt C is the way to go. :-/

_________________
silvertip257

- GNS3 Premium Member
- Freenode IRC: #cisco
.:|:.:|:.