5.3 Multicast Filtering

Just wanted to clarify the solution for this task. The task states to deny sending multicast traffic out F0/0 with a TTL value less than 13. My understanding is that a multicast packet will be forwarded if the packet's TTL is higher than or equal to the interface TTL. In this case, it should be set to

R1:

interface F0/0

 ip multicast ttl-threshold 13

The solution is set to 12 which will allow packets with a TTL of 12 to be forwared.

Comments

  • Per CCO, it is "greater than", so the SG is corrected.

    http://www.cisco.com/en/US/docs/ios/ipmulti/command/reference/imc_03.html#wp1059709



    Usage Guidelines


    Only multicast packets with a TTL value greater than the threshold are forwarded out the interface.

  • But, in this document ,http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a0080094b55.shtml#ttlsetting,

     

    The ip multicast ttl-threshold <value>
    command means that any packets with a TTL lower than the specified
    threshold, in this case, 15, are not forwarded. This command is usually
    used to provide a border to keep internal multicast traffic from
    drifting out of the intranet.

     

    And I also confirm it in the LAB, equal or greater than the setting will be forwarded.

     

    Pls refer to the other's test.

    http://ccietobe.blogspot.com/2009/02/multicast-ttl-threshold.html

  • I've tried this feature using traceroute sending udp packets with set ttl (since you can't set the ttl of ping) and I was not able to get to feature to work. I used a value higher than the ttl-threshold or lower, all UDP packets got through.

     

    Rack1R5#trace
    Protocol [ip]:
    Target IP address: 239.0.0.1
    Source address:
    Numeric display [n]:
    Timeout in seconds [3]:
    Probe count [3]:
    Minimum Time to Live [1]: 20              <--ttl value
    Maximum Time to Live [30]: 20           <--ttl value
    Port Number [33434]:
    Loose, Strict, Record, Timestamp, Verbose[none]:
    Type escape sequence to abort.
    Tracing the route to 239.0.0.1

     20  *  *  *

     

    I had a router on the path to the client set with "ip multicast ttl-threshold 12" and as you can see the multicast client (with configured igmp group 239.0.0.1) received packets with TTL of 11 below the threshold and TTL 14 and TTL 15 above the threshold.

     

    Extended IP access list 111
        10 permit ip any any ttl eq 5 log
        20 permit ip any any ttl eq 6 log
        30 permit ip any any ttl eq 7 log
        40 permit ip any any ttl eq 8 log
        50 permit ip any any ttl eq 9 log
        60 permit ip any any ttl eq 10 log
        70 permit ip any any ttl eq 11 log (3 matches)
        80 permit ip any any ttl eq 12 log
        90 permit ip any any ttl eq 13 log
        100 permit ip any any ttl eq 14 log (2 matches)
        110 permit ip any any ttl eq 15 log (1 match)
        120 permit ip any any ttl eq 16 log
        130 permit ip any any (100 matches)

     

    This featue does not work for 15.0 but looks like for some 12.4T code it doesn't work either.

     

  • Issue extend ping command, we can specify the TTL value.

     

    Rack1SW2#ping ip
    Target IP address: 239.1.1.1
    Repeat count [1]:
    Datagram size [100]:
    Timeout in seconds [2]:
    Extended commands [n]: y
    Interface [All]:   
    Time to live [255]: 13<------TTL
    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 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
    .
    Rack1SW2#

     

     

    And I verified it in the dynamips with 3725 12.4(15)T5.

  •  

    I had a same qustion about multicast ttl grater than or less than. The given CCO link clears everything, thanks for posting.

    Also the meaning of thereshold uses are explained in business scene. Make sense to me know why put ttl threshold.


    http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a0080094b55.shtml#ttlsetting

    The ip multicast ttl-threshold <value> command means that any packets with a TTL lower than the specified threshold, in this case, 15, are not forwarded. This command is usually used to provide a border to keep internal multicast traffic from drifting out of the intranet.

  • I validated this task and the solution guide seems to be correct.  By specifying 12 we are saying anything with a TTL of 12 of less cannot leave this interface.

     

    I used a named extended ACL as a numbered extended ACL does not provide you the TTL option to match on.  Also you have to do an extended ping to a multicast address as when you do an extended ping to a unicast address you do not get the option to specify TTL.

     

    I think the thing to keep in mind when testing is that a router will decrement TTL on packet as they are received and then this one-lower TTL value is compared against the threshold value on the outgoing interface the ip multicast ttl-threshold command is set on.  So for example if you have the ip multicast ttl-threshold command enabled on R1's F0/0 just like the task and you are sending traffic from R5, you have to account for R1's S0/0 interface decrementing TTL by 1 before TTL of the packet is evaluated against the ip multicast ttl-threshold value.

     

    Also I considered if this command was bidirectional.  Since we are not specifying an in or out direction when applying it I thought maybe if would effect traffic inbound to the interface as well.  I tested and it does not effect inbound traffic just outbound traffic.

     

    Then finally, this feature is not even support on current IOS lol.  It appears to be a hidden command but IOS alomost lets you configure it.

     


    2821(config)#int g0/0

    2821(config-if)#ip multicast ttl-threshold 80

    This command is no longer supported.

    2821(config-if)#do show ver | in IOS

    Cisco IOS Software, 2800 Software (C2800NM-ADVENTERPRISEK9-M), Version 15.1(4)M4, RELEASE SOFTWARE (fc1)

    2821(config-if)#do show run int g0/1 | in mul

    2821(config-if)#

     

    Ben,

  • Ben,

    Interesting and you are correct, according to the DocCD: "Effective with Cisco IOS Release 15.0(1)M and Cisco IOS Release 12.2(33)SRE, the ip multicast ttl-threshold command is not available in Cisco IOS software."


    So, for the time being it is still applicable on the lab exam, since the routers are using 12.4T line. Maybe that will change in the near future, time will tell.

    Les


    On Wed, Mar 6, 2013 at 8:19 PM, Ben1978 <bounce-Ben1978@ieoc.com> wrote:

    I validated this task and the solution guide seems to be correct.  By specifying 12 we are saying anything with a TTL of 12 of less cannot leave this interface.

     

    I used a named extended ACL as a numbered extended ACL does not provide you the TTL option to match on.  Also you have to do an extended ping to a multicast address as when you do an extended ping to a unicast address you do not get the option to specify TTL.

     

    I think the thing to keep in mind when testing is that a router will decrement TTL on packet as they are received and then this one-lower TTL value is compared against the threshold value on the outgoing interface the ip multicast ttl-threshold command is set on.  So for example if you have the ip multicast ttl-threshold command enabled on R1's F0/0 just like the task and you are sending traffic from R5, you have to account for R1's S0/0 interface decrementing TTL by 1 before TTL of the packet is evaluated against the ip multicast ttl-threshold value.

     

    Also I considered if this command was bidirectional.  Since we are not specifying an in or out direction when applying it I thought maybe if would effect traffic inbound to the interface as well.  I tested and it does not effect inbound traffic just outbound traffic.

     

    Then finally, this feature is not even support on current IOS lol.  It appears to be a hidden command but IOS alomost lets you configure it.

     


    2821(config)#int g0/0

    2821(config-if)#ip multicast ttl-threshold 80

    This command is no longer supported.

    2821(config-if)#do show ver | in IOS

    Cisco IOS Software, 2800 Software (C2800NM-ADVENTERPRISEK9-M), Version 15.1(4)M4, RELEASE SOFTWARE (fc1)

    2821(config-if)#do show run int g0/1 | in mul

    2821(config-if)#

     

    Ben,



    --
    View this message online at: http://ieoc.com/forums/p/13104/196242.aspx#196242

    Les Waller, Network Engineer  ..:|:..:|:..


    Home Page: http://www.facebook.com/groups/325762454132531/

    MBA, CISSP, CCNP/CCDA


  • I agree Les, we should keep this in mind since the lab tests 12.4T which supports the feature.

     

    Over the course of studying multicast I have learned of 10 different ways to scope multicast traffic and keep it from bleeding into network segments you don't wish it to travel to.  There may be more but I've spent the time to write some notes and if folks don't mind I'd like to share them as it took me some time to accumulate the info and I'd like to share my efforts.

     

    I have learned of 5 ways to scope the data plane and 5 ways to scope the control plane.  Some I imagine would be more popular in the real world than others but anything goes for the IE lab right, so here they are.

     


    DATA PLANE:

    Rate Limiting (may be deprecated)

    To control the rate at which a sender can send to a multicast group

    The group-list defines what multicast groups to limit traffic for and the source-list defines the source of the traffic

    EXAMPLE:

    interface serial 0

     ip multicast rate-limit out group-list 1 source-list 2 64

     

    State Limiters & Cost Limiting

    Limits the number of multicast group entries that can reside in the mroute table for a given interface

    An example to use this service would be for different levels of TV service

    EXAMPLE:

    interface GigabitEthernet0/0

     ip multicast limit out acl-basic 10

     ip multicast limit out acl-gold 25

     ip multicast limit out acl-premium 75

     

    ACL Filtering

    This option simply uses typical ACL filtering to block multicast traffic

    EXAMPLE:

    ip access-list extended MULTICAST_FILTER

     permit ip any host 230.0.0.254

     permit ip any host 224.0.0.1

     permit ip any host 224.0.0.2

     permit ip any host 224.0.0.22

     permit ip any host 224.0.0.13

     permit ip any host 224.0.0.5

     permit ip any host 224.0.0.6

     deny   ip any 224.0.0.0 15.255.255.255

     permit ip any any

    !

    interface Serial0/0

       ip access-group MULTICAST_FILTER in

     

    TTL Threshold

    This feature does not modify the TTL of multicast packets but creates a TTL boundry for multicast traffic

    Multicast traffic wishing to be sent out this interface must have a TTL value in the IP header Greater then the value set

    EXAMPLE:

    interface FastEthernet0/0

     ip multicast ttl-threshold 10

     

    Storm Control

    Storm Control is a switch feature only, not available on a router

    It monitors packets passing from an interface to the switching bus in a 1 second interval and compares the measurement with a predefind suppression-level threshold

    If a given traffic type exceeds its configured rate the port will block the ability to receive any more of that traffic type until the rate of receiving that traffic type has reduced to lower than the lower threshold

    EXAMPLE:

    interface FastEthernet0/24

     storm-control broadcast level 70.00

       storm-control multicast level 50.00 45.00

     storm-control unicast level pps 1g

       storm-control action shutdown

     storm-control action trap

     

     

    CONTROL PLANE:

    Multicast Boundary

    Configures an administratively scoped boundary on the router

    A standard or extended ACL is called in to permit or deny just the multicast groups or source plus groups 

    EXAMPLE:

    access-list 22 permit 230.0.0.254

    access-list 22 deny   230.1.2.3

    !

    interface Serial0/0

     ip multicast boundary 22 out

     

    PIM BSR Border

    This feature configures an interface to be a PIM domain border

    BSR messages will not be able to pass through this interface in either direction

    Effectively partitions the network into different multicast regions using different RPs if the RPs are selected via BSR

    No other PIM messages are dropped using this feature, just BSR messages

    EXAMPLE:

    interface FastEthernet0/1

       ip pim bsr-border

     

    IGMP Limiting

    By default there is no implied limit on the number of IGMP groups learned on a given interface as a result of IGMP Joins being received

    And because IGMP Join messages lead to mroute state information being maintained, if we control the IGMP state we can control the mroute state

    Using this feature we can apply a hard max globally to all interfaces on the router or per interface

    IGMP membership report messages exceeding this limit are not entered into the IGMP cache

    This feature can be usefull in preventing DoS attacks

    EXAMPLE:

    ip igmp limit 1000

    !

    interface Serial0/0

     ip igmp limit 200

     

     

    IGMP Filtering

    Controls at the edge what groups IGMP clients are allowed to join by crafting an ACL and applying it to the interface

    Standard ACLs match the multicast group(s)

    Extended ACLs match just the group(s) or a combination of source(s) and group(s), this is good for SSM and ASM

    EXAMPLE:

    ip access-list extended test1

     deny igmp any host 232.2.2.2

     permit igmp any any

    !

    interface FastEthernet0/0

     ip igmp access-group test1

     

    IGMP Profile (switches only)

    The 3550 and 3560 perform the same IGMP filtering described above but use an IGMP Profile concept for the configuration

    The IGMP Profile is first configured and then assigned to an interface

    EXAMPLE:

    ip igmp profile 1

       permit

       range 224.0.0.0 238.255.255.255

    !

    inteface FastEthernet0/7

     ip igmp filter 1

     ip igmp max-group 5

     ip igmp max-groups action replace

Sign In or Register to comment.