From: Scott Vermillion (scott_ccie_list@it-ag.com)
Date: Wed Mar 05 2008 - 20:25:13 ARST
Hey Ryan,
Glad you found that worth considering. If you don't have sufficient
physical interfaces on your routers, the track object thing is really quite
simple and reliable in my experience. I do a lot of mobile solutions and
I'm constantly punching GRE tunnels through GRE tunnels, etc. I try to run
EIGRP everywhere to keep track of up/up links but sometimes I just have to
do an SLA track to test for reachability down some pathway or another. You
can set these up as ICMP echoes, so you're just pinging from (in your case)
your router to your switch via that p-t-p link every so many seconds. You
have timers at your disposal to tweak. Cisco keeps renaming it, but I think
the latest and greatest is "Service Level Agreement" (aka Response Time
Reporter and one or two others). Let me know if you can't find a link for
the code you're running and I'll try to help you find something.
Joe's idea is actually far more interesting and exotic. I don't have any
experience using it, but I'm certainly keeping his post for future
reference!
Cheers,
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Ryan
Morris
Sent: Wednesday, March 05, 2008 3:16 PM
To: Joseph Brunner
Cc: ccielab@groupstudy.com
Subject: RE: Summarised Backup Network problem
Joe & Scott (V):
Those are both elegant and spectacular solutions! I haven't used the
event manager since I was studying back in September... how soon we
forget. Not sure if I have ethernet ports available for Scott's solution
but I'll definitely try these out.
Thanks guys,
Ryan Morris
CCIE #18953
On Wed, 5 Mar 2008, Joseph Brunner wrote:
> 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
> > >
> > >
This archive was generated by hypermail 2.1.4 : Tue Apr 01 2008 - 07:53:52 ART