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/
