Network 101: Multicast

Showing posts with label Multicast. Show all posts

Monday, September 19, 2011

Interdomain Multicasting

Example configuration

We have 2 Autonomous System in this scenarios. AS 100 and AS 200 each running OSPF as the IGP routing protocol. The requirement in this example is to configure network to forward the multicast traffic from AS 100 to AS 200. The source of multicast traffic is R3 loopback interface and the receiver is sitting at R4 in the AS 200.

In this scenario, we need to configure Interdomain MSDP. We have selected R1 and R2 as a RPs for each AS. They form the MSDP neighbor together to accomplish this. Here is the configuration.

R1
router bgp 100

bgp log-neighbor-changes
neighbor 192.168.1.2 remote-as 200
!
address-family ipv4
redistribute ospf 1
neighbor 192.168.1.2 activate
no auto-summary
no synchronization
network 1.1.1.0 mask 255.255.255.0
exit-address-family
!
address-family ipv4 multicast
neighbor 192.168.1.2 activate
no auto-summary
no synchronization
exit-address-family
!
ip forward-protocol nd

ip pim rp-address 1.1.1.1

ip msdp peer 2.2.2.2 connect-source Loopback0 remote-as 200

router bgp 200

bgp log-neighbor-changes

neighbor 192.168.1.1 remote-as 100

address-family ipv4

redistribute ospf 1

neighbor 192.168.1.1 activate

no auto-summary

no synchronization

network 2.2.2.0 mask 255.255.255.0

exit-address-family

address-family ipv4 multicast

neighbor 192.168.1.1 activate

no auto-summary

no synchronization

exit-address-family

ip forward-protocol nd

no ip http server

no ip http secure-server

ip pim rp-address 2.2.2.2

ip msdp peer 1.1.1.1 connect-source Loopback0 remote-as 100

ip pim rp-address 1.1.1.1

ip pim rp-address 2.2.2.2

Verify configuration

R1#sh ip msdp summary

MSDP Peer Status Summary

Peer Address AS State Uptime/ Reset SA Peer Name

Downtime Count Count

2.2.2.2 200 Up 00:06:54 0 0 ?

R1#

R3#ping 239.1.1.1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 10.1.1.2, 388 ms

R3#

R2#sh ip mroute

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,

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

Outgoing interface flags: H - Hardware switched, A - Assert winner

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 01:02:18/00:03:19, RP 2.2.2.2, flags: SJC

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

FastEthernet0/1, Forward/Sparse, 01:02:18/00:03:19

(172.16.1.2, 239.1.1.1), 00:00:26/00:02:33, flags: M

Incoming interface: FastEthernet0/0, RPF nbr 192.168.1.1

Outgoing interface list:

FastEthernet0/1, Forward/Sparse, 00:00:26/00:03:19

(*, 224.0.1.40), 01:08:40/00:03:21, RP 2.2.2.2, flags: SJCL

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

FastEthernet0/0, Forward/Sparse, 01:05:16/00:02:25

FastEthernet0/1, Forward/Sparse, 01:08:40/00:03:21

Configuring Netflow for multicast traffic

This section was copied from cisco.com

Configuring NetFlow for Multicast IP Traffic

To configure NetFlow for multicast IP traffic, perform this task:


	Command	Purpose
Step 1	Router(config)# ip multicast netflow output-counters	(Optional) Enables the calculation of output bytes/packets for an ingress flow.
Step 2	Router(config)# ip multicast netflow rpf-failure	(Optional) Enables NetFlow for multicast data that fails the RPF check.
Step 3	Router(config)# interface{vlan vlan_ID} \| {type slot/port} \| {port-channel port_channel_number}	Selects a Layer 3 interface to configure.
Step 4	Router(config-if)# ip flow{ingress \| egress}	Enables NetFlow multicast traffic on the specified interface (for RP and PFC). •Specify ingress to enable NetFlow multicast ingress accounting. •Specify egress to enable NetFlow multicast egress accounting.

Tuesday, August 16, 2011

multicast helper-map

Multicast Helper-map
Broadcast : 255.255.255.255
Multicast : 224.0.0.0 - 239.255.255.255
Broadcast address / subnet.

http://blog.ine.com/2008/05/06/understanding-the-ip-multicast-helper-map-command/

Tuesday, August 9, 2011

BSR Border

ip pim bsr-border

Prevent send / receive BSR message on the interface. When this command is used, the BSR domain will stop at the interface configured this command.

R1 ---- R2 -----R3

Before
R3

