Tuesday, 21 January 2020

PPPoE IA override Circuit/Remote ID

In this section, We are going to learn how to override the default Circuit and Remote ID.

PPPoE IA

The default behaviour of generic circuit id can be also configured with the below command

Configuration:
------------------
SW(config)#pppoe intermediate-agent format-type identifier-string string Home1 option pv delimiter #
------------------

Verification:
------------------
SW#sh pppoe intermediate-agent info
PPPoE Intermediate-Agent is enabled

Global access-node-id is default
Global generic error msg is not set
Global identifier-string Home1 delimiter #

PPPoE Intermediate-Agent trust/rate is configured on the following Interfaces:

Interface               IA         Trusted    Vsa Strip   Rate limit (pps)
----------------------- --------   -------    ---------   ----------------
GigabitEthernet0/1       yes        no         no          unlimited
PPPoE Intermediate-Agent is configured on following VLANs:
none
GigabitEthernet0/2       yes        yes        no          unlimited
PPPoE Intermediate-Agent is configured on following VLANs:
none

------------------

Tshark capture of PPPoE Discover packet:
------------------
FF FF FF FF FF FF 00 00 00 00 11 11 88 63 11 09 00 00 00 31 01 01 00 00 01 05 00 29 00 00 0D E9 01 09 48 6F 6D 65 31 20 31 23 31 02 18 30 30 30 30 2E 30 30 30 30 2E 39 39 39 39 3A 72 65 6D 6F 74 65 2D 69 64
















Let's look into TSHARK raw traffic capture, CIRCUIT ID: <Home1> <Port> < delimiter> <VLAN ID>.

Since its a global level command, it will be applied to all the PPPoE IA enabled client interface. Remember PPPoE IA agent will tag the VSA only for PADI, PADR, and PADT. 

Let's configure the Port Gi0/1 into VLAN 100 and check the same packet.

Configuration:
------------------
SW(config)#int gi0/1                                                                                                                          
SW(config-if)#switchport acess vlan 100                                          
SW(config-if)#pppoe intermediate-agent               
SW(config-if)#end                                                                            
------------------

Tshark capture of PPPoE Discover packet:
------------------

FF FF FF FF FF FF 00 00 00 00 11 11 81 00 00 64 88 63 11 09 00 00 00 33 01 01 00 00 01 05 00 2B 00 00 0D E9 01 0B 48 6F 6D 65 31 20 31 23 31 30 30 02 18 31 63 64 65 2E 61 37 37 63 2E 35 32 38 30 3A 72 65 6D 6F 74 65 2D 69 64




















If you notice the Circuit ID. Now it's having a VLAN ID 100 along with identifier string Home1 and port id.


Wednesday, 1 January 2020

Inter AS Multicast Routing





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)

iBGP peers
eBGP peers
R3----R1
R3----R4
R3----R2
R3----R8
R4----R6
R8----R4
R6----R5
R6 RR, R5 Client
R6----R7
R6 RR, R7 Non Client
R8----R9


Inter AS Multicast Routing uses MSDP and PIM
  1. MSDP to advertise source
  2. PIM to build the tree and do the RPF Check

Note: To do inter AS multicast transit over the internet all hops must run multicast.

Here R3, R4 and R8 going to be the RP. But as we already know the RP info can be populate via static and dynamic.
In AS100 , AS200 and AS300 RP populated via dynamic BSR. But this RP info should not pass the AS. Lets do that.
In AS100 R2 is the BSR and R3 is the RP.
R3(config)#ip pim rp-candidate loopback 0
R2(config)#ip pim bsr-candidate loopback 0

R3(config)#int s2/0
R3(config-if)#ip pim bsr-border
R3(config-if)#int fa1/0
R3(config-if)#ip pim bsr-border

Lets check about the RP info
R3#show ip pim rp mapping
PIM Group-to-RP Mappings
This system is a candidate RP (v2)
Group(s) 224.0.0.0/4
  RP 3.3.3.3 (?), v2
    Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:02:24, expires: 00:01:54
R3#

In AS300 we are going to configure the RP info statically
R8#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static
    RP: 8.8.8.8 (?)

R9#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static
    RP: 8.8.8.8 (?)

In AS200 R5 is the BSR and R4 is the RP.
R5(config)#ip pim bsr-candidate loopback 0
R4(config)#ip pim rp-candidate loopback 0

