MSDP Filtering

Load inter-as.multicast.msdp.configured.cfg

#IOS-XE
config replace flash:inter-as.multicast.msdp.configured.cfg
 
#IOS-XR
configure
load bootflash:inter-as.multicast.msdp.configured.cfg
commit replace
y

MSDP peering is already configured. Configure filtering as follows:

  • R10 should limit the number of SAs from XR1 to 500

  • R10 should filter inbound SAs from XR1 that are not sourced from XR1 itself

  • R10 should filter inbound SAs from XR2 that are for group 237/8

  • R10 should not originate SAs for 239/8 to any MSDP peer

  • R10 should filter outbound SAs for 236/8 to XR2

  • XR2 should limit the number of SAs from CSR10 to 500

  • XR2 should filter inbound SAs from XR1 that are not sourced from XR1 itself

  • XR2 should filter inbound SAs from CSR10 that are for group 234/8

  • XR2 should not originate SAs for 239/8 to any MSDP peer

  • XR2 should filter outbound SAs for 236/8 to XR1

Answer

#CSR10
ip msdp sa-limit 7.0.0.11 500
ip msdp sa-filter in 7.0.0.11 rp-list XR1_RP_ADDRESS
ip msdp sa-filter in 8.0.0.12 list XR2_FILTER_IN
ip msdp redistribute list LOCAL_TO_MSDP
ip msdp sa-filter out 8.0.0.12 list XR2_FILTER_OUT

ip access-l stand XR1_RP_ADDRESS
 permit host 7.0.0.11

ip access-l ext XR2_FILTER_IN
 deny ip any 237.0.0.0 0.255.255.255
 permit ip any any

ip access-l ext LOCAL_TO_MSDP
 deny ip any 239.0.0.0 0.255.255.255
 permit ip any any

ip access-l ext XR2_FILTER_OUT
 deny ip any 236.0.0.0 0.255.255.255
 permit ip any any

#XR2
ipv4 access-list XR1_RP_ADDRESS
 10 permit ipv4 host 7.0.0.11 any
!
ipv4 access-list CSR10_FILTER_IN
 deny ip any 234.0.0.0 0.255.255.255
 permit ip any any
!
ipv4 access-list DENY_PRIVATE_GROUPS
 10 deny ipv4 any 239.0.0.0/8
 20 permit ipv4 any any
!
ipv4 access-list XR1_FILTER_OUT
 deny ip any 236.0.0.0/8
 deny ip any 239.0.0.0/8
 permit ip any any

router msdp
 sa-filter out list DENY_PRIVATE_GROUPS
 !
 peer 7.0.0.11
  sa-filter in rp-list XR1_RP_ADDRESS
  sa-filter out list XR1_FILTER_OUT
 !
 peer 9.0.0.10
  maximum external-sa 500
  sa-filter in list CSR10_FILTER_IN

Pitfall

On IOS-XR there does not appear to be a way to filter (S, G) states that are “redistributed” into MSDP. Instead, we can apply a global sa-filter outbound. However, when you apply an outbound filter for a specific peer such as XR1, this will override the higher-level outbound SA filter. You must remember to deny 239/8 outbound for each peer that has an explicit outbound SA filter.

#XR2
ipv4 access-list DENY_PRIVATE_GROUPS
 10 deny ipv4 any 239.0.0.0/8
 20 permit ipv4 any any
!
ipv4 access-list XR1_FILTER_OUT
 deny ip any 236.0.0.0/8
 deny ip any 239.0.0.0/8                  <------- Remember this
 permit ip any any

router msdp
 sa-filter out list DENY_PRIVATE_GROUPS
 !
 peer 7.0.0.11
  sa-filter out list XR1_FILTER_OUT

Verification

CSR10

Verify the SA limit for XR1 is set on CSR10:

Verify that SAs using any other originator-ID on XR1 are rejected on CSR10. For example, we can change XR1’s originator ID to 10.10.11.11:

#XR1
router msdp
 originator-id Gi0/0/0/0.501

#CSR10
debug ip msdp 7.0.0.11 routes
debug ip msdp 7.0.0.11 peer

SAs from CSR9 that are reflected by XR1 should also be filtered out.

Verify that SAs from XR2 for group 237/8 are filtered, but any other group is not filted. Ping these groups from CSR3 to generate the SAs on XR2.

#CSR10
debug ip msdp 8.0.0.12 peer
debug ip msdp 8.0.0.12 routes

Verify that traffic from CSR2 to 239.0.0.0/8 does not produce an SA on CSR10, but traffic from any other group does.

#CSR2
ping 239.1.1.1 repeat 3
ping 230.1.1.1 repeat 3

Verify that traffic from CSR2 to 236/8 creates an SA that is advertised to CSR9 but not XR2.

XR2

In IOS-XR there does not appear to be a way to display the max SA limit.

Verify that SAs reflected from CSR9 to XR1 to XR2 are rejected on XR2 due to the originating RP address not being XR1’s loopback. Currently XR2’s best path to CSR9 is via XR1 due to the best path to 11.0.0.9 being via AS 7. If CSR4 originates multicast traffic, we should see no SA state on XR2. The SA reflected via CSR10 is rejected for RPF check, and the SA reflected via XR1 is rejected for originator ID.

Verify that traffic from CSR2 (which generates an SA by CSR10) is filtered for group 234/8 on XR2.

#CSR2
ping 234.1.1.1 repeat 5
ping 235.1.1.1 repeat 5

Verify that traffic from CSR3 to 239/8 is not advertised to any peers, but any other group is.

#CSR3
ping 239.1.1.1 repeat 3
ping 231.3.3.3 repeat 3

On IOS-XR, there doesn’t appear to be a “show advertised-SAs” command, so we can verify this on CSR10.

Verify that traffic from CSR3 to 236/8 is advertised to CSR10 but not XR1.

Last updated