Wednesday, 1 January 2020

Source Specific Multicast




Today we are going to discuss about the PIM Sparse-mode.
Note all the router preconfigured with the ipv4 address and OSPF is used as the routing protocol, all routers are in area 0. PIM sparse dense mode it running.
IP ADDRESS: Fast Ethernet 155.1.XY.X/24
                       Loopback         X.X.X.X/32
Where X & Y is the router host number.(X <Y)

To enable the PIM Sparse mode we need to enable IP PIM SPARSE DEFAULT. This will enable the pim sparse mode for the group 232.0.0.0/8.

Lets this time we will do in reverse we will configure R5 the receiver first.
R5(config-if)#int lo0
R5(config-if)#ip igmp join-group 232.1.1.1 source 1.1.1.1




But R5 is sending the IGMPv2. Note for PIM SPARSE MODE we need to enable the PIM SPARSE MODE.
R5(config-if)#ip igmp version 3
We have to enable the igmp version 3 on the last hop router.
R4(config-if)#ip igmp version 3

IN SSM we don’t need the RP as receiver itself telling form which  receiver it should receive the feed.
 Note: We can also manually define the Group

Lets enable the source
R1#ping
Protocol [ip]:
Target IP address: 232.1.1.1
Repeat count [1]: 100000000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Interface [All]: loopback0
Time to live [255]:
Source address: 1.1.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100000000, 100-byte ICMP Echos to 224.5.5.5, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.............................................

Lets enable the BSR to lets populate the RP details. This we have done just to update the RP and check the state information.

R2(config)#ip pim bsr-candidate lo0

R3 will be acting as the candidate RP.
R3(config)#ip pim rp-candidate loopback 0

SSM uses the shared path tree(S,G) throughout the Path

R4#smr 232.1.1.1 | be Int
 Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 232.1.1.1), 00:00:41/stopped, RP 3.3.3.3, flags: SP
  Incoming interface: FastEthernet1/0, RPF nbr 155.1.34.3
  Outgoing interface list: Null
(1.1.1.1, 232.1.1.1), 00:00:05/00:03:26, flags: T
  Incoming interface: FastEthernet0/0, RPF nbr 155.1.24.2
  Outgoing interface list:
    FastEthernet2/0, Forward/Sparse, 00:00:05/00:03:25

R2#smr 232.1.1.1 | be Int
 Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 232.1.1.1), 00:20:43/stopped, RP 3.3.3.3, flags: SP
  Incoming interface: FastEthernet1/0, RPF nbr 155.1.23.3
  Outgoing interface list: Null
(1.1.1.1, 232.1.1.1), 00:20:43/00:03:21, flags: T
  Incoming interface: FastEthernet0/0, RPF nbr 155.1.12.1
  Outgoing interface list:
    FastEthernet2/0, Forward/Sparse, 00:20:43/00:03:29

R3#smr 232.1.1.1 | be Int
 Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 232.1.1.1), 00:16:04/00:03:21, RP 3.3.3.3, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet1/0, Forward/Sparse, 00:10:48/00:03:21
(1.1.1.1, 232.1.1.1), 00:16:04/00:02:50, flags: PT
  Incoming interface: FastEthernet0/0, RPF nbr 155.1.23.2
  Outgoing interface list: Null

R5----------R4-(S,G)---------R2-(S,G)------------R1.

SSM works with both the SSM Group and also non SSM group at the same time.

Bidirectional PIM



Today we are going to discuss about the BIDIRECTIONAL PIM.
Note all the router preconfigured with the ipv4 address and OSPF is used as the routing protocol, all routers are in area 0. PIM sparse dense mode it running.
IP ADDRESS: Fast Ethernet 155.1.XY.X/24
                       Loopback         X.X.X.X/32
Where X & Y is the router host number.(X <Y)

Bi-Dir is kind of the opposite Source specific multicast, everything is a shared-tree, but traffic can flow bidirectional. That we will discuss later

What's the reason of using Bidirectional ??
The answer is think a massive network of multicast traffic, with many sources and many receivers (a many-to-many multicast application network). A network like this would quickly add hundreds, even thousands and tens of thousands of (S,G), multicast entries in the mroute table. One of the major applications for Multicast is financial services, stock markets etc, and in today's climate of HFT (High-Frequency-Trading), latency is a big no-no.

