Configuring QoS to prioritize EIGRP traffic

[tyler.perkey]

Hello all,

We are trying to create a QoS policy to prioritize EIGRP traffic across an L2 WAN link.  We are theorizing that the link is getting saturated, dropping EIGRP packets and thus dropping routes.  This is the police we have came up with and wanted to know if this looked correct for our situtation:

class-map match-all EIGRP

  match  dscp cs6

!

policy-map SHAPER_EIGRP

description for EIGRP outbound

  class EIGRP

    priority

policy-map POLICER_EIGRP

description for EIGRP inbound

   class EIGRP

priority

inter te2/1/11

service-policy input SHAPER_EIGRP

[rishrapsody1]

Can you please paste output of 'Show ip eigrp nei' from 1-2 devices. This should give a hint if eigrp packets are stuck in queue or not.

Also, do you see eigrp nei' flapping logs?

Can you enable eigrp log-neighbor changes within router config?

[Joseph W. Doherty]

"This is the police we have came up with and wanted to know if this looked correct for our situtation:"

No, it does not.

What are the devices and their IOS versions?

[tyler.perkey]

One device is a 3560 running cat3k_caa-universalk9, one is a 4500x running cat4500e-universalk9-m and the last one is 6880-x-le running c6800x-ipsesrvicesk9-m.

[Joseph W. Doherty]

All 3 devices have different QoS support (also all being switches means their QoS is generally a subset of what's found on software based routers).

Is the L2 WAN link's usable bandwidth the same as the physical interface hand-off? I.e. if the interface is running at 100 Mbps, your WAN provider guarantees 100 Mbps across their WAN, or do you have some subrate guarantee or limit, like your 100 Mbps hand-off only provides 50 Mbps across?

Is the EIGRP sourced by the device connected to the L2 WAN link, or is that device just a L2 transit?

[Giuseppe Larosa]

Hello Tyler,

>> We are theorizing that the link is getting saturated, dropping EIGRP packets and thus dropping routes.

as suggested by other colleague post

show ip eigrp neighbors

show ip eigrp neighbors detail

in a working and healthy environment the Q cnt column should be zero for all neighbors meaning no updates are waiting to be sent in the per neighbor queue.

EIGRP does not need to send periodic updates, but updates need to be delivered in order to each neighbor to make the DUAL algorithm to work correctly (for the loop less property of Dual even during transitions updates need to be delivered in order to each neighbor and acknowledged with an ACK unicast packet from each neighbor).

Also as noted by Joseph your QoS configuration is  wrong as shaping is supported only in outbound direction and you would like to apply the service-policy in input. There are other details of proposed config that are not correct but this is the main one.

Hope to help

Giuseppe

[tyler.perkey]

In regards to shaping vs policing, is one used exclusively for inbound and one for outbound or can they both be used both depending on the needs of the network?

[Joseph W. Doherty]

Generally, policing can be used for ingress or egress, shaping egress only.

Generally, many L3 switches don't support shaping, or a very precise version of it.

Generally, although policing ingress (or egress) impacts amount of traffic allowed downstream of the policer, it may slow upstream traffic if the traffic adjust its transmission rate when it detects lost packets (e.g. TCP). However, controlling a sender's rate, with a policer, tends to be slow to react and not very precise. I.e. it's often not very effective to insure a upstream path "preserves" bandwidth for "critical" traffic by policing "non-critical" traffic. Congestion management is best done before a bottleneck, not after it.

[Giuseppe Larosa]

Hello Tyler,

shaping is available only outbound and policing can be applied inbound or outbound.

I think Joseph has already pointed out the key facts about your network scenario:

a) WAN access rate versus switch interface speed.

If WAN CIR is a subrate of a full 100 Mbps or of 1000 Mbps you would need shaping even a rudimental form of it may be enough

b) Limited QoS capabilities of the involved devices.

Switches like C3560 have a command to allow for sub rate shaping expressed as a percentage of interface speed.

This may be enough for your needs.

I would expect C6880 to have better options but we should know what type of linecard is involved.

Edit:

for C4500-X the QoS features are different for different supervisor models

see

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/XE3-11-0E/configuration/guide/xe-311-cg/qos_mrg.html?dtid=osscdc000283

For the C4500-X and the C6880 it would be handy to provide

show module

and to tell us on which module is the port used to connect to the WAN handoff.

Edit 2:

see the section High Priority Packets in the following chapter for C4500-X.

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/XE3-11-0E/configuration/guide/xe-311-cg/qos_mrg.html?dtid=osscdc000283#40968

EIGRP packets should belong to this category as having IP Prec 6 and 802.1P CoS 6 in vlan tagged frames.

Hope to help

Giuseppe

[tyler.perkey]

The 6880 is running SUP C6880-X-LE-SUP, the 4500-X is WS-C4500X-16

[Giuseppe Larosa]

Hello Tyler,

only show module can tell us what type of supervisor is installed as WS-C4500X-16 is the chassis model.

If you worry about serial numbers you can hide them in your post.

Hope to help

Giuseppe