From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Thu Jul 06 2006 - 19:14:49 ART
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. Sin!
ce 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 scenario with two 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 amazing how 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
> >
> >
This archive was generated by hypermail 2.1.4 : Tue Aug 01 2006 - 07:13:46 ART