R3#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 1.1.1.1 (?), v2
Info source: 1.1.1.1 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:00:04, expires: 00:02:21
R3#

After
R2
int f0/1
description To R3
ip pim bsr-border

R3

R3#sh ip pim rp mapping
PIM Group-to-RP Mappings

R3#

From the example above, after we put in the command ip pim bsr-border on the interface of R2 connecting to the R3, we no longer see the RP on the R3.

Wednesday, June 1, 2011

igmp helper address

igmp helper address is used when we want to forward igmp join/leave message to another interface by specifying the ip address of the destination where we want to forward this igmp packet to.

In this example, R4 is trying to get the multicast traffic from R1. However, R3 is not a neighbor of R2. Therefore R4 cannot join the group. We need to add the igmp helper to forward this igmp join request to R2.

R2

interface FastEthernet0/1
ip address 192.168.2.1 255.255.255.0
ip pim sparse-dense-mode
ip pim neighbor-filter 1
duplex auto
speed auto

interface FastEthernet0/0

ip address 192.168.2.2 255.255.255.0

ip pim sparse-dense-mode

ip igmp helper-address 192.168.2.1

duplex auto

speed auto

end

interface FastEthernet0/0

ip address 192.168.3.2 255.255.255.0

ip igmp join-group 239.0.0.1

duplex auto

speed auto

Verify configuration

R1#ping 239.0.0.1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:

Reply to request 0 from 192.168.3.2, 132 ms

Monday, April 11, 2011

Mapping Agent (MAP RP)

The functionality of the mapping agent is the map multicast group to the RP in the Auto-RP process. In order to specify which multicast group going to which RP, we use this following command.

ip pim rp-announce-filter rp-list XXX group-list XXX

We can specify RPs in the rp-list and groups in the group-list.

Example

//Mapping agent

ip pim send-rp-discovery Loopback0 scope 16
!
ip pim rp-announce-filter rp-list R2_RP group-list R2_GROUPS
ip pim rp-announce-filter rp-list R1_RP group-list R1_GROUPS
!
ip access-list standard R1_GROUPS
permit 224.0.0.0 0.255.255.255
permit 226.0.0.0 0.255.255.255
permit 228.0.0.0 0.255.255.255
permit 230.0.0.0 0.255.255.255
permit 232.0.0.0 0.255.255.255
permit 234.0.0.0 0.255.255.255
permit 236.0.0.0 0.255.255.255
permit 238.0.0.0 0.255.255.255
!
ip access-list standard R1_RP
permit 150.1.1.1
!
ip access-list standard R2_GROUPS
permit 225.0.0.0 0.255.255.255
permit 227.0.0.0 0.255.255.255
permit 229.0.0.0 0.255.255.255
permit 231.0.0.0 0.255.255.255
permit 233.0.0.0 0.255.255.255
permit 235.0.0.0 0.255.255.255
permit 237.0.0.0 0.255.255.255
permit 239.0.0.0 0.255.255.255
!
ip access-list standard R2_RP
permit 150.1.2.2

Friday, March 25, 2011

Multicast over Frame Relay

Interesting Note.
http://www.cisco.com/en/US/docs/ios/solutions_docs/ip_multicast/White_papers/frmrlay.html

Thursday, March 17, 2011

PIM BSR priority

PIM BSR uses the 224.0.0.13 to send out the advertisement of the BSR and PR. In case there are more than one advertisement of the RP and BSR candidates, we use the priority and IP address criteria to election the primary RP and primary BSR. However, RP election and BSR election criteria is different

RP election consider the lowest priority or the lowest IP address as a primary RP. However, BSP election considers the highest priority or the highest IP address as primary BSR. We can see the RP and BSP by using following commad.

show ip pim rp mapping ( show RP mapping for the multicast groups )

show ip pim bsr-route ( show BSR router )

To change the priority of the RP and BSR, we use the following commands.

ip pim rp-candidate Loopback0 priority 10

BSR

ip pim bsr-candidate Loopback0 0 10

Example :

We configure R1 and R2 to announce themselves as the RP and BSR candidates. R1 has RP priority of 10 and BSR priority of 10. R2 has RP priority of 20 and BSR priority of 0. We expect that R1 will be the primary RP and R2 will be the primary BSR because of the criteria explained above.

Configuration

R1

ip pim bsr-candidate Loopback0 0 10

ip pim rp-candidate Loopback0 priority 10

ip pim bsr-candidate Loopback0 0

ip pim rp-candidate Loopback0 priority 20

RP Mapping

