IEOC - Internetwork Expert's Online Community

Working on Lab 12 came accross that storm-control unicast level command can be used like a bandwidth cap command. Questions was to limit Layer 2 interface to 3Mbps rate and not allowed to use policing.  I have configured srr-queue bandwidth limit 30 (after setting the speed on the interface to 10Mbps) thus limiting interface bandwidth to 30% or 3Mbps from 10Mbps interface.

My question is, what is the technical difference in using storm-control unicast level VS srr-queue bandwidth limit commands?

Thanks

Dmitriy

Isn't the direction different?  srr-queue bandwidth limit is outbound and strom-control unicast level is inbound?

Than i guess SG is not correct for the Lab 12 Task 1.5.... storm-control will not limit outgoing traffic to provider.

Good thought ... (I forgot to consider direction)

Thanks

Dmitriy

Well I just read the doc cd on storm-control...it measures traffic activity INBOUND but then blocks ALL traffic...which presumably means bidirectional which is cool.  I just wonder if outbound traffic would trigger it?

So that might be a technical difference...srr-queue bandwidth limit 10 would only block out. I don't think ingress would be affected.

OK here are my results from testing this feature ..... I took IE topology connection between R1 and R4 on VLAN 146 and R4 to R5 PTP link.  Storm-control was applied to interface connecting to R4 (SW4 port f0/4). Here is the idea i was testing ....

i am generating icmp traffic from R1 going to R5 via R4.  R4 is connected to SW4 port f0/4 and traffic is OUTBOUND to R4. I want to see if storm-control will be triggered. 

SW 4 config

F0/4

storm-control unicast level pps 2 - to engage faster i put it lower value.

TEST 1  was to do ping and yes the port is blocking traffic (ALL traffic) due to a condition or more than 2 pps.

TEST 2 ... here is where i applied some access-list filters on R4 to allow PING for metering and block echo-reply

R4

interface FastEthernet0/1

 ip address 155.1.146.4 255.255.255.0

 ip access-group 102 in

 ip access-group 103 out

!

interface Serial0/1

 ip address 155.1.45.4 255.255.255.0

 ip access-group 101 in

!

Rack1R4#sh access-list

Extended IP access list 101

    10 deny icmp any any echo-reply (396 matches)

Extended IP access list 102

    10 permit icmp any any echo (1088 matches)

Extended IP access list 103

    10 permit icmp any any echo

    20 permit icmp any any echo-reply

Rack1R4#

again .. PING was sent from R1 to R5 ...... lets follow the packet ... ECHO enters INBOUND direction on SW1 f0/1 (coming from R1) gets to SW4 and it is OUTBOUND on F0/4 to get to R4 f0/1 (this is where i have storm-control configured SW4 f0/4). Now packets gets to R4f0/1 is routed to R4 s0/1 and then goes to R5 s0/1 and reaches the destination ... Now .... up to this point, we havent sent back echo-reply which would be seen on SW4 f0/4 as INBOUND packet from R4... 

Take a look at my ACL's now to see my theory that storm-control is NOT triggered by OUTBOUND traffic .... ACL 103 is configured to meter OUTBOUND echo-reply going back to R1 and that ACL has "0" hits ... and on R4 s0/1 notice ACL 101 which is blocking those echo-replys.

ACL 102 will show that traffic entering interface is very heavy but yet storm-control was never triggered since there was no INBOUND packets received.

Rack1R1#ping 150.1.5.5 source lo0 repeat 1000 timeout 0

Type escape sequence to abort.

Sending 1000, 100-byte ICMP Echos to 150.1.5.5, timeout is 0 seconds:

Packet sent with a source address of 150.1.1.1 

......................................................................

......................................................................

Success rate is 0 percent (0/1000)

Rack1R1#

Access_Router#10

[Resuming connection 10 to sw4 ... ]

Rack1SW4#

Rack1SW4#sh storm-control unicast 

Interface  Filter State   Upper        Lower        Current

---------  -------------  -----------  -----------  ----------

Fa0/4      Forwarding          2 pps        2 pps        0 pps

Nice...so your test results match whats in the 3560 config guide (although vague the CG does say measured inbound at couple of times)...The not so obviously underlying assumption is symmetrical traffic but is is good know that when SC kicks in it is in fact bidirectional and all actually means all. so the block works. 

The result though is that if you had a large ftp transfer instead of pings (outbound on fa0/4) in your test the Storm control might not be triggered due to the asymmetrical flow (depending on your inbound setting big difference between 2pps and level 10).

If your going to use Storm-control in a production network you better have a good understanding/benchmark of your traffic flows and be prepared to tweak.

As far as the CCIE R&S lab exam...you are now most likely over prepared on Storm control and srr-queue band limit.  so we can both mark these off the list

haha i agree :-) was a good discussion

johnthom1865:

As far as the CCIE R&S lab exam...you are now most likely over prepared on Storm control and srr-queue band limit.  so we can both mark these off the list

i agree thanks for taking the time to test it