MSDP SA limit

Hello,

I would apreciate if someone can clarify something about MSDP SA limit.

I think topology is not really required, however it's added for clarity.

image

A have a very basic scenario. Considering that 120.1.99.99 is my MSDP peer and i limit the number of SA received from this peer to 1

!

ip msdp sa-limit 120.1.99.99 1

!

R1(config)#do show ip msdp sum
MSDP Peer Status Summary
120.1.99.99      700   Up       04:01:01 0     0     ?

!

R1(config)#do show ip msdp sa-ca
MSDP Source-Active Cache - 1 entries
(125.1.89.8, 224.1.1.8), RP 125.1.79.9, MBGP/AS 700, 00:04:53/00:03:17, Peer 120.1.99.99

!

With one SA already cached, the next SA message will be ignored

!

R1(config)#
%MSDP-4-SA_LIMIT: SA from peer 120.1.99.99, RP 125.1.79.9 for (120.1.8.8, 224.1.1.8) exceeded sa-limit of 1

!

So far so good, my new SA was rejected(see below)

R1(config)#do show ip msdp sa-ca rejected
MSDP Rejected SA Cache
3 rejected SAs received over 00:05:44, cache size: 100 entries
Timestamp (source, group)
15776.028, (120.1.8.8, 224.1.1.8), RP: 125.1.79.9

!

Now, what i understand here is that with SA limit reached and with all new SAs ignored. If i'll send traffic from a new source, the traffic will not be able to reach the receivers.  IS THIS CORRECT?

Why i'm asking this is because this is what i was expecting, however when i tried it was not the case.

My rejected SA was listed, however the traffic was successful.

 

R8(config)#do ping 224.1.1.8 so lo0  re 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.1.1.8, timeout is 2 seconds:
Packet sent with a source address of 120.1.8.8

Reply to request 0 from 125.1.12.2, 25 ms
Reply to request 0 from 125.1.12.2, 25 ms
Reply to request 1 from 125.1.12.2, 17 ms
Reply to request 1 from 125.1.12.2, 19 ms

 

 

