From: kevin gannon (kevin@gannons.net)
Date: Thu Sep 29 2005 - 13:40:53 GMT-3
I am afraid I am not aware of anything that tracks the
HSRP state they way you want to.
However you must be running strict RPF there is other
options like reachable via any interface which would
still give you some level of protection and allow for
the asymetric routing. This is how we handle this the
ISP side of our business.
Using the tracking you might loose capacity as if you
want to load share the outbound traffic.
Regards
Kevin
On 9/29/05, Geert Nijs <geert.nijs@simac.be> wrote:
> Kevin, this would also be a solution for that problem i know ! :-).
> But that is not my main reason. The reason i want to implement this is
> that one hop further from R1 and R2, there are routers R3 and R4 and
> they are running ip verify unicast and do not allow assymetric routing.
> So at this point, when hsrp switches, the routing must be manually
> adjusted so that ip verify unicast does not start dropping packets. The
> situation is a bit complicated to explain in short. If router R1
> completely fails, there is no problem, but if someone - by accident -
> changes the HSRP priorities in an attempt to solve other problems - and
> forgets to also change the routing metrics, we are in big problems :-)
>
> I am trying to keep symmetric routing automatically when hsrp switches
> (caused by for example someone who configures a higher prio). Ideally as
> long as R1 is HSRP active, only R1 should be announcing the LAN1 subnet.
> When R2 becomes active (for whatever reason), R2 should start
> advertising the LAN1 subnet or start advertising a route with a lower
> metric..
> I really miss this kind of functionality in a Cisco router.
> The problem is that you cant 'track' the state of an HSRP router. Is
> there a way to use the track functionality for this ?
> There is also something like HSRP redundancy group which is used by
> static NAT, so that as long as HSRP is not active, the router does not
> inject static nat entries in its table and mac cache. This is the only
> thing i know of that keeps an eye on the hsrp state......
>
> regards,
> Geert
>
> -----Original Message-----
> From: kgannon@gmail.com [mailto:kgannon@gmail.com] On Behalf Of kevin
> gannon
> Sent: donderdag 29 september 2005 14:10
> To: Leigh Harrison
> Cc: Geert Nijs; ccielab@groupstudy.com
> Subject: Re: changing incoming routing based on vrrp/hsrp
>
> By chance are you trying to stop flooding in a switched environment due
> to asymetric routing ?
>
> Regards
> Kevin
>
> On 9/29/05, Leigh Harrison <ccileigh@gmail.com> wrote:
> > Geert,
> >
> > Very interesting this one. My first thought is to use the hsrp
> > address of the routers as the gateway into LAN 1. But this depends on
>
> > why you want to make the different routers hsrp master.
> >
> > From that, my second though would be to use the global "track"
> > command and track on, say, a routes metric value, give it a threshold
> > and switch over if it's not the best route in.
> >
> > What would be your reason for cutting over in hrsp/vrrp ?
> >
> > LH
> >
> > Geert Nijs wrote:
> >
> > >Hi all,
> > >
> > >I am looking for a way to change incoming packets based on which
> > >router is HSRP active, in the following topology:
> > >
> > >| |
> > >| |
> > >R1 R2
> > >| |
> > >-------LAN 1 -----------
> > >
> > >
> > >Router R1 and R2 are running VRRP or HSRP for LAN 1 If R1 is HSRP
> > >master, i want packets for LAN1 to come in via R1 If R2 becomes HSRP
> > >master, i want packets for LAN1 to come in via R2 This can be done by
>
> > >changing the routing metric of the R1 and R2 uplinks or by
> > >configuring R1 and R2 in such a way that it wil not advertise LAN1
> > >when it is HSRP slave, but how to do this automatically ??
> > >
> > >Anyone an idea on how to accomplish this..........mmm..there must be
> > >a way....
> > >
> > >
> > >regards,
> > >
> > >Geert Nijs
> > >CCIE #13729
> > >
> > >#####################################################################
> > >########
> > >########
> > >Simac N.V. trades under the commercial name Simac ICT Belgium.
> > >This e-mail and any attached files are confidential and may be
> > >legally privileged.
> > >If you are not the addressee, any disclosure, reproduction, copying,
> > >distribution, or other dissemination or use of this communication is
> > >strictly prohibited.
> > >If you have received this transmission in error please notify Simac
> > >immediately and then delete this e-mail.
> > >
> > >Simac has taken all reasonable precautions to avoid virusses in this
> email.
> > >Simac does not accept liability for damage by virusses, for the
> > >correct and complete transmission of the information, nor for any
> > >delay or interruption of the transmission, nor for damages arising
> > >from the use of or reliance on the information.
> > >
> > >All e-mail messages addressed to, received or sent by Simac or Simac
> > >employees are deemed to be professional in nature. Accordingly, the
> > >sender or recipient of these messages agrees that they may be read by
>
> > >other Simac employees than the official recipient or sender in order
> > >to ensure the continuity of work-related activities and allow
> > >supervision thereof.
> > >#####################################################################
> > >########
> > >########
> > >
> > >_____________________________________________________________________
> > >__ Subscription information may be found at:
> > >http://www.groupstudy.com/list/CCIELab.html
> >
> > ______________________________________________________________________
> > _ Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:17 GMT-3