All those multicast entries in the mroute table will slow the switch down, and start to make the switch inefficient, thus, we have Bidirectional PIM, the idea is that if everything uses a shared tree, we can reduce the number of mroute table entries down to just those with (*,G), when using one multicast group address with multiple sources, this efficiency really starts making sense.

Bidirectional PIM can be assigned via static and BSR.
First we need to enable ip pim bidir-enable in all the routers

Rx(config)#ip pim bidir-enable

As we are going to use BSR. Here we choose R2 as our BSR and R3 as Candidate RP. First lets enable that
R2(config)#ip pim bsr-candidate loopback 0

R3(config)#ip pim rp-candidate loopback 0 bidir

R2#show ip pim rp mapping
PIM Group-to-RP Mappings
This system is the Bootstrap Router (v2)
Group(s) 224.0.0.0/4
  RP 3.3.3.3 (?), v2, bidir
    Info source: 155.1.23.3 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:01:40, expires: 00:01:48

So as far now we are ok we found the RP via BSR. Let generate some multicast feed

R1#ping
Protocol [ip]:
Target IP address: 224.5.5.5
Repeat count [1]: 100000000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Interface [All]: loopback0
Time to live [255]:
Source address: 1.1.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100000000, 100-byte ICMP Echos to 224.5.5.5, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.............................................

Lets check the path and mroute table
R2#show ip mroute 224.5.5.5 | be Int
 Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.5.5.5), 00:10:47/00:02:57, RP 3.3.3.3, flags: BP
  Bidir-Upstream: FastEthernet1/1, RPF nbr 155.1.23.3
  Outgoing interface list:
    FastEthernet1/1, Bidir-Upstream/Sparse, 00:10:47/00:00:00

See R2 receiving the multicast feed as unicast packet. Hence R2 learns that we have a group 224.5.5.5 and make an entry (*,224.5.5.5). This stream sent upside towards the RP via Fa1/1. Now check on RP R3

R3#show ip mroute 224.5.5.5 | be Int
 Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.5.5.5), 00:00:51/00:02:08, RP 3.3.3.3, flags: BP
  Bidir-Upstream: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null

Hence this is our RP as we don’t have any receiver its prune. Lets create the receiver

R6(config)#int lo0
R6(config-if)#ip igmp join-group 224.5.5.5

As soon as we had a receiver our ping getting the success
R1#
Reply to request 581 from 155.1.56.6, 656 ms
Reply to request 582 from 155.1.56.6, 788 ms
Reply to request 583 from 155.1.56.6, 576 ms
Reply to request 584 from 155.1.56.6, 564 ms


PIM Sparse Mode (Auto RP)




Here we are going to assign R2 ad R3 as the candidate RP  and R1 as the mapping agent.
Note all the router preconfigured with the ipv4 address and OSPF is used as the routing protocol, all routers are in area 0. PIM sparse dense mode it running.
IP ADDRESS: Fast Ethernet 155.1.XY.X/24
                       Loopback         X.X.X.X/32
Where X & Y is the router host number.(X <Y)

R2(config)#ip pim send-rp-announce loopback 0 scope 255

Once the R2 configured as the candidate R2 will be having the mroute as (S,G) (2.2.2.2,224.0.1.39)
R2#show ip mroute 2.2.2.2 224.0.1.39 | be Inter
 Interface state: Interface, Next-Hop or VCD, State/Mode
(2.2.2.2, 224.0.1.39), 00:09:33/00:02:28, flags: PT
  Incoming interface: Loopback0, RPF nbr 0.0.0.0
  Outgoing interface list: Null

 Now lets configure the R3 box
R3(config)#ip pim send-rp-announce loopback 0 scope 255

R3#smr 3.3.3.3 224.0.1.39 | be Int
 Interface state: Interface, Next-Hop or VCD, State/Mode

(3.3.3.3, 224.0.1.39), 00:03:27/00:02:33, flags: PT
  Incoming interface: Loopback0, RPF nbr 0.0.0.0
  Outgoing interface list: Null

Lets move to the mapping agent. R4 will be the mapping agent here. Am keeping the mapping agent one hop away form the candidate RP. Its because the directly connected routers will about the candidate RP.
R4(config)#ip pim send-rp-discovery loopback 0 scope 255

