search

GNS3 / dynamips

Dynamips development
GNU General Public License v2.0
349 stars 94 forks source link

Protocol status incorrect #33

Open fgierlinger opened 10 years ago

fgierlinger commented 10 years ago

Detecting the protocol down (shutting down the remote interface) on etheret interfaces does not work.

A fa0/0<->fa1/0 B

Turning down the interface fa1/0 should result in a "Protocol down" on interface fa0/0. But this behavior does only work on serial interfaces.

Related topics:
flaviojs commented 10 years ago

Thanks for reporting. =)

I'm able to reproduce it:

flaviojs commented 10 years ago

After analyzing a packet capture of the serial link there is a keep-alive packet (cHDLC, SLARP) that is sent between the routers and used to know if the line is up.

Relying on this packet means it will report line down on timeout, which explains the delay of the message in the other router.

flaviojs commented 10 years ago

After analyzing a packet capture of the ethernet link there are CDP packets sent every 62 seconds (with 180 timeout) and LOOP packets sent every 10 seconds.

Playing around with the configs:

Apparently it doesn't decide the ethernet line status from the traffic. If the line status is reported by the ethernet card then a viable option would be to have a configurable timeout for link down. (no data received for X seconds => link down)

Next step: how does the ethernet card report the line status? how does the ethernet card know that the interface is administratively down (shutdown)?

rednectar commented 10 years ago

I could be totally wrong here, but I believe that a physical router detects link_up and link_down from the physical state - ie the presence/absence of LIP (Link Integrity Pulse). I've just always assumed that since dynamips doesn't emulate the physical in the same way, then we'd have to put up with Ethernet interfaces always being up.

LIPs are also used to determine speed/duplex negotiation, and again this is another thing that dynamips does not do

But good luck!

On 5 April 2014 13:32, Flávio J. Saraiva notifications@github.com wrote:

After analyzing a packet capture of the ethernet link there are CDPhttp://wiki.wireshark.org/CDPpackets sent every 62 seconds (with 180 timeout) and LOOP http://wiki.wireshark.org/Loop packets sent every 10 seconds.

Playing around with the configs:

  • shut - nothing is sent
  • no cdp enable, no keepalive, no shut - normal packets
  • cdp enable, no keepalive, no shut - normal packets + CDP every 62 seconds
  • no cdp enable, keepalive, no shut - normal packets + LOOP every 10 seconds
  • no cdp enable, keepalive 5, no shut - normal packets + LOOP every 5 seconds

Apparently it doesn't decide the ethernet line status from the traffic. If the line status is reported by the ethernet card then a viable option would be to have a configurable timeout for link down. (no data received for X seconds => link down)

Next step: how does the ethernet card report the line status? how does the ethernet card know that the interface is administratively down (shutdown)?

Reply to this email directly or view it on GitHubhttps://github.com/GNS3/dynamips/issues/33#issuecomment-39626801 .

flaviojs commented 10 years ago

Yes, a real ethernet card detects link up/down from the physical state. But I'm not sure how it informs the software driver of the change in status. =~~

Indeed we don't emulate the physical layer. However we can still fake a link up/down if we rely on the fact that IOS sends periodic packets. (must be configurable since these packets can be disabled) It's similar to what IOS does to detect 'link down' in serial links. No traffic received for X time => link down. =)

rednectar commented 10 years ago

Cisco routers send LOOP packets every 10 seconds on Ethernet interfaces (I guess that goes for FastEthernet and GigabitEthernet too). They are simply packets sourced by the interface MAC address TO the same interface MAC address EtherTpye 0x9000 and about 6 bytes of data - the rest all 00

However, you can't really rely on an interface seeing LOOPS from another interface to determine up/down, because something as simple as a switch sitting between the two routers would filter the packets.

IF however you KNEW it was a point-to-point connection between two routers, then maybe detecting LOOPS would be good enough - but then you'd have to manage the type of connection to know whetehr you should be detecting LOOPS or not - getting messy.

But LOOPS are the only packet you can RELY on - all others can be turned off. And if the router is connected to switch (say NM-16ESW for instance) then you can't rely on anything - except in that case the switch would be sending Spanning Tree BPDUs.

Other cases - like directly connected to a host (VPCS) or Qemu/ASA/Virtual Box device - no packets are guaranteed to be seen (especially with an ASA)

Chris

On 7 April 2014 07:33, Flávio J. Saraiva notifications@github.com wrote:

Yes, a real ethernet card detects link up/down from the physical state. But I'm not sure how it informs the software driver of the change in status. =~~

Indeed we don't emulate the physical layer. However we can still fake a link up/down if we rely on the fact that IOS sends periodic packets. (must be configurable since these packets can be disabled) It's similar to what IOS does to detect 'link down' in serial links. No traffic received for X time => link down. =)

Reply to this email directly or view it on GitHubhttps://github.com/GNS3/dynamips/issues/33#issuecomment-39682626 .

flaviojs commented 10 years ago

Yes, as you point out, it's not completely reliable in any scenario. That's why I was thinking of leaving it off by default (configurable in each nio).

In my view any traffic received would indicate the link is still active, even an empty packet, and a configurable timeout time with no packets received would indicate link down.

My concern is... would it ever be used? Ex: currently we can limit the transmission bandwidth of a nio with the hypervisor command "nio set_bandwidth" but I don't recall it ever being used (except internally by the mueslix serial device) @grossmj your 2 cents from a GNS3 perspective?

flaviojs commented 10 years ago

Related topic: http://forum.gns3.net/topic9324.html

ikiris commented 10 years ago

I wouldn't do timeout based on packet events as to up/down. It's better to leave it up than false positive if you can't do event based detection on the far side.

tusune commented 6 years ago

@flaviojs After 4 years, up to this post.

There is a problem with the fact that interfaces are always up/line protocol up : If a link goes down (just remove a link between 2 routers, to simulate a real situation where a link goes down), the router consider that the interface is fully up, so routing table don't update.

I've got this problem yesterday, i had one link between two routers, and those two routers were connected to a local vlan (switch + pc). problem, one router is active (HSRP), but when the link between him and the local vlan is removed, the interface/line protocol are still up, so routing table don't update, so he don't know that he can go to the local vlan via the second router.