meter doesn't work for me

[Pedro2]

Hi,

On summmit X670-48x with 15.5.4.2 v1554b2-patch1-5 I have problem with meter, i try to limit icmp traffic but looks that ingress shaper doesn't work.
i see packets on counter icmp but i don't see any dropped packets. After the switch, on router, i also see all packets, nothing was dropped..


test:
ping 192.168.65.23 -i 0.0001 -c 100000

Here is my config

entry 1 {
if {
protocol icmp;
destination-address 192.168.65.23/32 ;
} then {
# deny ;
# permit ;
count icmp;
meter meter_10_K;
}
}

configure access-list icmp_drop ports 25 ingress

create meter meter_10_K
configure meter meter_10_K committed-rate 10 Kbps out-actions drop
create meter meter_100_K
configure meter meter_100_K committed-rate 100 Kbps out-actions drop

Summit1.27 # show access-list counter ports 25 ingressPolicy Name Vlan Name Port Direction
Counter Name Packet Count Byte Count
==================================================================
icmp_drop * 25 ingress
icmp 18981

Summit1.26 # show access-list meter ports 25 ingressPolicy Name Vlan Name Port
Committed Max Burst Out-of-Profile Out-of-Profile
Meter Rate (Kbps) Size (K) Action DSCP Packet Count
===============================================================================
icmp_drop * 25
meter_10_K 10 Max Drop 0

Thanks for any help or advice

[Henrique]

Hi Pedro, you can add the "trap" option in the meter CLI to generate an SNMP trap if traffic exceeds the configured rate.

[Pedro2]

Hi,

thanks for anserwers. I had to reduce burts size and i test with udp packet by hping. Looks better, drop counter counting..

There is some oid via snmp for Out-of-Profile dropped packtes/bits ? Can't find

greets,
Pedro

[Henrique]

Hi Pedro, for ICMP traffic I would recommend you to test with some application that sends traffic flows continuously (e.g. 1M/sec ICMP flow).

As already mentioned by Erik, -i option might be tricky as well as burst traffic.

[Erik_Auerswald]

Hello Pedro,

ping is a bit problematic if you are trying to create network load, because ping waits for responses before sending a new packet. The -i option adjusts the wait time after receiving an ICMP Echo Reply resp. after the timeout for a reply expires. You can try a flood ping (ping -f) to send more packets.

Because ping adapts to the network conditions (RTT), it is quite hard to generate a specific traffic rate in the presence of packet loss. Thus ping is a bad tool to measure rate limiters, which induce packet loss (or delayed packets in the case of shaping).

You should consider using iperf in UDP mode to test specific traffic rates.

Br,
Erik

[Balaji]

After editing the acl did you refresh the policy?