Here's another way to recreate this problem. Bring up a router but leave
all interfaces down. Configure a point-to-point interface (serial, frame
relay, whatever) with the ip address 10.1.1.1. Then add:
ip route 10.50.50.50 255.255.255.255 10.1.1.2
ip route 10.0.0.0 255.0.0.0 null0
Then, do show ip route 10.50.50.50. You will still see it reachable via
10.1.1.2! why? Because this router thinks that 10.1.1.2 is still reachable
via null0. It's not realizing that 10.1.1.2 is at the other end of a dead
point-to-point link and it could not possibly be up and running.
If I had my druthers (not DRothers <g>), the router would not behave this
way. The problem it created in our network was only resolvable by turning
off classless routing, which is okay for us, but not for everyone.
Hmm...I just discovered something interesting. If you replace the static
route for 10.0.0.0 with a default route, 0.0.0.0/0 pointing to null0, this
problem does not occur. Weird. So, the addition of a default route does
not cause this behavior, but the addition of a supernet route does. In
classless routing, why does it really matter?
It seems to me that a supernet is a supernet is a supernet. Isn't a default
route just the ultimate supernet route?
Okay, more research needed...
> I believe you have a default route or gateway of last resort set
> I could not get the routes in my table until I added a default route
> Duck
> here is the config
> Current configuration:
> !
> version 12.0
> service timestamps debug uptime
> service timestamps log uptime
> no service password-encryption
> !
> hostname Router
> !
> !
> ip subnet-zero
> !
> !
> process-max-time 200
> !
> interface Ethernet0
> no ip address
> no ip directed-broadcast
> shutdown
> !
> interface Serial0
> ip address 172.16.10.1 255.255.255.252
> no ip directed-broadcast
> no ip mroute-cache
> shutdown
> !
> router ospf 6
> !
> router bgp 65001
> !
> ip classless
> ip route 0.0.0.0 0.0.0.0 172.16.10.2
> ip route 192.168.1.64 255.255.255.240 Null0
> ip route 192.168.92.0 255.255.255.255 192.168.1.65
> ip route 200.168.1.16 255.255.255.240 192.168.92.65
> ip ospf name-lookup
> !
> !
> line con 0
> exec-timeout 0 0
> transport input none
> line vty 0 4
> login
> !
> end
>
> Router#
> Router#
> Router#
> Router#sh ip route
> Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
> D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
> N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
> E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
> i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate
default
> U - per-user static route, o - ODR
>
> Gateway of last resort is not set
>
> 192.168.92.0/32 is subnetted, 1 subnets
> S 192.168.92.0 [1/0] via 192.168.1.65
> 192.168.1.0/28 is subnetted, 1 subnets
> S 192.168.1.64 is directly connected, Null0
> ----- Original Message -----
> From: John Neiberger <[EMAIL PROTECTED]>
> To: JZ <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Monday, February 05, 2001 8:48 AM
> Subject: Re: Extremely Odd Routing resolved, sort of...
>
>
> > 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]
_______________________________________________________
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]