R3#sh ip pim rp mapping

PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4

RP 1.1.1.1 (?), v2

Info source: 1.1.1.1 (?), via bootstrap, priority 10, holdtime 150

Uptime: 00:16:29, expires: 00:02:12

RP 2.2.2.2 (?), v2

Info source: 1.1.1.1 (?), via bootstrap, priority 20, holdtime 150

Uptime: 00:16:40, expires: 00:01:56

BSR Router

R2#show ip pim bsr-router

PIMv2 Bootstrap information

BSR address: 1.1.1.1 (?)

Uptime: 00:13:08, BSR Priority: 10, Hash mask length: 0

Expires: 00:01:12

This system is a candidate BSR

Candidate BSR address: 2.2.2.2, priority: 0, hash mask length: 0

Candidate RP: 2.2.2.2(Loopback0)

Holdtime 150 seconds

Advertisement interval 60 seconds

Next advertisement in 00:00:37

Candidate RP priority : 20

Wednesday, March 2, 2011

IGMP Snooping Cisco Catalyst problem

This article is copied from Cisco website
http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a008059a9df.shtml

Problem
Multicast traffic does not seem to pass across Catalyst switches, even in the same VLAN. Figure 1 depicts a typical scenario:
Figure 1 – Network Setup with Multicast Source and Receivers

The multicast source is connected to Switch 1, which is a Catalyst 6500 Switch with Supervisor Engine 720 that runs Cisco IOS Software. Receiver 1 is connected to Switch 1, and Receiver 2 is connected to Switch 2. Switch 2 is a Catalyst 3750. There is a Layer 2 link, either access or trunk, between Switch 1 and Switch 2.
In this setup, you find that Receiver 1, which is on the same switch as the source, gets the multicast stream with no problems. However, Receiver 2 does not get any multicast traffic. This document aims to resolve this issue.

Revisit Some Key Multicast Concepts

Before you explore the solution and the different options you have, you must be clear on certain key concepts of Layer 2 multicast. This section defines these concepts.

Note: This section provides a very simple and direct explanation that focuses only on this particular issue. See the Related Information section of this document for a more detailed explanation of these terms.

IGMP

IGMP is a protocol that enables end hosts (receivers) to inform a multicast router (IGMP querier) of the end host intention to receive particular multicast traffic. So this is a protocol that runs between a router and end hosts and allows:

Routers to ask end hosts if they need a particular multicast stream (IGMP query)
End hosts to tell or respond to the router if they seek a particular multicast stream (IGMP reports)

IGMP Snooping

IGMP snooping is a mechanism to constrain multicast traffic to only the ports that have receivers attached. The mechanism adds efficiency because it enables a Layer 2 switch to selectively send out multicast packets on only the ports that need them. Without IGMP snooping, the switch floods the packets on every port. The switch "listens" for the exchange of IGMP messages by the router and the end hosts. In this way, the switch builds an IGMP snooping table that has a list of all the ports that have requested a particular multicast group.

Mrouter Port

The mrouter port is simply the port from the switch point of view that connects to a multicast router. The presence of at least one mrouter port is absolutely essential for the IGMP snooping operation to work across switches. The Understand the Problem and Its Solutions section of this document discusses this requirement in more detail.

Multicast at L2

Any IP version 4 (IPv4) traffic with a destination IP in the range of 224.0.0.0 to 239.255.255.255 is a multicast stream. All IPv4 multicast packets map to a predefined IEEE MAC address that has the format 01.00.5e.xx.xx.xx.

Note: IGMP snooping works only if the multicast MAC address maps to this IEEE-compliant MAC range. Some reserved multicast ranges are excluded from being snooped by design. If a nonconforming multicast packet is sourced on a switched network, the packet is flooded throughout that VLAN, which means that it is treated like broadcast traffic.

Understand the Problem and Its Solutions

By default, the Catalyst switches have IGMP snooping enabled. With IGMP snooping, the switch snoops (or listens) for IGMP messages on all the ports. The switch builds an IGMP snooping table that basically maps a multicast group to all the switch ports that have requested it.

Assume that, without any prior configuration, Receiver 1 and Receiver 2 have signaled their intentions to receive a multicast stream for 239.239.239.239 that maps to the L2 multicast MAC address of 01.00.5e.6f.ef.ef. Both Switch 1 and Switch 2 create an e

ntry in their snooping tables for these receivers in response to the IGMP reports that the receivers generate. Switch 1 enters port Gigabit Ethernet 2/48 in its table, and Switch 2 enters port Fast Ethernet 1/0/47 in its table.

