From: mikey (mikey@xxxxxxxxxxxxxx)
Date: Fri Feb 09 2001 - 08:25:43 GMT-3
Something interesting (at least I thought so) that I stumbled on the the lab
via a typo. You can create a 0.0.0.0 0.0.0.0 default route in EIGRP.
Create a summary address of 0.0.0.0 0.0.0.0 It propagates thru the network
and works great.
mikey
----- Original Message -----
From: Chuck Larrieu <chuck@cl.cncdsl.com>
To: Justin Menga <Justin.Menga@computerland.co.nz>; <erickbe@yahoo.com>;
CCIE_Lab Groupstudy List <ccielab@groupstudy.com>
Sent: Thursday, February 08, 2001 12:01 PM
Subject: RE: Default routes and default networks - some experiments
> Sorry, I was too tired the other night to post configs or the doc CD
> reference that talks about this.
>
> Under (E)IGRP, an ip default-network must be configured. If that network
is
> part of the (E)IGRP routing process, then that route appears as the
> candidate default throughout the (E)IGRP domain. If the default network is
> directly connected, then additionally, the edge router ( the one on which
> the ip default-network is configured ) also requires a static route, so
that
> the router has some place to route.
>
> I don't believe it is correct that if you have (E)IGRP as your routing
> protocol that you cannot use 0.0.0.0 0.0.0.0 You can do so on each and
> every router in the (E)IGRP domain and reach the places you want to reach.
>
> BTW, as part of this process I rediscovered my problem with the phantom
> statics in IGRP when entering the ip default-network command.
>
> In my case, the connection between the two domains was 100.100.100.0/24
>
> After entering the ip default-network command I had not only the default
> net but also a static
> Ip route 100.0.0.0 255.0.0.0 100.100.100.0
>
> According to the documentation CD, this is expected behaviour.
>
> The problem at its root is that neither IGRP nor EIGRP support the
> default-originate command, which every other routing protocol does
support.
> A rather interesting oversight / construction / design. I have to wonder
> what folks were thinking when they did things this way.
>
> In terms of CCIE Lab preparation, I believe it is well known and well
> understood that candidates will often find themselves in situations where
> they have to propagate default information without resorting to static
> routes. I can imagine a situation where one must somehow do that, and the
> conditions are similar to what I had set up - a directly connected VLSM
> network. Hence leading to the phantom statics, panic on the part of the
> candidate, and a lot of time spent trying to eliminate the "phantom
static"
> . leaving one discombobulated and short on time to address other issues.
>
> NOTE: at the time of this writing I have NOT been in the Lab, and
therefore
> cannot be violating NDA. I am speculating based on my discoveries and
> frustration in my own studies. The NDA police need not be concerned. :->
>
> Chuck
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Justin Menga
> Sent: Thursday, February 08, 2001 3:15 AM
> To: 'erickbe@yahoo.com'; Justin Menga; 'Chuck Larrieu'; CCIE_Lab
Groupstudy
> List
> Subject: RE: Default routes and default networks - some experiments
>
> Yep, I agree, this is what I found......the way that IGRP marks a
> default-network is by marking the route as an EXTERIOR route. So if in
the
> scenario below R1 (S0) is the default network, of course R1 never sends
this
> route to R2 (as it is the local connected network), hence R2 doesn't
receive
> an EXTERIOR 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
> web: http://www.computerland.co.nz
>
>
> -----Original Message-----
> From: Erick B. [mailto:erickbe@yahoo.com]
> Sent: Thursday, 8 February 2001 7:50 p.m.
> To: Justin Menga; 'Chuck Larrieu'; CCIE_Lab Groupstudy List
> Subject: RE: Default routes and default networks - some experiments
>
>
> 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:43 GMT-3