R4(config)#int s3/0
R4(config-if)#ip pim bsr-border
R4(config-if)#int s3/1
R4(config-if)#ip pim bsr-border


Configure the Multicast feed Source 1

R1#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: 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.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
....

As soon as we configured the Source R1 router RP should be known the (S,G)
R3#show 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:04:39/stopped, RP 3.3.3.3, flags: SP
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null

(1.1.1.1, 224.1.1.1), 00:04:39/00:02:10, flags: P
  Incoming interface: FastEthernet0/0, RPF nbr 155.1.23.2
  Outgoing interface list: Null

To pass the Source info we have MSDP protocol. Lets have R3, R4 and R8 as the MSDP peer. As MSDP are the unicast TCP session based peer we should have the loopback address reachable. To have the reachability we are going to advertise the loopback in BGP.
R3(config)#router bgp 100
R3(config-router)#net 3.3.3.3 mask 255.255.255.255

R4(config)#router bgp 200
R4(config-router)#net 4.4.4.4 mask 255.255.255.255

R8(config)#router bgp 300
R8(config-router)#net 8.8.8.8 mask 255.255.255.255

R3#ping 8.8.8.8 source 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/370/664 ms
R3#ping 4.4.4.4  source 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 356/550/656 ms
R3#

Lets have a source R5
R5(config)#int lo0
R5(config-if)#ip igmp join-group 224.1.1.1

R4#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:02:50/00:02:38, RP 4.4.4.4, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet1/0, Forward/Sparse, 00:02:50/00:02:38

(1.1.1.1, 224.1.1.1), 00:02:50/00:03:20, flags: MT
  Incoming interface: Serial3/0, RPF nbr 155.1.34.3
  Outgoing interface list:
    FastEthernet1/0, Forward/Sparse, 00:02:50/00:02:40

Lets check the path which it took from R5 to R1.

R5#mtrace 5.5.5.5 1.1.1.1
Type escape sequence to abort.
Mtrace from 5.5.5.5 to 1.1.1.1 via RPF
From source (?) to destination (?)
Querying full reverse path...
 0  1.1.1.1
-1  155.1.12.1 PIM  [5.5.5.5/32]
-2  155.1.12.2 PIM  [5.5.5.5/32]
-3  155.1.23.3 PIM  [5.5.5.5/32]
-4  155.1.34.4 PIM  [5.5.5.5/32]
-5  155.1.45.5 PIM  [5.5.5.5/32]
-6  5.5.5.5

R5#traceroute 1.1.1.1 sou 5.5.5.5
Type escape sequence to abort.
Tracing the route to 1.1.1.1
  1 155.1.45.4 352 msec 92 msec 244 msec
  2 155.1.34.3 644 msec 656 msec 420 msec
  3 155.1.23.2 868 msec 924 msec 1092 msec
  4 155.1.12.1 1268 msec 1180 msec 1236 msec
R5#

Here Multicast feed and unicast path taking the same path. If we want to have a different path we can use BGP attribute and change but it will effect both the unicast and as well as unicast.
Multicast BGP is a solution which is used to alter the path for the multicast feed without effecting the unicast. But this cause the RPF check fail. Hence the solution they provided is RPF check is checked first if the path available via multicast BGP table then unicast table.
Multicast BGP is not the routing protocol its just an BGP extension to support path alteration in multicast tree.





We can alter the multicast feed path from R1----R2----R3----R4----R5 to R1----R2----R3----R8----R4---R5.

To do this we should enable the Multicast BGP extension capability between the routers R3, R4 and R8.


R3(config)#router bgp 100
R3(config-router)#address-family ipv4 multicast
R3(config-router-af)#nei 8.8.8.8 activate

R8(config)#router bgp 100
R8(config-router)#address-family ipv4 multicast
R8(config-router-af)#nei 3.3.3.3 activate
R8(config-router-af)#nei 4.4.4.4 activate

R4(config)#router bgp 100
R4(config-router)#address-family ipv4 multicast
R4(config-router-af)#nei 8.8.8.8 activate

R3#show ip bgp sum | be Nei
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4   100     228     237       18    0    0 03:41:49        1
2.2.2.2         4   100     174     186       18    0    0 02:49:15        0
4.4.4.4         4   200     224     231       18    0    0 02:13:39        4
8.8.8.8         4   300     257     235       18    0    0 00:10:12        4