Note: At this point, the multicast source has not started its traffic, and none of the switches knows about the switch mrouter port.

When the source on Switch 1 starts to stream multicast traffic, Switch 1 has "seen" the IGMP report from Receiver 1. As a result, Switch 1 delivers the multicast out port Gigabit Ethernet 2/48. But, since Switch 2 "absorbed" the IGMP report from Receiver 2 as part of the IGMP snooping process, Switch 1 does not see an IGMP report (multicast request) on port Gigabit Ethernet 2/46. As a result, Switch 1 does not send any multicast traffic out to Switch 2. Therefore, Receiver 2 never gets any multicast traffic, even though Receiver 2 is in the same VLAN but merely on a different switch than the multicast source.

The reason for this issue is that IGMP snooping is not really supported on any Catalyst platform without an mrouter. The mechanism "breaks down" in the absence of an mrouter port. If you want a fix for this solution, you must have the switches somehow learn or know of an mrouter port. The Solutions section of this document explains the procedure. But how does the presence of an mrouter port on the switches remedy the situation?

Basically, when the switches learn or statically know about an mrouter port, two critical things occur:

The switch "relays" the IGMP reports from the receivers to the mrouter port, which means that the IGMP reports go toward the multicast router. The switch does not relay all the IGMP reports. Instead, the switch sends only a few of the reports to the mrouter. For the purpose of this discussion, the number of reports is not important. The multicast router only needs to know if there is at least one receiver that is still interested in the multicast downstream. In order to make the determination, the multicast router receives the periodic IGMP reports in response to its IGMP queries.
In a source-only multicast scenario, in which no receivers have yet "joined" in, the switch only sends the multicast stream out its mrouter port.

When the switches know their mrouter port, Switch 2 relays out the IGMP report that the switch received from Receiver 2 to its mrouter port. This port is Fast Ethernet 1/0/33. Switch 1 gets this IGMP report on the switch port Gigabit Ethernet 2/46. From the perspective of Switch 1, the switch has received merely another IGMP report. The switch adds that port into its IGMP snooping table and begins to send out the multicast traffic on that port as well. At this point, both the receivers receive the requested multicast traffic, and the application works as expected.

But how do the switches identify their mrouter port so that IGMP snooping works as it is expected to work in a simple environment like this? The Solutions section provides some answers.

Solutions

Use these solutions to solve the problem.

Solution 1: Enable PIM on the Layer 3 Router/VLAN Interface

All Catalyst platforms have the ability to dynamically learn about the mrouter port. The switches passively listen to either the Protocol Independent Multicast (PIM) hellos or the IGMP query messages that a multicast router sends out periodically.

This example configures the VLAN 1 switched virtual interface (SVI) on the Catalyst 6500 with ip pim sparse-dense-mode.

Switch1#show run interface vlan 1
!
interface Vlan1
 ip address 1.1.1.1 255.255.255.0
 ip pim sparse-dense-mode
end

Switch 1 now reflects itself (Actually the internal router port) as an Mrouter port. 

Switch1#show ip igmp snooping mrouter 
vlan            ports
-----+----------------------------------------
   1  Router

Switch 2 receives the same PIM hellos on its Fa 1/0/33 interface. So it assigns that 
port as its Mrouter port.

Switch2#show ip igmp snooping mrouter 
Vlan    ports
----    -----
   1    Fa1/0/33(dynamic)

Solution 2: Enable IGMP Querier Feature on a Layer 2 Catalyst Switch

The IGMP querier is a relatively new feature on Layer 2 switches. When a network/VLAN does not have a router that can take on the multicast router role and provide the mrouter discovery on the switches, you can turn on the IGMP querier feature. The feature allows the Layer 2 switch to proxy for a multicast router and send out periodic IGMP queries in that network. This action causes the switch to consider itself an mrouter port. The remaining switches in the network simply define their respective mrouter ports as the interface on which they received this IGMP query.

Switch2(config)#ip igmp snooping querier

Switch2#show ip igmp snooping querier 
Vlan      IP Address     IGMP Version   Port               
-------------------------------------------------------------
1         1.1.1.2        v2             Switch

Switch 1 now sees port Gig 2/46 linking to Switch 2 as an mrouter port.

Switch1#show ip igmp snooping mrouter 
vlan            ports
-----+----------------------------------------
   1  Gi2/46

When the source on Switch 1 starts to stream multicast traffic, Switch 1 forwards the multicast traffic to the Receiver 1 found via IGMP snooping (i.e., out port Gig 2/48) and to the mrouter port (i.e., out port Gig 2/46).

