pimd: Indicating the configured PIM Rendezvous Point (RP) in the MSDP SA message #14517
Conversation
adrianomarto
force-pushed
the
pim-msdp-sa-rp
branch
2 times, most recently
from
e78f1f6 to
c48e5f1
Compare
Continuous Integration Result: FAILEDContinuous Integration Result: FAILEDTest incomplete. See below for issues. This is a comment from an automated CI system. Get source / Pull Request: SuccessfulBuilding Stage: SuccessfulBasic Tests: IncompleteTopotests Ubuntu 18.04 arm8 part 6: Failed (click for details)Topotests Ubuntu 18.04 arm8 part 6: Unknown Log URL: https://ci1.netdef.org/browse/FRR-PULLREQ2-14418/artifact/TOPO6U18ARM8/TopotestDetails/ Topotests Ubuntu 18.04 arm8 part 6: No useful log foundUbuntu 20.04 deb pkg check: Incomplete(check logs for details)Successful on other platforms/tests
|
Continuous Integration Result: FAILEDContinuous Integration Result: FAILEDSee below for issues. This is a comment from an automated CI system. Get source / Pull Request: SuccessfulBuilding Stage: SuccessfulBasic Tests: FailedTopotests Ubuntu 18.04 amd64 part 9: Failed (click for details)Topology Test Results are at https://ci1.netdef.org/browse/FRR-PULLREQ2-TOPO9U18AMD64-14419/test Topology Tests failed for Topotests Ubuntu 18.04 amd64 part 9 Successful on other platforms/tests
Warnings Generated during build:Checkout code: Successful with additional warningsTopotests Ubuntu 18.04 amd64 part 9: Failed (click for details)Topology Test Results are at https://ci1.netdef.org/browse/FRR-PULLREQ2-TOPO9U18AMD64-14419/test Topology Tests failed for Topotests Ubuntu 18.04 amd64 part 9 |
Continuous Integration Result: FAILEDTest incomplete. See below for issues. This is a comment from an automated CI system. Get source / Pull Request: SuccessfulBuilding Stage: SuccessfulBasic Tests: IncompleteCentOS 7 rpm pkg check: Incomplete(check logs for details)Ubuntu 18.04 deb pkg check: Incomplete(check logs for details)Debian 10 deb pkg check: Incomplete(check logs for details)Successful on other platforms/tests
|
|
ci:rerun |
|
I see an assertion from you that this is incorrect. Can you provide a reference that this is wrong? Will this break backwards compatibility? |
|
The RFC-3618, section 12.2.1, describes the fields included in the MSDP SA message. The "RP address" field is "the address of the RP in the domain the source has become active in". In the most common case, we will establish an MSDP connection from RP to RP. However, there are cases where we want to establish a MSDP connection from an interface/address that is not the RP. Section 3 of RFC-3618 describes that scenario as "intermediate MSDP peer". Moreover, the RP could be another router in the PIM domain - not the one establishing the MSDP connection. The current implementation could be problematic even with a single router per PIM domain. Consider the following scenario:
With the changes included in this pull request, the multicast source available in router 1 would still be communicated to router 2 twice. But both MSDP SA messages would indicate the same RP, and one of them would be discarded due to failure in the RPF-check failure. Also, the changes allow us to define the RP that will be included in the MSDP SA message, and it could be one of the interfaces used to establish the MSDP connection, some other interface on the router, a loopback interface, or another router in the PIM domain. These changes should not create compatibility issues. As I mentioned, we usually establish MSDP connections from RP to RP. In this case, the result will be the same. We would still indicate the address used to establish the MSDP connection if the RP is not set - I wonder if that should even be a valid configuration. |
|
Can you add this analysis to the commit message? Future programmers would want this |
Indicating the configured PIM Rendezvous Point (RP) in the MSDP SA message The RFC-3618, section 12.2.1, describes the fields included in the MSDP SA message. The "RP address" field is "the address of the RP in the domain the source has become active in". In the most common case, we will establish an MSDP connection from RP to RP. However, there are cases where we want to establish a MSDP connection from an interface/address that is not the RP. Section 3 of RFC-3618 describes that scenario as "intermediate MSDP peer". Moreover, the RP could be another router in the PIM domain - not the one establishing the MSDP connection. The current implementation could be problematic even with a single router per PIM domain. Consider the following scenario: * There are two PIM domains, each one with a single router. * The two routers are connected via two independent networks. Let's say that is to provide redundancy. * The routers are configured to establish two MSDP connections, one on each network (redundancy again). * A multicast source becomes active on the router 1. It will be communicated to router 2 via two independent MSDP SA messages, one per MSDP connection. * Without these changes, each MSDP SA message will indicate a different RP. * Both RP addresses will pass the RPF check, and both MSDP sources will be accepted. * If the router has clients interested in that multicast group, it will send PIM Join messages to both RPs and start receiving the multicast traffic from both. With the changes included in this commit, the multicast source available in router 1 would still be communicated to router 2 twice. But both MSDP SA messages would indicate the same RP, and one of them would be discarded due to failure in the RPF-check failure. Also, the changes allow us to define the RP that will be included in the MSDP SA message, and it could be one of the interfaces used to establish the MSDP connection, some other interface on the router, a loopback interface, or another router in the PIM domain. These changes should not create compatibility issues. As I mentioned, we usually establish MSDP connections from RP to RP. In this case, the result will be the same. We would still indicate the address used to establish the MSDP connection if the RP is not set - I wonder if that should even be a valid configuration. Signed-off-by: Adriano Marto Reis <[email protected]>
adrianomarto
force-pushed
the
pim-msdp-sa-rp
branch
from
c48e5f1 to
95e31a6
Compare
The current implementation sends MSDP Source Active (SA) messages with incorrect RP for the local multicast sources. They indicate the local address used to establish the connection to the MSDP peer as the RP. The correct is to indicate the RP that has been configured via the command "ip pim rp A.B.C.D A.B.C.D/M".
This pull request changes the MSDP SA messages so they indicate the correct RP for local multicast sources.