Traffic Shaping and Policing – Why Ingress Traffic is Managed

bandwidthfirewallqostcpudp

Pardon me for my ignorance. I have not tried QoS nor traffic shaping/policing before.

I have been pondering on whether can/why would we want to shape/police ingress traffic if you have no control over the next hop device.

Let's say my FWs WAN interface is connected to an ISP router. The ISP router will just send traffic down the pipe to my FW as much as the bandwidth allows.

Even if my FW has some traffic shaping/policing rules in place, it will just cause ingress packets to get either queued or dropped, and the external sender to resend the drop packets (eventually consuming more bandwidth for a longer period?)

Am I missing the point? Why would we want to police/shape ingress traffic?

Best Answer

You queue or shape on traffic leaving a router, and it is really done on traffic outbound from your network. You can police (drop) traffic either inbound or outbound.

You shape and/or police outbound traffic to give different traffic flows differing amounts of the total outbound bandwidth.

Shaping the ingress traffic as it leaves your router into your network doesn't really accomplish much because you probably have greater bandwidth to your network than you do coming into your router from the WAN.

You can really only police traffic on the ingress of a router, and dropping TCP packets will cause the TCP receiver to miss segments and not ACK the missing segments, causing the segments to be resent, and the TCP sender will slow things down. This is inexact compared to egress traffic shaping, where you can actually give specific bandwidth numbers or percentages of the total bandwidth to different traffic flows.

Even if my FW has some traffic shaping/policing rules in place, it will just cause ingress packets to get either queued or dropped, and the external sender to resend the drop packets (eventually consuming more bandwidth for a longer period?)

Yes, it will cause TCP to take longer to send something to your network, but it will be sending at a reduced rate (lower bandwidth), giving other inbound traffic a chance. It will actually be consuming less bandwidth, but more data usage over a longer period of time. Do not confuse bandwidth and data usage. Bandwidth is the maximum number of bits a link can handle per second, but data usage is how much data is actually sent or received over a period of time. They are very different terms, and many people confuse them.

You can't really do much about connectionless (UDP or other) traffic clogging your inbound bandwidth, and a single host could practically monopolize the bandwidth inbound to your network.

Related Solutions

Ethernet switch capable of H-QoS at the 802.1q level

While I don't think it's as "robust" as H-QoS/giving percentages based on DSCP values and would probably require more configuration overhead, you could rate-limit outbound against L2 ACL's that reference a VLAN. Example:

policy-map 10Mbps
  cir 9992688 cbs 32768 eir 0 ebs 1250 excess-priority 0

!numbered access lists in the range of 400-599 are for L2 MAC access lists
access-list 400 permit any any 2000 etype any
!2000 will represent the VLAN ID

interface ethernet 1/1
  qos pcp encode-policy off     ! preserve outer VLAN CoS if applicable
  rate-limit strict-acl         ! drop traffic that's denied by a rate-limiting ACL
  rate-limit output access-group 400 policy-map 10Mbps

According to the docs, you can bind multiple rate limiting policies to a single port, however once a matching ACL clause is found for a packet, the device doesn't evaluate subsequent clauses in the rate limiting ACL and subsequent rate limiting ACLs.

As to setting EF, instead of doing that you may be able to commit to 25% of the 10Mbps and the rest can go to an EIR/EBS value.

Cisco – QoS voice traffic on WAN of Cisco 1841

The short answer is no. Your queuing policy needs to be applied outbound at the point of bottleneck. In this case, the bottleneck is the WAN connection (20 Mbps) between the pfSense and the 1841. Thus, the proper location of your queuing policies are outbound on the LAN interface (a bit of a misnomer) of the pfSense and outbound on Fa0/01 of the 1841, which you have.

All that being said, your policy on the 1841 is flawed. In your example, you've reserved 1 Mbps of bandwidth for VoIP and applied the policy to a 100 Mbps interface. What happens when the PCs start pushing 70Mbps of traffic while trying to make a VoIP call? From a queuing standpoint on the 1841, the answer is nothing. There is only 70 Mbps of data flowing out Fa0/1. Therefore, there is always 1 Mbps available for VoIP. However, once this traffic reaches the pfSense, at least 50 Mbps of data and VoIP will be dropped. Your calls would be terrible at best.

Without getting into all of the details, and using your prior example, the policy should be something like this:

class-map match-any CM-VOICE-TRAFFIC
 match access-group 145
!
policy-map PM-PRIORITISE-VOICE-child
 class CM-VOICE-TRAFFIC
   set ip dscp ef
   priority 1000
 class class-default
   fair-queue
!
policy-map Shape-20Mb-parent
 class class-default
  shape average 20000000
  service-policy PM-PRIORITISE-VOICE-child
!
interface FastEthernet0/1
 service-policy output Shape-20Mb-parent
!
access-list 145 permit ip 10.0.59.0 0.0.0.255 any

This policy creates an artificial bandwidth limit on all traffic leaving the Fa0/1 on the 1841. Thus, the pfSense will never have the opportunity to drop traffic indiscriminately. Also, instead of the bandwidth command, the priority command should be used to limit latency and jitter. The tagging and the ACL change should be self-explanatory.

Best Answer

Related Solutions

Ethernet switch capable of H-QoS at the 802.1q level

Cisco – QoS voice traffic on WAN of Cisco 1841

Related Topic