From: Pat Chui (cui666@gmail.com)
Date: Mon Mar 28 2005 - 04:29:03 GMT-3
Hi, Tim
Here is my $.02:
1,2. you will have a loop if you have default at each side pointing to
each other, I don't know how you can prevent it if you leave the
defaults there. the packet will eventually get dropped due to ip ttl
expiration.
3. packet for networks outside of 172.16.0.0/16 will get dropped by
the first router it reaches
4. depends on what network statement you have in rip/eigrp and how you
put your static routes in the router(interface or next-hop ip?), the
static routes may or may NOT get redistributed.
5. ip ospf demand-circuit is another method of doing isdn backup,
normally you choose either ip ospf demand-circuit or floating route,
of course some other ways also available like dialer-watch, backup
interface, routing protocol specific methods like snapshot routing,
triggered updates. but the basic rule is you use one and ONLY one of
them unless specified otherwise.
6. you're right.
On Sun, 27 Mar 2005 14:08:02 -0500, ccie2be <ccie2be@nyc.rr.com> wrote:
> Hi Guys and Happy Easter,
>
> I'm wondering if this config will cause a routing loop? Even if it doesn't
> this scenario raises some interesting issues which I'd like to hear your
> opinions on.
>
> Lots of Left side networks R1 isdn R2 lots of Right side
> networks
>
> Assume there's another path for packets to get back and forth between the
> networks on the Left and Right side.
>
> The isdn link is there to serve as a backup if the primary path fails.
> Also, assume when the primary path is available
>
> the IGP's are fully converged and all routes are reachable.
>
> R1 and R2 are each configured with a default static floating route pointing
> to the other side of the isdn link;
>
> For example,
>
> ip route 0.0.0.0 0.0.0.0 <ip addr of other end of isdn link> 250
>
> Now, there are a few things to think about when configuring this scenario:
>
> 1 Assume the primary path is down and the isdn has come up. If R1 has a
> packet for which it doesn't have a path, it will send that packet
>
> to R2 based on the default static route. But, suppose R2 when it gets that
> packet also doesn't have a path it. Will R2, based on its own static route,
> send
>
> the packet back to R1? Or, will R2 drop the packet?
>
> 2 If the default behavior is for R2 to send the packet back to R1, is there
> a way to prevent that? Enable split-horizon, maybe?
>
> 3 Assume that all networks on both sides are subnets of 172.16.0.0/16.
> Would there be any benefit of configuring the default static route like
> this?
>
> ip route 172.16.0.0 255.255.0.0 <ip addr of remote end of isdn link> 250
>
> If so, what is the advantage?
>
> 4 According to Doyle, if the IGP running on both sides of this network are
> either rip or eigrp, I don't need to redist the static route into the
> routing process. Both of those IGP's do that automatically, true? But, if
> the IGP's are either OSPF or ISIS, then I have to use the command, default
> info originate. Agree?
>
> 5 Regarding interesting traffic, my thinking is that there's no point to
> having routing protocol traffic be considered interesting or even allowed to
> cross the isdn link (I would use passive interface bri 0) in this scenario.
> Nor, if the IGP is ospf is there any reason to use ip ospf demand-circuit.
> Does everyone agree?
>
> 6 In the example above, I used an AD of 250 on the static route. Does
> everyone agree that the actual value used for the AD doesn't matter as long
> as it's higher than the AD of any IGP's running in the network but lower
> than 255?
>
> I know I've thrown a lot of thoughts and issues in this post, but as you all
> know, Cisco doesn't give partial credit on the lab. One tiny mistake and
> you lose all the points for that section.
>
> I appreciate any comments, feedback, or insights you might make.
>
> TIA, Tim
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Apr 03 2005 - 17:56:53 GMT-3