Home > cisco > Multicast, MPLS and MDT’s, oh my!

Multicast, MPLS and MDT’s, oh my!

Here, as promised, is my first post of real substance!  I’ve been building a new core network for the health system I work at and one of the requirements was to enable multicast across the wired as well as wireless network.  Seems fairly straightforward at first, enable PIM on all interfaces that could potentially carry multicast traffic, set up your RP’s (auto-rp, bsr, or manually) and off you go.

Well, the new core network is MPLS based, and has a set of firewalls filtering traffic between VRF’s so there is a bit more to getting multicast to work which I will walk through here.  I also have a mix of Cisco Nexus 7k’s in my core and 6500’s in my distribution layers and there is a caveat that needs to be addressed which I will go over as well.

The network is a pair of Nexus 7k’s as the core of the MPLS network with 6509’s hung off of them acting as building distribution PE’s.  Routing between VRF’s is handled by an “Interchange” router that is northbound of the core switches and an ASA in transparent mode, sits in between the core and interchange routers handing firewall duties for each VRF:

network overview

I am using pim sparse mode so first thing to do is set up our rendezvous points.  I want some redundancy so I will set up anycast RP’s using MSDP between the pair of interchange routers as all inter-VRF traffic must traverse these routers anyway.

On Interchange Router1:

feature pim
feature msdp
ip pim rp-address 10.252.0.99 group-list 224.0.0.0/4
ip msdp originator-id loopback0
ip msdp peer 10.252.0.103 connect-source loopback0 remote-as 65050

On Interchange Router2:

feature pim
feature msdp
ip pim rp-address 10.252.0.99 group-list 224.0.0.0/4
ip msdp originator-id loopback0
ip msdp peer 10.252.0.102 connect-source loopback0 remote-as 65050

We are using MSDP since each RP is basically in its own PIM domain and in order for both RP’s to see all active sources we need to set up msdp peering between them so in the event one of the RP’s goes down, the other will know about any active sources and clients will still be able to join any active multicast groups.

Another point to remember is that if your routing protocol is BGP, such as it is here, your MSDP peering address and BGP source address should be the same in order to pass the RPF check.

We also need to enable pim sparse mode on all interfaces that will carry multicast traffic.  In this example on the interchange routers we have 3, vlan 301 which is the user network, vlan 309 which is the video network and vlan 307 which is the wireless network.  These vlans traverse their own firewall context on the ASA and end up in their respective VRF on the core Nexus routers.

Here is where the fun begins!  We need to enable multicast within each VRF that will carry multicast traffic. We will do this by configuring a MDT per VRF. There are two types of MDT’s you can configure, one is required and one is optional but highly recommended.

Required: Default-MDT – Used to send low bandwidth and control traffic to all PE’s with VRF’s configured for this MDT
Optional: Data-MDT – Used to send high bandwidth streams only to PE’s with interested receivers.

Also, make sure to have PIM-SM enabled on all PE and P router interfaces carrying MPLS traffic as MDT relies on the underlying core network having PIM enabled.

On both Core1 and Core2 Nexus routers here is the configuration:

feature pim
feature mvpn
!
vrf context user
ip pim rp-address 10.252.0.99 group-list 224.0.0.0/4
ip pim ssm range none
ip pim pre-build-spt
mdt default 239.232.0.10
no mdt enforce-bgp-mdt-safi
mdt data 239.232.10.0/24 threshold 1
!
vrf context video
ip pim rp-address 10.252.0.99 group-list 224.0.0.0/4
ip pim ssm range none
ip pim pre-build-spt
mdt default 239.232.0.30
no mdt enforce-bgp-mdt-safi
mdt data 239.232.30.0/24 threshold 1
!
vrf context wireless
ip pim rp-address 10.252.0.99 group-list 224.0.0.0/4
ip pim ssm range none
ip pim pre-build-spt
mdt default 239.232.0.70
no mdt enforce-bgp-mdt-safi
mdt data 239.232.70.0/24 threshold 1

The threshold keyword on the mdt-data configuration tells the switch when to transition traffic from the shared tree (MDT-Default) to the source tree (MDT-Data) so as not to flood traffic out unnecessarily. The threshold here is configured for 1 kbps.

Also, here is the caveat I was talking about earlier. You MUST use the threshold keyword and specify a value when configuring Data-MDT’s between Nexus and 6500 switches. Otherwise, traffic will never switch over to the Data-MDT and multicast traffic will be flooded across the Default-MDT to any 6500’s in the topology. This is not an issue if all you have are 6500’s only or Nexus only.

The VLANs on the MPLS side of the firewall are 201,207 and 209 for user, wireless and video respectively:

int vlan 201
vrf member user
ip address a.a.a.a/28
ip pim sparse
!
int vlan 207
vrf member wireless
ip address b.b.b.b/28
ip pim sparse
!
int vlan 209
vrf member video
ip address c.c.c.c/28
ip pim sparse

The Default-MDT by default builds its tunnels off of the same interface that BGP updates are sourced from so be sure to enable PIM-SM on that interface as well. In this topology, that would be loopback 0.

