cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2298
Views
0
Helpful
32
Replies

Multicast VPN issue

gregwoodson
Level 1
Level 1

I've got 2 core routers peered via BGP. I have deployed a Multicast VPN between them based on the following doc:

http://www.cisco.com/en/US/tech/tk828/tech_digest09186a00801a64a3.html

I actually see the multicast routes on all of the VRF's being broadcast from router to router and throughout the entire network. However, I am not able to see Multicast traffic passing. This is a very bizarre problem. Attached is the pertinent configs for the 2 routers.

Any ideas?

32 Replies 32

CustomerA Site>sh ip mroute 239.194.0.0 count

Multicast route-limit: 200000

IP Multicast Statistics

23 routes using 13408 bytes of memory

12 groups, 0.91 average sources per group

Forwarding Counts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per second

Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 239.194.0.0, Source count: 4, Packets forwarded: 31713, Packets received: 31738

RP-tree: Forwarding: 2280/0/212/0, Other: 2305/0/25

Source: 10.105.0.250/32, Forwarding: 679/0/212/0, Other: 679/0/0

Source: 10.105.0.253/32, Forwarding: 1287/0/359/0, Other: 1287/0/0

Source: 10.105.0.254/32, Forwarding: 3585/0/496/0, Other: 3585/0/0

Source: 10.105.8.10/32, Forwarding: 23882/1/458/3, Other: 23882/0/0

CustomerA Site>sh ip rpf 10.105.0.254

RPF information for ? (10.105.0.254)

RPF interface: Serial5/1

RPF neighbor: ? (10.105.255.1)

RPF route/mask: 10.105.0.0/24

RPF type: unicast (bgp 65512)

RPF recursion count: 2

Doing distance-preferred lookups across tables

CustomerA Site>

10.105.0.254 is a server off of Core-1 that is broadcasting a stream over to Core-2 thru the tunnel. The route is making it, however, the actual information is not. CustomerA Site is off of Core-2

Greg,

The counters above are incrementing, showing that not only the control plane is functioning as it should but also the data plane.

According to output you posted before, these streams are forwarded on interface Gig0/1.

(10.105.0.254, 239.194.0.0), 12:43:14/00:03:24, flags: T

Incoming interface: Serial5/1, RPF nbr 10.105.255.1

Outgoing interface list:

GigabitEthernet0/1, Forward/Sparse-Dense, 12:43:14/00:02:32

What is connected to that interface? Are there any receivers connected to CustomerA_Site?

Regards,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

yes, there are about 70 users that are supposed to be receiving the data stream. All we see is the control stream though. We've done wireshark traces- and all we are seeing is control traffic.

Greg,

My point is that the multicast streams are getting to this specific box. On which interfaces are the end users connected and is PIM enabled on these interfaces.

Regards,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

from the config I come to know that there is sparse-mode for the backhaul connectivity; but donot you think that there is should be ip pim auto-rp listener command for the flooding of group of 39 and 40.

regards

shivlu

Shivlu,

Can you give me an example of what that should look like? I'm more than willing to give it a try...

what i means, it u r using spare-mode then ip pim auto-rp listner is required.Becasue without this the group to rp mapping won't happen in case of rp loose. Another thing is that are u advertising your rp by using access list. Becasue if u are not using a access-list for your group, so by default it will be using 224.0.0.0 group but for auto-rp you damn need 239 group. So create acl fo r239 grp and bind it with the auro command in advertising.

regards

shivlu

command is ip pim auto-rp listner.

Actually what happens when you configure auto-rp it requires 224.0.0.39 and 224.0.0.40 group and these groups has been identified with the help of dense mode. But in configs you are using sparse mode; so the intial group information is not flooded. When you entered the command in every router you see the the twp above mentioned groups.Once you get this all will work fine.

regards

shivlu

I entered the "ip pim autorp listener" command in the routers in question. I see little bits of traffic traversing the tunnel- but nothing with consistency. I dont understand what you were talking about with the access lists. I added simply that command- what else is this requiring?

Thanks

Greg

Greg,

Ok , Please let me know are you using auto-rp or BSR. If auto-RP is there, then r u using pim-sparse mode or pim sparse-dense-mode.

regards

shivlu

We are using auto-RP. Based on the config guide for this- we are using sparse-dense mode for the connections to CE routers, sparse-mode between the cores.

That's the really strange part- I see that traffic shows up on the routers- but when I put a wireshark client on the network- I dont see the multicast streams making it out. Nor do I see it on any of the machines. It looks like controls are making it thru the tunnel, the streams are not.

can you post the output of shouw ip mroute for vrf specific

regards

shivlu

Here are the show ip mroute commands- Like I said before - the control packets (and routes) come thru fine. The data just isnt traversing the tunnels correctly

End users are connected to many of the different interfaces on the PE. They are all ip pim sparse-dense-mode. Im getting really confused by this problem. None of our guys can figure this out.