From: Josef A (josefnet@gmail.com)
Date: Tue Dec 19 2006 - 09:46:14 ART
In addition, IP SLA and object tracking can be used with HSRP to track the
state of R1 interface, this way the tunnel will always be up/up.
Thx
On 12/19/06, Josef A <josefnet@gmail.com> wrote:
>
> Tunnel between between R4 and R3 ?
>
> thx
>
>
> On 12/19/06, Koen Zeilstra <koen@koenzeilstra.com> wrote:
> >
> > Hey group,
> >
> > Imagine the following scenario:
> >
> > |--R1--|
> > HOSTA---R4------| |----R3---HOSTB
> > |--R2--|
> >
> >
> > On the hostA subnet HSRP runs with virt. ip 192.168.1.3.
> >
> > R1 f0/0: 192.168.1.1 HSRP prio 120
> > R2 f0/0: 192.168.1.2 HSRP prio 110
> >
> > Host B sends multicast to group 239.1.1.1.
> >
> > R4 does a RPF check on the mcast packets which are sourced from R1 f0/0
> > ( 192.168.1.1). The RPF check fails because the unicast route to R3 is
> > via
> > the HSRP virt. ip address 192.168.1.3.
> >
> > How is this solved?
> >
> > 1. We can use static mroutes on R4 pointing to R1, this will work
> > however
> > there is no failover for multicast as there is for unicast traffic. The
> > mroute will not dissapear because if R1 fails the ethernet interface on
> > R4
> > will still be up and running. If R4 f0/0 fails there is no connectivity
> > towards R2 anyways...
> >
> > 2. I can imagine a PBR routing scenario where all traffic from R1 and R2
> > towards R4 is sourced from the HSRP virt. ip address? Not nice, since
> > this
> > will cause all traffic to be process switched.
> >
> > Any nice solutions anybody?
> >
> > all help appreciated!
> >
> > thanks,
> >
> > Koen
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Tue Jan 02 2007 - 07:50:38 ART