Ok, this is completely baking my noodle. If someone can solve this, I will
fly to your location and kiss you on the forehead.
Here is the layout: RouterA has two frame relay PVCs, point to point, that
go to router B. EIGRP is running on one link but not the other. (RIP is
running on routerA but is not currently being used on any links.) We have
static routes for the traffic we want to take the second PVC. At router A I
have the following:
ip route 10.2.50.70 255.255.255.255 10.2.70.75 50
ip route 10.2.50.70 255.255.255.255 10.1.111.60 100
ip route 10.0.0.0 255.0.0.0 Null0 (don't ask why this is here, it just is
<g>)
10.2.50.70 is the loopback address of router B, and 10.2.70.75 is the IP
address at Router B's second PVC. 10.1.111.60 is the secondary dial backup
route. So far, so good. Now for the part that is completely freakin' me
out.
The entire circuit at A that has the second PVC to B goes down, and
subsequently all PVCs on that circuit go down. The main circuit and its
associated PVCs are still up. Remember, eigrp is running on this link.
So...
10.2.70.75 is no longer available, that PVC is down. That static route is
removed from the routing table. There should now be an eigrp-learned route
with an AD of 90 for 10.2.50.70 on the main PVC. This is NOT happening! I
do a show ip route 10.2.50.70 and I get the following:
RouterA#show ip route 10.2.50.70
Routing entry for 10.0.0.0/8
Known via "static", distance 1, metric 0 (connected)
Redistributing via eigrp 1, rip
Advertised by eigrp 1
rip
Routing Descriptor Blocks:
* directly connected, via Null0
Route metric is 0, traffic share count is 1
The secondary static route is also not in use because in this scenario, the
remote branch circuit is not completely down, and dial backup has not
occured. All of their other PVCs are up.
Now, take a look at this:
RouterA#sho ip eigrp topo 10.2.50.0 255.255.255.0
IP-EIGRP topology entry for 10.2.50.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2297856
Routing Descriptor Blocks:
10.2.10.75 (Serial1/1.27), from 10.2.10.75, Send flag is 0x0
Composite metric is (2297856/128256), Route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 25000 microseconds
Reliability is 255/255
Load is 12/255
Minimum MTU is 1500
Hop count is 1
There is a valid route in the topology table, but it is not being entered
into the routing table. Why not? Why is it choosing the less specific
10.0.0.0/8 route to Null0? Ok, now it gets even stranger...
Remember the static routes, one with an AD of 50 and the other with an AD of
100? Once I removed them manually by typing no ip route 10.2.50.70 etc.,
the valid route in the eigrp topology table was entered into the routing
table. What difference does this make? Those static routes weren't even
being used because the next hop addresses were unreachable. Why did the
router wait for me to remove them manually before it entered the dynamically
learned route into the table?
I just do not understand this behavior, and it is certainly not what I would
expect. I have a couple of guesses, but I can't follow them to any logical
conclusion.
Might this have something to do with the fact that the primary route is a
static host route and not a route for a specific subnet? Might this behave
differently if I change the static route to 10.2.50.0 255.255.255.0? Then
it would match exactly to the route available in the topology table. I
don't see why that matters, but who knows...
Also, RIP is being redistributed into eigrp. We haven't finished
implementing RIP yet, but it is configured on routerA. We will be adding
some 675 model routers later and they can only do RIP. I don't see how this
would affect things, but perhaps it is.
Please, please, someone....help me before my brain completely melts down!
Many thousands of 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]
