From: Scott Morris (swm@emanon.com)
Date: Thu Jul 06 2006 - 14:40:13 ART
Brian Dennis's reasoning behind why it is not available on multipoint
interfaces is correct... But beyond that, I think Narbik was talking about
the reason WHY the extensions were created (which if I remember right, they
were created by some folks from Shiva (remote access gods back in the day)).
And the reason WHY was more due to slow-speed dial-up circuits and not
wanting to keep those lines up all the time.
Yes, what happens is a DNA similar to OSPF Demand Circuit (amazing
similarities). And this really only makes sense (logically) to do on a P2P
circuit, hence the command only being available there.
While it was entertaining to read all the messages, I think that all of you
are right, but not necessarily relating to what the other person is saying!
Brian Dennis's response to the original question though DID answer why it
wasn't available on multipoint interfaces, it just may have been a bit
clearer IMHO.
RFCs most certainly always have the answers although they're boring to read.
But I'd suggest looking at the introduction/overview sections, because
you'll find in there the exact reasons that Narbik spelled out for why they
were created.
Also:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120
t/120t1/trigrip.htm
"Entries in the routing database can be either temporary or semi-permanent.
Entries learned from broadcasts on LANs are temporary; they will expire if
not periodically refreshed by more broadcasts.
Entries learned from a triggered response on the WAN are semi-permanent;
they do not time out like other entries. Certain events can cause these
routes to time out, such as the interface going down, or if the outgoing
interface is the same as the incoming interface. Neighbor updates of the
routes with a metric of 16 (infinity) mean the route is unreachable, and
those routes are eventually removed from the routing table."
HTH,
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE
#153, CISSP, et al.
CCSI/JNCI-M/JNCI-J
smorris@ipexpert.com
http://www.ipexpert.com
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Brian McGahan
Sent: Thursday, July 06, 2006 1:14 PM
To: Narbik Kocharians; Brian Dennis
Cc: Sami; ccielab@groupstudy.com
Subject: RE: RIP triggered
Triggered extensions to RIP are not a Cisco specific feature; they
are defined in RFC 2091.
http://www.internetworkexpert.com/rfc/index.php?rfc=2091
If you read through the RFC and tested the behavior you would see
that your explanation is not correct.
Routes in the RIP database learned on an interface running triggered
extensions behave like DNA LSAs in the OSPF database. In other words the
invalid timer does not apply to them. Instead RIP relies on the
point-to-point nature of the WAN link to invalidate installed updates when
the link goes down.
As 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. If you run RIP triggered across a P2P
serial
> > link and the remote end goes down, your local interface should also
go
> > down. This will allow your local router to detect that the remote
> > router's routes should be removed from the routing table. 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. 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 ?
> > advertise Specify update interval
> > authentication Authentication control
> > receive advertisement reception
> > send advertisement transmission
> > v2-broadcast send ip broadcast v2 update
> >
> > R4(config)#int s0/0/0
> >
> > R4(config-if)#ip rip ?
> > advertise Specify update interval
> > authentication Authentication control
> > receive advertisement reception
> > send advertisement transmission
> > triggered enable rfc2091 triggered rip
> > v2-broadcast send ip broadcast v2 update
> >
> >
This archive was generated by hypermail 2.1.4 : Tue Aug 01 2006 - 07:13:46 ART