Multicast MSDP SA (Source Active) Filtering

MSDP uses SA (Source Active) messages that contain S,G (Source Group) information for RPs (Rendezvous Points) in PIM sparse domains. Thanks to MSDP, RPs can learn about multicast sources in remote PIM sparse domains. With a default MSDP configuration, all SA messages are advertised and received between MSDP peers.

On your network, there are probably a couple of S,G states that should stay within your network and that don’t have to be advertised to MSDP peers on remote networks. For example:

    • Local applications that use multicast and that are only used on the LAN.
    • Multicast traffic that uses private addresses as the source.
  • Multicast groups in the private 239.0.0.0/8.

By enabling MSDP SA filtering of some S,G states we:

  • Reduce the number of MSDP SA messages that are exchanged between MSDP peers.
  • Reduce the size of the MSDP SA cache.
  • Don’t leak information about S,G state information that remote peers shouldn’t know about.

Configuration

To demonstrate MSDP SA filtering, I use this topology:

Msdp Sa Filtering Topology

Here’s what we have:

  • R1 and H1 are one LAN1, R2 and H2 are on LAN2.
  • R1 and R2 are connected to each other with a private WAN connection.
  • R1 is the RP in LAN1.
  • R2 is the RP in LAN2.
  • R1 and R2 are MSDP peers.
  • H1 and H2 are only used to ping different multicast groups to trigger MSDP SA messages.

Configurations

Want to take a look for yourself? Here you will find the startup configuration of each device.

H1

hostname H1
!
no ip routing
!
no ip cef
!
interface GigabitEthernet0/1
 ip address 192.168.1.1 255.255.255.0
!
ip default-gateway 192.168.1.254
!
end

H2

hostname H2
!
no ip routing
!
no ip cef
!
interface GigabitEthernet0/1
 ip address 192.168.2.2 255.255.255.0
!
ip default-gateway 192.168.2.254
!
end

R1

hostname R1
!
no ip domain lookup
ip multicast-routing 
ip cef
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 ip pim sparse-mode
!
interface GigabitEthernet0/1
 ip address 12.12.12.1 255.255.255.0
!
interface GigabitEthernet0/2
 ip address 192.168.1.254 255.255.255.0
 ip pim sparse-mode
!
ip pim rp-address 1.1.1.1
ip msdp peer 12.12.12.2 connect-source GigabitEthernet0/1
ip msdp originator-id GigabitEthernet0/1
!
end

R2

hostname R2
!
no ip domain lookup
ip multicast-routing 
ip cef
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip pim sparse-mode
!
interface GigabitEthernet0/1
 ip address 12.12.12.2 255.255.255.0
!
interface GigabitEthernet0/2
 ip address 192.168.2.254 255.255.255.0
 ip pim sparse-mode
!
ip pim rp-address 2.2.2.2
ip msdp peer 12.12.12.1 connect-source GigabitEthernet0/1
ip msdp originator-id GigabitEthernet0/1
!
end

Let’s take a look at our MSDP peering:

R1#show ip msdp peer 
MSDP Peer 12.12.12.2 (?), AS ?
  Connection status:
    State: Up, Resets: 0, Connection source: GigabitEthernet0/1 (12.12.12.1)
    Uptime(Downtime): 00:03:09, Messages sent/received: 4/4
    Output messages discarded: 0
    Connection and counters cleared 00:04:09 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: 0
  Number of connection transitions to Established state: 1
    Input queue size: 0, Output queue size: 0
  MD5 signature protection on MSDP TCP connection: not enabled
  Message counters:
    RPF Failure count: 0
    SA Messages in/out: 0/0
    SA Requests in: 0
    SA Responses out: 0
    Data Packets in/out: 0/0

As you can see above, nothing is filtered at all. This means that all S,G state entries are exchanged through MSDP.  Let’s try a quick ping from H1 to see if this is true:

H1#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:
.

The ping fails since there is no listener for this multicast group but it doesn’t matter. This adds an entry in the multicast routing table that will be exchanged through MSDP. Let’s check R2:

R2#show ip msdp sa-cache 
MSDP Source-Active Cache - 1 entries
(192.168.1.1, 239.1.1.1), RP 12.12.12.1, AS ?,00:00:23/00:05:41, Peer 12.12.12.1

Above, we see that R2 has received an entry for 239.1.1.1 with RP 1.1.1.1 in its MSDP SA cache.

Let’s try to filter some things. I’ll create the following access-list on both MSDP routers:

R1 & R2
(config)#ip access-list extended MSDP_SA_FILTER

Let’s look at some example of what we could filter now.

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 798 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

543 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,


Forum Replies

  1. Hi Rene,

    I think this topics should be also put in CCIE R/S since its on CCIE blue printer, not only under written…just a suggestion

  2. Hello Samer

    Thanks for the suggestion! @ReneMolenaar will take a look and when he gets a chance.

    Thanks again!

    Laz

  3. Hi Rene
    I really confuse about this, since R1 connected to R2 via internet, so MSDP can establish peering through global network which not enable multicast routing like internet ? and can we send multicast traffic from one site to one site through internet without using VPN ?
    Sovandara
    Thank you

  4. Hello Heng

    The important thing to note here is that multicast mechanisms are not being employed over the Internet itself. MSDP allows for two edge routers to share multicast information such that multicast traffic can be sent between them. Such multicast traffic is sent using PIM Sparse Mode, which means that multicast traffic traversing the internet is sent to the RP that is at the edge of the other autonomous system and is being used as the specific “next hop” of the multicast traffic. Remember, the RP knows about all the sources and receivers for any part

    ... Continue reading in our forum

  5. Hello René,

    Great work, thank you.
    I had a problem with your ACL that match also the source address deny ip 192.168.0.0 0.0.255.255 any, with this entry the filter will not work because the source is using 192.168.0.0/24 segment. could you confirm that please ?
    regards,

4 more replies! Ask a question or join the discussion by visiting our Community Forum