|
0:00:13
|
In our next section for multicast routing, we're going to talk about
|
|
0:00:16
|
the multicast source distribution protocol or MSDP
|
|
0:00:20
|
and how it can be applied to implement any cast RP
|
|
0:00:24
|
for load balancing between different rendezvous points within
|
|
0:00:26
|
one single multicast network.
|
|
0:00:30
|
Now MSDP just like PIM and IGMP the other protocols
|
|
0:00:34
|
that we talked about up to this point, it is an open
|
|
0:00:37
|
standard if you want to get the packet level information
|
|
0:00:40
|
about it, that's definitely going to be the best resource
|
|
0:00:42
|
is RFC 3618
|
|
0:00:44
|
additionally that book that I mentioned before the inter-AS
|
|
0:00:48
|
multicast for Cisco -- solutions
|
|
0:00:51
|
that's another good printed resource for information about
|
|
0:00:55
|
MSDP where originally this protocol was designed for
|
|
0:00:59
|
inter-AS multicast routing whereas service providers
|
|
0:01:03
|
over the internet would run PIM in sparse mode on their
|
|
0:01:07
|
transit links between each other, but use MSDP
|
|
0:01:11
|
to peer between rendezvous points to exchange what are the active
|
|
0:01:16
|
multicast sources in the network.
|
|
0:01:19
|
Now the key to understand about MSDP is that it is not
|
|
0:01:22
|
a replacement for PIM and it's unrelated to
|
|
0:01:27
|
multicast BGP.
|
|
0:01:28
|
Simply what this is designed to do is do basically a PIM
|
|
0:01:33
|
registration message between multiple rendezvous points.
|
|
0:01:38
|
So normally when a source becomes active in the network
|
|
0:01:42
|
the router that is connected to the source is going to tell the
|
|
0:01:46
|
rendezvous point that this particular s,g entry is sending
|
|
0:01:50
|
based on the PIM register message.
|
|
0:01:53
|
Once the rendezvous point receives that, it will acknowledge
|
|
0:01:56
|
the designated router and install the s,g entry into the
|
|
0:02:00
|
multicast routing table.
|
|
0:02:03
|
Now the problem with using the same type of logic as a
|
|
0:02:06
|
large scale inter-AS design
|
|
0:02:09
|
is that the routers may not want to install the state information
|
|
0:02:12
|
for every possible source in the inter-AS network.
|
|
0:02:18
|
So with MSDP, it's an optimization as compared
|
|
0:02:21
|
to the regular PIM registration
|
|
0:02:24
|
because when we receive the information about the sources
|
|
0:02:27
|
we're not automatically going to create the state information
|
|
0:02:30
|
in the multicast routing table.
|
|
0:02:32
|
We're simply going to keep a separate cached copy
|
|
0:02:36
|
of what the source is and groups that they're sending to
|
|
0:02:39
|
then ultimately if a client reports that it wants to
|
|
0:02:43
|
receive traffic for a particular multicast group, we can signal
|
|
0:02:46
|
through the normal PIM join messages
|
|
0:02:49
|
to add the hop by hop interfaces to the shortest path tree
|
|
0:02:54
|
from the sender all the way down to the receiver.
|
|
0:02:58
|
Now MSDP is a TCP based protocol which implies that
|
|
0:03:03
|
the rendezvous points would need some sort of IGP
|
|
0:03:07
|
or typically BGP reachability to each other when we're dealing
|
|
0:03:10
|
with an inter-AS design
|
|
0:03:14
|
where this TCP transport is going to be used to advertise
|
|
0:03:16
|
what is known as the source active or the MSDP SA messages
|
|
0:03:22
|
to advertise between the different autonomous systems
|
|
0:03:24
|
who the senders are.
|
|
0:03:27
|
Now only once the remote rendezvous points receive the
|
|
0:03:30
|
*,G PIM joins for the particular groups will the actual
|
|
0:03:36
|
s,g tree be built from the source down to the final destination.
|
|
0:03:43
|
So similar to the normal rendezvous point in PIM sparse mode
|
|
0:03:46
|
the MSDP peer is only used for the control plane information
|
|
0:03:51
|
and not necessarily in the transit path of the data plane forwarding.
|
|
0:03:57
|
So the MSDP peer is going to know about the source
|
|
0:03:59
|
and it's going to be used to build the shortest path tree
|
|
0:04:02
|
but it doesn't necessarily mean that it's actually in the
|
|
0:04:05
|
forwarding path for that particular sender and destination.
|
|
0:04:08
|
It's going to be based on the normal destination
|
|
0:04:12
|
route back to the original source.
|
|
0:04:16
|
So even for the inter-AS routing, we're still using
|
|
0:04:19
|
the reverse of the unicast routing.
|
|
0:04:21
|
We're doing the routing based on the source address
|
|
0:04:24
|
not based on the destination address.
|
|
0:04:27
|
Once the tree is built from the receiver back to the sender
|
|
0:04:30
|
then the traffic is going to be routed based on the normal
|
|
0:04:33
|
multicast routing table using the incoming interface
|
|
0:04:36
|
pointing towards the source and the outgoing interface
|
|
0:04:39
|
pointing down towards the destinations.
|
|
0:04:44
|
Now as I mentioned originally MSDP was designed for an
|
|
0:04:47
|
inter-AS multicast application where we are typically running this
|
|
0:04:51
|
between different BGP autonomous systems
|
|
0:04:54
|
but it also can be used for an intra-AS design
|
|
0:04:58
|
that is called anycast rendezvous point or anycast RP in order to
|
|
0:05:03
|
use a very basic IGP based load balancing
|
|
0:05:08
|
to get redundancy between the different rendezvous points.
|
|
0:05:13
|
Now the key point of anycast that's not necessarily specific
|
|
0:05:16
|
to multicast routing for the rendezvous points
|
|
0:05:19
|
is that anycast means a one to any routing paradigm
|
|
0:05:24
|
as opposed to one to one for unicast or one to many
|
|
0:05:28
|
for multicast.
|
|
0:05:31
|
So in a one to any routing design, it means that
|
|
0:05:36
|
whoever the destination's address is there can be
|
|
0:05:40
|
multiple physical devices in the network that are sharing
|
|
0:05:42
|
that same address.
|
|
0:05:45
|
Based on the underlying routing topology whether this be
|
|
0:05:48
|
IGP or BGP or even static routing, whoever the closest
|
|
0:05:54
|
neighbor is based on our routing metrics
|
|
0:05:57
|
is the device that is going to be receiving our traffic.
|
|
0:06:02
|
So again, a good practical example of this is how the
|
|
0:06:05
|
top level DNS servers work on the internet.
|
|
0:06:09
|
In order to load balance between them, they simply
|
|
0:06:11
|
have the same IP address that is advertised
|
|
0:06:14
|
into global BGP.
|
|
0:06:16
|
So let's say for example it's 1.1.1.1
|
|
0:06:20
|
Now depending on where I am physically in the network
|
|
0:06:24
|
I'm going to look at what my closest route is to the destination
|
|
0:06:28
|
1.1.1.1
|
|
0:06:30
|
If I'm in US West Coast most likely I'm going to
|
|
0:06:33
|
use US West Coast DNS servers.
|
|
0:06:35
|
If I'm on US East Coast, likewise. If I am Western Europe
|
|
0:06:38
|
it's going to be some server over there.
|
|
0:06:41
|
But the key is no matter which top level DNS server I query
|
|
0:06:45
|
since their databases are the same, it doesn't really matter
|
|
0:06:49
|
where I get the information from.
|
|
0:06:51
|
So as long as they're doing the out of band synchronization
|
|
0:06:55
|
of the DNS zone transfers
|
|
0:06:59
|
then regardless of whether I query a server that's in
|
|
0:07:02
|
San Jose or New York or London
|
|
0:07:04
|
ultimately I'm going to get the same information.
|
|
0:07:08
|
So the key behind anycast is that as long as the anycast
|
|
0:07:11
|
destinations are basically mirrors of each other
|
|
0:07:15
|
it doesn't really matter where you go.
|
|
0:07:17
|
So you can think of this as kind of like a poor man's load balancing
|
|
0:07:21
|
where if you were to take your two web servers and just assign them
|
|
0:07:24
|
identical IP addresses, when the web request is received
|
|
0:07:28
|
by the network, it's going to be routed based on whatever the
|
|
0:07:31
|
closest web server is based on the topology.
|
|
0:07:36
|
Now the problem we run into though is that if
|
|
0:07:38
|
there is a disconnect in the control plane of one anycast
|
|
0:07:42
|
RP versus another, we want to avoid the case
|
|
0:07:46
|
where one of the rendezvous points knows about a sender
|
|
0:07:48
|
and a different one knows about a receiver.
|
|
0:07:52
|
And this is where MSDP comes in to make sure that the
|
|
0:07:55
|
rendezvous points have synchronized information
|
|
0:07:57
|
about who the sources are.
|
|
0:08:01
|
So the load balancing mechanism is going to be based on just the
|
|
0:08:05
|
fact that we're going to use our closest IGP route to the
|
|
0:08:07
|
destination, then if any of these devices happen to go
|
|
0:08:11
|
down, we're simply going to reroute based on our IGP convergence.
|
|
0:08:15
|
And if we can get subsecond or somewhere near that order of
|
|
0:08:19
|
convergence, it ultimately means that our multicast
|
|
0:08:23
|
convergence should be just as fast
|
|
0:08:26
|
because when we look at the alternate mechanisms
|
|
0:08:29
|
like using auto RP or BSR
|
|
0:08:31
|
it's generally going to take much longer to remove
|
|
0:08:35
|
the stale rendezvous point information from a BSR message
|
|
0:08:39
|
and then advertise new information than it is to
|
|
0:08:42
|
have IGP just reconverge to a new address.
|
|
0:08:48
|
So in our particular topology let's look at an example of this
|
|
0:08:51
|
by having Router 3 and Router 5 advertise
|
|
0:08:56
|
the duplicate address 1.1.1.1
|
|
0:08:59
|
into IGP
|
|
0:09:04
|
So the first thing we're going to do is go to these
|
|
0:09:08
|
two devices and configure these as loopback addresses.
|
|
0:09:12
|
So on Router 3 we'll say interface loopback 1
|
|
0:09:16
|
address 1.1.1.1
|
|
0:09:20
|
/32
|
|
0:09:26
|
Next after we configure the address, we're going to go under the
|
|
0:09:30
|
EIGRP process
|
|
0:09:34
|
advertise the prefix 1.1.1.1
|
|
0:09:38
|
into IGP
|
|
0:09:43
|
and the same thing on Router 5
|
|
0:10:03
|
Now we do have to take into account since both Router 5
|
|
0:10:06
|
and Router 3 have overlapping addresses
|
|
0:10:08
|
that if these loopbacks were used as the router IDs
|
|
0:10:12
|
in EIGRP or OSPF or BGP
|
|
0:10:15
|
then we could potentially have some other design issues in the network.
|
|
0:10:19
|
We know specifically in the case of EIGRP if there's
|
|
0:10:22
|
duplicate router IDs it means that these devices
|
|
0:10:24
|
will not be able to install each other's external routes.
|
|
0:10:28
|
And the case of OSPF if we have duplicate router IDs in the same area
|
|
0:10:33
|
when one router originates an LSA, the other one is going
|
|
0:10:36
|
to withdraw it.
|
|
0:10:39
|
For any inter area OSPF we would not be able to
|
|
0:10:42
|
accept the type three LSAs that are originated about our same address
|
|
0:10:46
|
so just in general, it's going to break a lot of things about
|
|
0:10:49
|
the network if we have overlapping addresses.
|
|
0:10:52
|
So this would then imply for my BGP configuration
|
|
0:10:56
|
for OSPF, LDP and MPLS I would want to make sure
|
|
0:11:00
|
that 1.1.1.1 is not the router ID.
|
|
0:11:05
|
Now from the other devices in the network let's say I were to go
|
|
0:11:07
|
to Switch 3 and telnet to 1.1.1.1
|
|
0:11:15
|
From Switch 3's perspective, the closest device in the topology
|
|
0:11:19
|
is Router 3
|
|
0:11:22
|
Now if I were to go somewhere else let's say from Switch 4
|
|
0:11:27
|
and do the same thing telnet 1.1.1.1
|
|
0:11:33
|
its closest device in the topology is Router 5
|
|
0:11:37
|
Now if Router 3 were to fail
|
|
0:11:39
|
then the IGP network would reconverge for the rest of
|
|
0:11:42
|
the devices in the network to continue to use Router 5
|
|
0:11:49
|
so at this point we have our basic load balancing configured just
|
|
0:11:51
|
for the address 1.1.1.1
|
|
0:11:59
|
The next step would be to configure these addresses
|
|
0:12:02
|
as the rendezvous point for the network
|
|
0:12:04
|
regardless of whether we're doing this statically or dynamically.
|
|
0:12:07
|
So everyone could simply say ip pim rp address 1.1.1.1
|
|
0:12:13
|
or advertise this into auto RP or to BSR
|
|
0:12:20
|
Next we're going to configure an MSDP peering between
|
|
0:12:23
|
Router 1 and Router 3 or Router 3 and Router 5 excuse me
|
|
0:12:26
|
but we need to make sure that this is not using the address
|
|
0:12:29
|
1.1.1.1
|
|
0:12:35
|
Since these devices are going to be TCP peers with each other
|
|
0:12:38
|
it doesn't make sense that Router 3 would be able to source
|
|
0:12:41
|
a packet from 1.1.1.1 going to 1.1.1.1
|
|
0:12:47
|
so the devices are still going to have some sort of globally
|
|
0:12:49
|
routable address that they're going to be referencing each other through.
|
|
0:12:54
|
Now we'll see once the actual registrations happen for PIM
|
|
0:12:58
|
or the join messages, the devices are going to communicate this
|
|
0:13:02
|
with MSDP and ultimately have synchronized information
|
|
0:13:06
|
about what's going on in the multicast topology.
|
|
0:13:10
|
So our next step on all of the devices in the multicast network
|
|
0:13:13
|
we'll simply configure them as the -- to have 1.1.1.1
|
|
0:13:20
|
as the rendezvous point's address.
|
|
0:13:28
|
So in global config we'll say ip pim rp address
|
|
0:13:31
|
1.1.1.1
|
|
0:13:35
|
then on Router 5 I'm going to withdraw the previous
|
|
0:13:38
|
BSR information.
|
|
0:13:40
|
Now I could advertise this with BSR that would be fine
|
|
0:13:43
|
the key is that I would need to make sure that the BSR's address is
|
|
0:13:47
|
unique and that it's advertising the candidate RP address of 1.1.1.1
|
|
0:13:58
|
So Router 5 is going to withdraw the BSR candidate
|
|
0:14:06
|
and it's no longer the RP candidate so that's fine.
|
|
0:14:08
|
If we now look at the show ip pim
|
|
0:14:11
|
rp mapping
|
|
0:14:15
|
we have a static rendezvous point assignment of 1.1.1.1
|
|
0:14:19
|
and everyone should already have an IGP route to this.
|
|
0:14:25
|
So now we need to figure out what is some globally routable
|
|
0:14:28
|
address that Router 3 and 5 can reach on each other.
|
|
0:14:31
|
From 5, we should be able to get to Router 3's other loopback
|
|
0:14:35
|
when sourcing traffic from our own local loopback.
|
|
0:14:42
|
This means that I could use this as the source and destination
|
|
0:14:44
|
for the MSDP peering.
|
|
0:14:46
|
But I have to have some address that's globally addressable
|
|
0:14:50
|
uniquely globally addressable between the two of them.
|
|
0:14:57
|
So now we'll define the ip msdp peers
|
|
0:15:00
|
address is 150.28.3.3
|
|
0:15:07
|
The connect source which is basically my update source
|
|
0:15:11
|
is coming from my loopback 0
|
|
0:15:15
|
Router 3 is going to do the same thing accept the ip msdp peer
|
|
0:15:19
|
as 150.28.5.5
|
|
0:15:22
|
connect source is loopback 0
|
|
0:15:27
|
We can see we get the log message that the peerings are up
|
|
0:15:29
|
if we look at the show ip msdp peers
|
|
0:15:34
|
it says that the connection state is up between them.
|
|
0:15:39
|
Right now we have learned no source active messages
|
|
0:15:42
|
from the peer which essentially means that no one has registered
|
|
0:15:46
|
with either of the rendezvous points.
|
|
0:15:50
|
So since we already have pim in sparse mode on all of the
|
|
0:15:53
|
transit interfaces in the network, this essentially
|
|
0:15:56
|
is the final configuration for the whole network.
|
|
0:16:00
|
Assuming that we don't have any problems with
|
|
0:16:02
|
the RPF failure or any of the Layer 2 transit links
|
|
0:16:06
|
then any time either Router 3 or 5 receives a registration
|
|
0:16:11
|
they should tell each other this through an MSDP
|
|
0:16:14
|
SA message.
|
|
0:16:17
|
So now let's say that we have some sender
|
|
0:16:19
|
that is Switch 3
|
|
0:16:23
|
Switch 3 sends traffic out into the network
|
|
0:16:25
|
Switch 1 is then going to register this towards
|
|
0:16:28
|
1.1.1.1
|
|
0:16:31
|
depending on whether we're using Router 3 or Router 5
|
|
0:16:34
|
is going to depend on our IGP metric in order to
|
|
0:16:37
|
reach that particular destination.
|
|
0:16:41
|
So if we were to go to Switch 1 and telnet
|
|
0:16:44
|
to 1.1.1.1
|
|
0:16:47
|
our closest neighbor in the topology is Router 3
|
|
0:16:50
|
so from Switch 3 if I start pinging let's say any random
|
|
0:16:55
|
multicast address 228.8.8.8
|
|
0:17:03
|
from Router 3's perspective we should now receive a registration
|
|
0:17:06
|
for this
|
|
0:17:09
|
we see we know about Switch 3 is a source going to 228.8.8.8
|
|
0:17:19
|
Right now I have the debug ip mpacket on
|
|
0:17:21
|
Notice that the packets are being dropped as they're received
|
|
0:17:24
|
in because I don't currently have any clients.
|
|
0:17:27
|
There's no receivers for it.
|
|
0:17:30
|
Additionally it says that
|
|
0:17:37
|
this is capital A which is candidate for MSDP advertisement.
|
|
0:17:44
|
On the remote rendezvous point which is Router 5
|
|
0:17:47
|
if we look at the show ip msdp sa cache
|
|
0:17:51
|
we now know about the S,G entries that Router 3
|
|
0:17:56
|
had registered to it.
|
|
0:17:59
|
The difference will be though if we look at the
|
|
0:18:01
|
show ip mroute
|
|
0:18:04
|
Router 5 has not yet installed these in the routing table.
|
|
0:18:14
|
Only once we have a client that signals an IGMP
|
|
0:18:17
|
join message and Router 5, the RP, receives a PIM join
|
|
0:18:23
|
will it install the S,G state into the routing table
|
|
0:18:27
|
and then ultimately send the PIM join back to the source.
|
|
0:18:31
|
So from Router 5 if we were to trace how do we get to 155.28.9.9
|
|
0:18:40
|
right now it says to go to Router 3
|
|
0:18:45
|
but let's say theoretically that Router 5 is not routing through 3
|
|
0:18:49
|
and we could do this by changing what the IGP metric is
|
|
0:18:57
|
for that particular destination.
|
|
0:19:00
|
So let's say that on Router 5's frame relay interface
|
|
0:19:05
|
this has a really high delay value, so this is less preferred link.
|
|
0:19:30
|
So now on Router 5 let's do a trace route back to the source
|
|
0:19:33
|
155.28.9.9 we can see now the traffic is not
|
|
0:19:37
|
transiting through Router 3
|
|
0:19:40
|
but we're still going to learn the MSDP SA message from Router 3
|
|
0:19:44
|
so when we look at the show ip msdp sa-cache
|
|
0:19:50
|
we know about those particular sources.
|
|
0:19:53
|
If Switch 3 were to send this traffic to a different
|
|
0:19:56
|
destination, let's say 228.8.8.9
|
|
0:20:02
|
we should see that Router 5 is also going to install these.
|
|
0:20:07
|
So we're learning information from Router 3, but it doesn't
|
|
0:20:10
|
necessarily means that the traffic has to go through Router 3
|
|
0:20:15
|
Once someone actually joins the group, let's say that on
|
|
0:20:19
|
Switch 4 on VLAN 10 we ip igmp join 228.8.8.9
|
|
0:20:31
|
if we then look at Router 5 and look at the show ip mroute
|
|
0:20:36
|
we now install the 228.8.8.9 state into the routing table
|
|
0:20:41
|
and send the S,G join back to the source.
|
|
0:20:48
|
So this actual transit path it says it's coming in serial 0/1/0
|
|
0:20:55
|
the traffic is actually not going through Router 3
|
|
0:20:58
|
Router 3 is only used for the control plane of the MSDP message.
|
|
0:21:04
|
So we have the MSDP peering there, but everywhere along the
|
|
0:21:10
|
path we still have PIM enabled
|
|
0:21:12
|
because PIM is the one that is still building the tree.
|
|
0:21:15
|
MSDP is just used for Router 3 to tell 5 I have this particular
|
|
0:21:20
|
S,G entry.
|
|
0:21:24
|
So once the actual client joins, so we have the IGMP
|
|
0:21:29
|
report message coming into Switch 4, this is turned
|
|
0:21:32
|
into a PIM join, once it gets to Router 5, Router 5 know the
|
|
0:21:38
|
source, it does the reverse path lookup and the join goes this way.
|
|
0:21:44
|
Now one additional tool that I didn't mention yet that you can
|
|
0:21:48
|
use for the verification and the troubleshooting here is the
|
|
0:21:51
|
multicast trace command or the mtrace
|
|
0:21:55
|
this is going to be based on a particular source and destination
|
|
0:22:00
|
if I were to say that the traffic is coming from 155.28.9.9
|
|
0:22:07
|
and going to a particular destination let's say is me
|
|
0:22:12
|
it says that ultimately the reverse path is from me
|
|
0:22:16
|
to Switch 2 to Router 5 to Router 4 to Router 6
|
|
0:22:22
|
to Switch 1 to Switch 3 and then to the final destination.
|
|
0:22:25
|
So this is the reverse path from me back to them.
|
|
0:22:30
|
Now in this particular case it's actually the identical one
|
|
0:22:33
|
as the unicast path
|
|
0:22:36
|
but it doesn't necessarily have to be.
|
|
0:22:39
|
If I were to go to Router 5 and let's say that I manually
|
|
0:22:43
|
change the multicast route to the source
|
|
0:22:49
|
so if I say this source is now reachable via Router 3
|
|
0:22:54
|
over the frame relay
|
|
0:22:57
|
we should see now that the multicast destination
|
|
0:23:03
|
is using a different tree than the unicast destination.
|
|
0:23:08
|
But this is kind of useful because it's going to tell you exactly
|
|
0:23:10
|
what the path is and if this is from a normal dynamic
|
|
0:23:14
|
IGP or whether it's being overridden by either a
|
|
0:23:18
|
static mroute or multicast BGP
|
|
0:23:22
|
Additionally, if there's some problem in the multicast domain
|
|
0:23:25
|
like let's say that between Router 5 and Router 3 we
|
|
0:23:27
|
don't have PIM enabled, so on Router 5
|
|
0:23:33
|
let's say on the frame relay interface no ip pim sparse mode
|
|
0:23:39
|
When Switch 4 does the trace, not the unicast trace, the
|
|
0:23:44
|
multicast trace
|
|
0:23:47
|
we should see -- actually we're doing the static route there, but
|
|
0:23:50
|
let's go to Router 3
|
|
0:23:53
|
and we'll disable pim here no ip pim sparse
|
|
0:24:02
|
It says multicast is disabled.
|
|
0:24:06
|
So this would then be an indication that there's going to be a failure
|
|
0:24:08
|
of the data plane because there's some multicast control plane
|
|
0:24:13
|
problem between Router 3 and Router 5
|
|
0:24:18
|
So again, the key with the anycast is that it's not
|
|
0:24:21
|
a particular feature on its own
|
|
0:24:24
|
it's a different combination of routing design logic
|
|
0:24:27
|
for the IGP destinations having overlapping addressing
|
|
0:24:32
|
and the MSDP in order to advertise the sources
|
|
0:24:35
|
between the rendezvous points.
|
|
0:24:38
|
Now any time you start to scale this for than two rendezvous points
|
|
0:24:43
|
you start to get into an additional RPF check that is
|
|
0:24:47
|
specific to MSDP
|
|
0:24:50
|
and it actually works through really complicated rules that are
|
|
0:24:52
|
designed to prevent data plane traffic loops on the inter-AS
|
|
0:24:58
|
design, so I doubt that this would be within the scope of the
|
|
0:25:01
|
routing and switching exam, but you may want to take a
|
|
0:25:04
|
look at this if you look for the MSDP RPF rules
|
|
0:25:12
|
you should see that there's a link on Cisco's website about
|
|
0:25:15
|
MSDP compliance per this specific RFC
|
|
0:25:21
|
and there's a bulleted list here it says these are the different RPF rules
|
|
0:25:28
|
which is different than the normal just looking at
|
|
0:25:32
|
the data plane to see if there's a loop in the network.
|
|
0:25:35
|
So this reverse path forwarding this is based on the source active message.
|
|
0:25:42
|
But it says that if the neighbor is the only peer, the router accepts the
|
|
0:25:47
|
source active message from them, so in this particular
|
|
0:25:51
|
case, Router 3 and Router 5 basically they're not performing
|
|
0:25:54
|
an RPF check on their SA messages.
|
