This lab is setup for Multicast Source Discovery Protocol (MSDP) I will also be applying Source Active (SA) filtering on our Rendezvous Points (RP). On this occasion I will use Auto-RP to discover RP on each domain then use MSDP to enable us to share SA messages about our multicast sources. The SA filtering will be applied to R2 and R3. When using MSDP setup a multicast boundary, imagine a line between domains where you create an access-list which permits or allows any multicast address which you specify.

The reason I am using Auto-RP is to show the significance of using the multicast boundary, we will block the Auto-RP multicast address of 224.0.1.39 and 224.0.1.40 this will guarantee the boundaries between our domains, but not limited to only that purpose.

The main commands you will need are “ip msdp peer [ip address] connect-source [interface]” for SA filtering use the command “ip msdp sa-filter in | out [peer ip] list [access-list]” for the multicast boundary under interface use the command “ip multicast boundary [access-list] in | out filter-autorp” My previous blog “Multicast Notes” will provide a little more detail, and also some examples of access-lists.

MSDP Topology

MSDP Topology

 

Attached are the config’s for each router (Router Configs). As I’m using GNS3 I had to enter commands “no ip route-cache” and “no ip mroute-cache” on each PIM interface. Also add “no ip cef”. You won’t need this for physical routers.

Verify our msdp peers with the command “show ip msdp summary” from R3 shows we have 2 MSDP peers, both show as UP. All is looking good at this point.

R3#sh ip msdp summary
MSDP Peer Status Summary
Peer Address     AS   State   Uptime/  Reset    SA   Peer Name
Downtime Count  Count
10.255.255.2     2     Up         00:09:29      0          0            ?
10.255.255.6     6     Up         00:10:19      0          0            ?

We can also use the command “show ip msdp peer 10.255.255.2” from R3 to show us is if any SA filtering is being applied and also how many SA messages received from the peer. In our example we have received 1 SA message from our peer 10.255.255.2 highlighted in red, and we are filtering inbound SA messages, also highlighted in red.

MSDP Peer 10.255.255.2 (?), AS 2
Connection status:
State: Up, Resets: 0, Connection source: Loopback1 (10.255.255.3)
Uptime(Downtime): 00:17:41, Messages sent/received: 18/19
Output messages discarded: 0
Connection and counters cleared 00:19:31 ago
SA Filtering:
Input (S,G) filter: 101, 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
Input queue size: 0, Output queue size: 0
Message counters:
RPF Failure count: 0
SA Messages in/out: 1/0
SA Requests in: 0
SA Responses out: 0
Data Packets in/out: 0/0

To display any SA messages the router has received we use the command “show ip msdp sa-cache” this will display the source tree entry for any multicast sources our neighbour is aware of, bearing in mind all SA messages are flooded to MSDP neighbours unless filtered by an SA-filtering

R3#sh ip msdp sa-cache
MSDP Source-Active Cache – 1 entries
(74.74.74.5, 239.4.4.4), RP 2.2.2.2, BGP/AS 2, 00:01:50/00:05:04, Peer 10.255.255.2

Now let’s consider SA-filtering, as per my multicast notes blog I will use this to filter messages sent from R2 to R3. The scenario is as follows, R5 is the multicast source of 239.4.4.4 and 232.8.8.8 but R7 doesn’t need to receive multicast traffic from R5 on 232.8.8.8 only traffic from R5 239.4.4.4 is required. So on R2 which is the nearest RP to R5 I will filter outbound messages to R3. In reverse we could do an inbound filter on R2. Configuration is as follows on R2.

access-list 101 permit ip host 74.74.74.5 host 239.4.4.4
!
ip msdp sa-filter out 10.255.255.3 list 101

Let’s test this with a ping to the multicast address.

R5#ping 239.4.4.4 rep 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 239.4.4.4, timeout is 2 seconds:
Reply to request 0 from 74.74.74.1, 28 ms
Reply to request 0 from 17.17.17.7, 156 ms
Reply to request 1 from 74.74.74.1, 52 ms
Reply to request 1 from 17.17.17.7, 180 ms
Reply to request 2 from 74.74.74.1, 48 ms
Reply to request 2 from 17.17.17.7, 176 ms

R5#ping 232.8.8.8 rep 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 232.8.8.8, timeout is 2 seconds:
Reply to request 0 from 74.74.74.1, 52 ms
Reply to request 1 from 74.74.74.1, 48 ms
Reply to request 2 from 74.74.74.1, 40 ms

So as you can see above R7 replies to 239.4.4.4 but not 232.8.8.8, so the filter works as expected.

Also on R2 I used an inbound SA-Filter this does the opposite from an outbound filter. So the commands will only accepts SA-messages from peer 10.255.255.3 with (10.10.10.4 , 232.8.8.8).

ip msdp sa-filter in 10.255.255.3 list 102
access-list 102 permit ip host 10.10.10.4 host 232.8.8.8

Below you can see some packet captures on the routers showing the source active messages being sent from R2 to R3 and also from from R3 to R6.

MSDP SA from R2 -> R3

MSDP SA from R2 -> R3

MSDP SA from R3 -> R6

MSDP SA from R3 -> R6

RH

Advertisements