Packet drops in self ip of ethernet

[prashirsha1]

Hello,
 

When i am pinging the self ip of an ethernet intercface. it is having drops. rate limit is applied in it with ratio of 1:1/8. When i applied the rate-limit of in the ratio of 1:1. No drops occur. Please help us tio know the reason behind it.

Earlier:

VAPI-PE-01#sh run int gi0/0.115
Building configuration...

Current configuration : 355 bytes
!
interface GigabitEthernet0/0.115
 description HDFC- Char Rasta Vapi 512 K VPN 23-12-13
 encapsulation dot1Q 115
 ip vrf forwarding HDFC:1605
 ip address 10.101.33.217 255.255.255.252
 rate-limit input 512000 64000 64000 conform-action continue exceed-action drop
 rate-limit output 512000 64000 64000 conform-action continue exceed-action drop
end

When this was the configuration, we are getting drops in self ip.

Now:

VAPI-PE-01#sh run int gi0/0.115
Building configuration...

Current configuration : 355 bytes
!
interface GigabitEthernet0/0.115
 description HDFC- Char Rasta Vapi 512 K VPN 23-12-13
 encapsulation dot1Q 115
 ip vrf forwarding HDFC:1605
 ip address 10.101.33.217 255.255.255.252
 rate-limit input 512000 512000 512000 conform-action continue exceed-action drop
 rate-limit output 512000 512000 512000 conform-action continue exceed-action drop
end

VAPI-PE-01#

no drops occur in self ip after that

[Martin Hruby]

from what you wrote I understand you are trying to ping locally your own IP 10.101.33.217 in VRF HDFC:1605, correct?

Do you have any live traffic going across this sub-interface?

Can you please show the output of "show interfaces GigabitEthernet0/0.115 rate-limit"

[prashirsha1]

Hi Martin,

Yes, at that time traffic was very low. the output of rate limit is provided above.

======Ouote===

Earlier:

VAPI-PE-01#sh run int gi0/0.115
Building configuration...

Current configuration : 355 bytes
!
interface GigabitEthernet0/0.115
 description HDFC- Char Rasta Vapi 512 K VPN 23-12-13
 encapsulation dot1Q 115
 ip vrf forwarding HDFC:1605
 ip address 10.101.33.217 255.255.255.252
 rate-limit input 512000 64000 64000 conform-action continue exceed-action drop
 rate-limit output 512000 64000 64000 conform-action continue exceed-action drop
end

When this was the configuration, we are getting drops in self ip.

Now:

VAPI-PE-01#sh run int gi0/0.115
Building configuration...

Current configuration : 355 bytes
!
interface GigabitEthernet0/0.115
 description HDFC- Char Rasta Vapi 512 K VPN 23-12-13
 encapsulation dot1Q 115
 ip vrf forwarding HDFC:1605
 ip address 10.101.33.217 255.255.255.252
 rate-limit input 512000 512000 512000 conform-action continue exceed-action drop
 rate-limit output 512000 512000 512000 conform-action continue exceed-action drop
end

VAPI-PE-01#

no drops occur in self ip after that

====unquote=====

Please let me know your feedback on same

[Martin Hruby]

Hi

I didn't mean to see the configuration, I wanted to see the output of the show command which shows the number of conformed and exceeding packets/bytes.

Please share the output of: show interfaces GigabitEthernet0/0.115 rate-limit

[virendra pathak]

Did you check offer rate on Interafce?

Regards

Shirin

[rosaho]

This discussion has been reposted from Additional Communities to the Other Network Infrastructure Subjects community.

[prashirsha1]

Hi Martin,

Sorry for the confusion. Please find the output of required command and still drops are facing in self ip.

VAPI-PE-01#sh int GigabitEthernet0/0.115 rate-limit
GigabitEthernet0/0.115 HDFC- Char Rasta Vapi 512 K VPN 23-12-13
  Input
    matches: all traffic
      params:  512000 bps, 64000 limit, 64000 extended limit
      conformed 6553 packets, 902848 bytes; action: continue
      exceeded 0 packets, 0 bytes; action: drop
      last packet: 8ms ago, current burst: 0 bytes
      last cleared 00:00:59 ago, conformed 121000 bps, exceeded 0 bps
  Output
    matches: all traffic
      params:  512000 bps, 64000 limit, 64000 extended limit
      conformed 5890 packets, 1291340 bytes; action: continue
      exceeded 22 packets, 11956 bytes; action: drop
      last packet: 4ms ago, current burst: 0 bytes
      last cleared 00:00:53 ago, conformed 194000 bps, exceeded 1000 bps
VAPI-PE-01#sh int GigabitEthernet0/0.115 rate-limit
GigabitEthernet0/0.115 HDFC- Char Rasta Vapi 512 K VPN 23-12-13
  Input
    matches: all traffic
      params:  512000 bps, 64000 limit, 64000 extended limit
      conformed 6757 packets, 932839 bytes; action: continue
      exceeded 0 packets, 0 bytes; action: drop
      last packet: 16ms ago, current burst: 0 bytes
      last cleared 00:01:02 ago, conformed 119000 bps, exceeded 0 bps
  Output
    matches: all traffic
      params:  512000 bps, 64000 limit, 64000 extended limit
      conformed 6040 packets, 1322566 bytes; action: continue
      exceeded 22 packets, 11956 bytes; action: drop
      last packet: 0ms ago, current burst: 0 bytes
      last cleared 00:00:56 ago, conformed 187000 bps, exceeded 1000 bps
VAPI-PE-01#

[Martin Hruby · Accepted solution]

Hello

From the output it is clear that you are exceeding the rate in outbound direction. Because the rate is around 200 kbps and you are limiting to 512 kbps which is well above, the dropped packets are because of sudden bursts. In a short time period (Tc) you receive more bytes (Bc) than you are allowed to send. With Bc=64 kB and CAR=512 kbps, you are allowed to send 64 kB of traffic (which is 512000 bits) once every second (not taking the excess rate into consideration for sake of simplicity) - this happens very quickly on the GigabitEthernet interface and most of the second you are just waiting - during which time the ping times out.

According to Cisco recommendation you should use normal burst = CAR/8 * 1.5 and excess burst = 2 * normal burst, which translates to:
rate-limit output 512000 96000 192000 conform-action continue exceed-action drop

I would recommend however to get rid of the legacy CAR-based QoS configuration (i.e. rate-limit commands) and instead configure QoS using MQC which would allow you to shape in outbound direction (and buffer exceeding traffic) and police in inbound direction using a more flexible approach, for example:

policy-map P_SHAPE_512k
 class class-default
  shape average 512000

policy-map P_POLICE_512k
 class class-default
  police 512000 conform-action transmit  exceed-action drop

interface GigabitEthernet0/0.115
  service-policy input P_POLICE_512k
  service-policy output P_SHAPE_512k

Verify using: show policy-map interface GigabitEthernet0/0.115

Best regards,
Martin