MSDP Filtering
Last updated
Last updated
Load inter-as.multicast.msdp.configured.cfg
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
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.
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:
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.
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.
Verify that traffic from CSR2 to 236/8 creates an SA that is advertised to CSR9 but not 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.
Verify that traffic from CSR3 to 239/8 is not advertised to any peers, but any other group is.
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.
