5.1 Multicast

Why SG uses BSR instead of Auto-RP.

From my sight both could be acepted.

I have an issue using Auto-rp.

R1,2,3,4,5, SW1

ip pim auto-rp listener

R5

ip pim nbma-mode

 

However, none mapping arrive at R4...

some get this working with Auto-RP?

All other routers get mappings with out problems...

Comments

  • i think u r missing little concept Auto rp by default work on DM where as BSR Sparse mode...

    if any client is the RP and MA then discovery updates ll never be on the other clients ..

    2 solutioin i have

    1.... make MA 224.0.1.40  messages as in sparse mode or u can use static RP

    2. tunnel between Clients..

     

  • Hi,

    the task wants us to use a solution where R3 is doing the RP to group mapping.  The BSRs do NOT do any mapping, the client routers do it (the hash function). That's why in my opinion only Auto-RP may be used for this task and the solution in the SG is not correct.

     

  • So you says Auto-RP has to be used?

    did you get mappings at R4?

    how did you got the...

  • SG uses BSR, but scenario says "R3 should be responsible for group to RP mappings."

    I think this wording calls specifically for Auto-RP, since in Auto-RP RP is responsible for Group-to-rp mappings, whereas at BSR the responsibility is on every router for itself.

     

  • Can someone from INE, please, tell us why BSR was used instead of Auto-RP?

     

    Thanks in advance.

  • Petr wrote excellent blog regarding BSR and Auto-RP:

    http://blog.ine.com/2009/04/07/understanding-bsr-protocol/

    Thanks Petr!

  • Thanks for your reply AndiS,

    I read the blog and here is what I have retained:

    "BSRs listen and accumulate candidate RP announcements, performing the
    role similar to Auto-RP MA. However, unlike Auto-RP MA, the BSR does not
    elect the best RP for every group range it learns about. Instead of
    this, for every group range known, the BSR builds a set of candidate
    RPs, including all routers that advertised their willingness to service
    this range. This is called “group range to RP set mapping”

    It still doesn't answer the question why BSR was used instead.

     

    Thanks again for your input.

  • I agree, the wording of R3 doing the mappings leads you towards Auto-RP.  In addition, if this is done these groups are flooded in dense mode.  Though you do need the 'ip pim nbma-mode' on R5, this will not flood the auto-rp information down to R4 b/c nbma-mode works for sparse groups only.  So you have to tunnel to accomplish this with auto-rp (I did so from R4 to R3).  My configuration seems to have worked, but I was a bit suprised to see BSR in the SG.

  • SG uses BSR, but scenario says "R3 should be responsible for group to RP mappings."

    I think this wording calls specifically for Auto-RP, since in Auto-RP RP is responsible for Group-to-rp mappings, whereas at BSR the responsibility is on every router for itself.

     

     

     

    Yep I d say that here when I did the task :P

     

    I did not get the mapping on R4 too ....

     

  • Indeed I never remember that NBMA mode on PIM enabled interface works only for SPARSE groups !

     

    So I created  tunnel like this on R4 (similar config on R3 approx :D )

     

     

    RSRack1R4#sh run int tunnel 34
    Building configuration...

    Current configuration : 132 bytes
    !
    interface Tunnel34
     ip unnumbered FastEthernet0/0
     ip pim sparse-mode
     tunnel source Loopback0
     tunnel destination 150.1.3.3
    end


    ip mroute 0.0.0.0 0.0.0.0 Tunnel34

     

    Now I get the mapping on R4 :D

     

     


    RSRack1R4#sh ip pim rp mapping
    PIM Group-to-RP Mappings

    Group(s) 224.0.0.0/4
      RP 149.1.127.7 (?), v2v1
        Info source: 149.1.254.3 (?), elected via Auto-RP
             Uptime: 00:00:09, expires: 00:02:46
    RSRack1R4#

     

    Happy Happy !

  • Did anyone get Auto-RP to work without tunnels? I am still confused as to why the auto-rp messages are not reaching R4. Everything seems to be configured correclty for this to work between R5 and R4.

    R5:
    ip pim autorp listener
    interface Serial0/0/0
     ip pim nbma-mode
     ip pim sparse-mode

    R4:
    ip pim autorp listener
    interface Serial0/0/0
     ip pim sparse-mode

  • I tried replying to the email, but that didnt appear to work :) Here was my response:

    So heres whats ultimately happening.  Those groups for autorp
    (224.0.1.39 and .40) run in dense mode.  pim nbma-mode only works for
    sparse mode groups so R5 will never ever forward them to R4 unless there
    is a tunnel, or you trick the routers into thinking that those are
    sparse groups (i.e. assign an rp for them).  HTH's

  • So heres whats ultimately happening.  Those groups for autorp (224.0.1.39 and .40) run in dense mode.  pim nbma-mode only works for sparse mode groups so R5 will never ever forward them to R4 unless there is a tunnel, or you trick the routers into thinking that those are sparse groups (i.e. assign an rp for them).  HTH's


    On Sat, May 28, 2011 at 2:50 PM, mvinogradsky <[email protected]> wrote:

    Did anyone get Auto-RP to work without tunnels? I am still confused as to why the auto-rp messages are not reaching R4. Everything seems to be configured correclty for this to work between R5 and R4.

    R5:
    ip pim autorp listener
    interface Serial0/0/0
     ip pim nbma-mode
     ip pim sparse-mode

    R4:
    ip pim autorp listener
    interface Serial0/0/0
     ip pim sparse-mode




    Internetwork Expert - The Industry Leader in CCIE Preparation

    http://www.internetworkexpert.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • jason - that makes perfect sense now. Thanks! 

  • As a note.. While the SG is wrong on this one, I think everyone is overlooking a very simple solution:

     

    R4

    int s0/1

    ip pim sparse-mode

    !

    ip mroute 0.0.0.0 0.0.0.0 Serial0/1

     

     

     

    R5

    int s0/1

    ip pim sparse-mode

    !

     

     

    Seems to work fine and still keeps the Auto-RP mapping on R3.

     

     

    RSRack1SW1#ping 224.1.1.1 source vlan7

     

    Type escape sequence to abort.

    Sending 1, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:

    Packet sent with a source address of 149.1.7.7 

     

    Reply to request 0 from 149.1.254.5, 196 ms

    Reply to request 0 from 149.1.45.4, 400 ms

    Reply to request 0 from 149.1.45.4, 360 ms

    Reply to request 0 from 149.1.45.4, 308 ms

    Reply to request 0 from 149.1.254.5, 296 ms

    Reply to request 0 from 149.1.45.4, 284 ms

    Reply to request 0 from 149.1.254.5, 252 ms

    Reply to request 0 from 149.1.254.5, 200 ms

     

     

    I don't see anything saying you can't do it.

     

  • I also used Auto RP, and it does work without any tunnel !

    Both R4 Vlan4 & R5 Vlan5 reply.

    R1,2,3,4,5, SW1

    ip pim auto-rp listener

    R5 S0/0/0

    ip pim nbma-mode

     

    RSRack7SW1#ping 224.1.1.1 repeat 50 source vlan 7

    Type escape sequence to abort.
    Sending 50, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
    Packet sent with a source address of 149.7.7.7

    Reply to request 0 from 149.7.254.5, 93 ms
    Reply to request 0 from 149.7.254.4, 252 ms
    Reply to request 0 from 149.7.254.5, 176 ms
    Reply to request 0 from 149.7.254.4, 160 ms
    Reply to request 0 from 149.7.254.4, 143 ms
    Reply to request 1 from 149.7.254.5, 84 ms

     

    RSRack7SW1#sh ip mr 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
           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

    (*, 224.1.1.1), 00:15:09/stopped, RP 149.7.127.7, flags: S
      Incoming interface: Null, RPF nbr 0.0.0.0
      Outgoing interface list:
        Vlan127, Forward/Sparse, 00:14:13/00:03:07

    (149.7.127.7, 224.1.1.1), 00:00:09/00:02:54, flags: PT
      Incoming interface: Vlan127, RPF nbr 0.0.0.0
      Outgoing interface list: Null

    (149.7.77.7, 224.1.1.1), 00:00:10/00:03:23, flags: T
      Incoming interface: Vlan77, RPF nbr 0.0.0.0
      Outgoing interface list:
        Vlan127, Forward/Sparse, 00:00:10/00:03:19

    (149.7.7.7, 224.1.1.1), 00:00:10/00:03:23, flags: T
      Incoming interface: Vlan7, RPF nbr 0.0.0.0
      Outgoing interface list:
        Vlan127, Forward/Sparse, 00:00:10/00:03:19

     

    RSRack7R4#sh ip mr 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,
           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

    (*, 224.1.1.1), 00:23:45/stopped, RP 149.7.127.7, flags: SJCL
      Incoming interface: Serial0/0/0, RPF nbr 149.7.254.5
      Outgoing interface list:
        FastEthernet0/1, Forward/Sparse, 00:23:45/00:02:09

    (149.7.7.7, 224.1.1.1), 00:00:25/00:02:37, flags: LJT
      Incoming interface: Serial0/0/0, RPF nbr 149.7.254.5
      Outgoing interface list:
        FastEthernet0/1, Forward/Sparse, 00:00:25/00:02:34

    (149.7.77.7, 224.1.1.1), 00:00:25/00:02:37, flags: LJT
      Incoming interface: Serial0/0/0, RPF nbr 149.7.254.5
      Outgoing interface list:
        FastEthernet0/1, Forward/Sparse, 00:00:25/00:02:34

    (149.7.127.7, 224.1.1.1), 00:00:25/00:02:37, flags: LJT
      Incoming interface: Serial0/0/0, RPF nbr 149.7.254.5
      Outgoing interface list:
        FastEthernet0/1, Forward/Sparse, 00:00:25/00:02:34

     

     

  • Hello,

    bringing the PIM neighbor UP on the Serial link btw R4&R5 is the valid solution?

    Thanks

  • Hi,

      First of all, if the lab has initial configs running PIM sparse mode, and you are not told to change it, you should stick to things that do not require dense mode. Second, configuring PIM between R4 and R5 is allowed? Depends on lab do and dont's, if not concludent clarify it with the proctor.

    Good luck with your studies!

  • I though this task is giving us options to use either Auto-RP or BSR so i prefered BSR as it was easier to implement and have less issues. Is the the second bullet point of the task really mean to use auto-rp instead ?



  • jason_lunde, this is a great answer, thank you again for providing it.

     

    Just wanted to add one more thing to this why .

     

    R4 will only send PIM Graft messages for the AutoRP group 224.0.0.40.

    R5's NBMA only understands  PIM Join not Graft in order to work.

     

    So anytime you have AutoRP listener and NBMA mode you'll have problems as the original interface will fail the general rule of not forwarding out the same interface as received.

     

     

     

    Tom

     

     

     

  • Good to know that i'm not the only one that have R4 isolated from RP mapping advertisement.

    Feels like "what.. what!!" after knowing SG using PIM BSR as the solution. But after applying BSR instead of AutoRP, things seems getting smooth. And we don't need to enable autorp listener on each router.

    Seems like this task smelt trick here. If we trapped into AutoRP, it will cost our valuable time on the lab.

  • Jason, excellent answer.  That is a great reminder.  I went with AutoRP at first, but now I see why BSR would be best.

  • Very educational thread. What an awesome community IEOC is, you can learn so much reading the topics here.

     

     

  • Hi Cristian, thanks for that answer. I guess some of the SG must have changed by now, but i'll list my answer anyway.

    The comment of enabling between R4 and R5 is a bit strange since you are enabling it on the SW2 and R3 Lo0's... 

    I sticked to SM, but i did enable it on the PPP link between R4 and R5 and lowered the OSPF cost (from 9999 to 30). This will make sure the incoming interface on R5 is s0/0/0 while the outgoing is S0/1/0. 

     

    (*, 224.1.1.1), 03:38:21/00:03:29, RP 149.1.77.7, flags: SJCL

      Incoming interface: Serial0/0/0, RPF nbr 149.1.254.3

      Outgoing interface list:

        Serial0/0/1, Forward/Sparse, 00:26:28/00:03:29

        FastEthernet0/0, Forward/Sparse, 03:31:16/00:02:47, Int limit 2000 kbps


    This will provide a valid RPF on R4 as well to the MA:


    (150.1.3.3, 224.0.1.40), 03:36:22/00:02:56, flags: LT

      Incoming interface: Serial0/0/1, RPF nbr 149.1.45.5

      Outgoing interface list:

        Serial0/0/0, Forward/Sparse, 00:27:23/00:00:00

        FastEthernet0/1, Forward/Sparse, 03:36:22/00:00:00, Int limit 2000 kbps





    no tunnels.

    no dense-mode in the FR cloud.

    no nbma mode


    good luck everybody.
Sign In or Register to comment.