Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
791
Views
0
Helpful
6
Replies

Multicast Issue

atupilojon
Level 1
Level 1

‎04-10-2015 01:38 PM - edited ‎03-07-2019 11:29 PM

Hello.

I'm having some issues deploying multicast in the network for a client requierement. The logical topology is as follows.

 

PE: ASR1006.

CPE: C2921.

The problem is that the user at the vigilancy desk can not see the camera's images when he sets the video streaming to multicast. For this particular client I decided to use PIM sparse mode and subif facing PE is the rendevouz point. The thing is that cameras don´t send multicast traffic to receiver. I see the IGMP joins at CPE LAN interface and, just in case, I configure a static join too.

I can ping from PE to mcast group (because of the static join) but mtrace is unsolved.

Camera [154.1.161.14/30]  === [154.1.161.13/30] PE [154.1.161.1/30] === [154.1.161.2/30] CPE [192.168.5.2/24] === receiver [192.168.5.15/24] 
PE#mtrace vrf VPN_user 192.168.5.2 
Type escape sequence to abort.
Mtrace from 192.168.5.2 to 154.1.161.1 via RPF in VRF VPN_user
From source (?) to destination (?)
Querying full reverse path... * switching to hop-by-hop:
 0  154.1.161.1
-1  154.1.161.1 ==> 154.1.161.1 PIM/MBGP  [192.168.5.0/24]
-2  * * * 154.1.161.2

Config. on PE (only mcast command lines)

ip pim vrf VPN_user bsr-candidate GigabitEthernet0/0/1.10000130 0
ip pim vrf VPN_user rp-candidate GigabitEthernet0/0/1.10000130

ip multicast-routing vrf VPN_user distributed
interface GigabitEthernet0/0/1.10000130
description To_CPE
encapsulation dot1Q 1000 second-dot1q 130
ip vrf forwarding VPN_user
ip address 154.1.161.1 255.255.255.252
ip pim sparse-mode

interface GigabitEthernet0/0/1.10000200
description Camara
encapsulation dot1Q 1000 second-dot1q 200
ip vrf forwarding VPN_user
ip address 154.1.161.5 255.255.255.252
ip pim sparse-mode

 

Do I have to configure address-family ipv4 multicast? Or it is just to mVPN?

Thank you.

Labels:
Preview file
17 KB
0 Helpful
6 Replies 6

minhda
Cisco Employee
Cisco Employee

‎04-10-2015 05:45 PM

Hi,

On both routers, please post the output of the following commands:

show ip mroute vrf VPN_user <mcast group>

show ip pim vrf VPN_user rp-mapping

show ip pim vrf VPN_user neighbour

show ip pim vrf VPN_user interfaces

 

Also, not sure if it was a typing error, please verify the interface connecting to camera is having correct IP address.

 

Regards,

Minh

0 Helpful

atupilojon
Level 1
Level 1
In response to minhda

‎04-13-2015 06:14 AM

Hi Minh.

Thank you for you reply.

Customer has more than one camera, I'm trying to do troubleshooting on only one.

interface GigabitEthernet0/0/1.10000202
 description Camera
 encapsulation dot1Q 1000 second-dot1q 202
 ip vrf forwarding VPN_user
 ip address 154.1.161.13 255.255.255.252
 ip pim sparse-mode

PE

sh ip mroute.

The IP camera mcast group are 239.1.161.6 and 239.1.161.14.

IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, 
       Z - Multicast Tunnel, z - MDT-data group sender, 
       Y - Joined MDT-data group, y - Sending to MDT-data group, 
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute, 
       Q - Received BGP S-A Route, q - Sent BGP S-A Route, 
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.161.6), 2d14h/00:03:01, RP 154.1.161.1, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Gi0/0/1.10000130, Forward/Sparse, 2d14h/00:03:01

(*, 239.1.161.14), 2w2d/00:02:49, RP 154.1.161.1, flags: SJC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Gi0/0/1.10000202, Forward/Sparse, 2w2d/00:02:49

(*, 224.0.1.40), 2w2d/00:02:46, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Gi0/0/1.10000200, Forward/Sparse, 1w4d/00:02:46

RP mapping

PIM Group-to-RP Mappings
This system is a candidate RP (v2)
This system is the Bootstrap Router (v2)

Group(s) 224.0.0.0/4
  RP 154.1.161.1 (?), v2
    Info source: 154.1.161.1 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 6d17h, expires: 00:01:59

PIM neighbor

PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      P - Proxy Capable, S - State Refresh Capable, G - GenID Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
154.1.161.2       Gi0/0/1.10000130         2d10h/00:01:44    v2    1 / DR S P G

PIM interfaces

Address          Interface                Ver/   Nbr    Query  DR     DR
                                          Mode   Count  Intvl  Prior
154.1.161.5      Gi0/0/1.10000200         v2/S   0      30     1      154.1.161.5
154.1.161.13     Gi0/0/1.10000202         v2/S   0      30     1      154.1.161.13
154.1.161.1      Gi0/0/1.10000130         v2/S   1      30     1      154.1.161.2

 

CPE

sh ip mroute.

I configured a static join for 239.1.161.6 in order to test without customer intervention.

IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, 
       Z - Multicast Tunnel, z - MDT-data group sender, 
       Y - Joined MDT-data group, y - Sending to MDT-data group, 
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.161.6), 2d11h/00:02:43, RP 154.1.161.1, flags: SJCL
  Incoming interface: GigabitEthernet0/1.130, RPF nbr 154.1.161.1
  Outgoing interface list:
    GigabitEthernet0/0, Forward/Sparse, 2d11h/00:02:43