As we know the egg and the chicken problem. Since R2 and R3 are the candidate RP they should register themselves to the mapping agent but to register they need to join 224.0.1.40 group for that they should know the RP. So solve this method we have three solution
  1. PIM Sparse-Dense Mode
  2. Auto RP listener
  3. PIM dense mode for 224.0.1.39/40 other sparse

Auto listener feature we should enable on all the routers.
Rx(config)#ip pim autorp listener

Lets check the mapping agent.

R4#sh ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP-mapping agent (Loopback0)
Group(s) 224.0.0.0/4
  RP 3.3.3.3 (?), v2v1
    Info source: 3.3.3.3 (?), elected via Auto-RP
         Uptime: 00:03:04, expires: 00:02:53
  RP 2.2.2.2 (?), v2v1
    Info source: 2.2.2.2 (?), via Auto-RP
         Uptime: 00:03:00, expires: 00:01:59
R4#

The above details say that for all the multicast group R3 and R2 are the candidate RP's. In both of them R3 is the Winner due to the highest IP.
The ? Is for the DNS lookup. So lets configure the DNS lookup.

R4(config)#ip host R3 3.3.3.3
R4(config)#ip host R2 2.2.2.2

R4#sh ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP-mapping agent (Loopback0)
Group(s) 224.0.0.0/4
  RP 3.3.3.3 (R3), v2v1
    Info source: 3.3.3.3 (R3), elected via Auto-RP
         Uptime: 00:09:38, expires: 00:02:20
  RP 2.2.2.2 (R2), v2v1
    Info source: 2.2.2.2 (R2), via Auto-RP
         Uptime: 00:09:33, expires: 00:02:28
R4#

Lets have a source for 224.1.1.1

R7#ping
Protocol [ip]:
Target IP address: 224.1.1.1
Repeat count [1]: 10000000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: yes
Interface [All]: loopback0
Time to live [255]:
Source address: 7.7.7.7
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 7.7.7.7
..




R7 will generate the multicast feed and as the first hop router receive the feed its checks for the RP info. So lets check the RP info on R1.
R1#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 3.3.3.3 (?), v2v1
    Info source: 4.4.4.4 (?), elected via Auto-RP
         Uptime: 00:26:28, expires: 00:02:15

R1 details say that R4(4.4.4.4) update the RP(3.3.3.3) via Auto-RP.
(S,G) entry will be seen only on R1 and R3.

 
R3#smr 7.7.7.7 224.1.1.1 | be Inter
 Interface state: Interface, Next-Hop or VCD, State/Mode
(7.7.7.7, 224.1.1.1), 00:23:07/00:01:55, flags: P
  Incoming interface: Serial1/1, RPF nbr 155.1.13.1
  Outgoing interface list: Null

As we don’t have any receivers for the group 224.1.1.1 the OIL is NULL. Lets have a client asking for the 224.1.1.1 group
R6(config)#int lo0
R6(config-if)#ip igmp join-group 224.1.1.1

We are getting reply from R6.


R6#mtrace 7.7.7.7
Type escape sequence to abort.
Mtrace from 7.7.7.7 to 155.1.146.6 via RPF
From source (?) to destination (?)
Querying full reverse path...
 0  155.1.146.6
-1  155.1.146.6 PIM  [7.7.7.7/32]
-2  155.1.146.4 PIM  [7.7.7.7/32]
-3  155.1.14.1 PIM  [7.7.7.7/32]
-4  155.1.17.7 PIM  [7.7.7.7/32]
-5  7.7.7.7

From trace we found like multicast feed coming from R7---R1---R4----R6 but as we know we have a R3 as RP. Lets check why R3 is not used

R3#smr 224.1.1.1
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,
       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
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 00:33:09/00:03:08, RP 3.3.3.3, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial1/1, Forward/Sparse, 00:07:15/00:03:08

(7.7.7.7, 224.1.1.1), 00:33:09/00:01:53, flags: PT==========> PT is the reason
  Incoming interface: Serial1/1, RPF nbr 155.1.13.1
  Outgoing interface list: Null

R1 will check, its waste of bandwidth to pass the feed to R3 and again R3 anyhow send back the feed to R1. So R1 will send a special PIM Prune msg with RP bit set and switch to shortest path tree.

