John,
By default EIGRP does auto-summarization.  This cause a NETWORK statement to
be all inclusive.  And any route it learns about to classfull it (regardless
of a no classfull statement).  Even if you place the network statement in
each classless masking you still summarize.   Therefore, the EIGRP will
place any routes it does not know about as learned via NULL0.  Try using a
no auto summary and review your routers passive statements.

>  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>)

This is VERY CLEARLY a summarization.  EIGRP Summarizes by DEFAULT without
the no auto summary.  Please let me know if this helps.

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
John Neiberger
Sent: Thursday, February 01, 2001 5:27 PM
To: [EMAIL PROTECTED]
Subject: Re: Extremely Strange Routing Problem! (update)


More info.  The router does not appear to realize that the "directly"
connected next-hop address is unreachable.

RouterA#sho ip route 10.2.7.75
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

So, even though the interface directly connected to the next-hop address is
down, it thinks it is still reachable via a static routing pointing to
Null0, a connected interface.  Does this seem irrational to anyone but me??
If the next hop is down but there is a valid next-hop in the eigrp topology
table, I want it to take that route, not the default route!  Dang it all!
:-)

I still don't understand this behavior at all, but perhaps this will provide
a clue to some of you.

Going insane,
John

>  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]





_______________________________________________________
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]

Reply via email to