Thanks, you nailed the problem exactly! I'm not sure if that behavior is
good or bad, but I know that in my case it is bad. Since we don't need
classless routing on this router, we turned it off, but I wish there were a
better solution.
My preference would be for the router to remove all static routes pointing
to next-hop addresses at the other side of directly attached interfaces that
are down, even if it thinks that network is reachable via another route. If
the link is point-to-point, the network is absolutely unreachable, so why
not treat it as such?
Anyone else have thoughts about this?
> As we all know, when we configure a static IP route, the next hop IP
> address should be a host IP address of a directly connected network (or
an
> exit interface number). for example, in Windows NT or Netware systems,
if
> your system is connected to, say, network 192.168.50.0/24, and you try
to
> add a static IP route, say, 192.168.60.0/24 with a next hop IP address
> 192.168.53.x. you will get an error message. Am I right?
> If you are thinking this will be the same in Cisco IOS, you could be
wrong.
> Try to turn on you router (just one router is enough), and leave all you
> interface down. Then typing in the following lines
>
> IP route 200.168.1.16 255.255.255.240 192.168.92.65
> IP route 192.168.92.0 255.255.255.255 192.168.1.65
> IP route 192.168.1.64 255.255.255.240 Null 0
>
> Note that, none of the router's interface is connected to any of the
network
> numbers shown in the configuration (of course, except the null 0
interface).
>
> Now try a 'show IP route'. You will get the following lines
>
> s 200.168.1.16/28 via 192.168.92.65
> s 192.168.92.0/24 via 192.168.1.65
> s 192.168.1.64/28 is directly connected, null0
>
> This experiment approved that IOS will keep a static route in its routing
> table as long as it thinks there is a 'live' path to that network, even
that
> 'live' path will lead to a dead null interface. and it really does not
care
> where the next hop IP address is located in the entire network as long
as
> that hop is 'reachable' according to its own routing table.
>
> Is this a good thing, bad thing or an IOS Bug???
>
> However, this explains John's problem very well. Even when the PVC is
down
> the route entry
> 'S 10.50.1.1 255.255.255.255 via 10.1.1.2'
> will be still in routing table, because the next hop address 10.1.1.2 is
> still reachable via
> 'S 10.0.0.0 255.0.0.0 is directly connected Null0'
>
> Could anyone explain how John's problem would be fixed without turning
off
> 'IP classless' and still keep the
> 'IP route 10.0.0.0 255.0.0.0 Null0' entry in the routing table?
>
> JZ
>
> "John Neiberger" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > Ok, to recap, here was the problem. We have two PVCs from router A to
> > router B. We have eigrp running on the first PVC but not on the
second,
> and
> > there are static routes forcing certain traffic to use the second PVC.
> > These are point-to-point frame relay links. Here are the relevant
static
> > routes affecting the second PVC, and let's assume the loopback address
at
> > the router B is 10.50.1.1:
> >
> > ip route 10.50.1.1 255.255.255.255 10.1.1.2 50
> >
> > We also have another static route for an entirely separate reason, but
it
> is
> > involved here, as well:
> >
> > ip route 10.0.0.0 255.0.0.0 Null0
> >
> > We recently upgraded to 12.1 from 11.2. In 11.2, "no ip classless" was
> the
> > default. In 12.x, ip classless is the default.
> >
> > We thought that if the second PVC went down, since the next hop was
> > unavailable, the router would pick the next available route with a
higher
> > administrative distance. Since there is a valid route to router B over
> the
> > first PVC, we thought it would take this route. The odd thing was, it
> > wasn't and we didn't know why. Here's why:
> >
> > Even though 10.1.1.2 was at the other end of a point-to-point link and
> shows
> > in the routing table as directly connected, the router never realized
that
> > that route disappeared! When the PVC was down, if I did a show ip
route
> > 10.50.1.1, it would show as reachable via 10.1.1.2. Then a show ip
route
> > 10.1.1.2 would show that it was reachable thanks to the 10.0.0.0 route
> > pointing to null0. Isn't that freaky??
> >
> > I assumed that the router would be smart enough to know that if a point
to
> > point link is down, the remote IP address is truly unreachable, even if
> > there is valid supernet route; apparently, such is not the case. I
did
> > some testing and proved to myself that this is what was happening.
> >
> > So, since we don't require classless routing on this router, I've
turned
> it
> > off. Now, the router will not use the 10.0.0.0 supernet route and it
will
> > correctly decide that the point to point link is down. Then, it will
use
> > the eigrp-learned route on the other PVC.
> >
> > If someone understands why a router would choose a supernet route to
reach
> a
> > directly attached down interface, please let me know. I'm sure this
will
> > come up later!
> >
> > Thanks,
> > John
> >
> >
> >
> >
> >
> > _______________________________________________________
> > Send a cool gift with your E-Card
> > http://www.bluemountain.com/giftcenter/
> >
> >
> > _________________________________
> > FAQ, list archives, and subscription info:
> http://www.groupstudy.com/list/cisco.html
> > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
> >
>
>
> _________________________________
> FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
_______________________________________________________
Send a cool gift with your E-Card
http://www.bluemountain.com/giftcenter/
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