Solution 3: Configure Static Mrouter Port on the Switch

The multicast traffic fails within the same Layer 2 VLAN because of the lack of an mrouter port on the switches, as the Understand the Problem and Its Solutions section discusses. If you statically configure an mrouter port on all the switches, IGMP reports can be relayed in that VLAN to all switches. As a result, multicasting is possible. So, in the example, you must statically configure the Catalyst 3750 Switch to have Fast Ethernet 1/0/33 as an mrouter port.

In this example, you need a static mrouter port on Switch 2 only:

Switch2(config)#ip igmp snooping vlan 1 mrouter interface fastethernet 1/0/33

Switch2#show ip igmp snooping mrouter
Vlan    ports
----    -----
   1    Fa1/0/33(static)

Solution 4: Configure Static Multicast MAC Entries on All the Switches

You can make a static content-addressable memory (CAM) entry for the multicast MAC address on all the switches for all the receiver ports and the downstream switch ports. Any switch obeys the static CAM entry rules and sends the packet out all the interfaces that are specified in the CAM table. This is the least-scalable solution for an environment that has a lot of multicast applications.

Switch1(config)#mac-address-table static 0100.5e6f.efef vlan 1 interface 
gigabitethernet 2/46 gigabitethernet 2/48

!--- Note: This command should be on one line.

Switch1#show mac-address-table multicast vlan 1

 vlan   mac address     type   learn qos             ports
-----+---------------+--------+-----+---+--------------------------------
   1  0100.5e6f.efef    static  Yes          -   Gi2/46,Gi2/48


Switch2(config)#mac-address-table static 0100.5e6f.efef vlan 1 interface 
fastethernet 1/0/47

!--- Note: This command should be on one line.

Switch2#show mac-address-table multicast vlan 1
Vlan    Mac Address       Type       Ports
----    -----------       ----       -----
   1    0100.5e6f.efef    USER        Fa1/0/47

Solution 5: Disable IGMP Snooping on All the Switches

If you disable IGMP snooping, all switches treat multicast traffic as a broadcast traffic. This floods the traffic to all the ports in that VLAN, regardless of whether the ports have interested receivers for that multicast stream.

Switch1(config)#no ip igmp snooping

Switch2(config)#no ip igmp snooping

** mrouter = port on the Catalyst Switch to the multicast router **.

Tuesday, March 1, 2011

IGMP Snooping

In subnets where IGMP is configured, IGMP snooping manages multicast traffic at Layer 2 to dynamically forward multicast traffic to interfaces that want to receive the multicast traffic only. IGMP snooping, thus, helps reduce the broadcast traffic in the layer 2 network.

Router sends out periodic general IGMP queries. When the IGMP snooping is enabled, the switch will response the query and create the entry per subnet in the layer forwarding table for each layer 2 multicast group. Host which are interested in the multicast traffic send IGMP join request and are added to the forwarding table.

**Note**

IGMP snooping constrains traffic in MAC multicast groups 0100.5e00.0001 - 0100.5eff.ffff

Configuration

- In global configuration : ip igmp snooping vlan <vlan number>

Configure host statically

Command	Purpose
Switch(config-if)# ip igmp snooping vlan vlan_ID static mac_address interface interface_num	Configures a host statically in the VLAN.

Show the multicast MAC address on the Switch

- Show MAC address of the multicast group and list of all ports which are associated with it.

Switch# show mac-address-table multicast vlan <Vlan number>

Multicast MAC address conversion

Multicast MAC address starts with 0100.5e and the range is from 0100.5e00.0000 through 0100.5e7f.ffff. Here is how we convert multicast IP address to MAC address.

Convert IP address into binary. Note that the first 4 bits are always 1110.
Replace first 4 bits with 0100.5e
Replace the next 5 bits with 0
Copy the last 23 bits of the binary IP address
Convert last 24 bits to Hexadecimal digits.

Example

Practice

239.1.1.1
1110 | 1111 | 0000 | 0001 | 0000 | 0001 | 0000 | 0001

0100.5e01.0101

224.12.34.45

1110 | 0000 | 0000 | 1100 | 0010 | 0010 | 0010 | 1101

0100.5e0c.222d

235.220.2.1

1110 | 1011 | 1101 | 1100 | 0000 | 0010 | 0000 | 0001

0100.5e5c.0201

Monday, February 7, 2011

Multicast Boundary

