Forwarding FHRP (HSRP) Multicast over a GRE Multicast-enabled Tunnel
I've been reading through various Multicast Forwarding over GRE (i.e. enable PIM Sparse on the Interesting Interface on each router, and the GRE Tunnel), and can see that this allows you to use the pre-allocated 220.127.116.11 Multicast subnet.
My intent here is to try and run HSRP between two routers with a shared Subnet (i.e. RouterA has an Fa1/0 as 10.230.108.2/28 -
HSRP 10.230.108.1; RouterB has an Fa1/0 as 10.230.108.3/28 - HSRP 10.230.108.1) - however that Shared Subnet is actually a Resilient (Active/Passive) pair of ASA Firewalls, hence I don't have a common Broadcast Domain for the HSRP -> 18.104.22.168 Multicast "Hello" messages to traverse.
RouterA and RouterB have a /30 routed interface between them, and some Track objects/IP SLA which enables the WAN -> Firewall and Firewall -> WAN Failover to occur (big hint: turn CEF off or watch your Sunday afternoon disappear in a cloud of "Why are you routing there when the RIB table says you go here?!" smoke).
It seems to be possible to forward Multicast across a GRE Tunnel, connected to both RouterA and RouterB so can this be extended to forward HSRP Multicast packets to 22.214.171.124, without needing common Switched infrastructure between RouterA and Router B?
Forwarding FHRP (HSRP) Multicast over a GRE Multicast-enabled Tu
Thanks. I achieved what I wannted by investigating bridge-domains instead, as I have a direct L3 link between two routers than a BDI could run across - logically extending ("cross connecting") the L2 domain across, and hence spanning the HSRP.
Very interesting though - the theory was there, just shame the TTL part stopped me,
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...