RE: Summarised Backup Network problem

From: Joseph Brunner (joe@affirmedsystems.com)
Date: Wed Mar 05 2008 - 18:27:59 ARST


Ryan,

Just run a very recent 12.4 (you don't need T train) and you can make this
eigrp summary conditional. Here's my router with your solution

logging buffered 8192
logging on

router eigrp 1
network 166.16.1.1 0.0.0.0
network 166.16.254.254 0.0.0.0
network 201.1.11.11 0.0.0.0
no auto-summary

interface loop1
ip address 166.16.254.254 255.255.255.255

inteface f0/1
ip address 166.16.1.1 255.255.255.0

track 20 interface f0/0 line-protocol

event manager applet track1
 event syslog pattern "%TRACKING-5-STATE: 20 rtr 20 state Up->Down"
 action 1.0 cli command "enable"
 action 1.1 cli command "configure terminal"
 action 1.2 cli command "interface loop1"
 action 1.3 cli command "shutdown"
!

interface f0/0
ip address 201.1.11.11 255.255.255.0
ip summary address-eigrp 1 166.16.0.0 255.255.0.0

You will need to enable the loop1 yourself later, or write another applet to
bring it back up

event manager applet track2
 event syslog pattern "%TRACKING-5-STATE: 20 rtr 20 state Down->Up"
 action 1.0 cli command "enable"
 action 1.1 cli command "configure terminal"
 action 1.2 cli command "interface loop1"
 action 1.3 cli command "no shutdown"
!

-Joe
#19366

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Ryan
Morris
Sent: Wednesday, March 05, 2008 1:43 PM
To: Jason Madsen
Cc: ccielab@groupstudy.com
Subject: Re: Summarised Backup Network problem

Hi Jason,

A good idea, but there's no hsrp in this picture. The links between the
WAN routers and the switches are all routed (and they need to be point to
point to accomodate some inline devices we use to accelerate traffic).

I've been trying to find another feature that uses the track command to
shutdown an interface, but so far no luck.

Thanks!

Ryan Morris
CCIE #18953

On Wed, 5 Mar 2008, Jason Madsen wrote:

> a link referencing what I mentioned earlier:
>
http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/1
2.2_44_se/configuration/guide/sweot.html#wp1084432
>
> more specifically, the "*track ip route reachability*" command, which is
> just below the area that the link will take you to.
>
> Jason
> On Wed, Mar 5, 2008 at 11:15 AM, Ryan Morris <ryan@egate.net> wrote:
>
> > Here's a scenario I've run into in real life:
> >
> > We have a branch office with two WAN connections, primary and backup.
> > Traffic will only take the backup link if the primary is not available.
> > We run EIGRP between these routers and our data centre routers. I'm
> > planning to summarise the routes coming out of these branch routers in
> > order to simplify my routing table. Per best practice, there is a
> > loopback address in each of the branch routers that is in the netblock
> > for that office.
> >
> > Inside the branch office, there is a group of core switches made up of
two
> > 3550s. Each 3550 connects to one of the WAN routers, and has an EIGRP
> > relationship with the other 3550 and the connected router.
> >
> > So if the primary WAN link or the primary router fails, no problem.
> > Traffic routes to the backup.
> >
> > Problem: if the connection between the primary router and the 3550
fails
> > (or, let's say the switch dies), that router will continue to advertise
> > the summary because of the loopback, and because it has a better
> > metric than the backup, traffic will not fail over to the backup.
> >
> > Any ideas on how to solve this? i.e. a feature that shuts down an
> > interface or explicitly stops advertising a route if another interface
> > fails? Or is the the simple answer (take the loopback off the primary
> > router) the only way to keep this from happening?
> >
> > Input appreciated!
> >
> > Ryan Morris
> > CCIE #18953
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html



This archive was generated by hypermail 2.1.4 : Tue Apr 01 2008 - 07:53:52 ART