From: Faryar Zabihi \(fzabihi\) (fzabihi@cisco.com)
Date: Thu Jul 06 2006 - 20:15:34 ART
You should have a router off...if things aren't settled just give each other a
hug and remember...u are doing this for the children.
-----Original Message-----
From: Narbik Kocharians [mailto:narbikk@gmail.com]
Sent: Thursday, July 06, 2006 07:10 PM Eastern Standard Time
To: Brian McGahan
Cc: ccielab@groupstudy.com
Subject: Re: RIP triggered (long)
Brian, you went around the world and ended up with what i was saying to
begin with, i was saying that, this is implemented by Cisco to suppress the
updates on slow WAN connections, and you are repeating what i was saying to
begin with, by the way i did not trick the IOS in running the command on a
multipoint interface, all i did was i entered the command and tested the
configuration, actually this is the first or the second reason that Cisco
stated in their documentation, if you are talking about a valid design, to
me this is a very good design, once you run it on the BRI interface it
freezes the updates unless there is a change in the topology. Here we can
both add this one when ISDN comes back into the game.
Trust me i do have an understanding of the basics i have done this when some
of the people were wearing diapers. But the problem is that you want me to
see it your way, but i still say the URL is correct. What you are mentioning
here is also true, but that has nothing to do with what the discussion ended
up to be, you asked me to show you the config, and when i showed you the
config, you said it was not a valid design.
Anyway i agree with your partner, i think we are getting into the you said i
said zone, and i don't wish to be there.
Narbik Kocharians
CCIE# 12410 (R&S, SP, Security)
CCSI# 30832
Network Learning, Inc. (CCIE class Instructor)
www.ccbootcamp.com (CCIE Training)
On 7/6/06, Brian McGahan <bmcgahan@internetworkexpert.com> wrote:
>
> Narbik,
>
> You're missing the point of the original question. The question
> was "ip rip triggered command is not under ethernet interface ? is there
any
> speific reason for not having it ?" The answer to this is yes, there is a
> specific reason, and this reason does not conflict with the
> documentation. Understanding why the feature works this way first requires
> an understanding of the fundamental difference between multipoint and
> point-to-point configurations.
>
> Per CCO:
> <cco>
> When triggered extensions to RIP are enabled, routing updates are sent on
> the WAN only if one of the following events occurs:
> -The router receives a specific request for a routing update. (Full
> database is sent.)
> -Information from another interface modifies the routing database. (Only
> latest changes are sent.)
> -The interface comes up or goes down. (Partial database is sent.)
> -The router is first powered on, to ensure that at least one update is
> sent. (Full database is sent.)
> </cco>
>
> This is compliant per RFC 2091:
>
> <rfc 2091>
> In Triggered RIP, routing updates are only transmitted on the WAN
> when required:
>
> 1 When a specific request for a routing update has been received.
>
> 2 When the routing database is modified by new information from
> another interface.
>
> 3 When the circuit manager indicates that a destination has changed
> from an unreachable (circuit down) to a reachable (circuit up)
> state.
>
> 4 And also when a unit is first powered on to ensure that at least
> one update is sent. This can be thought of as a transition from
> circuit down to circuit up. It MAY contain no routes or services,
> and is used to flush routes or services from the peer's database.
> </rfc 2091>
>
> Your description of the feature being used to limit updates on the
> link to conserve bandwidth is correct; that point is not in question. What
> is in question is your understanding and explanation of the implication of
> point 3 of the RFC that is used to track neighbor reachability. Under
> normal RIP operation neighbor reachability is tracked, like you said,
> through the usage of the invalid timer. If an update is not received
within
> a certain period of time the destination reachable through that neighbor is
> withdrawn. With triggered RIP this is not the case however.
>
> In order to reduce the amount of updates sent the above four rules
> are followed. This implies that the invalid timer no longer comes in to
> play. Furthermore this means that a route can only be withdrawn from the
> routing table if:
>
> 1. a triggered update is received that poisons the route
> 2. the link connecting to the neighbor goes down which causes all routes
> through that neighbor to be withdrawn
>
> Case 1 would only occur if there was a network failure upstream of
> the directly connected link between the two neighbors in question. Case 2
> would only occur if the layer 2 protocol between the neighbors was capable
> of report a link down event. This case is described as the "circuit
> manager" in the RFC. In point-to-point configurations the "circuit
manager"
> is always able to satisfy this requirement. HDLC uses its own keepalive,
> PPP uses LCP, point-to-point Frame Relay interfaces use LMI status, etc.
In
> multipoint configurations this is rarely the case, which in turn prevents
> the usage of RIP triggered on those links.
>
> Take for example the following topology:
>
> Net_X--R1--Switch1--R2
>
> R1 advertises Net_X to R2 via RIP over the Ethernet segment
> connecting them. While R1 and R2 are in the same logical broadcast domain,
> the physical link between them is terminated at Switch1. If triggered
> extensions for RIP run over this link R2 will not be using the invalid
timer
> to keep track of the routes learned from R1. Now suppose that R1's
Ethernet
> interface fails. While this will affect the link status between R1 and
> Switch1, it will not affect the link status between Switch1 and R2. Now we
> run into a case where R2 cannot detect that the Net_X prefix should be
> removed from the routing table because 1. no one sent a triggered update
> about it, and 2. the "circuit manager" cannot accurately determine that a
> link failure has occurred between the neighbors.
>
> Take the same case over multipoint Frame Relay:
>
> Net_X--R1--Frame_Cloud--R2
>
> R1 advertises Net_X to R2 via RIP over the Frame Relay segment
> connecting them. While R1 and R2 are connected by the same logical virtual
> circuit the physical link between them is terminated by their local Frame
> Relay providers. If triggered extensions for RIP run over this link R2
will
> not be using the invalid timer to keep track of the routes learned from
> R1. Now suppose that there is a failure of the Frame Relay circuit
anywhere
> in the cloud besides the local link between R2 and the Frame cloud. If R2
> is using its main interface it cannot detect that R1 is unreachable, and
> hence cannot detect that the Net_X prefix should be removed from the
routing
> table. This is due to the fact that the main interface tracks the overall
> LMI keepalive from the Frame Relay cloud, not the individual circuit
> status. Even though the circuit between R1 and R2 is "inactive" (assuming
> that LMI is end-to-end in the first place) the line protocol of the Serial
> interface will remain up. Since the line protocol of the Serial interface
> is up the routing process will be able to perform route recursion to the
> next hop value (which recurses to the Serial interface) and will in turn
> continue to believe that the installed RIP routes are valid. The same
would
> be true with a main BRI interface since it is spoofed as UP/UP regardless
of
> the active call status.
>
> Now take the above design and use a point-to-point link between
> them. If the link were a point-to-point Serial interface running HDLC or
> PPP a failure of the remote end of the link on R1 would cause the interface
> of R2 to be either UP/DOWN or DOWN/DOWN, which would in turn prevent the
> next hop of the RIP routes to be able to be recursed to, which would in
turn
> invalidate them in the RIP database, which would in turn cause R2 to issue
a
> triggered update withdrawing them. If the link were a point-to-point
Frame
> Relay subinterface an LMI status of INACTIVE or DELETED would cause the
line
> protocol of the subinterface to go down, hence ultimately causing the RIP
> routes to be withdrawn.
>
> Now whether you can trick the IOS into running the feature on a
> multipoint interface is not the point. The design goal of the feature is
to
> reduce the amount of routing updates required on an interface, but not at
> the expense of lack of accuracy of the routing table. So in other words,
no
> the feature does not work on multipoint interfaces.
>
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
> 24/7 Support: http://forum.internetworkexpert.com
> Live Chat: http://www.internetworkexpert.com/chat/
>
> ________________________________________
> From: Narbik Kocharians [mailto:narbikk@gmail.com]
> Sent: Thursday, July 06, 2006 4:26 PM
> To: Brian McGahan
> Subject: Re: RIP triggered
>
>
> My friend Brian, let's not jump from one subject to another, since when
> any of these commands are implemented in a good design? Would you use RIP
in
> a good design? Please say NO.
> The discussion was that DOES IT WORK IN A MULTIPOINT configuration, and i
> am telling you that the answer is YES, it bloody works, and it works fine,
> now if you want to talk about designing a good network that is a different
> subject, we can do that.
> But to answer your question, i tested the scenariowithtwo routers
> connected and if both ends have the "ip rip triggered" command and one of
> their directly connected routes go down, they will trigger an update.
> But if you read the URL, it does exactly what Cisco states. I can't
> understand why you guys would argue with the documentation; don't you think
> these guys know something? I know there are some mistakes but this is not
> one of them.
>
> You and your partner are both knowledgeable and very well educated in this
> arena, and its amazinghow you guys come up with detailed explanation for
> some of the questions that people have regarding your work books, i love
> some of the explanations,but that does not change the fact and as far as i
> am concerned Cisco's URL is correct and the command may not work in all
> Multipoint configurations but it does on some.
>
> Narbik Kocharians
> CCIE# 12410 (R&S, SP, Security)
> CCSI# 30832
> Network Learning, Inc. (CCIE class Instructor)
> www.ccbootcamp.com (CCIE Training)
>
>
>
> On 7/6/06, Brian McGahan <bmcgahan@internetworkexpert.com> wrote:
> Just because it takes the command does not mean it is a valid
> design.Suppose you are dialing in a hub-and-spoke fashion and running
> triggered RIP.What happens on the hub when one of the spokes
> disconnects?Does it withdraw the routes learned from that spoke or not?
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
> 24/7 Support: http://forum.internetworkexpert.com
> Live Chat: http://www.internetworkexpert.com/chat/
>
> ________________________________________
> From: Narbik Kocharians [mailto:narbikk@gmail.com]
> Sent: Thursday, July 06, 2006 3:36 PM
> To: Sami
> Cc: wayne@ipexpert.com; Brian Dennis; Brian McGahan;
> ccielab@groupstudy.com; smorris@ipexpert.com
> Subject: Re: RIP triggered
>
> Router(config)#int bri0/0
> Router(config-if)#ip addr 1.1.1.1 255.0.0.0
> Router(config-if)#ip rip tr
> Router(config-if)#ip rip triggered
>
> Mr. Brian McGahan,I think this is a multipoint, don't you?
> But I still say thatCisco implemented this to suppress the updates on slow
> links just like the url from Cisco states.
> I kinda agree with Scott, because what he says is that we are looking at
> this from different angles, and maybe he is correct. The only reason I
> disagree is that it works on some Multipoint interfaces and does not work
on
> others.
>
> interface BRI0/0
> ip address 1.1.1.2 255.0.0.0
> ip rip triggered
> dialer map ip 1.1.1.1 broadcast 1111031
> dialer-group 1
> isdn switch-type basic-ni
> isdn spid1 11110410101
> isdn spid2 11110420101
>
> Do you guys see the "ip rip triggered" command??????????????????????????
>
> But I truly believe that we have totally killed the subject. By the way
> Wayne when you took your CCIE lab was it three days or four days? (Just
> kidding).
>
>
> Narbik Kocharians
> CCIE# 12410 (R&S, SP, Security)
> CCSI# 30832
> Network Learning, Inc. (CCIE class Instructor)
> www.ccbootcamp.com (CCIE Training)
>
> On 7/6/06, Sami < sy1977@gmail.com> wrote:
> Guys,
>
> I didn't know that a small RIP triggred command will trigger such a huge
> discussion which will involve all the so called CCIE Guru's.
>
> Why I asked this IE workbook VOL2 lab 5 section 3.5 ask for this command
> on a ethernet interface because both the routers are connected with other
on
> ethernet interface.I couldn't find this command on ethernet interface
> hence I fired this question to group. IE team please review your VOL2labs ,
> I found lot of mistakes in VOL2 workbook which are notin syncwith
> labtopology.
>
> Narbik , Scott, Brians's thank you very much.
>
> -Sami
>
>
>
>
>
> On 7/6/06, Wayne Lawson <wayne@ipexpert.com > wrote:
> Geeesh.....When I took the lab (back in the good ol' days) RIP was only a
> few points -grin-, thus - not that big of a deal....Now we've got 2 triple
> IE's, a quad IE and another very intelligent engineer bickering about
> RIP.....I guess the lab's getting harder! -huge grin-
>
> Wayne A. Lawson II
> Founder, President & CCIE #5244 - IPexpert, Inc.
> "When Will You Be an IP Expert?!"
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto: nobody@groupstudy.com] On Behalf Of
> Brian Dennis
> Sent: Thursday, July 06, 2006 1:46 PM
> To: Narbik Kocharians; Brian McGahan
> Cc: Sami; ccielab@groupstudy.com
> Subject: RE: RIP triggered
>
> Did you try putting an IP address on the physical interface or multipoint
> subinterface before testing?See below:
>
> Rack1R1(config)#int s0/0
> Rack1R1(config-if)#encap frame-relay
> Rack1R1(config-if)#ip rip triggeredb no problem since there isnbt an IP
> address assigned
> Rack1R1(config-if)#ip add 167.1.1.1 255.255.255.0
> Rack1R1(config-if)#ip rip triggered
> RIP: Serial0/0 is not a point-to-point interface.
>
> Rack1R1(config-if)# int s0/0.2 multipoint
> Rack1R1(config-subif)#ip rip triggered b no problem since there isnbt
> an
> IP address assigned
> Rack1R1(config-subif)#ip address 10.10.10.1 255.255.255.0
> Rack1R1(config-subif)#ip rip triggered
> RIP: Serial0/0.2 is not a point-to-point interface.
>
>
> HTH,
>
> Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
> bdennis@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987
> Direct: 775-745-6404 (Outside the US and Canada)
>
>
>
> From: Narbik Kocharians [mailto:narbikk@gmail.com ]
> Sent: Thursday, July 06, 2006 10:33 AM
> To: Brian McGahan
> Cc: Brian Dennis; Sami; ccielab@groupstudy.com
> Subject: Re: RIP triggered
>
> There are someB vendors that implement RFCs and some that don't, Cisco
> decided to implement the RFC for the reason i mentioned and thats why its
> available on WAN and not LAN interfaces.
> You mean that the "ip rip triggered"B command does not suppress the
> updates
> so it does not consume BD? I guess this guys in CiscoB did not test it as
> well?
> B
>
>
http://www.cisco.com/en/US/products/sw/iosswrel/ps1830/products_feature_guid
> e09186a008008746f.html
> B
> By the way you stated thatB this command isB not supported on multipoint,B
> i
> have to totally disagree with that as well. When you configure frame-relay
> directly under the physical interface, isn't that considered a multipoint?
> Therefore, it's not an issue of P2P Vs Multipoint, itsB LAN versus WAN.
> B
> Narbik Kocharians
> CCIE# 12410 (R&S, SP, Security)
> CCSI# 30832
> Network Learning, Inc. (CCIE class Instructor)
> www.ccbootcamp.com (CCIE Training)
>
> B
> On 7/6/06, Brian McGahan < bmcgahan@internetworkexpert.com> wrote:
> B B B B B BTriggered extensions to RIP are not a Cisco specific feature;
> they are defined in RFC 2091.
>
> http://www.internetworkexpert.com/rfc/index.php?rfc=2091
>
> B B B B B BIf you read through the RFC and tested the behavior you would
> see that your explanation is not correct.
>
> B B B B B BRoutes in the RIP database learned on an interface running
> triggered extensions behave like DNA LSAs in the OSPF database.B B In
> other words the invalid timer does not apply to them.B B Instead RIP
> relies on the point-to-point nature of the WAN link to invalidate
> installed updates when the link goes down.
>
> B B B B B BAs Brian pointed out this configuration is not valid on
> multipoint interfaces because the layer 1 status of the interface does
> not necessarily reflect end-to-end reachability on the segment, i.e . one
> side of the link can be up while the other side is down.
>
>
>
> HTH,
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
> 24/7 Support: http://forum.internetworkexpert.com
> Live Chat: http://www.internetworkexpert.com/chat/
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > Narbik Kocharians
> > Sent: Thursday, July 06, 2006 11:47 AM
> > To: Brian Dennis
> > Cc: Sami; ccielab@groupstudy.com
> > Subject: Re: RIP triggered
> >
> > RIP does not care if the other end point is down or not, if RIP does
> not
> > receive the updates from a router on a point-to-point or multipoint
> > interface, it has two timers that it will use to handle that
> situation,
> > invalidation timer and Flush timer.
> >
> > There are two reasons that Cisco came up with this extension:
> >
> > The periodic updates (every 30 seconds be default) can keep the
> circuit
> > up,
> > and the second reason is to cut down on the number of periodic updates
> > even
> > on a Point-to-point connections.
> > Its because of these two points that the command "ip rip triggered" is
> > only
> > available on the wan interfaces and it has nothing to do with neighbor
> > down
> > detection, it has provisions for that already. I am sorry but I have
> to
> > disagree.
> >
> > Narbik Kocharians
> > CCIE# 12410 (R&S, SP, Security)
> > CCSI# 30832
> > Network Learning, Inc. (CCIE class Instructor)
> > www.ccbootcamp.com (CCIE Training)
> >
> >
> > On 7/6/06, Brian Dennis <bdennis@internetworkexpert.com > wrote:
> > >
> > > Think about it like this.B B If you run RIP triggered across a P2P
> serial
> > > link and the remote end goes down, your local interface should also
> go
> > > down.B B This will allow your local router to detect that the remote
> > > router's routes should be removed from the routing table.B B Now if
> it's a
> > > multipoint interface like Ethernet (more than one endpoint possible)
> > > then if the remote router goes down, the Ethernet interface will not
> > > normally go down assuming a hub or switch is being used.B B This means
> > > that even though the remote router is down, its routes will not be
> > > removed from your local router's routing table since you are not
> > > expecting periodic updates and you can not determine based on the
> > > interface state if the remote router is down.
> > >
> > > HTH,
> > >
> > > Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
> > > bdennis@internetworkexpert.com
> > >
> > > Internetwork Expert, Inc.
> > > http://www.InternetworkExpert.com
> > > Toll Free: 877-224-8987
> > > Direct: 775-745-6404 (Outside the US and Canada)
> > >
> > >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto: nobody@groupstudy.com] On Behalf
> Of
> > > Sami
> > > Sent: Thursday, July 06, 2006 4:56 AM
> > > To: ccielab@groupstudy.com
> > > Subject: RIP triggered
> > >
> > > Group,
> > >
> > > ip rip triggered command is not under ethernet interface ? is there
> any
> > > speific reason for not having it ?
> > >
> > > R4(config)#int fastEthernet 0/0
> > > R4(config-if)#ip rip ?
> > > advertiseB B B B B BSpecify update interval
> > > authenticationB B Authentication control
> > > receiveB B B B B B B Badvertisement reception
> > > sendB B B B B B B B B B B B advertisement transmission
> > > v2-broadcastB B B B send ip broadcast v2 update
> > >
> > > R4(config)#int s0/0/0
> > >
> > > R4(config-if)#ip rip ?
> > > advertiseB B B B B BSpecify update interval
> > > authenticationB B Authentication control
> > > receiveB B B B B B B Badvertisement reception
> > > sendB B B B B B B B B B B B advertisement transmission
> > > triggeredB B B B B Benable rfc2091 triggered rip
> > > v2-broadcastB B B B send ip broadcast v2 update
> > >
> > >
> _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Tue Aug 01 2006 - 07:13:46 ART