L2TPv3 and QOS

[tomrayjr]

Got a good one here...

Scenario: I have a 1921 router with an 8-port switch module. I'm trying to limit the total amount of traffic coming into one specific interface of the switch module (no more than 2mbps) because it overloads my wireless network connected to the WAN side.. I have had no success limiting traffic with any type of 'input' qos on that interface. What does seem to limit traffic is an outbound policy on the WAN port, but I'm really only wanting to limit the traffic coming into the specific LAN switchport (other switchports support different networks but do not send much traffic). My WAN interface is part of an L2TPv3 tunnel so I can't simply create an access list relating to the L3 subnet of the switchport (traffic outbound from the WAN interface is already encapsulated in the pseudowire so I assume the WAN interface cannot act on the original source IP address). Any ideas?

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

I don't know all the capabilities of a 1921 with an Ethernet switch module.  Assuming the Ethernet switch module ports are tied to a VLAN, have you tried an ingress policy on the VLAN interface?

Haven't directly worked with L2TPv3 tunnels, but on other tunnels, you can apply QoS to the tunnel interface or the physical interface.  Other tunnel interfaces normally "see" the non-encapsulated packet. Physical interfaces, carrying tunnel traffic, "see" the encapsulated packet unless you enable pre-classify on the tunnel interface, then a copy of the IP header is "seen".

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information  contained within this posting without consideration and with the  reader's understanding that there's no implied or expressed suitability  or fitness for any purpose. Information provided is for informational  purposes only and should not be construed as rendering professional  advice of any kind. Usage of this posting's information is solely at  reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

Ah, I think I now better understand the situation.  The 1921 may have the capability to police selected traffic egressing the L2TPv3 tunnel.

The problem, though, is since L2TPv3 is operating at L2, you can't use a L3 interface service policy for your ingress wireless traffic, and L2TPv3 tunnel egress matching may be very limited.

If your wireless traffic has a specific L2 CoS priority, you might be able to police it.

I noticed the following on the Q&A for the Cisco EtherSwitch EHWIC:

Q. Can I assign the 802.1p priority for untagged 802.3 packets?

A. Yes, you can assign the EHWIC switch for untagged 802.3 packets an 802.1p priority to refine the traffic inside your network.

[Giuseppe Larosa]

Hello Tomrayir,

L2TPv3 is a point to point L2 transport service, so the L2TPv3 payload does not carry IP packets but ethernet frames.

There are some options to mark the external L2TPv3 IPv4 header based on some parameter of the layer2 traffic carried inside.

In your case you should mark with a specific 802.1p CoS the traffic of the Vlan to be limited.

then based on this CoS you can have a different IP precedence for traffic of that specific traffic class,

This should be a policy-map applied inbound on the LAN facing interface (internal)

Then, on the outbound WAN interface you can use a policy-map to police only traffic between the L2TPv3 endpoint addresses with that specific IP precedence value.

see QoS marking for L2TPv3 tunnels

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/12stnlmk.html#wp1056339

A more direct option would be to match on vlan-id value.

see

http://www.cisco.com/en/US/docs/ios-xml/ios/qos/command/match_access-group_through_mls_ip_pbr.html#GUID-A3F8E122-D76E-4D59-9458-78D5861B8389

support for match vlan starts from 15.1.(1)T

Hope to help

Giuseppe

[tomrayjr]

I guess what I'm afraid of, which may not be a valid fear, is that the interface will not know that there is congestion at all. The WAN interface is a gig interface. It plugs physically into a wireless radio at LAN speeds then ultimately the wireless signal itself is the choke point (only allows for 30mbps or so due to distance and mesh technology used). That's I was hoping to just do a hard cap on that one LAN interface.

[Joseph W. Doherty · Accepted solution]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Policing doesn't depend on interface (congestion) backpressure.