There are many ways to control the size of the multicast domain: In this article, we will talk about TTL and multicast boundary command.

TTL : we use " ip multicast ttl-threshold x " command. When the router receives the multicast packet, it will compare the TTL to the configured value. If the packet TTL is greater than configured TTL, the router will pass the multicast traffic. If not, it will drop. And that is the boundary of the multicast domain.

Example: ip multicast ttl-threshold 240
It will not forward any multicast packet with TTL less than 240

Multicast Boundary : we use "ip multicast boundary <access-list>" command at the interface level of the router stating that this interface is the multicast boundary. The router will not send any multicast traffic (matched the access-list) to the downstream router

Example : ip mutlicast boundary 15
Configured the multicast boundary of the access-list 15

Monday, January 31, 2011

PIM BSR

Note:

The BSR sends mapping messages to 224.0.0.13 (all-PIM-routers). This does notrequire dense mode support or a known RP

Sample Configuraiton

Task:

Configure R1 loopback 0 as a multicast source of 239.1.1.1 group
R2 uses PIM BSR to announce RP.
R3 will be 239.1.1.1 receiver

Configuration

R2
ip pim bsr-candidate Loopback0 0
ip pim rp-candidate Loopback0

interface FastEthernet0/0

ip address 192.168.2.2 255.255.255.0

ip pim sparse-mode

ip igmp join-group 239.1.1.1

duplex auto

speed auto

end

Verify Configuration

R3#sh ip pim rp mapping

PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4

RP 2.2.2.2 (?), v2

Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150

Uptime: 00:05:27, expires: 00:02:20

R3#sh ip mroute

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,

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

Outgoing interface flags: H - Hardware switched, A - Assert winner

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 00:03:25/00:02:55, RP 2.2.2.2, flags: SJPCL

Incoming interface: FastEthernet0/0, RPF nbr 192.168.2.1

Outgoing interface list: Null

(*, 224.0.1.40), 00:09:36/00:01:57, RP 0.0.0.0, flags: DCL

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

FastEthernet0/0, Forward/Sparse, 00:09:36/00:01:57

R1#ping 239.1.1.1 source loopback 0

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

Reply to request 0 from 192.168.2.2, 144 ms

Reply to request 0 from 192.168.2.2, 468 ms

R1#

Multicast Auto-RP

Auto-RP uses 2 multicast addresses to advertise the RP and the mapping information which are 224.0.1.39 and 224.0.1.40. It is operating in a sparse mode. However, there is a issue in the sense that all PIM routers need to join these 2 multicast groups in order to receive the RP announcement information. We encounter this problem by this followings.

PIM sparse-dense mode : in this mode the router will act as if it is in dense mode at first. Then it moves back to sparse mode. Therefore, it will learn the 224.0.1.39 and 224.0.1.40 when it is in dense mode.
Autorp-listener: This command will be configured at the global configuration. It allows only 2 multicast group which are 224.0.1.39 and 224.0.140 to to flood out to all PIM routers. It helps increase efficiency then flooding all multicast group to all routers at once like PIM sparse-dense mode does.

Example Configuration

Explanation

Multicast source of 239.1.1.1 is located at R1 loopback interface with source address of 1.1.1.1
Configure Auto-RP at R2 with RP announce at 2.2.2.2
Configure the mapping agent at R2.
R3 is a receiver of 239.1.1.1 multicast group.

Configuration

R2
ip pim send-rp-announce Loopback0 scope 5
ip pim send-rp-discovery scope 5
!

R3
ip multicast-routing

interface FastEthernet0/0

ip address 192.168.2.2 255.255.255.0

ip igmp join-group 239.1.1.1

duplex auto

speed auto

Debug output

*Mar 1 00:32:00.015: PIM(0): check pim_rp_announce 1

*Mar 1 00:32:00.015: PIM(0): send rp announce

*Mar 1 00:32:14.283: PIM(0): Send RP-reachability for 239.1.1.1 on FastEthernet0/1

*Mar 1 00:32:24.083: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.1.1.1

*Mar 1 00:32:28.999: PIM(0): Received v2 Join/Prune on FastEthernet0/1 from 192.168.2.2, to us

*Mar 1 00:32:29.003: PIM(0): Join-list: (*, 239.1.1.1), RPT-bit set, WC-bit set, S-bit set

*Mar 1 00:32:29.003: PIM(0): Update FastEthernet0/1/192.168.2.2 to (*, 239.1.1.1), Forward state, by PIM *G Join

Verify

R3

show ip mroute

