search

GNS3 / gns3-server

GNS3 server
GNU General Public License v3.0
806 stars 263 forks source link

DTP frames incorrectly handled ? #475

Closed 1001QAdotNET closed 8 years ago

1001QAdotNET commented 8 years ago

By accident I run into what seems to be a bug Create a config with three switches daisy chained, no configs whatsoever, just as you created them. Start all of them and capture the traffic at the most to the left or to the right port , like in the picture You will see DTP frames originated by one switch making it all the way to the other end when they should be consumed by the middle switch

https://i.imgur.com/nTVvGT7.png

julien-duponchelle commented 8 years ago

What run on the switches?

1001QAdotNET commented 8 years ago

I tried both, IOU and vIOS, latest versions , it seems to be a server related issue

julien-duponchelle commented 8 years ago

When using the vIOS it's direct connection between qemu emulator via UDP tunnel. This mean when sending a packet from SW1 to SW3 the packet is forwarded by the SW2 OS. It's not possible for a packet to leak from a link to another. It's possible that your cisco images missed that features.

Seem some images are buggy: http://community.dev-innovate.com/t/bugs-associated-with-native-vlan-and-vlan1/6168

1001QAdotNET commented 8 years ago

It does not happen on Unetlab

grossmj commented 8 years ago

Unetlab uses Linux bridges... they may filter out the DTP frames.

1001QAdotNET commented 8 years ago

Then that would be equally blocked between SW1-SW2 and the packets will not reach SW3 either.

grossmj commented 8 years ago

I don't think there is anything to fix there. As Julien told, we use UDP tunnels, what goes out of a source interface goes to a destination interface, no filtering, pretty simple. We don't control what is going on inside a VM.

1001QAdotNET commented 8 years ago

ok, I already passed this section of my studies. If you do not think it is bug then close it and don't check it. Might be Cisco as you suggested.

julien-duponchelle commented 8 years ago

It's interesting that unetlab doesn't have the same behavior. A proof that bridge could make subtle modifications to the packet with uncommon protocol.

On Wed, Apr 6, 2016 at 8:17 PM 1001QAdotNET notifications@github.com wrote:

ok, I already passed this section of my studies. If you do not think it is bug then close it and don't check it. Might be Cisco as you suggested.

— You are receiving this because you modified the open/close state.

Reply to this email directly or view it on GitHub https://github.com/GNS3/gns3-server/issues/475#issuecomment-206500847