From: Erick B. (erickbe@xxxxxxxxx)
Date: Thu Feb 08 2001 - 03:50:01 GMT-3
Justin and Chuck,
Was the directly connected network you had set as a
default-network a directly connected network in the
neighboring router or a IGRP learned route?
If you have:
(e1)r1(s0)----(s0)r2(s1)---(s1)r3
If s0 subnet is default-network on r1, r2 will have it
as a directly connected network - not from IGRP. No
routes will be marked as gateway of last resort on r2
since the IGRP route isn't in main routing table
because the directly connected route has a lower admin
dist. r3 would see all routes but not have a gateway
of last resort either since r2 has no IGRP route
flagged as default in its main routing table.
If e1 on r1 is default-network, and in IGRP process
then r2 will have a IGRP learned route in its table
and this will become the gateway of last resort. This
will also get passed along to r3 with r2 as next hop.
In summary, if you're using default-network statements
then the route *has* to be learned dynamically
(IGRP/EIGRP) in the main routing table for the gateway
of last resort to be set or passed on to other
neighboring routers part of the IGRP/EIGRP process.
HTH, Erick Bergquist - take 2 in May
--- Justin Menga <Justin.Menga@computerland.co.nz>
wrote:
> Hi Chuck,
>
> I just tested your theory - doesn't sound right - I
> had a connected network
> configured as a default-network, no static or
> default routes - this was
> propagated to other IGRP neighbors.........
>
> You do have to wait for the next IGRP update for
> this change to propagate -
> or you can 'clear ip route *'
>
> Regards,
>
> Justin Menga CCIE #6640 MCSE+I CCSE
> WAN Specialist
> Computerland New Zealand
> PO Box 3631, Auckland
> DDI: (+64) 9 360 4864 Mobile: (+64) 25 349 599
> mailto: justin.menga@computerland.co.nz
>
>
> -----Original Message-----
> From: Chuck Larrieu [mailto:chuck@cl.cncdsl.com]
> Sent: Wednesday, 7 February 2001 6:49 p.m.
> To: CCIE_Lab Groupstudy List
> Subject: Default routes and default networks - some
> experiments
>
>
> Trying to pare down my inbox by getting rid of
> threads I have saved for
> experimentation. This one has me, and I am ashamed
> to admit it, but I can't
> figure out why.
>
> ISIS domain ----------------------------- Other
> Protocol Domain
> Ip route 0.0.0.0 0.0.0.0 --> <- default route or
> default network depending
>
> Ok, work out the bugs in my design. Everything is
> what it should be. Now
> then....
>
> When "other domain" is RIP and I do a
> default-information originate, I can
> ping all over the place and life is good.
>
> Same thing when "other domain" is OSPF
>
> But when "other domain" is IGRP, life is hell. Pings
> go nowhere. I can get
> to the other side of the connection to the ISIS
> domain but not beyond. I can
> get from the ISIS domain to the other edge of the
> IGRP domain but not
> beyond. The candidate default route is in all of the
> IGRP router routing
> tables.
>
> Same when "other domain" is EIGRP
>
> No changes were made on the ISIS side of the fence
> during any of these
> tests.
>
> I conclude that the problem is my misunderstanding
> of the ip default-network
> mechanism. Until this moment, I had believed that
> all that was required was
> that the default network be part of the routing
> process and appear in the
> routing table. This does not appear to be true. I am
> certain this is not a
> classful / classless issue because I am only using
> classful networks
>
> Well, a bit of research, and here is what I come up
> with. I don't like it,
> if for no other reason than it has been said here
> and elsewhere that this is
> grounds for losing points in the Lab:
>
> If the default network is a directly connected
> network, then the router
> itself still needs a default route.
> So, you must have an ip route 0.0.0.0 0.0.0.0
> [network]
> And then an ip default-network [network]
>
> Only in this manner can (E)IGRP then propogate the
> default.
>
> This also explains why my grand WAN in the brokerage
> firm actually worked
> the way it was supposed to, even though I was
> running EIGRP. I had the
> 0.0.0.0 0.0.0.0 static on each and every router.
>
> Obviously there are ways around this. Route maps of
> various flavors. Policy
> routing of varying degrees of cleverness. But this
> is one hell of a "gotcha"
> / "pitfall"
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:28:41 GMT-3