We can assign the RP/Group. To do this just create the access-list and match the multicast group.
R2(config)#access-list 1 permit 224.0.0.0 0.255.255.255
R2(config)#ip pim send-rp-announce loopback 0 scope 255 group-list 1

R3(config)#access-list 1 permit 239.0.0.0 0.255.255.255
R3(config)#ip pim send-rp-announce lo0 scope 255 group-list 1


R4#sh ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP-mapping agent (Loopback0)
Group(s) 224.0.0.0/8
  RP 2.2.2.2 (R2), v2v1
    Info source: 2.2.2.2 (R2), elected via Auto-RP
         Uptime: 00:03:01, expires: 00:01:56
Group(s) 239.0.0.0/8
  RP 3.3.3.3 (R3), v2v1
    Info source: 3.3.3.3 (R3), elected via Auto-RP
         Uptime: 00:01:50, expires: 00:02:08

In Mapping agent it don’t have any security to find whose and which multicast group it should have the RP/Group.
To Provide this feature cisco has RP-announce filter option
R4#sh ip access-lists
Standard IP access list Any
    10 deny   any
Standard IP access list Ay+Group
    10 deny   any
Standard IP access list R2
    10 permit 2.2.2.2
Standard IP access list R2_Group
    10 permit 224.0.0.0, wildcard bits 0.255.255.255
Standard IP access list R3
    10 permit 3.3.3.3
Standard IP access list R3_Group
    10 permit 239.0.0.0, wildcard bits 0.255.255.255

R4(config)#ip pim rp-announce-filter rp-list R3 group-list R3_Group
R4(config)#ip pim rp-announce-filter rp-list R2 group-list R2_Group
R4(config)#ip pim rp-announce-filter rp-list Any group-list Any_Group

To check this lets do debugging
R4#
*May 31 01:09:13.083: Auto-RP(0): Received RP-announce, from 5.5.5.5, RP_cnt 1, ht 181
*May 31 01:09:13.083: Auto-RP(0): Filtered 224.0.0.0/4 for RP 5.5.5.5
*May 31 01:09:13.083: Auto-RP(0): Received RP-announce, from 5.5.5.5, RP_cnt 1, ht 181
*May 31 01:09:13.083: Auto-RP(0): Filtered 224.0.0.0/4 for RP 5.5.5.5
R4#
See R5 is been filtered :)
R4#sh ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP-mapping agent (Loopback0)

Group(s) 224.0.0.0/8
  RP 2.2.2.2 (R2), v2v1
    Info source: 2.2.2.2 (R2), elected via Auto-RP
         Uptime: 00:00:12, expires: 00:02:44
Group(s) 239.0.0.0/8
  RP 3.3.3.3 (R3), v2v1
    Info source: 3.3.3.3 (R3), elected via Auto-RP
         Uptime: 00:00:44, expires: 00:02:12
R4#



PIM Sparse Mode (Static RP)



Same Topology and Same IP address scheme am going to use here.
But the only change is instead of running PIM Dense mode here we are running PIM Sparse mode.
Lets verify it

R1#sh ip pim interface

Address          Interface                Ver/   Nbr    Query  DR     DR
                                                         Mode   Count   Intvl    Prior
1.1.1.1          Loopback0                v2/S   0      30     1      1.1.1.1
155.1.17.1       Serial0/0                v2/S   1      30     1      0.0.0.0
155.1.12.1       Serial0/1                v2/S   1      30     1      0.0.0.0
155.1.13.1       Serial0/2                v2/S   1      30     1      0.0.0.0
155.1.14.1       Serial0/3                v2/S   1      30     1      0.0.0.0

That’s it we enabled the PIM Sparse Mode now lets give the Rendezvous  Point  (RP) to each router.

Here I have created a loopback address 0 on R1 with ip 1.1.1.1/32. Since all the router running OSPF all router may be reachable to this IP. And here am going to use R1 as RP.
Note: On R1 also we should give the details of RP or else R1 will pop out the error msg saying the invalid RP address.

R7(config)#ip pim rp-address 2.2.2.2
R7#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s): 224.0.0.0/4, Static
    RP: 2.2.2.2 (?)

See we configured on R7 about the RP but R1 popped out this error msg
R1#
*Mar  1 00:40:34.943: %PIM-6-INVALID_RP_JOIN: Received (*, 224.0.1.40) Join from 155.1.17.7 for invalid RP 2.2.2.2.
Like this configure on all the routers.