(*, 239.1.1.1), 00:30:14/00:02:25, RP 2.2.2.2, flags: SP

Incoming interface: FastEthernet0/0, RPF nbr 192.168.2.1

Outgoing interface list: Null

When R3 joined the 239.1.1.1 multicast group

R3 Join 239.1.1.1

ip igmp join-group 239.1.1.1

(*, 239.1.1.1), 00:25:13/00:02:27, RP 2.2.2.2, flags: SJPCL

Incoming interface: FastEthernet0/0, RPF nbr 192.168.2.1

Outgoing interface list: Null

R3 received the traffic from R1 lo0 (multicast source)

R3#sh ip mroute

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,

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

Outgoing interface flags: H - Hardware switched, A - Assert winner

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 00:26:20/stopped, RP 2.2.2.2, flags: SJPCL

Incoming interface: FastEthernet0/0, RPF nbr 192.168.2.1

Outgoing interface list: Null

(1.1.1.1, 239.1.1.1), 00:00:16/00:02:48, flags: PLTX

Incoming interface: FastEthernet0/0, RPF nbr 192.168.2.1

Outgoing interface list: Null

(192.168.1.1, 239.1.1.1), 00:00:16/00:02:48, flags: PLTX

Incoming interface: FastEthernet0/0, RPF nbr 192.168.2.1

Outgoing interface list: Null

(*, 224.0.1.39), 00:34:11/stopped, RP 0.0.0.0, flags: DC

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

FastEthernet0/0, Forward/Sparse-Dense, 00:34:11/00:00:00

(2.2.2.2, 224.0.1.39), 00:00:53/00:02:06, flags: PTX

Incoming interface: FastEthernet0/0, RPF nbr 192.168.2.1

Outgoing interface list: Null

(*, 224.0.1.40), 00:35:42/stopped, RP 0.0.0.0, flags: DCL

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

FastEthernet0/0, Forward/Sparse-Dense, 00:35:42/00:00:00

(192.168.2.1, 224.0.1.40), 00:30:12/00:02:37, flags: PLT

Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0

Outgoing interface list: Null

Wednesday, January 19, 2011

Anycast RP

Anycast RP provide RP load balancing and RP redundancy in the network. Each source and receiver of the network will communicate to the nearest RP to request or send a multicast traffic.The source information will be transmitted between two RPs via MSDP protocol in order to sync the source information between MSDP peer.

In this exmaple we have configured R1 and R2 as RP. They announce themselves by using the Auto-RP protocol. MSDP forms a peer relationship between R1 and R2. The RP address has been configure to 1.1.1.1/24 identical to both routers. Loopback 1 is used as a source of msdp peer in order to establish the relationship between them. Please see the diagram between for the network detail.

Configuration

R1

!
interface Loopback0
description RP1 address
ip address 1.1.1.1 255.255.255.0
ip pim sparse-mode
!
interface Loopback1
description MSDP address
ip address 192.168.1.1 255.255.255.0
!
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
ip pim sparse-mode
!
interface FastEthernet0/1
ip address 10.1.2.1 255.255.255.0
ip pim sparse-mode

ip pim send-rp-announce Loopback0 scope 5
ip pim send-rp-discovery Loopback0 scope 5
ip msdp peer 192.168.2.1 connect-source Loopback1
!

R2

interface Loopback0
description RP2 address
ip address 1.1.1.1 255.255.255.0
ip pim sparse-mode
!
interface Loopback1
description MSDP address
ip address 192.168.2.1 255.255.255.0
!
interface FastEthernet0/0
ip address 10.1.1.2 255.255.255.0
ip pim sparse-mode
!
interface FastEthernet0/1
ip address 10.1.3.1 255.255.255.0
ip pim sparse-mode

ip pim send-rp-announce Loopback0 scope 5
ip pim send-rp-discovery Loopback0 scope 5
ip msdp peer 192.168.1.1 connect-source Loopback1
!

debug ip msdp peer

*Mar 1 00:30:58.099: MSDP(0): 192.168.2.1: Sending TCP connect
*Mar 1 00:30:58.191: %MSDP-5-PEER_UPDOWN: Session to peer 192.168.2.1 going up
*Mar 1 00:30:58.191: MSDP(0): 192.168.2.1: TCP connection established
*Mar 1 00:30:59.139: MSDP(0): 192.168.2.1: Sending Keepalive message to peer
*Mar 1 00:31:00.139: MSDP(0): 192.168.2.1: Building SA message from SA cache
*Mar 1 00:31:05.443: MSDP(0): 192.168.2.1: Received 3-byte msg 0 from peer
*Mar 1 00:31:05.447: MSDP(0): 192.168.2.1: Keepalive TLV

