IRC Logs

Network: freenode Channel: #cisco

	Enter your search terms Submit search form
	Web www.irclog.org

[02:01]<dzzzzzzz>which is about what 90seconds
[02:01]<dzzzzzzz>for Hold down timer
[02:01]<vcul>well the holddown timer is about 180sec
[02:01]<vcul>the updates are 30 secs
[02:02]<dzzzzzzz>hmmm no I think Hold down timer is 90 seconds
[02:02]<dzzzzzzz>followed by 180
[02:02]<dzzzzzzz>and than 270
[02:03]<dzzzzzzz>my bad I got them confused
[02:03]<dzzzzzzz>invalid is what I was thinking about
[02:03]<dzzzzzzz>Update timer = 30 seconds
[02:03]<dzzzzzzz>Invalid timer = 90 seconds
[02:03]<dzzzzzzz>Hold down timer = 180 seconds
[02:03]<mrxmjum>tkup, but it says that this mac is used by all vlans.. it sounds like a mac for the switch..
[02:03]<dzzzzzzz>followed by daddy O of the timers
[02:03]<dzzzzzzz>Flush timer = 270 seconds
[02:04]<vcul>invalid timer is actually 180 as well
[02:04]<mrxmjum>what does this mean "and is used by the switch to initiate Layer 3 packet lookups"
[02:04]<dzzzzzzz>by default invalid is supposed to be 90
[02:04]<vcul>Mahmoud, a layer three device needs a mac. like somebody else said arp needs it to forward that packet to another router
[02:05]<gndyvx>Mahmoud: as i said before, possibly arp
[02:05]<dzzzzzzz>tkup IPX Rip yes IP rip no
[02:05]<vcul>Deranger, the weird thing is that rip didn't wait 180 seconds before reflagging that route as accessible.
[02:05]<vcul>Deranger, http://www.ciscopress.com/articles/article.asp?p=102174&seqNum=3
[02:06]<dzzzzzzz>thats weird man
[02:07]<dzzzzzzz>When I was studying RIP my understanding was RIp timer was at 90 for invalid
[02:07]<vcul>unless IOS added some feature where if the route is Connected (local int) it puts that route back in the table without waiting that long
[02:07]<vcul>Deranger, did you check ripv2?
[02:08]<dzzzzzzz>Hmm...it does make sense cause my router did show same
[02:08]<dzzzzzzz>180 180 240
[02:08]<dzzzzzzz>like the example u gave me
[02:09]<dzzzzzzz>tkup: did it have time to send out an update the route was down?
[02:09]<dzzzzzzz>maybe it never made it out?
[02:10]<dzzzzzzz>cause link-state protocols send out updates when changes happen, where as distance vector does it in intervals....
[02:10]<vcul>I did see flash triggers while debugging and those flash triggers reinstated the route. However and again, they shouldn't have reinstated it until 280s later
[02:10]<vcul>dv does have flash triggers as well
[02:10]<dzzzzzzz>RipV2 timers same
[02:10]<vcul>or should I say triggered updates
[02:14]<dzzzzzzz>I am not big fan of RIP overall
[02:15]<dzzzzzzz>I remember the first time I tried it
[02:15]<dzzzzzzz>I used a simulator and it didn't work
[02:15]<dzzzzzzz>POS lol
[02:15]<fjzvxnz-wjzc>rip is mostly outdated
[02:15]<dzzzzzzz>mostly?
[02:16]<dzzzzzzz>I think they took it out of CCIE not sure about CCNP tests
[02:16]<dzzzzzzz>I am not sure about ISDN
[02:16]<dzzzzzzz>but I know it's still present in CCNA
[02:17]<fjzvxnz-wjzc>ISDN is still in CCNA
[02:17]<fjzvxnz-wjzc>from what i hear, anyways
[02:17]<vcul>yup it is
[02:17]<dzzzzzzz>yeah but I don
[02:17]<dzzzzzzz>yeah CCNA yes, but CCIE i think they took it out
[02:17]<dzzzzzzz>I believe so
[02:18]<gndyvx>and is-is is still in the ccnp
[02:18]<gndyvx>but not in the ie
[02:19]<fjzvxnz-wjzc>is IS-IS still useful?
[02:20]<dzzzzzzz>I look at it as RIP good to know but wouldn't want to run nor support it
[02:20]<gndyvx>loather-work: absolutly
[02:20]<vcul>nemith, would you know why the hold-down timer is not respected when a link goes down and then up a few seconds later?
[02:20]<gndyvx>it has some advantages over ospf
[02:20]<vcul>in rip that is
[02:20]<gndyvx>many SPs and ISPs use IS-IS for thier IGP
[02:21]<gndyvx>tkup: i am not sure
[02:21]<dzzzzzzz>nemith: really?
[02:21]<gndyvx>tkup: debug the rip packets and find out
[02:21]<gndyvx>Deranger: oh yeah
[02:21]<dzzzzzzz>hmm I guess I underEstimated it
[02:21]<fjzvxnz-wjzc>i'm not familiar with it, so i don't really know
[02:21]<vcul>nemith: well I did yesterday and right after plugging the cable back in, it's triggered updates and route is reinstated
[02:22]<vcul>i'll play with it again tonight
[02:22]<dzzzzzzz>Well gentlemen I bid you all farewell time to bounce
[02:22]<dzzzzzzz>bye
[02:22]<vcul>yeah same here
[02:22]<vcul>off
[02:23]<gndyvx>tkup: did it say anything about a hold-down timer?
[02:24]<gndyvx>me too
[02:25]<fjzvxnz-wjzc>see y'all
[02:59]<mrxmjum>wtf
[03:14]<gndyvx>Mahmoud: tfw?
[03:17]<vcul>for some odd reason, now that I unplugged a link one hop away from the frame relay switch, rip behaved as expected (hold-down timer)
[03:17]<vcul>I don't understand why it didn't work when I broke that link that's close to the FR
[03:17]<gndyvx>hmm
[03:17]<gndyvx>interesting
[03:19]<vcul>well this is the same lab I'm trying this on: http://www.internetworkpro.org/wiki/images/a/a5/Tkuplabv5.png
[03:19]<vcul>when I break the upper left ethernet link I don't observe the rip hold-down
[03:20]<vcul>but when I break the 10.3.0.0 link, hold-down is respected
[03:21]<gndyvx>what is P0?
[03:21]<gndyvx>do a debug rip packets on the two routers and paste them to pastebin
[03:22]<vcul>it's the ethernet link e 0
[03:22]<gndyvx>ah
[03:24]<vcul>ok hold on
[03:53]<vcul>alright, this is what happens on the C4000 end: http://pastebin.com/719833
[03:54]<vcul>and the 2500's:http://pastebin.com/719834
[03:59]<gndyvx>#
[03:59]<gndyvx>00:55:44: 10.3.0.0 in 16 hops (inaccessible) <-- poision reverse :)
[04:00]<gndyvx>maybe since they both sent a requestwhen it came back up?
[04:17]<vcul>maybe since they both sent a requestwhen it came back up? <-- what kind of request?
[04:17]<vcul>are you implying that a loop occured but in this case it's *good*?
[04:17]<vcul>but it happens every time I try this. it's too much of a coincidence

Back to #cisco
Or go to some related logs:
#netbsd
#gentoo
#python
#blender
#ubuntu