Edge Application Marking with DSCP and Policy Based Routing on Firewall

  • 1
  • Question
  • Updated 5 years ago
  • Answered
My theory is that the 'application' recognition used by our Meraki and/or Aerohive is unable to DSCP mark the initial 3 way handshake for many types of claimed recognised traffic (especially if it's more heuristic based after set up or based upon payload/application layer pre-amble or matching) thus the firewall has already set up a session on our primary ISP link and thus so, the Policy Based Routing on DSCP values (marked by the access points application vis) becomes *moot* as the session is already set up in the firewall session table and thus doesn't get sent out the active backup link. The Juniper SRX looks up existing sessions for fast forwarding and sees a standard session based upon DSCP 0.

The firewall can see DSCP marked packets subsequently coming from the (W)LAN and the counter for that CS2 value is increasing correctly on the firewall, however the RIB(Routing Information BAse) that the FBF(Filter Based Forwarding) should send it out the secondary WAN2 PPP interface doesn't then work as the session ID has already matched on the WAN1 PPP interface.

The Filter Based Forwarding works fine for explicit ports and prefixes on the firewall (i.e. new sessions with explicit matching) but unless the downstream access points mark the initial SYN packets with the DSCP value at 3-way set up, this application based recognition on the edge and marking with DSCP seems to fail...

Any thoughts?
Photo of irldexter


  • 37 Posts
  • 1 Reply Like

Posted 5 years ago

  • 1
Photo of Anoop Dawar

Anoop Dawar

  • 26 Posts
  • 16 Reply Likes
Sorry for the late response. I had a hard time figuring out how to answer till I realized that maybe I should share with you why we added AVC in the first place.

You want QoS/Control in place where there is congestion in your network. The usual place historically was at the WAN side. However, we all know that as Wi-Fi has become mission critical for organizations, that the issue of Wi-Fi congestion has to be addressed at the source as well. Obviously Wi-Fi specs and standard QoS techniques are already available for this.

Some benefits of AVC are

1. Ability to identify applications so the administrator is provided with a full view of what is happening on the Wi-Fi network. Arguably a part of this is available on the WAN side as well -but maybe not to the granularity that is provided by Aerohive AVC - e.g. you can now see what applications are used, by user, by AP, by SSID, by location, by user-profile/policy etc.
2. You can also prioritize them (including rate limits, markings and possibly drop-behavior) - you can prevent a lot of traffic from getting onto the network in the first place. Also you can now mark the traffic so the rest of your network infrastructure could use those markings if needed. The key to note here is that now you have a new order of granularity for these controls -that was yet-again not available on the WAN side. We see that the primary use-case has been applying these policies per user-profile. This allows you to disallow Facebook games and Facebook post by contractors but allow Facebook posts by Marketing. It may also allow certain streaming applications -but throttle (rate limit) them per user-profile.

The piece you mention about DSCP markings is also a functionality in addition to per user profile application blocking or rate limiting. The DSCP helps within your network control -but may not help after that based on how policies are configured on your WAN side Firewall device.

Hope this helps