Verify configuration

R2#sh ip msdp peer

MSDP Peer 192.168.1.1 (?), AS ?

Connection status:

State: Up, Resets: 0, Connection source: Loopback1 (192.168.2.1)

Uptime(Downtime): 00:13:41, Messages sent/received: 14/14

Output messages discarded: 0

Connection and counters cleared 00:14:35 ago

SA Filtering:

Input (S,G) filter: none, route-map: none

Input RP filter: none, route-map: none

Output (S,G) filter: none, route-map: none

Output RP filter: none, route-map: none

SA-Requests:

Input filter: none

Peer ttl threshold: 0

SAs learned from this peer: 1 ( SA learned a source from peer)

Input queue size: 0, Output queue size: 0

MD5 signature protection on MSDP TCP connection: not enabled

Tuesday, January 11, 2011

Frame Relay Multicast (RPF check failure)

Frame Relay Multicast

When doing multicast in frame relay network, the very important thing we need to take a close look at is RPF check. Since in some types of Frame Relay network, it is not a full mesh topology.

What is RPF?

RPF is used to prevent multicast loop in the network. RPF uses routing table to check whether it prunes the interface or not. When it receives multicast traffic, it checks where the source of multicast traffic is and compare to its routing able and make sure that the received interface and the forwarding interface to the source is the same interface.

For example, if router received the multicast packet on f0/0. It performs RPF check by looking at its routing table to see the forwarding interface back to the multicast source is the f0/0. If it is not, RPF is failed. If it is, RPF check is passed.

In the frame relay Hub and spoke network, RPF check will be failed since the multicast traffic is received from spoke by hub and forward out by hub to another spoke. Therefore we need a tunnel interface to help accomplished this.

Example

Configuration

interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
frame-relay lmi-type ansi
!
interface Serial1/0.1 multipoint
ip address 192.168.1.1 255.255.255.0
ip pim dense-mode
ip igmp join-group 239.1.1.1
ip ospf network point-to-multipoint
snmp trap link-status
frame-relay map ip 192.168.1.2 101 broadcast
frame-relay map ip 192.168.1.3 102 broadcast
no frame-relay inverse-arp

R2

interface Serial1/0
ip address 192.168.1.2 255.255.255.0
ip pim dense-mode
encapsulation frame-relay
ip ospf network point-to-multipoint
serial restart-delay 0
frame-relay map ip 192.168.1.3 202 broadcast
frame-relay map ip 192.168.1.1 202 broadcast
no frame-relay inverse-arp
!

R3

interface Serial1/0
ip address 192.168.1.3 255.255.255.0
ip pim dense-mode
encapsulation frame-relay
ip igmp join-group 239.1.1.1
ip ospf network point-to-multipoint
serial restart-delay 0
frame-relay map ip 192.168.1.2 303 broadcast
frame-relay map ip 192.168.1.1 303 broadcast
no frame-relay inverse-arp
!
R4
A source of 239.1.1.1 multicast group

This configuration will not work in this case since it is a hub and spoke network RPF check is failed. Therefore, we need to configure the tunnel interface between R1 and R3.

Building Tunnel interface

R1

interface Tunnel0
ip address 1.1.1.1 255.255.255.0
ip pim dense-mode
tunnel source Serial1/0.1
tunnel destination 192.168.1.3

R3

interface Tunnel0
ip address 1.1.1.2 255.255.255.0
ip pim dense-mode
tunnel source Serial1/0
tunnel destination 192.168.1.1

Now, multicast traffic is going through tunnel between R1 and R3. To pass the RPF check in R3 routing table should forward packet to source via Tunnel as well. However, R3 uses s1/0 at this time. To make it work, we require to add static multicast route to R3 as follow.

ip mroute 10.10.10.1 255.255.255.255 tunnel0

Then, we pass RPF check and accomplish this task.

Pages

Monday, September 19, 2011

This section was copied from cisco.com

Configuring NetFlow for Multicast IP Traffic

Tuesday, August 16, 2011

Tuesday, August 9, 2011

Wednesday, June 1, 2011

Monday, April 11, 2011

Friday, March 25, 2011

Thursday, March 17, 2011

Wednesday, March 2, 2011

This article is copied from Cisco website

Tuesday, March 1, 2011

Monday, February 7, 2011

Monday, January 31, 2011

Wednesday, January 19, 2011

Tuesday, January 11, 2011