We now need to configure the MDT address family under BGP so that we can propagate MDT info throughout the MPLS network to other PE’s:

router bgp 65050
neighbor x.x.x.x
address-family ipv4 mdt
send-community extendedneighbor y.y.y.y
address-family ipv4 mdt
send-community extended

Now to configure the Default and Data MDT’s on the 6500 distribution switch. this switch will have our user,video and mgmt SVI’s on it.

ip multicast-routing vrf user
ip multicast-routing vrf video
ip multicast-routing vrf wireless
!
ip pim vrf user rp-address 10.252.0.99
ip pim vrf video rp-address 10.252.0.99
ip pim vrf wireless rp-address 10.252.0.99
!
vrf definition user
address-family ipv4
mdt default 239.232.0.10
mdt data 239.232.10.0 0.0.0.255
exit-address-family
!
vrf definition wireless
address-family ipv4
mdt default 239.232.0.70
mdt data 239.232.70.0 0.0.0.255
exit-address-family
!
vrf definition video
address-family ipv4
mdt default 239.232.0.30
mdt data 239.232.30.0 0.0.0.255
exit-address-family
!
router bgp 65050
address-family ipv4 mdt
neighbor x.x.x.x activate
neighbor x.x.x.x send-community both
neighbor y.y.y.y activate
neighbor y.y.y.y send-community both
exit-address-family
!
int vlan 100
dec — User Network —
ip pim sparse
!
int vlan 200
desc — Video Network —
ip pim sparse
!
int vlan 300
desc — Wireless Network —
ip pim sparse

Now that we have everything configured, lets do some verification. First lets verify our MSDP peers are up and see each other:

n7k-interchange# sh ip msdp peer
MSDP peer 10.252.0.103 for VRF “default”
AS 65051, local address: 10.252.0.102 (loopback0)
Description: none
Connection status: Established
Uptime(Downtime): 6w1d
Last reset reason: TCP read error
Password: not set
Keepalive Interval: 60 sec
Keepalive Timeout: 90 sec
Reconnection Interval: 10 sec
Policies:
SA in: none, SA out: none
SA limit: unlimited

Great, we see our Connection status is Established. This peer (10.252.0.102) is the one that is preferred by our IGP so it knows about all active sources. Our peer on the other hand only knows about them via this peering relationship. To see what active sources it is learning about we issue the following command:

n7k-interchange# sh ip msdp sa-cache
MSDP SA Route Cache for VRF “default” – 104 entries
Source Group RP ASN Uptime
10.123.146.75 224.0.1.60 10.252.0.102 0 05:28:10
10.123.162.11 224.0.1.60 10.252.0.102 0 02:25:46
10.123.162.56 224.0.1.60 10.252.0.102 0 2d04h
10.123.194.66 224.0.1.60 10.252.0.102 0 04:44:25
10.125.170.54 224.0.1.60 10.252.0.102 0 4d01h
10.125.174.123 224.0.1.60 10.252.0.102 0 05:14:48
10.193.43.231 224.0.1.60 10.252.0.102 0 4w1d
152.16.164.175 224.0.1.60 10.252.0.102 0 00:04:14
10.193.77.17 224.0.1.184 10.252.0.102 0 3w0d
10.126.51.70 224.0.23.63 10.252.0.102 0 01:20:11
10.126.51.90 224.0.23.63 10.252.0.102 0 1d21h
10.126.51.202 224.0.23.63 10.252.0.102 0 01:24:19
10.127.165.239 224.0.23.63 10.252.0.102 0 00:53:52
10.127.165.254 224.0.23.63 10.252.0.102 0 21:22:05
10.123.155.154 224.123.155.154 10.252.0.102 0 2d14h
10.125.236.118 224.125.236.118 10.252.0.102 0 1d18h
….

So now that we know our anycast RP’s are working correctly, lets set up a stream and verify that traffic actually is flowing. I have VLC sending out an audio stream within the Video VRF to the group 239.252.100.1 and I will have another host in the User VRF attempt to listen to the audio.

Here is the (S,G) route learned by the RP:

n7k-interchange# sh ip mroute 239.252.100.1 det
IP Multicast Routing Table for VRF “default”
!
Total number of routes: 214
Total number of (*,G) routes: 65
Total number of (S,G) routes: 149
Total number of (*,G-prefix) routes: 0
!
(10.153.8.10/32, 239.252.100.1/32), uptime: 1w6d, pim ip
Stats: 26248142/35382495416 [Packets/Bytes], 251.627 kbps
Attached oif(s) : No
Incoming interface: Vlan309, RPF nbr: 10.253.209.1, internal
Outgoing interface list: (count: 1)
Vlan301, uptime: 1w6d, pim

As you can see, traffic from this server is incoming on VLAN 309 which connects to the video VRF and is outgoing to the client in the User VRF on VLAN 301 at a rate of about 251 kbps.

Advertisements
Categories: cisco Tags: ,
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: