I'm beating my head on the desk over this. Never tried to do it over L2L VPN, but have done it successfully over MPLS VPN's.
What I am trying to do is create a GRE tunnel between a remote site, and the corporate network to allow multicast traffic to traverse. Currently, this office is connecting to the network via a L2L tunnel terminating at an ASA. The GRE tunnel interfaces are located on the remote router and the core router at the primary datacenter. The toplogy looks like this...
The tunnel interfaces show up/up, and I can see traffic passing through. Mroutes are in place and both are part of 126.96.36.199 and 188.8.131.52. On the core, I can see all the other Mcast networks with routes, on the remote, it only shows itself.
I've tried a few different configurations for the tunnel interface. I've bound the source to a Loopback address on the remote and core sides, the sub-interface on the remote, the SVI on the core, the outside interface of the remote... Nothing seems to be working. When I ping the MCast broadcast IP, there are no routes.
GRE Tunnels are a bit odd, an up/up interface doesn't mean that the tunnel has established end-to-end, it just means that the local tunnel has a valid source interface and the router can successfully recurse to the destination IP address.
To test the tunnel, are you able to configure a /30 IP address on the tunnel interfaces and ping between them? Also has a pim neighborship established between the tunnel interfaces?
What is the IP address of the device sending the multicast stream?
You also dont need the mroute on the core as the outgoing interface to the receiver will be determined by the incoming pim join messages over the tunnel interface from the remote router.
[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...