Re: [c-nsp] ISR detects interface status with delay
Thanks! Configuring keepalive messages interval to 1 second(default is 10s) indeed decreases polling interval to 1 second. For example if I configure no keepalive, then ISR Ethernet interface will never go down while the cable is physically disconnected. However, why does decreasing the keepalive messages interval cause this polling interval to decrease? Is this just some sort of (legacy) code in IOS which creates this relation between keepalive messages interval and interface status polling interval? As far as I knew, keepalive frames(ethertype 0x9000, same src and dst MAC) were just used for loop-detection in case of older Ethernet cabling standards.. thanks, Martin On 2/8/15, Swapnendu Mazumdar ccie19...@gmail.com wrote: keepalive 1 under ethernet interface on ISR. On Sun, Feb 8, 2015 at 4:40 AM, Martin T m4rtn...@gmail.com wrote: Lukasz, thanks for the reply! Just to make sure, there isn't a way to decrease this polling interval on ISR platform, is there? Martin On Sat, Feb 7, 2015 at 11:42 AM, Łukasz Bromirski luk...@bromirski.net wrote: On 06 Feb 2015, at 10:36, Martin T m4rtn...@gmail.com wrote: In order to illustrate this behavior I made a short video where IOS detects that interface Fa0/0 went down with almost 13 seconds delay. Usually this delay is around 5 to 8 seconds, but sometimes up to 15 seconds. Video can be seen here: https://www.dropbox.com/s/yb9o379935s3hou/20150206_110347.mp4 PHY chip should detect this within micro- or milliseconds and as seen from the video, LED's indicating the link status went off immediately when I removed the cable, but why does it take so long for IOS to detect this? First of all, carrier-delay on ISRs is not supported. The command is for that hardware platforms, that have more extensive instrumentation on the edge between hardware and software. Second, ISR polls interface controllers for up/down, so your better bet would be to use BFD, despite it being CPU-intensive, to detect link up/down event. -- There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromir...@jabber.org about. John von Neumann | http://lukasz.bromirski.net ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ISR detects interface status with delay
On 08 Feb 2015, at 01:40, Martin T m4rtn...@gmail.com wrote: Lukasz, thanks for the reply! Just to make sure, there isn't a way to decrease this polling interval on ISR platform, is there? In current code no, according to my knowledge. -- There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromir...@jabber.org about. John von Neumann |http://lukasz.bromirski.net ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ISR detects interface status with delay
On 06 Feb 2015, at 10:36, Martin T m4rtn...@gmail.com wrote: In order to illustrate this behavior I made a short video where IOS detects that interface Fa0/0 went down with almost 13 seconds delay. Usually this delay is around 5 to 8 seconds, but sometimes up to 15 seconds. Video can be seen here: https://www.dropbox.com/s/yb9o379935s3hou/20150206_110347.mp4 PHY chip should detect this within micro- or milliseconds and as seen from the video, LED's indicating the link status went off immediately when I removed the cable, but why does it take so long for IOS to detect this? First of all, carrier-delay on ISRs is not supported. The command is for that hardware platforms, that have more extensive instrumentation on the edge between hardware and software. Second, ISR polls interface controllers for up/down, so your better bet would be to use BFD, despite it being CPU-intensive, to detect link up/down event. -- There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromir...@jabber.org about. John von Neumann |http://lukasz.bromirski.net ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ISR detects interface status with delay
Lukasz, thanks for the reply! Just to make sure, there isn't a way to decrease this polling interval on ISR platform, is there? Martin On Sat, Feb 7, 2015 at 11:42 AM, Łukasz Bromirski luk...@bromirski.net wrote: On 06 Feb 2015, at 10:36, Martin T m4rtn...@gmail.com wrote: In order to illustrate this behavior I made a short video where IOS detects that interface Fa0/0 went down with almost 13 seconds delay. Usually this delay is around 5 to 8 seconds, but sometimes up to 15 seconds. Video can be seen here: https://www.dropbox.com/s/yb9o379935s3hou/20150206_110347.mp4 PHY chip should detect this within micro- or milliseconds and as seen from the video, LED's indicating the link status went off immediately when I removed the cable, but why does it take so long for IOS to detect this? First of all, carrier-delay on ISRs is not supported. The command is for that hardware platforms, that have more extensive instrumentation on the edge between hardware and software. Second, ISR polls interface controllers for up/down, so your better bet would be to use BFD, despite it being CPU-intensive, to detect link up/down event. -- There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromir...@jabber.org about. John von Neumann |http://lukasz.bromirski.net ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ISR detects interface status with delay
In order to illustrate this behavior I made a short video where IOS detects that interface Fa0/0 went down with almost 13 seconds delay. Usually this delay is around 5 to 8 seconds, but sometimes up to 15 seconds. Video can be seen here: https://www.dropbox.com/s/yb9o379935s3hou/20150206_110347.mp4 PHY chip should detect this within micro- or milliseconds and as seen from the video, LED's indicating the link status went off immediately when I removed the cable, but why does it take so long for IOS to detect this? thanks, Martin On Thu, Feb 5, 2015 at 3:44 PM, Martin T m4rtn...@gmail.com wrote: Hi, I have a Cisco WS-C2960G-24TC-L switch(IOS c2960-lanbasek9-mz.150-2.SE7.bin) and Cisco 1841 router(IOS c1841-advipservicesk9-mz.151-4.M1.bin) connected like this: sw1[Gi0/3] - [Fa0/0]r3 If I pull out the cable from sw1 port Gi0/3, then r3 detects this with 5 - 7 second delay. I configured carrier-delay msec 0 under r3 interface Fa0/0, but this did not help. For example here: http://s1.postimg.org/9zf76q0el/cable_removed_from_sw1_Gi0_3.png sw1 detects that the port Gi0/3 went down at 15:10:57 - 15:10:58, but r3 detected this 15:11:04 - 15:11:05. Clock in all the devices is exactly the same. What might cause such behavior? thanks, Martin ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
