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#
No comments:
Post a Comment