Part 2 – Troubleshooting Multicast

Topology:

Procedure:
– First, we will work back from the receiver’s DR to it’s RP, to be sure the RPT branch is
built correctly.
– Second, we will check to see if the receiver’s RP knows about the source.
– Third, we will check with the source end for their RP knowledge/advertisement of the source.
– Last, we will troubleshoot MSDP as needed.

— START —

1. Does the DR have the right RP?
— OUTPUT
R6#sh ip pim rp mapping 239.1.1.1
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static
RP: 10.1.1.9 (?)

Troubleshooting PIM Multicast

Topology:

Basic Questioning for multicast issue:
a. Timeframe when did the issue stop working?
b. How big (Kbps/Mbps) is the multicast stream (slowness)?
c. What is the multicast group address?

Troubleshooting Commands/Approach:

Deep dive – PIM Sparse mode

I. Understanding Hello Messages
II. DR Election
III. FHR Segment – PIM Register
IV. LHR Segment – PIM Join

Topology:

I. PIM Hello Message
> Both PIM modes require the establishment of neighbor adjacencies throughout the network.
>> Leads to the creation of the base multicast tree.
>>> Topology of links where multicast traffic can flow/
>> Routed multicast traffic will only flow between two directly connected PIM nodes.
Note: Can be radically different from the unicast routing topology.

> PIM uses Hello messages to discover directly connected neighbors.
>> Destination IP – 224.0.0.13 (All-PIM-Routers)
>> Source IP – Exit interface in which PIM is configured.
>> IP protocol – 103
>> TTL 0 1
>> Options carried as TLVS

Unicast vs Multicast forwarding

rotocol-Independent Multicast (PIM)
PIM is protocol independent because it can leverage whichever unicast routing protocol is used to populate the unicast routing table, including EIGRP, OSPF, BGP, or static route, to support IP multicast. PIM also uses a unicast routing table to perform the reverse path forwarding (RPF) check function instead of building a completely independent multicast routing table. PIM does not send and receive multicast routing updates between routers like other routing protocols do.

– Connection messages (PIM Joins) follow unicast routing table toward multicast source.
– PIM uses any unicast routing protocol to build the data distribution trees.
– PIM is the only multicast routing protocol deployed on the Internet to distribute multicast data natively and not over a bandwidth-limited, tunneled topology.

Ezvpn Troubleshooting

Troubleshooting EZVPN on Cisco router

Provides a sample configuration for IPsec between a Cisco 871 router and a Cisco 7200VXR router using Easy VPN (EzVPN). The 7200 acts as the Easy VPN Server and the 871 acts as the Easy VPN Remote. In this example, the loopback interfaces are used on both routers as private networks. These can be replaced by other interfaces such as FastEthernet or Serial interfaces as required.

— Check the ezvpn status and ipsec phase 1 – Displays the Cisco Easy VPN Remote configuration.
R3#sh crypto ipsec client ezvpn
Easy VPN Remote Phase: 6
Tunnel name : EZVPN
Inside interface list: Loopback9
Outside interface: FastEthernet0/0
Current State: READY
Last Event: CONNECT
Save Password: Allowed
Current EzVPN Peer: 1.1.1.2

IGMP Snooping

IGMP Snooping
> Define in RFC 4541
> Switch intercepts “snoops” IGMP messages to build multicast entries.
Note: Multicast find on destination of frames and packet. You would not find them as source/ Source is coming from unicast.

IGMP snooping is a wan on the switch where the switch can actually watch these igmp transaction between the receiver and the quirier.
> Mac address of the receiver
> Mac address of multicast stream
> Multicast IP of the stream
> Port/Vlan of receiver

Note: IGMP is enabled by default.

Proxy Reporting

1. Host A send MR stream 225.9.9.9 / 01-00-5E-09-09-09
2. Once switch received the MR w/ igmp snooping enabled the switch start to build his igmp snooping table.
> show ip igmp groups or sh ip igmp snooping groups

Internet Group Management Protocol (IGMP)

Introduction – Internet Group Management Protocol
> Used by receivers to indicate the mcast interest to directly-connected routers.
>> Used between your laptop (receiver) and you default gateway (no further that default gateway).
>> Carried using IP (behind ipv4 header) and has the TTL of 1.
> Used for IPv4 multicast
> Multicast Listener Discovery protocol (MLDP) is an IPv6 equivalent.
> Switches flood multicast by default
> IGMP “snooping” allow switches to create a multicast mac entries.

IGMPv1
> RFC 1112
> Two message type
>> IGMP Query (general query) – Sends every minute
>> IGMP Report or Membership report – IGMP join (1st message)
> TTL = 1
> 224.0.0.1 – All multicast host

Note: After 3 general queries (3min) and no received IGMP report/reply then the router will timeout the interface (will not the stream) but still continues to sent the general query to all multicast host (224.0.0.1).

Report Suppression – If all host are in the same broadcast domain and a host see’s a query came in and will run a count down but in the instance that before it get to 0 someone else send a query report and if they’re reporting the same stream a the host then it will suppress it’s query.

Layer-2 Multicast – IGMP Lab (WIP)

Topology:

Basic Steps:
1. IP Addressing
2. Enabling Multicast Forwarding
3. Configuring Multicast Routing Monitor (MRM)

Introduction – Multicast Protocol (WIP)

Basically Multicast is the process of sending data to a group of receivers. A good example would be radio and television in which a transmitter sends data on a certain frequency, and some group of receivers acquires the data by tuning to that frequency. The frequency is, is this sense, multicast address. All receivers within the range of the transmission are capable of receiving the signal, but only those who listen to the correct frequency actually receive it.

Multiple approach can be used by the source in order to deliver data to multiple receiver.

1. Replicated unicast – Source creates a separate packet containing identical data for each destination host in the group.

Issue: Multiple copies will be sent out to each destination host or what we called “Head-end replication”. Slow WAN links become potential bottlenecks. There are also problems if the data is delay-sensitive and cannot be contained in a single packet.

WIP: Multicast LAB