(*, 224.0.1.40), 2d11h/00:02:37, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet0/1.130, Forward/Sparse, 2d11h/00:02:37

RP mapping

Group(s) 224.0.0.0/4
  RP 154.1.161.1 (?), v2
    Info source: 154.1.161.1 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 2d11h, expires: 00:01:37

PIM neighbor

PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      P - Proxy Capable, S - State Refresh Capable, G - GenID Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
154.1.161.1       GigabitEthernet0/1.130   2d11h/00:01:31    v2    1 / S P G

PIM interfaces

Address          Interface                Ver/   Nbr    Query  DR     DR
                                          Mode   Count  Intvl  Prior
192.168.5.2      GigabitEthernet0/0       v2/S   0      30     1      192.168.5.2
154.1.161.2      GigabitEthernet0/1.130   v2/S   1      30     1      154.1.161.2

Thank you!

0 Helpful

Chris Dixon
Level 1
Level 1
In response to atupilojon

‎04-13-2015 08:25 AM

Can you verify that the mcast traffic is actually getting to the PE from the cameras? Theres no (S,G) created at the RP so it could be not getting that traffic or it could be fialing rpf check can you do sh ip rpf and sh ip mroute count on the PE? Bear in mind that by default the CPE will try and switch to the shortest path to the sender so make sure unicast routing for receiver back to sender is correct so rpf check there succeeds too.  

0 Helpful

atupilojon
Level 1
Level 1
In response to Chris Dixon

‎04-13-2015 10:48 AM

Hello Chris.

Thank you for your time.

There isn't traffic from cameras to PE. I want to be sure that configuration is Ok before contacting camera's provider. 

RPF

RPF information for ? (192.168.5.2)
  RPF interface: Gi0/0/1.10000130
  RPF neighbor: ? (154.1.161.2)
  RPF route/mask: 192.168.5.0/24
  RPF type: unicast (bgp 11664)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base

mroute count

There are other routes that (I think) has nothing to do with this. I let it in the print just in case... Cameras replace first octect for 239 in order to build the multicast group IP address.

IP Multicast Statistics
16 routes using 12732 bytes of memory
10 groups, 0.60 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 239.255.255.250, Source count: 3, Packets forwarded: 2358, Packets received: 2645
  RP-tree: Forwarding: 2338/0/346/0, Other: 2338/0/0
  Source: 192.168.5.250/32, Forwarding: 0/0/0/0, Other: 13/0/13
  Source: 192.168.5.15/32, Forwarding: 0/0/0/0, Other: 33/0/33
  Source: 192.168.5.10/32, Forwarding: 20/0/488/0, Other: 261/0/241

Group: 239.168.5.61, Source count: 1, Packets forwarded: 744, Packets received: 6541
  RP-tree: Forwarding: 2/0/1436/0, Other: 2/0/0
  Source: 192.168.5.61/32, Forwarding: 742/0/1342/0, Other: 6539/0/5797

Group: 239.168.5.178, Source count: 1, Packets forwarded: 252, Packets received: 254
  RP-tree: Forwarding: 0/0/0/0, Other: 0/0/0
  Source: 192.168.5.178/32, Forwarding: 252/0/1233/0, Other: 254/0/2

Group: 238.168.5.179, Source count: 1, Packets forwarded: 807, Packets received: 7376
  RP-tree: Forwarding: 1/0/1366/0, Other: 1/0/0
  Source: 192.168.5.179/32, Forwarding: 806/0/1268/0, Other: 7375/0/6569

Group: 239.1.161.134, Source count: 0, Packets forwarded: 0, Packets received: 0

Group: 239.1.161.118, Source count: 0, Packets forwarded: 0, Packets received: 0

Group: 239.1.161.34, Source count: 0, Packets forwarded: 0, Packets received: 0

Group: 239.1.161.6, Source count: 0, Packets forwarded: 0, Packets received: 0

Group: 239.1.161.14, Source count: 0, Packets forwarded: 4, Packets received: 6
  RP-tree: Forwarding: 4/0/100/0, Other: 6/2/0

Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets received: 0

 

0 Helpful

minhda
Cisco Employee
Cisco Employee
In response to atupilojon

‎04-13-2015 04:30 PM

Hi,

 

Please contact the camera provider to troubleshoot again. Once camera is turn back on, please show ip mroute vrf <VRF name> under both CE & PE routers.

 

Regards,

Minh

0 Helpful

Chris Dixon
Level 1
Level 1
In response to minhda

‎04-14-2015 04:22 AM

All those groups is confusing!

 

I think these are the 2 groups you expect to get traffic for, please let me know if thats wrong:

Group: 239.1.161.6, Source count: 0, Packets forwarded: 0, Packets received: 0

Group: 239.1.161.14, Source count: 0, Packets forwarded: 4, Packets received: 6
  RP-tree: Forwarding: 4/0/100/0, Other: 6/2/0

 

for the second one you do appear to have forwarded a small amount of traffic in the past. I would start traffic again from the cameras and check the mroute on PE - you should see the (S,G) entry for the traffic from camera IP to the group if it is working, woith an outgoing interface list specifying the interface towards the recivers (you may need to rejoin the group from the receiver side). On the PE you should see both (*,G) and (S,G) groups to show it switching from RPT to SPT if everything has worked correctly and the RPF checks have passed. Please show this output with just the groups you need for the cameras, thanks

0 Helpful
Customers Also Viewed These Support Documents
Review Cisco Networking products for a $25 gift card