R3#show bgp ipv4 multicast summary | be Nei
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
8.8.8.8         4   300     258     235        1    0    0 00:10:49        0
R3#


It means that we have established the capability and no route are updated in Multicast BGP.
R3#sh ip bgp neighbors 8.8.8.8 | in Address family
    Address family IPv4 Unicast: advertised and received
    Address family IPv4 Multicast: advertised and received

Now we must advertise the source for which we are going to change source path.
R3(config)#router bgp 100
R3(config-router)#address-family ipv4 multicast
R3(config-router-af)#net 1.1.1.1 mask 255.255.255.255

R4(config)#router bgp 200
R4(config-router)#address-family ipv4 multicast
R4(config-router-af)#net 5.5.5.5 mask 255.255.255.255


Through the multicast BGP all the RP will be populated with.

R3#sh bgp ipv4 mu | be Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       155.1.23.2               3         32768 i
*> 5.5.5.5/32       8.8.8.8                                0 300 200 i
R3#

R8#sh bgp ipv4 mu | be Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       3.3.3.3                  3             0 100 i
*> 5.5.5.5/32       4.4.4.4                  2             0 200 i
R8#

R4#sh bgp ipv4 mu | be Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       8.8.8.8                                0 300 100 i
*> 5.5.5.5/32       155.1.45.5               2         32768 i
R4#

Now we check the multicast path and unicast both will be different.

Multicast Path
R5#mtrace 5.5.5.5 1.1.1.1
Type escape sequence to abort.
Mtrace from 5.5.5.5 to 1.1.1.1 via RPF
From source (?) to destination (?)
Querying full reverse path...
 0  1.1.1.1
-1  155.1.12.1 PIM  [5.5.5.5/32]
-2  155.1.12.2 PIM  [5.5.5.5/32]
-3  155.1.23.3 PIM/MBGP  [5.5.5.5/32]
-4  155.1.38.8 PIM/MBGP  [5.5.5.5/32]
-5  155.1.48.4 PIM  [5.5.5.5/32]
-6  155.1.45.5 PIM  [5.5.5.5/32]
-7  5.5.5.5

Unicast Path
R5#traceroute 1.1.1.1 source 5.5.5.5
Type escape sequence to abort.
Tracing the route to 1.1.1.1
  1 155.1.45.4 804 msec 1100 msec 260 msec
  2 155.1.34.3 1384 msec 1200 msec 1104 msec
  3 155.1.23.2 1200 msec 1304 msec 1388 msec
  4 155.1.12.1 1736 msec 1860 msec 1780 msec
R5#

Since the multicast feed through which its receiving but its unicast to the source is not the same hence the RPF check should fail. This can be avoided by multicast BGP. Multicast BGP is like static route but dynamic upgrade.

Note: We can create the MSDP group its used to avoid the SA msg reliable.
R3(config)#ip msdp mesh-group RP_Group 4.4.4.4

R8(config)#ip msdp mesh-group RP_Group 4.4.4.4
R8(config)#ip msdp mesh-group RP_Group 3.3.3.3

R4(config)#ip msdp mesh-group RP_Group 3.3.3.3

Update received from mesh-group will not be sent back to the mesh-group routers. Mesh-Group is used to avoid the Source Active msg loop.

Multicast Source Distribution Protocol




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)

Lets enable the R3 as BSR and R4 as the candidate RP.
R3(config)#ip pim bsr-candidate loopback 0
&
R4(config)#ip pim rp-candidate loopback 0

As we already discussed the PIM BSR the function we are not going to discuss. Lets check the AS100 all router populated with RP address via BSR.

R1#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
  RP 4.4.4.4 (?), v2
    Info source: 3.3.3.3 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:07:44, expires: 00:02:28
R1#
R2#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
  RP 4.4.4.4 (?), v2
    Info source: 3.3.3.3 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:08:07, expires: 00:02:06
R2#
R3#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 4.4.4.4 (?), v2
    Info source: 155.1.34.4 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:08:11, expires: 00:02:18
R3#

R4#show ip pim rp mapping
PIM Group-to-RP Mappings
This system is a candidate RP (v2)
Group(s) 224.0.0.0/4
  RP 4.4.4.4 (?), v2
    Info source: 3.3.3.3 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:08:18, expires: 00:01:52
R4#
R5#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
  RP 4.4.4.4 (?), v2
    Info source: 3.3.3.3 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:08:24, expires: 00:01:46
