Protocol status incorrect

[fgierlinger]

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:

• http://forum.gns3.net/topic9324.html

[flaviojs]

Thanks for reporting. =)

I'm able to reproduce it:

• add two c1700 routers with WIC-1T
• connect the f0 and s0 interfaces of the routers
• configure interfaces and bring them up (ip address 10.0.X.Y 255.255.255.0 and no shutdown)
• confirm everything is up (show interfaces summary)
• bring down the interfaces of one of the routers (shutdown)
• wait for log message in other router ("%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to down"); the f0 interface stays up, the s0 interface is down

[flaviojs]

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]

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:

• shutdown - nothing is sent
• no cdp enable, no keepalive, no shutdown - normal packets
• cdp enable, no keepalive, no shutdown - normal packets + CDP every 62 seconds
• no cdp enable, keepalive, no shutdown - normal packets + LOOP every 10 seconds
• no cdp enable, keepalive 5, no shutdown - 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)?

[rednectar]

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//issues/33#issuecomment-39626801
.

[flaviojs]

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]

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//issues/33#issuecomment-39682626
.

[flaviojs]

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]

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

[ikiris]

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]

@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.