Comments

  • JoeMJoeM ✭✭✭

    What does R8 show for its RP's?    

               sh ip pim rp map

     

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

    Group(s) 224.1.1.8/32
      RP 120.1.9.9 (?), v2
        Info source: 120.1.9.9 (?), via bootstrap, priority 0, holdtime 150
             Uptime: 01:56:34, expires: 00:02:24

  • JoeMJoeM ✭✭✭

    This is how I am reading this.

    With the SA-limit, R1 is limited in receiving caching from R9.   But R9 still has the mapping for 224.1.1.8.

    What does this show?    sh ip mroute 224.1.1.8

  • Yes you are right, R9 still has the mapping for 224.1.1.8 but this still does not clarify on how and where i'll use SA-limitation.

    R9#show ip mroute 224.1.1.8

    (*, 224.1.1.8), 00:00:52/stopped, RP 120.1.9.9, flags: SP
      Incoming interface: Null, RPF nbr 0.0.0.0
      Outgoing interface list: Null

    (120.1.8.8, 224.1.1.8), 00:00:15/00:02:44, flags: TA
      Incoming interface: Ethernet0/0.89, RPF nbr 125.1.89.8
      Outgoing interface list:
        Ethernet0/0.79, Forward/Sparse, 00:00:15/00:03:14
             
    (125.1.89.8, 224.1.1.8), 00:00:52/00:02:07, flags: TA
      Incoming interface: Ethernet0/0.89, RPF nbr 125.1.89.8
      Outgoing interface list:
        Ethernet0/0.79, Forward/Sparse, 00:00:52/00:02:37

     

  • Can you try to ping from another router in AS700? not the same that have RP infos
    + mroute S,G entries and not the MSDP peer, i mean another router that is not the same from
    which you already registered via MSDP sa cache messages.

  •  

    image

    From R10 i can successfully ping

    R10(config)#do ping 224.1.1.8 so e0/0.90 re 10
    Packet sent with a source address of 125.1.90.10

    Reply to request 0 from 125.1.12.2, 28 ms

    !

    R9#show ip mroute 224.1.1.8

    (*, 224.1.1.8), 00:07:11/stopped, RP 120.1.9.9, flags: SP
      Incoming interface: Null, RPF nbr 0.0.0.0
      Outgoing interface list: Null

    (125.1.90.10, 224.1.1.8), 00:00:04/00:02:55, flags: TA
      Incoming interface: Ethernet0/0.90, RPF nbr 125.1.90.10
      Outgoing interface list:
        Ethernet0/0.79, Forward/Sparse, 00:00:04/00:03:25
             
    (125.1.89.8, 224.1.1.8), 00:00:17/00:02:42, flags: TA
      Incoming interface: Ethernet0/0.89, RPF nbr 125.1.89.8
      Outgoing interface list:
        Ethernet0/0.79, Forward/Sparse, 00:00:17/00:03:12


    R1#show ip msdp sa-ca
    MSDP Source-Active Cache - 1 entries
    (125.1.90.10, 224.1.1.8), RP 125.1.79.9, MBGP/AS 700, 00:07:44/00:05:28, Peer 120.1.99.99
    R1#

    %MSDP-4-SA_LIMIT: SA from peer 120.1.99.99, RP 125.1.79.9 for (125.1.89.8, 224.1.1.8) exceeded sa-limit of 1

  • JoeMJoeM ✭✭✭

    Yes you are right, R9 still has the mapping for 224.1.1.8 but this still does not clarify on how and where i'll use SA-limitation.

    EDIT:  It is important to understand that there is a difference between a mapping and a cache.   R9 does not need any caching information.  R1 is the router that is limiting any cache updates to itself (from R9).   Any devices using R9 as their RP are already taken care of for this address.

     

    R8 is already using R9 as its RP, so it doesn't need any cached information from R1.

    For testing, we need to use a device that depends on R1 (not R9) for the shared tree.   

     

    Maybe do this.   Use a different mcast address that R1 is mapping (and trying to send to R9).   Then do the SA-LIMIT testing on R8/R9 (limiting R9's cache).

     

    I have not found much information for this command. The docs are limited to this.

    cisco-doc: "Use this command to prevent distributed denial of service attacks. We
    recommend configuring this command on all MSDP peer connections."

  • So if that worked i believe in my personal opinion that the sa-limit command can only prevent some sort of overgrowth of the sa-cache of the MSDP router like in a denial of service attack where the cache could simply be exhausted after n entries. So i don't think that it could be used for filtering.

    I would rather prefer the ip msdp sa-filter (in|out) command to do that.

  • JoeMJoeM ✭✭✭

    From R10 i can successfully ping

    R10(config)#do ping 224.1.1.8 so e0/0.90 re 10
    Packet sent with a source address of 125.1.90.10

    Reply to request 0 from 125.1.12.2, 28 ms

     

    Now we need to see what R10 is using for its RP.   Probably R9 again, right?    No cache is needed. R9 already as the mapping.

  • Maybe do this.   Use a different mcast address that R1 is mapping (and trying to send to R9).   Then do the SA-LIMIT testing on R8/R9 (limiting R9's cache).

    Yes that would be right, usage guidelines also suggest the sa-limit to be configured on every MSDP peer for consistency. But if we do the test like you said it should be fine anyway.

  • JoeMJoeM ✭✭✭

    Thanks PGallo.   I have found very little information on this command, and I have not labbed this scenario -- but I am about ready to do that.  ;-)

    Another way to test this, might be to hard-code R8's RP to be R1 (not allowing it to use R9)

                       ip pim rp-address x.x.x.x override

  • Thanks PGallo.   I have found very little information on this command, and I have not labbed this scenario -- but I am about ready to do that.  ;-)

    Another way to test this, might be to hard-code R8's RP to be R1 (not allowing it to use R9)

                       ip pim rp-address x.x.x.x override

    Well me too i have to test it honestly. I'm not sure if the override keyword does work only with AUTO-RP?

    Is it valid for BSR too? [^o)]

  • JoeMJoeM ✭✭✭

    You are making me doubt myself.   [8-)]

    I would say yes. It will also work with BSR, because an RP is an RP -- regardless of whether it is learned via AUTORP or BSR.

  • image

    This is my big picture with my topology.

    Apparently any AS700 source will be able to send multicast traffic towards 224.1.1.8 receivers. The fact that R9 knows that R1 is the MSDP peer looks to be enough, even though R1 will not cache information about the (S,G)/RP.

    Another interesting result is the flooding scope of the SA. Again, SA-limit of one is in place on R1, however this will not stop the flooding for ignored SAs. R1 will receive the second SA(in my case traffic from R10) which will be ignored and afterthat the ignored SA will be flooded to other MSDP peers, R4 in this case.

     

    R4#show ip  msdp sa-cache
    MSDP Source-Active Cache - 2 entries
    (125.1.89.8, 224.1.1.8), RP 125.1.79.9, MBGP/AS 700, 00:00:26/00:05:41, Peer 120.1.11.11
    (125.1.90.10, 224.1.1.8), RP 125.1.79.9, MBGP/AS 700, 00:00:15/00:05:44, Peer 120.1.11.11
    R4#

  • JoeMJoeM ✭✭✭

    Now that you have introduced another RP (R4), I feel that we are flying blind a little, with how your configuration is setup.

    Can we see the configs just for your MSDP setup?

    Also, can you describe this information:

    • pim connectivity. Is there any separation between domains?  This is where MSDP is useful.
    • each RP is mapped to which mcast groups? (not cached)
    • Which receivers/sources use which RP's?
    • MSDP peering configs  (R1,R4,R9)

     

    Verification depends upon knowing which RP is being used by the given router.   Also,  Anycast  is a partner technology, but we are only talking MSDP right now, correct?

    All MSDP does, is attempt to sync the RP's (useful when in different PIM-SM domains and/or for anycast).   The keyword is "cache". The RP that is caching, is dependent on the other RP for this information. 

    I would like to understand how these RP's are connected to each other and to their receivers/sources.  Thanks.

     

  • JoeMJoeM ✭✭✭

    Better yet, if there is some way you can post this GNS3 lab, I would not mind playing with it.   Looks interesting.

  • This are configs for all routers.

    (It looks like in these configs, i missed on R1 ip msdp sa-limit 1)

    /cfs-file.ashx/__key/CommunityServer.Components.UserFiles/00.00.00.58.56/configs.txt

     

    My topology is

    image

    Anyway, to answer your questions

     

    • pim connectivity. Is there any separation between domains?  This is where MSDP is useful. YES(ip pim bsr-border)
    • each RP is mapped to which mcast groups? (not cached) R1 and R7: 224.1.1.8,224.1.1.6, 224.1.1.6, R4: 224.0.0.0/4
    • Which receivers/sources use which RP's? R2's e0/0.12 and R5's e0/0.45 will join 224.1.18


    MSDP peering configs  (R1,R4,R9). Nothing but MSDP peers R1-R7, R1-R4, also on R1 we have SA-limit 1

     

    All i want here is to understand WHY and WHERE i can use MSDP SA-LIMIT

  • JoeMJoeM ✭✭✭

    All i want here is to understand WHY and WHERE i can use MSDP SA-LIMIT

    I have never implemented this, and I do not see anything on this in the workbooks. But I am going with it, because it is a valid topic on the R&S exam.

    Cisco says it is a tool to limit attacks. I suppose we would set the sa-limit to a number of (S,G) entries we would expect -- and include a little overhead for busy days.   But I am just speaking from logic.

    Maybe there is a multicast expert on the list that can give an idea of the real-world limit that should be used.

     

    "Maximum number of SA messages from an MSDP peer allowed in the SA cache.


    Use this command to prevent distributed denial
    of service attacks
    . We recommend configuring this command on all MSDP
    peer connections.
    "

    http://www.cisco.com/c/en/us/td/docs/ios/12_2/ipmulti/command/reference/fiprmc_r/1rfmsdp.html#wp1034402

  • That will be great to have someone who can clarify this

  • JoeMJoeM ✭✭✭

    So if that worked i believe in my personal opinion that the sa-limit command can only prevent some sort of overgrowth of the sa-cache of the MSDP router like in a denial of service attack where the cache could simply be exhausted after n entries. So i don't think that it could be used for filtering.

    I would rather prefer the ip msdp sa-filter (in|out) command to do that.

    This.  

    Just like a rate-limit would mitigate at a certain rate (ceiling).  Or max entries in a number of other technologies.

    I also get the feeling that you are trying to treat it as a filter. At first, I thought you were only experimenting to see the reject.  Cisco recommends this on all peer connections.

     

  • Based on how it is described, i imagined this feature as a filter as soon as sa-limit is reached.

    For example in my scenario:

     1. R8 will generate a multicast feed 224.1.1.8 which will be registered with R9(RP).

    2. R9 will build SA[(R8,224.1.1.8), RP] which will be sent to R1(MSDP peer)

    3. R1 will add this entry into cache, OIL list will be used to forward traffic and all good so far.

    4. R10 will generate the second feed 224.1.1.8 which will be registered with R9(RP)

    5. R9 will build SA[R10,224.1.1.8),RP] which will be sent to R1(MSDP peer)

    6. R1 already have one entry(from R8) into sa-cache and also msdp sa-limit cache is limited to one entry.

    --------------------This is how i imagined this feature-------------------------------------------------------------

    7. SA from R10 will be ignored and as a result R1 will not have any entry for (R10,224.1.1.8) in mroute table

    ---------------------This is how apparently it works-----------------------------------------------------------------

    8. SA from R10 will be ignored. No new entry will be added to R1's sa-cache.

    9. Ignored SA will still make R1 to create a new mroute entry (R10,224.1.1.8)

    10. An inter domain SPT will be built even though there is no sa cached for this (R10,224.1.1.8)

    The only result here is that R1 will have less memory consumed by SAs

     

    As a conclusion, I think the only usage for this feature is a DOS attack as specified by Cisco.

    I think i envisioned this feature of being something more than really is.

  • JoeMJoeM ✭✭✭

      9. Ignored SA will still make R1 to create a new mroute entry (R10,224.1.1.8)

    But the new entry will not be a cached entry, correct?

    Sounds like you may also have a mapping for that group on R1.

    If so, try changing the group(s) on R1, so that it is forced to cache anything for this test mcast group.

     

    Cisco also recommends putting this on all RP's. I think your results will be more interesting if you do that. 

    But still, your testing will always depend on what RP is being used by the receivers/sources.

     

    If you want to link the GNS files, I will load the lab and experiment with it.

  • But the new entry will not be a cached entry, correct?

    Yes, that's correct.

    Sounds like you may also have a mapping for that group on R1.

    Yes, that's also correct and it's required. Without RP/G mapping this will not work.

Sign In or Register to comment.