R5#

Under AS200 we should not get any RP info as still now we didn’t configure any RP over there. So lets check the Router under AS200

R6#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
  RP 4.4.4.4 (?), v2
    Info source: 3.3.3.3 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:12:27, expires: 00:01:46
R6#

This behavior is   what we don’t want. As PIM is not control by AS, PIM can exchange the between the AS. This is the reason hop by hop PIM updated the RP info in AS200 also. We can filter the PIM update form passing out the AS.

R3(config-if)#ip pim bsr-border
R4(config-if)#ip pim bsr-border
R5(config-if)#ip pim bsr-border

Lets clear the RP mapping in AS200.
R6#show ip pim rp mapping
PIM Group-to-RP Mappings

R7#show ip pim rp mapping
PIM Group-to-RP Mappings

R8#show ip pim rp mapping
PIM Group-to-RP Mappings

See as we enabled the bsr-border RP info not getting the updated from PIM process.

So lets enable the BSR and RP under AS200 routers.

R6(config)#ip pim rp-candidate loopback 0

R6(config)#int ran fa0/0 , fa1/0 , fa2/0
R6(config-if-range)#ip pim bsr-border

R7(config)#ip pim bsr-candidate  lo0

Under the AS200 RP info also populated via AS200 BSR.
R6#show ip pim rp mapping
PIM Group-to-RP Mappings
This system is a candidate RP (v2)
Group(s) 224.0.0.0/4
  RP 6.6.6.6 (?), v2
    Info source: 7.7.7.7 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:00:24, expires: 00:02:18
R6#

R7#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 6.6.6.6 (?), v2
    Info source: 155.1.67.6 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:00:34, expires: 00:01:55
R7#

R8#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
  RP 6.6.6.6 (?), v2
    Info source: 7.7.7.7 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:00:48, expires: 00:01:54
R8#

Now Lets have the source and the receiver. Here we are going to configure the R1 as the source and R8 as the receiver.

R1#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: 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 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
…….....

From R1(source)------R2(First hop router)-------R3(transits router)-----------R4(RP)

As the first hop router will be getting the feed it will update the (S,G) entry in the mroute table.

R2#show 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:02:29/stopped, RP 4.4.4.4, flags: SPF
  Incoming interface: FastEthernet1/0, RPF nbr 155.1.23.3
  Outgoing interface list: Null

(155.1.12.1, 224.1.1.1), 00:02:29/00:00:37, flags: PFT
  Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
  Outgoing interface list: Null

(*, 224.0.1.40), 00:41:54/00:02:42, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:42:01/00:02:34

R3 the transit router will not be knowing any info regarding the feed source.

R3#show 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.0.1.40), 00:43:54/00:02:44, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:43:54/00:02:44

R4 the RP knows about the source by PIM register msg. It will update the Mroute entry with (S,G)

R4#show 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:03:58/stopped, RP 4.4.4.4, flags: SP
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null

(1.1.1.1, 224.1.1.1), 00:03:58/00:01:02, flags: P
  Incoming interface: FastEthernet0/0, RPF nbr 155.1.34.3
  Outgoing interface list: Null

(*, 224.0.1.40), 00:05:34/00:02:12, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:05:42/00:02:04

Note: The OIL has Null this is because receiver is not know still. So lets enable the receiver that is R8.

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

Lets check the mroute entry on R6 and R7.
R7#show 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:06:57/00:03:23, RP 6.6.6.6, flags: S
  Incoming interface: FastEthernet0/0, RPF nbr 155.1.67.6
  Outgoing interface list:
    FastEthernet1/0, Forward/Sparse, 00:06:57/00:03:23

(*, 224.0.1.40), 00:49:19/00:02:20, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:49:19/00:02:20
R7#

R6#show 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:07:03/00:03:19, RP 6.6.6.6, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet3/0, Forward/Sparse, 00:07:03/00:03:19

(*, 224.0.1.40), 00:50:51/00:02:12, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:50:51/00:02:12
R6#

Note: Incoming interface list is Null. Its because this RP(R6) don’t know about the source.
As R6 is our RP but now the problem 2 RP's are there one RP(R4) knows about the source and second RP(R6) knows about the receiver. We need some protocol that can communicate between this RP's and get the source/receiver info and build the complete tree for the feed.
MSDP is a protocol which run between the RP's and get the control plane to build the tree.