As soon as we will generate the MULTICAST TRAFFIC the next hop router from the source will generate the Unicast PIM REGISTER MSG to the RP. So lets enable the multicast traffic on R7, since R7 is a PIM Router and it’s the one who generating the multicast traffic hence it will generate the PIM Register msg.
R7#ping
Protocol [ip]:
Target IP address: 224.1.1.1
Repeat count [1]: 100000000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Interface [All]: loopback0
Time to live [255]:
Source address: 7.7.7.7
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 7.7.7.7

...............

RP (R2) will ack it with a PIM Register stop msg.



Now on RP (R2)we have a (S,G) entry since we got the source info from the ICMP which is encapsulated in the register msg lets check the RP mroute.

R2#sh ip mroute 224.1.1.1
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,
       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
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 00:07:50/stopped, RP 2.2.2.2, flags: SP
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null

(7.7.7.7, 224.1.1.1), 00:07:50/00:01:09, flags: P
  Incoming interface: Serial0/0, RPF nbr 155.1.12.1
  Outgoing interface list: Null

Note: IF the Router is DR and its generate the multicast traffic  then the PIM Register msg will not be generated by the DR. DR will be knowing the (S,G) entry.
Because the DR Will check only the incoming multicast traffic on the interface.

Now since the PIM Register msg sent by R7 and passed via R1 but still R1 will not have the (S,G) entry
R1#sh ip mroute 224.1.1.1
Group 224.1.1.1 not found

Lets have a client for a group 224.1.1.1 on R6.





R6(config)#int lo0
R6(config-if)#ip igmp join-group 224.1.1.1

Reply to request 841 from 155.1.45.6, 204 ms
Reply to request 842 from 155.1.45.6, 200 ms
Reply to request 843 from 155.1.45.6, 208 ms
Reply to request 844 from 155.1.45.6, 236 ms
Reply to request 845 from 155.1.45.6, 192 ms
Reply to request 846 from 155.1.45.6, 152 ms
Reply to request 847 from 155.1.45.6, 228 ms
Reply to request 848 from 155.1.45.6, 144 ms


R6 generate the (*,G ) PIM Join and





Now R6---R4---R1---R7 has (*,G)

R6#sh ip rpf 7.7.7.7
RPF information for ? (7.7.7.7)
  RPF interface: FastEthernet0/0
  RPF neighbor: ? (155.1.45.4)
  RPF route/mask: 7.7.7.7/32
  RPF type: unicast (ospf 1)
  RPF recursion count: 0
  Doing distance-preferred lookups across tables

R4#sh ip rpf 7.7.7.7
RPF information for ? (7.7.7.7)
  RPF interface: Serial0/0
  RPF neighbor: ? (155.1.14.1)
  RPF route/mask: 7.7.7.7/32
  RPF type: unicast (ospf 1)
  RPF recursion count: 0
  Doing distance-preferred lookups across tables

R1#sh ip rpf 7.7.7.7
RPF information for ? (7.7.7.7)
  RPF interface: Serial0/0
  RPF neighbor: ? (155.1.17.7)
  RPF route/mask: 7.7.7.7/32
  RPF type: unicast (ospf 1)
  RPF recursion count: 0
  Doing distance-preferred lookups across tables

R1#sh ip mroute
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,
       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
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 00:26:09/00:03:01, RP 2.2.2.2, flags: S
  Incoming interface: Serial0/1, RPF nbr 155.1.12.2
  Outgoing interface list:
    Serial0/3, Forward/Sparse, 00:19:21/00:03:01

(7.7.7.7, 224.1.1.1), 00:26:09/00:03:26, flags: T
  Incoming interface: Serial0/0, RPF nbr 155.1.17.7
  Outgoing interface list:
    Serial0/3, Forward/Sparse, 00:19:21/00:03:01

(*, 224.0.1.40), 01:35:52/00:03:13, RP 2.2.2.2, flags: SJCL
  Incoming interface: Serial0/1, RPF nbr 155.1.12.2
  Outgoing interface list:
    Serial0/0, Forward/Sparse, 01:34:58/00:02:44
    Serial0/3, Forward/Sparse, 01:35:26/00:03:13
    Loopback0, Forward/Sparse, 01:35:52/00:02:03

R1#