RE: HSRP: the other side ?

From: Henry Dziewa (HenryD@xxxxxxxxxxxxx)
Date: Mon Jun 24 2002 - 11:04:45 GMT-3


   
Not sure if this was discussed already but here it goes...

One other option is to have the HSRP routers log any activities to a syslog
Server, parse the HSRP logs to a script, in case where the HSRP state
changes
You could start a script to log into the appropriate router and change
prefixes
Advertised thru BGP or their attributes. As long as there is a way for the
ISP
To distinguish this information either using communities or MED, this should
work.

I'd assume for a small network this would be doable, as far as the
enterprise/sp goes
You might have to look for a better solution, meaning some re-design.

Hope it helps...

CCIE #8472

-----Original Message-----
From: Carlos G Mendioroz [mailto:tron@huapi.ba.ar]
Sent: Friday, June 21, 2002 3:41 PM
To: P729
Cc: Groupstudy ccielab list
Subject: Re: HSRP: the other side ?

Hmm,
if you had a hook, you could do it. Conditional advertising does let you do
what I want from the BGP side. The problem is that HSRP does not tell you at
level 3 which is your active router for your network!

But I have been thinking and found no way to tell. No new networks, no
interface status, no nothing :-(

P729 wrote:
>
> You can't really "prevent" it. While you can control how traffic
> leaves your network, you can only influence how traffic comes to your
> network to a limited degree, as in sending BGP MEDs (which are often
> ignored), prepending your AS-path or perhaps sending well-known
> communities.
>
> Depending on your arrangement with your ISP, you'll pretty much have
> to talk them into traffic engineering the path(s) taken by traffic
> destined for your network from the Internet-at-large. It's more
> feasible if all of your traffic comes via one ISP, but it becomes more
> difficult (perhaps totally
> impractical) when two or more are involved and you aren't taking full
> routes.
>
> Regards,
>
> Mas Kato
> https://ecardfile.com/id/mkato
> ----- Original Message -----
> From: "Carlos G Mendioroz" <tron@huapi.ba.ar>
> To: "Groupstudy ccielab list" <ccielab@groupstudy.com>
> Sent: Friday, June 21, 2002 11:18 AM
> Subject: Re: HSRP: the other side ?
>
> > It seems I'm not making an interesting thing out of this :-(
> >
> > Say you have 2 routers like before, but one has a 100Mbit interface
> > and is the preferred access, and the other is an old 4000 with only
> > 10Mbit interface, but you do HSRP between them not to have a single
> > point of failure on the router. Obviously you don't want your
> > traffic to come via the 10Mbit half duplex interface to your lan.
> >
> > How would you prevent it ?
> >
> > Carlos G Mendioroz wrote:
> > >
> > > I'm still looking for a way to solve what I think is a problem ;-)
> > > Namely, you have a network and a couple of routers doing HSRP for
> > > providing redundant exit path to the rest of the world.
> > >
> > > As I see it, this has two sides.
> > >
> > > 1) The inside:
> > > HSRP solves the redundancy by using a polling mech (HSRP) to
> > > identify which router out of a group is responsible for the group
> > > MAC and IP. Every host on the net uses this MAC/IP to go out. It
> > > works and actually can deal with many problems (with track you can
> > > even react to some external problems).
> > >
> > > 2) The outside:
> > > The rest of the world need to know how to reach your network. And
> > > here, AFAIK HSRP has no hooks to make this easy.
> > >
> > > E.g.
> > >
> > > N -- R1 -- wan link to ISP
> > > E
> > > T -- R2 -- backup wan link to ISP
> > >
> > > When R2 turns active, how does it signal ISP that now traffic to
> > > your net should be forwarded to it (instead of to R1) ?
> > >
> > > It's easy if R1's net interface went down, but it might not be the
> > > case...
> > >
> > > Comments ?
> > > I have some weird ideas, but would like to know if there is an
> > > orthodox way out.
> > >
> > > --
> > > Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina



This archive was generated by hypermail 2.1.4 : Tue Jul 02 2002 - 08:12:40 GMT-3