But before we enable the MSDP lets enable shut the link between R3-R6 & R5-R6. Reason we will discuss later.
R6(config-if)#int fa2/0
R6(config-if)#sh
R6(config-if)#int fa0/0
R6(config-if)#sh

Lets enable the MSDP now.
R6(config)#ip msdp peer 4.4.4.4 connect-source loopback 0
R4(config)#ip msdp peer 6.6.6.6 connect-source loopback 0

MSDP peer uses TCP session to form the peer.





Now after the TCP session established. MSDP peer we will update themselves





R4 sending the Source Active msg inside the TCP port number 639.
As R4 knows about the Source and the group. Its sending the (S,G) (224.1.1.1 , 1.1.1.1)


R6#show 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:25:56/00:03:11, RP 6.6.6.6, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet3/0, Forward/Sparse, 00:25:56/00:03:11

(1.1.1.1, 224.1.1.1), 00:07:32/00:03:29, flags: MT
  Incoming interface: FastEthernet1/0, RPF nbr 155.1.46.4
  Outgoing interface list:
    FastEthernet3/0, Forward/Sparse, 00:07:32/00:03:11
R6#

R6 updated the S,G info. Note MT, M means MSDP and T means SPT tree.

As we know we shutdown the R3-R6 and R5-R6 link. Before we enable just check the mtrace for 1.1.1.1 from R8.
R8#mtrace 1.1.1.1
Type escape sequence to abort.
Mtrace from 1.1.1.1 to 155.1.78.8 via RPF
From source (?) to destination (?)
Querying full reverse path...
 0  155.1.78.8
-1  155.1.78.8 PIM  [1.1.1.1/32]
-2  155.1.78.7 PIM  [1.1.1.1/32]
-3  155.1.67.6 PIM  [1.1.1.1/32]
-4  155.1.46.4 PIM  [1.1.1.1/32]
-5  155.1.34.3 PIM  [1.1.1.1/32]
-6  155.1.23.2 PIM  [1.1.1.1/32]
-7  155.1.12.1 PIM  [1.1.1.1/32]
-8  1.1.1.1

Now unshut the R5-R6 link and check the mtrace.
R6(config)#int fa0/0
R6(config-if)#no sh

R8#mtrace 1.1.1.1
Type escape sequence to abort.
Mtrace from 1.1.1.1 to 155.1.78.8 via RPF
From source (?) to destination (?)
Querying full reverse path...
 0  155.1.78.8
-1  155.1.78.8 PIM  [1.1.1.1/32]
-2  155.1.78.7 PIM  [1.1.1.1/32]
-3  155.1.67.6 PIM  [1.1.1.1/32]
-4  155.1.46.4 PIM  [1.1.1.1/32]
-5  155.1.34.3 PIM  [1.1.1.1/32]
-6  155.1.23.2 PIM  [1.1.1.1/32]
-7  155.1.12.1 PIM  [1.1.1.1/32]
-8  1.1.1.1

So no effect but lets unshut the Link between R3-R6 and note the mtrace path till the source.
R6(config)#int fa2/0
R6(config-if)#no sh

R8#mtrace 1.1.1.1
Type escape sequence to abort.
Mtrace from 1.1.1.1 to 155.1.78.8 via RPF
From source (?) to destination (?)
Querying full reverse path...
 0  155.1.78.8
-1  155.1.78.8 PIM  [1.1.1.1/32]
-2  155.1.78.7 PIM  [1.1.1.1/32]
-3  155.1.67.6 PIM  [1.1.1.1/32]
-4  155.1.36.3 PIM  [1.1.1.1/32]
-5  155.1.23.2 PIM  [1.1.1.1/32]
-6  155.1.12.1 PIM  [1.1.1.1/32]
-7  1.1.1.1

This is what I want to show the now the path is different its because the shortest path. The feed should not be must to route via RP.


As soon as R6 find the shortest path to reach the R1(source) R6 will send the PIM join msg to the upstream router (R3).


At last we are getting the feed :)
Reply to request 1359 from 155.1.78.8, 1080 ms
Reply to request 1360 from 155.1.78.8, 900 ms
Reply to request 1361 from 155.1.78.8, 1056 ms
Reply to request 1362 from 155.1.78.8, 980 ms
Reply to request 1363 from 155.1.78.8, 860 ms