I'm having real through deciphering the incoming and outgoing interfaces on an RPT shared tree output e.g.
R1(config-if)#do sh ip mroute 228.13.20.216
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 228.13.20.216), 00:44:29/stopped, RP 10.224.1.1, flags: SPF
Incoming interface: FastEthernet1/0, RPF nbr 10.2.2.2 <<<<<<<<<<<<<<<<<<<
Outgoing interface list: Null
(10.1.1.88, 228.13.20.216), 00:44:29/00:03:28, flags: FT
Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet1/1, Forward/Sparse, 00:06:02/00:03:11
Are there clear rules for determining what the inbound and outbound interfaces will be for an entry in an (*,G) RPT?
The rules for an (S,G) SPT are easy:
- Incoming = interface heading to source of tree (upstream RPF previous hop)
- Outgoing = interface heading to group members (i.e. traffic destined to the multicast address in question)
- Incoming null = I am connected to the source
- Outgoing null = there are no group members out any of my interfaces
So... In = to source. Out = to destination (members)
But when it comes to RPT it seems to be whatever the router feels like... at least... I can't spot any reasonable pattern.
What I've come up with so far is:
If I am the RP for a given (*, G) entry ... my sh ip mroute <mc_address> will show incoming interfaces of null (I am the RP... so far so good). The outgoing interfaces point towards both the registered source and the group members.
If I am a router sitting between the RP and host group members... my incoming interfaces for an (*,G) entry will be the interface that leads to (lowest unicast cost) to the RP. My outgoing interfaces will be towards the group members.
But this is where it gets messed up....
If I am connected to the SOURCE (its DR)... my incoming interface is to the RP (makes sense... the RP is the "root" of the tree)... but my outgoing is to the source... which doesn't make sense to me.... I've always though of outgoing as "where do I send traffic OUT that is destined downstream to this multicast address..." but that can't be right. I wouldn't send traffic BACK to the source.
I'm getting even more confused when I see entries for DRs that have (*,G) outbound entries of null.... Now I know the DR will build an SPT to the RP... but when does the (*,G) entry show the source connected interface in its outbound list? Text book says one thing, GNS3 sim says another.
I mean... the DR doesn't really ever use the RPT tree. It will either end unicast encapsulated register packets to the RP or send traffic over the SPT that has been built to the RP.
My head is really starting to spin on this one and trying to keep track of RP Registration and Group Member routers switching to SPTs at the time isn't making things any easier...
Are there clear rules for determining what the inbound and outbound interfaces will be for an entry in an (*,G) RPT?
