Task 5.1 RP assignment

How about ip pim rp-candidate with priority lower on R4 than R5. I think this will also work for failover and group specific RP assignment.

no ip pim dm-fallback is also needed on all multicast routers.

Comments

  • You can do it but in he task of filtering in vlan 63 RP announcement you will do it with ip pim bsr-border instead of ip multicast boundary ACL filter-autorp ...

     

    ip pim dm-falbback is enabled for interfaces configured with either the ip pim dense-mode or ip pim sparse-dense-mode not in this scenario. so you don't need to disable it.

     

    hth



  • Does anyone else feels the solution is not right?

    The task says to make sure 239.0.0.0/8 is not distributed in either sparse and dense fashion.

    The SG implements rp-announce-filter on R3 and i don't see why. There is no specific requirement for this.

    R3 doesn't filter anything.

    Notice that there is no 239.0.0.0/8 group anywhere,

    in both RP-annoucements and RP-discoveries. So let's say another router decides to advertise itself as RP for 239.0.0.0/8. R3 won't do anything about it. Filter

    only applies to mentioned RP's.

    Therefore the correct thing to do would be do advertise "negative" mapping on R6 for 239.0.0.0/8 (deny 239.0.0.0 0.255.255.255).

    The domain will ALWAYS treat this group in dense mode even if another router tries to advertise it. Therefore no traffic  for this group can ever flow this domain.

    Edit: The another solution would be to add rp-announce-filter on R3 which stops any other RP from advertising 239.0.0.0.

    If you disagree for some reason please reply back.

     

     

  • Here are my thoughts on the solution guide:



    • R3 doesn't need autorp listener - it's not forwarding any auto-RP packets as it's the MA. It simply receives announcements and ORIGINATES discoveries.
    • R6 doesn't need autorp listener as it's leaf node and doesn't need to forward discoveries from R3 onto anyone
    • R3 could have used V3003 interface as MA source, would have been more in line with lab requirements by not enabling PIM on an extra interface.
    • Applying filters at R3 seems unnecessary considering we're only sending specific announcements in the first place.
    I don't think there's any requirement to negatively map 239/8 is there? The specificity of the groups announced on R6 implicitly denies it. So the fact that there is no RP for it and we're not running dense or dm-fallback anywhere guarantees it won't be advertised.


    I think perhaps the task wording on this needs revision as it seems out of line with what the SG has done.

  • Hi,

    Yes, I would ask for some clarification - when they ask that we make sure 239.0.0.0/0 is not propagated, do they mean in the future as well? In that case either advertise the group as negative or filter on R3 would solve it. Otherwise, since none of the RPs are advertising that group anyway, the filtering on R3 is not needed. In fact on the lab exam i would do it my way, there's no harm of extra filtering and they shouldn't take points for it. Otherwise the task is really straighforward.

  • To jdkrouter:

    RP announce filterint on R3 is necessary - 239.0.0.0/8 is part of 232.0.0.0/5. That's why they made enumeration of 232.0.0.0/5 - 238.0.0.0/5 and left 239.0.0.0/8.

    You cannot use negative statements to filter RP announcements on R3. It just does not work and INE guys said the same in their videos.  More over what you are filtering on R3 the same you have to get from RPs. Otherwise no announcements will be accepted and fillter out at all.

     

    Tom

  • Also domain will treat 239.0.0.0/9 as dense! The reason is as follows. Every group is treated as dense unless there is an RP defined for it. And we filtered this group on both R4/R5.

    This was stressed many times in INE videos.

    Tom

  • Hi,

    Tommoser we'r almost talking about the same thing, but i
    don't completely agree. I don't know about those videos your talking
    about but I'm sure my reasoning is correct; however let me say if this
    was on lab i would ask proctor to clarify what exactly is requirement.

    First,
    the remark about negative group doesn't apply here, or rather it applies under special case; i played around
    with scenario when i was doing this task and changed interfaces to
    sparse-dense mode (and forgot that it originaly was sparse). My remark
    about negative group is valid only when there is no filter on MA.

    Now, the rp filter on R3 is not
    neccesary - it isn't doing anything that R3 without filter wouldn't do.
    The task says that R3 needs to map RPs and announcements - since R3 is
    Mapping agent it will map everything that those two RPs announced. Also
    note that R6 needs to advertise ONLY the groups that R3 will match with
    filter (or other way around). Otherwise R6 cannot be RP. Therefore
    again, R3 filter is not needed since it doesn't really DO anything. It
    doesn't add or take anything to overall state. And R3 will map
    announcements wether there is filter or not, therefore i don't go
    agains the requirement.

    Finaly, if the task says 239.0.0.0/8
    should never be distributed one way or the other - that sounds to me
    like we need to make sure no other rogue RP can advertise itself for
    239.0.0.0/8, ever. R3 doesn't do anything about this - the filter only
    applies to mentioned RPs. Therefore, either another statement is needed
    on R3 which will make sure only R4,R5,and R6 can be RPs, or like i said
    before,if there is no filters on MA, negative mapping on RP  will make sure it stays negative even if another RP advertise
    itself for that group. Therefore the fact that 239.0.0.0/8 is not advertised
    on R4/R5 has nothing to do with stopping it reapear somewhere else.

    I
    read this last part many times and this is how i see it. Again, if this
    was lab i would ask somebody to clarify the requirement a bit!

    Btw, try advertising negative mapping on one of RP, see if it works.

     

     

     

  • Hi all,

       I would like to clarify this topic here; also May updates will contain needed fixes along with a breakdown. Given the task requirements, and the fact that routers are pre-configured to run PIM in sparse-mode, you have two options to accomplish this: through BSR or Auto-RP. The hint given to you in order to choose Auto-RP is "configure R3 to assign R4 as the RP for the servers in VLAN45 and R6 as the RP for the servers in VLAN63". This means you need to filter RP announcements from candidate RPs; as  this is not supported with BSR, you need to use Auto-RP. So this basically makes you use Auto-RP and configure RP filtering on R3; so the RP filter on R3 is needed as asked by the task.

      Indeed, "ip pim autorp listener" is needed only on R1 for this case so it can flood 224.0.1.39 and 224.0.1.40 in dense mode, while its interfaces are running in sparse-mode.

       For the last requirement, the administrativ scope will not be distributed in dense-mode as network runs in sparse-mode; there is no need for "no ip pim dm-fallback". To make sure it is not distributed in sparse mode as well, additional filter on MA is needed and it was added in the May updates.

    Hope it all makes sense now,

    Regards,

  • One additional question on this.

    what is the reason of those deny statements in access-list ANY_RP?

    My config is:

    ip pim rp-announce-filter rp-list R4 group-list multi-1
    ip pim rp-announce-filter rp-list R6 group-list multi-2
    ip pim rp-announce-filter rp-list any-rp group-list deny-admin
    ip pim rp-announce-filter rp-list R5 group-list multi-1

    ip access-list standard R4
     permit 154.1.0.4
    ip access-list standard R5
     permit 150.1.5.5
    ip access-list standard R6
     permit 192.10.1.6
    ip access-list standard any-rp
     permit any
    ip access-list standard deny-admin
     deny   239.0.0.0 0.255.255.255
     permit any
    ip access-list standard multi-1
     permit 224.0.0.0
    ip access-list standard multi-2
     permit 232.0.0.0 3.255.255.255
     permit 236.0.0.0 1.255.255.255
     permit 238.0.0.0 0.255.255.255

    And output looks good:

    Rack1R3#show ip pim rp map
    PIM Group-to-RP Mappings
    This system is an RP-mapping agent (Loopback0)

    Group(s) 224.0.0.0/5
      RP 154.1.0.4 (?), v2v1
        Info source: 154.1.0.4 (?), elected via Auto-RP
             Uptime: 00:00:35, expires: 00:02:21
      RP 150.1.5.5 (?), v2v1
        Info source: 150.1.5.5 (?), via Auto-RP
             Uptime: 00:00:06, expires: 00:02:50
    Group(s) 232.0.0.0/6
      RP 192.10.1.6 (?), v2v1
        Info source: 192.10.1.6 (?), elected via Auto-RP
             Uptime: 00:00:31, expires: 00:02:29
    Group(s) 236.0.0.0/7
      RP 192.10.1.6 (?), v2v1
        Info source: 192.10.1.6 (?), elected via Auto-RP
             Uptime: 00:00:31, expires: 00:02:29
    Group(s) 238.0.0.0/8
      RP 192.10.1.6 (?), v2v1
        Info source: 192.10.1.6 (?), elected via Auto-RP
             Uptime: 00:00:31, expires: 00:02:28

     

    Additionally, few another questions on this topic:

    * is the order of rp-announce-filter important?

    * how are rp-announcements matched by rp-announce filter? For example, i could change my R5 to announce 224.0.0.0/4 and mapping agent didn't filtered it out even if it is set to filter 239.0.0.0 from any sources, which is part of 224.0.0.0/4.

    * can I use just "permit host 224.0.0.0" to match all scopes which begins at 224.0.0.0? (for example 224.0.0.0/10, 224.0.0.0/24)

     

  • Debug ip pim autorp and see what happens when the messages come into the mapping agent. 

    Brian McGahan, CCIE #8593 (R&S/SP/Security)
     
    Internetwork Expert, Inc.
    Toll Free: 877-224-8987 x 705
    Outside US: 775-826-4344 x 705
    Online Community: http://www.IEOC.com

    On Feb 9, 2011, at 6:36 AM, "jdr" <[email protected]> wrote:

    One additional question on this.

    what is the reason of those deny statements in access-list ANY_RP?

    My config is:

    ip pim rp-announce-filter rp-list R4 group-list multi-1
    ip pim rp-announce-filter rp-list R6 group-list multi-2
    ip pim rp-announce-filter rp-list any-rp group-list deny-admin
    ip pim rp-announce-filter rp-list R5 group-list multi-1

    ip access-list standard R4
     permit 154.1.0.4
    ip access-list standard R5
     permit 150.1.5.5
    ip access-list standard R6
     permit 192.10.1.6
    ip access-list standard any-rp
     permit any
    ip access-list standard deny-admin
     deny   239.0.0.0 0.255.255.255
     permit any
    ip access-list standard multi-1
     permit 224.0.0.0
    ip access-list standard multi-2
     permit 232.0.0.0 3.255.255.255
     permit 236.0.0.0 1.255.255.255
     permit 238.0.0.0 0.255.255.255

    And output looks good:

    Rack1R3#show ip pim rp map
    PIM Group-to-RP Mappings
    This system is an RP-mapping agent (Loopback0)

    Group(s) 224.0.0.0/5
      RP 154.1.0.4 (?), v2v1
        Info source: 154.1.0.4 (?), elected via Auto-RP
             Uptime: 00:00:35, expires: 00:02:21
      RP 150.1.5.5 (?), v2v1
        Info source: 150.1.5.5 (?), via Auto-RP
             Uptime: 00:00:06, expires: 00:02:50
    Group(s) 232.0.0.0/6
      RP 192.10.1.6 (?), v2v1
        Info source: 192.10.1.6 (?), elected via Auto-RP
             Uptime: 00:00:31, expires: 00:02:29
    Group(s) 236.0.0.0/7
      RP 192.10.1.6 (?), v2v1
        Info source: 192.10.1.6 (?), elected via Auto-RP
             Uptime: 00:00:31, expires: 00:02:29
    Group(s) 238.0.0.0/8
      RP 192.10.1.6 (?), v2v1
        Info source: 192.10.1.6 (?), elected via Auto-RP
             Uptime: 00:00:31, expires: 00:02:28

     

    Additionally, few another questions on this topic:

    * is the order of rp-announce-filter important?

    * how are rp-announcements matched by rp-announce filter? For example, i could change my R5 to announce 224.0.0.0/4 and mapping agent didn't filtered it out even if it is set to filter 239.0.0.0 from any sources, which is part of 224.0.0.0/4.

    * can I use just "permit host 224.0.0.0" to match all scopes which begins at 224.0.0.0? (for example 224.0.0.0/10, 224.0.0.0/24)

     




    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
  • Debug ip pim autorp and see what happens when the messages come into the mapping agent. 

    Thanks Brian,

    I did the debug, cannot see any unexpected things. I was diggin around the network to find some theory about this, but no luck. Some articles on cisco.com, some on ine blog, some on ipexpert blog. Articles are good and also examples are good as well, but too simple - if you want to dive deeper - nothing really useful.

    One thing I learned is, that if RP is not matched in access-lists, its not filtered at all. But still don't understand if order of rp-announce-filter entries is important, if there is first-match rule like in ACL or what are the rules of creating those entries anyway.

     

  • It's IOS version dependent. As long as the result is what you want then the solution is fine. 

    Brian McGahan, CCIE #8593 (R&S/SP/Security)
     
    Internetwork Expert, Inc.
    Toll Free: 877-224-8987 x 705
    Outside US: 775-826-4344 x 705
    Online Community: http://www.IEOC.com

    On Feb 9, 2011, at 1:33 PM, "jdr" <[email protected]> wrote:

    image Brian McGahan:
    Debug ip pim autorp and see what happens when the messages come into the mapping agent. 

    Thanks Brian,

    I did the debug, cannot see any unexpected things. I was diggin around the network to find some theory about this, but no luck. Some articles on cisco.com, some on ine blog, some on *** blog. Articles are good and also examples are good as well, but too simple - if you want to dive deeper - nothing really useful.

    One thing I learned is, that if RP is not matched in access-lists, its not filtered at all. But still don't understand if order of rp-announce-filter entries is important, if there is first-match rule like in ACL or what are the rules of creating those entries anyway.

     




    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
  • Hi Cristian..... i agree with your comments...however....

     

    one of the requirements was that R4 need to be the RP for the adverticed groups...and in case R4 not available then R5 need to be the backup....

     

    based on Auto-rp election on the mapping agent.... the highest IP will be elected the RP for certain groups....

     

    thus wouldn't the SG by using Auto-rp...violate this requirement...... by electing R5 as it's the higher lo0....

     

    this directed me to use BSR instead of auto-rp...as the priority could be adjusted with bsr....

     

    please comment if I miss something!

     

     

  • Hi JJ,

       In my opinion my post is clear, enough (BSR allows you to assign different RP's per groups, based on hash function, but with BSR you cannot designate a router as RP for a specific group with also fallback option):

    "I would like to clarify this topic here; also May updates will contain needed fixes along with a breakdown. Given the task requirements, and the fact that routers are pre-configured to run PIM in sparse-mode, you have two options to accomplish this: through BSR or Auto-RP. The hint given to you in order to choose Auto-RP is "configure R3 to assign R4 as the RP for the servers in VLAN45 and R6 as the RP for the servers in VLAN63". This means you need to filter RP announcements from candidate RPs; as this is not supported with BSR, you need to use Auto-RP. So this basically makes you use Auto-RP and configure RP filtering on R3; so the RP filter on R3 is needed as asked by the task.

    Indeed, "ip pim autorp listener" is needed only on R1 for this case so it can flood 224.0.1.39 and 224.0.1.40 in dense mode, while its interfaces are running in sparse-mode.

    For the last requirement, the administrativ scope will not be distributed in dense-mode as network runs in sparse-mode; there is no need for "no ip pim dm-fallback". To make sure it is not distributed in sparse mode as well, additional filter on MA is needed"

    Good luck with your studies!

  • Hi Cristian..... i agree with your comments...however....

     

    one of the requirements was that R4 need to be the RP for the adverticed groups...and in case R4 not available then R5 need to be the backup....

     

    based on Auto-rp election on the mapping agent.... the highest IP will be elected the RP for certain groups....

     

    thus wouldn't the SG by using Auto-rp...violate this requirement...... by electing R5 as it's the higher lo0....

     

    this directed me to use BSR instead of auto-rp...as the priority could be adjusted with bsr....

     

    please comment if I miss something!

     

     

     

    Hi Josua,

     

    In fact, R4 uses its s0/0/0 (154.1.0.4) for Auto-RP announcements (ip pim send-rp-announce 154.1.0.4 scope 16 group-list GROUPS_224) which is higher than R5 loopback (150.1.5.5).

     

    Regards,

     

    Bassam

     

  • I'm still confused on this one too.

    I too did the BSR-solution

    While it says configure R3 to Assign the Group-to RP mappings, it never said it had to be filtered at R3.  I beleive the BSR-candidate assigns the group to RP mappings (although granted, it just sends what it is received).

    I did not view "assign" as "filter", but rather "assign to the rest of the receiving routers".

    To be honest, I started with autorp, but could not find a way to make R4 Preferred as the RP for 224.0.0.0/5 over R5 (lack of a priority feature) -- which only BSR offered.  Although in the SG, this did seem to behave as desired, I can't find the reason other than likely a loopback address value.

    Even after reading the above, I'm still confused with how to meet this requirement.

    My solutions was:

    R3:

    ip pim bsr-candidate Loopback0 8

    R4:
    ip access-list standard acl_vlan_45_groups
     permit 224.0.0.0 7.255.255.255

    ip pim rp-candidate Loopback0 group-list acl_vlan_45_groups priority 5

    R5:

    ip pim rp-candidate Loopback0 group-list acl_vlan_45_groups priority 10
    ip access-list standard acl_vlan_45_groups
     permit 224.0.0.0 7.255.255.255

    R6:

    ip pim rp-candidate Loopback0 group-list acl_vlan_63_groups priority 5
    ip access-list standard acl_vlan_63_groups
     permit 232.0.0.0 3.255.255.255
     permit 236.0.0.0 1.255.255.255
     permit 238.0.0.0 0.255.255.255
     permit 240.0.0.0 0.255.255.255

  • I think the word "assign" is key here to choose between Auto-RP and BSR :

    - auto-rp mapping agent does assign an RP, since it is the one which decides which router will be the RP for which group

    - the BSR router on the other hand does not assign anything and just collects all RP-related information and sends it out.

     

    Now, I still disagree that filtering on R3 is implied by the question here (and as mentioned by others before, the filtering does not do anything, solution works the same without filtering).

     

    As for Auto-Rp mapping agent selecting an RP when more than one is a candidate for the same range of groups, the rule is that the RP with the highest IP address is selected (as per the command reference for the ip pim send-rp-discovery if I remember correctly).

     

    Cheers.

  • Hi Cristian,

    When I read the text "configure R3 to assign R4 as the RP for the servers in VLAN45 and R6 as the RP for the servers in VLAN63" I read it with the knowledge that a Mapping agent always makes it's decision before advertising out to its leafs, (without an RP-filter) and that if R3 were acting as a BSR it would just forward all the information to its leafs where THEY make the decision.   

    The question doesn't say anything regarding assign these to the exclusion of all others.  The MA will assign/decide without the rp-announce-filters but would forcefully assign with the exclusion of others with it in place.

    The administratively scoped range is excluded from above. rp-announce-filter can't be questioned there.

    Seperately, big thumbs up with your input on the Lab tasks I've got through so far. Much appreciated.

    Paul B

     

     

Sign In or Register to comment.