Scribd Logo
Upload

Welcome to Scribd!

  • Lec-11 Multicast PIM Prune Override

    Uploaded by

    Abhishek garg
    15 views16 pages

    Original Title

    lec-11 Multicast PIM Prune Override

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Report this Document

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    15 views16 pages

    Lec-11 Multicast PIM Prune Override

    Uploaded by

    Abhishek garg

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    of 16
    091052023, 22:45 Muticast PIM Prune Overide Search Q © Multicast PIM Prune Override ‘The PIM prune mechanism works a bit different on multi-access links compared to point-to-point links. On point to point links there is only one other router on the other end so when we receive a prune message, it's safe to stop forwarding the traffic. On multi-access links however it's possible that we have more than one downstream router that is interested in receiving the multicast traffic. When we receive a prune on a multi-access link, we need to make sure that nobody else still wants to receive it. This is done with the prune override mechanism and it applies to both PIM dense and sparse mode. Here’s an example: hitpstnetworklessons.com/muticasUmulicast-pim-prune-overrde a6 091052023, 22:45 ‘Multicast PIM Prune Oversde ‘Above we have a source (S1) sending multicast traffic to R1. At the bottom are two receivers (H2 and H3) R2/R3 are both forwarding the traffic. After a few minutes, H2 doesn’t want to receive this traffic anymore. hnps:inetworklessons.com/mulicasUmullicast-pim-prune-override ons @ ane 091052023, 22:45 ‘Multicast PIM Prune Oversde ons @ H2 will send an IGMP leave towards R2 who will send a PIM prune to its upstream neighbor, R1. This PIM prune message is destined to 224.0.0.13 so R1 and R3 will both receive it. Here’s what happens next: hnps:inetworklessons.com/mulicasUmullicast-pim-prune-override ane 091052023, 22:45 ‘Multicast PIM Prune Oversde Received PIM prune, setting timer before I stop forwarding... en R1 receives the prune message but it wor't stop forwarding right away. It willwalt for a few seconds to se (> if other routers are still interested. R3 is still interested so it will send a PIM join. Since this PIM join overrides the prune, we call ita prune override but the packet is a regular PIM join... R1 now knows what to do: hnps:inetworklessons.com/mulicasUmullicast-pim-prune-override ans 091052023, 22:45 ‘Multicast PIM Prune Oversde Received PIM join from R3, "Il keep. forwarding! Since R3 fs stil nterested,R1 will gnore the prune message from R2 and will keep forwarding the multice G2) traffic, Let's take a look at some real routers to see how this works in action! hnps:inetworklessons.com/mulicasUmullicast-pim-prune-override ene osiosi2023, 22:45 ‘Multicast PIM Prune Overside 4 Here's the topology I will use: 254 192.168.1.0/24 1 10/2 ; 192.168.123.0/24 a aj Ss s @ 2 39 Bo .254 Sq 254 co og an aN o Pa s 8 4 4 a i g ei Above we have a small network with three routers. $1 will send multicast packets and H2/H3 will be the receivers. OSPF has been configured as the unicast routing protocol and PIM dense mode for multicast routing. If you want to test this example yourself, you can find the startup configurations below: Startup Configurations Want to take a look for yourself? Here you will find the final configuration of each device. R1 ~ hnps:inetworklessons.com/mulicasUmullicast-pim-prune-override ane 091052023, 22:45 Muticast PIM Prune Overide ip multicast-routing ip cef interface Gigabitétherneto/1 ip address 192.168.123.1 255.255.255.0 ip pim dense-node duplex auto speed auto media-type rja5 ! interface Gigabitetherneto/2 ip address 192.168.1.254 255.255.255.0 ip pim dense-node duplex auto speed auto media-type rj45 router ospf 1 network 192.168.1.0 @.0.0.255 area @ network 192.168.123.0 .0.0.255 area @ end R2 hostname R2 ! ip multicast-routing ip cef interface Gigabitethernet@/1 ip address 192.168.123.2 255.255.255.0 ip pim dense-node duplex auto speed auto media-type rja5 hitpstnetworklessons.com/mulicasUmulicast-pim-prune-overrde m6 091052023, 22:45 Muticast PIM Prune Overide a ip address 192.168.2.254 255.255.255.0 ip pim dense-node duplex auto speed auto media-type 745 router ospf 1 network 192.168.2.0 0.0.0.255 area 0 network 192.168.123.0 @.0.0.255 area @ end R3 ~ hostname R3 ! ip multicast-routing ip cef ' interface Gigabitetherneto/1 ip address 192.168.123.3 255.255.255.0 ip pim dense-node duplex auto speed auto media-type rja5 interface Gigabitethernet@/2 ip address 192.168.3.254 255.255.255.0 ip pim dense-node duplex auto speed auto media-type rja5 ! router ospf © network 192,168.3.0 @.8.0.255 area @ network 192.168.123.0 @.0.0.255 area @ hitpstnetworklessons.com/mulicasUmulicast-pim-prune-overrde ane 091052023, 22:45 Muticast PIM Prune Overide H2 ~ hostname H2 ' no ip routing ' interface Gigabitétherneto/1 ip address 192.168.2.2 255.255.255.0 no ip route-cache duplex auto speed auto media-type rj45 ! ip default-gateway 192.168.2.254 ! end H3 ~ hostname H3 no ip routing interface Gigabitetherneto/1 ip address 192.168.3.3 255.255.255.0 no ip route-cache duplex auto speed auto media-type rja5 ! ip default-gateway 192.168.3.254 ! © end hitpstnetworklessons.com/muticasUmulicast-pim-prune-overrde one 091052023, 22:45 Muticast PIM Prune Overide hostname $1 ! no ip routing ! interface Gigabitethernet0/1 ip address 192.168.1.1 255.255.255.0 no ip route-cache duplex auto speed auto media-type rja5 ip default-gateway 192.168.1.254 end Let's configure the hosts to receive our multicast traffic: Ho & #3 (config)#interface GigabitEthernet 0/1 (config-if)#ip ignp join-group 239.1.1.1 ‘And generate some traffic from $1 Siping 239.1.1.1 repeat 1000 Type escape sequence to abort. Sending 100@, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 second: Reply to request 1 from 192.168.2.2, 20 ms Reply to request 2 from 192.168.3.3, 5 ms S1 is receiving replies from H2 and H3, Let's check the multicast routing tables of R2 and R3: © R2#show ip mroute 239.1.1.1 192.168.1.1 (192.168.1.1, 239.1.1.1), @1:51:50/@0:01:33, flags: T hitpstnetworklessons.com/mulicasUmulicast-pim-prune-overrde sone 091052023, 22:45 Muticast PIM Prune Overide a Gigabitetherneto/2, Forward/Dense, 08:00:36/stopped R3show ip mroute 239.1.1.1 192.168.1.1 (292.168.1.1, 239.1.1.1), @1:52:29/00:01:55, flags: T Incoming interface: GigabitEtherneto/1, RPF nbr 192.168.123.1 Outgoing interface list: Gigabitethernete/2, Forward/Dense, @1:52:29/stopped Both router are forwarding traffic to the hosts. Before we configure H2 to stop listening, let's enable a debug R1, R2 & RB #debug ip pim PIM debugging is on Let’s configure H2 to stop listening H2(config)#interface Gigabitethernet 0/1 H2(config-if)#no ip igmp join-group 239.1.1.1 Here's what we we will see on R2: Rae PIM(@): Insert (192.168.1.1,239.1.1.1) prune in nbr 192.168.123.1's queue PIM(@): Building Join/Prune packet for nbr 192.168.123.1 PIM(@): Adding v2 (192.168.1.1/32, 239.1.1.1) Prune PIM(@): Send v2 join/prune to 192.168.123.1 (Gigabitetherneto/1) PIM(@): Received v2 Join/Prune on Gigabitéthernet@/1 from 192.168.123.1, not to us PIM(): Prune-List: (192.168.1.1/32, 239.1.1.1) PIM(@): Received v2 Join/Prune on Gigabitethernet@/1 from 192.168.123.3, not to us PIM(@): Join-List: (192.168.1.1/32, 239.1.1.1) R2 sends the prune message to its upstream neighbor, R1. Here's what R1 thinks of it: hitpstnetworklessons.com/muticasUmulicast-pim-prune-overrde me 091052023, 22:45 Muticast PIM Prune Overide a Fanos ReLeiveu v2 suun/Frume UN wLgoULLELMErHELO/ 4 TrUM 492-100.429.2, LO UD PIM(): Prune-list: (192.168.1.1/32, 239.1.1.1) PIM(@): Schedule to prune Gigabitetherneto/1 for (192.168.1.1/32, 239.1.1.1) PIM(@): Received v2 Join/Prune on GigabitEthernet@/1 from 192.168.123.3, to us PIM(Q): Join-List: (192.168.1.1/32, 239.1.1.1) PIM(@): Update Gigabitetherneto/1/192.168.123.3 to (192.168.1.1, 239.1.1.1), Forward state, by PIM SG Join R1 receives the prune from R2 and is ready to stop forwarding, you can see it schedules the pruning, A bit later it receives the PIM join (prune override) from R3 and decides to keep forwarding. Here's what it looks like on R3: RBH PIM(@): Received v2 Join/Prune on GigabitEthernet@/1 from 192.168.123.2, not to us PIM(®): Prune-list: (192.168.1.1/32, 239.1.1.1) PIM(@): Set join delay timer to 600 msec for (192.168.1.1/32, 239.1.1.1) on Gigabitetherneto/1 PIM(@): Received v2 Join/Prune on Gigabitéthernet@/1 from 192.168.123.1, not to us PIM(): Prune=list: (192.168.1.1/32, 239.1.1.1) PIM(): Join delay timer running at 580 for (192.168.1.1, 239.1.1.1) on Gigabitetherneto/1 PIM(): Insert (192.168.1.1,239.1.1.1) join in nbr 192.168.123.1's queue PIN(@): Building Join/Prune packet for nbr 192.168.123.1 PIM(@): Adding v2 (192.168.1.1/32, 239.1.1.1) Join PIM(@): Send v2 join/prune to 192.168.123.1 (GigabitEthernet@/1) Above we can see that R3 receives the prune message from R2. Since R3 still has a receiver, it will send a PIM join to R1. R3 is using a delay timer before sending the PIM join. When there are multiple multicast routers, on the multi-access segment that still want to receive traffic then only one of them has to @ inform R1 to keep forwarding. By using a random delay timer, one router will send the PIM join (prune override) first. Other routers will see it and will cancel their own PIM join message. hitpstnetworklessons.com/muticasUmulicast-pim-prune-overrde vane osiosi2023, 22:45 ‘Multicast PIM Prune Override a Frame 1: 68 bytes on wire (544 bits), 68 bytes captured (544 bits) on interface 0 > Ethernet IL, Src: fa:16:3e:ab:6b:f6 (fa:16:3e:ab:6b: 16), Dst: IPvamcast_Od (01:00:5e: Internet Protocol Version 4, [Src: 192.168.123.2, Dst: 224.0.0.13] ~ Protocol Independent Multicast 0010 .... = Version: 2 s+, 0011 = ype: Join/Prune (3) Reserved byte(s): 00 Checksum: @xeb94 [correct] ¥ PIM Options Upstrear (bor: 192. 168.123 Reserved byte(s): 00 Num Groups: 1 Holdtime: 210 ¥ Group @: 239.1.1.1/32 Num Joins: @ Wom Prones? 7 Ip address: 192.168.1.1/32 R1 will “relay” the prune message which we can see below: Frame 2: 68 bytes on wire (544 bits), 68 bytes captured (544 bits) on interface ethernet 1), Dst: IPvancast od (01:00:5e:00: Internot ¥ Protocol Independent Multicast o@10 .... = Version: 2 see. B11 = Type: Join/Prune (3) Reserved byte(s): 00 Checksum: @xeb94 [correct] ¥ PIM Options Upstream-neighbor: 192.168.123.1 Reserved byte(s): 00 Num Groups: 1 Holdtime: 210 ¥ Group @: 239.1.1.1/32 Num Joins: @ Num Peunes: 1 IP address: 192.168.1.1/32 ‘And finally R3 will send the PIM join (prune override) to R1: hnps:inetworklessons.com/mulicasUmullicast-pim-prune-override rane 091052023, 22:45 Muticast PIM Prune Overide - @ ¥ Protocol Independent. Multicast = Version: 2 [Iype:_Join/Prune (3) Reserved byte(s): 00 Checksum: @xeb94 [correct] ¥ PIM Options Upstreai Reserved byte(s): Num Groups: 1 Holdtime: 210 ¥ Group @: 239.1.1.1/32 [Nam Joins? T IP address: 192,168.1.1/32 Tum Prunes: @ weighbor: 199,168, 193.1 00 We can verify that R2 has stopped forwarding traffic to H2 by checking the multicast routing tables again: R2#show ip mroute 239.1.1.1 192.168.1.1 IP Multicast Routing Table Flags: D - Dense, S = Sparse, B - Bidir Group, s - SSM Group, C - Connected, Local, P - Pruned, R - RP-bit set, F - Register flag, = URD, I - Received Source Specific Host Report, - Multicast Tunnel, z - MDT-data group sender, Joined MOT-data group, y - Sending to MOT-data group, - Received BGP C-Mroute, g - Sent BGP C-Mroute, - Received BGP S-A Route, q - Sent BGP S-A Route,

    You might also like