Steering web traffic using Application Visibility & Control - or - Herding Lots of Odd Little Sheep!

Sometimes you get thrown a curveball and just have to see where it takes you...

Being a 'Netflow' guy you get some odd questions from your colleagues and customers but this ended up being a great opportunity to see a practical use for AVC, and explore how deep you have to dig to make things work sometimes...

Grab a shovel and join me on the journey!

As a precursor I'd been exploring custom NBAR entries and what you could do with them (especially where you could either recognize and tag a customer's application traffic so it appears in their Netflow data, whether it was port based, HTTP header based or even encrypted traffic - using SSL cert common name!).

Also I'm leaning on years of HTML5 and Javascript experience...4000 lines of Javascript application anyone?!

But this curveball all started as a simple question...with what looked like a simple answer!


'Can you use Application Recognition to direct certain traffic down a specific link?'

Well in theory the answer is yes!


My mental gymnastics go into overdrive....

... PBR to steer marked traffic, NBAR type features to tag traffic with a distinct DSCP value, Bob's your proverbial mother's brother! How difficult can it be...

Of course it's at this point you have to ask some questions...my list is short.

'Why?' - cos sometimes there's a cleaner solution that can be employed
'What traffic?' - this became the technical scary bit...

The 'Why' turned out to be a common requirement in certain places in the world...

And the 'What traffic' makes the 'Why' obvious...

The traffic is all web traffic going to the BBC website...and the reason...certain countries have filtered Internet connections where going to such a public newsfeed is impossible over 'controlled' links - only certain sanctioned Internet connections are allows to get to sites like the BBC or Facebook... so we have to steer our BBC web traffic to an unfettered Internet link while the rest would follow the filtered Internet connection.

But let's construct this in reverse order...


PBR

This is the easy bit.

On my LAN side interface I want a PBR statement that directs certain traffic to a different next hop than the one in the routing table.

!
interface Vlan200
 description inside VLAN interface
 ip policy route-map PBR_GLOBAL_INET

!

route-map PBR_GLOBAL_INET permit 10

 match ip address 102

 set ip next-hop 172.21.0.2

!

access-list 102 permit ip any any dscp af43

!

So any DSCP AF43 traffic is directed to the 172.21.0.2 next hop

Marking the traffic to be PBR'ed

Again kinda easy...back to our inbound LAN side interface and have a QoS marking policy.

!

interface Vlan200

 service-policy input GLOBAL_INET_MARK

!

policy-map GLOBAL_INET_MARK

 class GLOBAL_INET_DEST

  set dscp af43

! 

⚙Note: always check your logic again the order of operations for your router...a quick 'show cef interface xxx' will uncover the order in which things are done, to ensure that marking happens on your inbound interface before traffic is PBRed...

But what does our class-map need to look like?

Application Recognition

This turned out to be the tricky piece and for the purposes of explaining I'll shoot off at a tangent for a while...

Network guys are simple dudes in general...an 'application' is defined by the ports and protocols it uses (1990s thinking)...'web applications' are defined by the HTTP headers we can recognize (2010s thinking)...

But the reality is more complex and needs the nettie to think and explore like a programmer...so pick up some new tools here....

Dig out your favourite browser and get ready to point it to www.bbc.co.uk (good place to start!)

Well is that actually where your traffic is going? Pull up your command prompt/power shell or whatever and do 'nslookup www.bbc.co.uk'. From where I am that resolves out to two addresses for 'www.bbc.net.uk'. So putting in just www.bbc.co.uk into my AVC part might not necessarily have caught all the traffic! What if a user typed 'www.bbc.com' instead? That's different again!

Quiz time...if my browser pulls up the 'www.bbc.co.uk' page, how many separate connections are used for that one page?

• One? It's just a single page...
• Maybe 4-5 but they are all within *.bbc.*? 
• The most common answer may be 'I have no idea!'

⚙So let's use a nifty little tool that comes with all the popular browsers - the Web Developer Console! 

Under Chrome its found under View -> Developer -> Developer Tools.  Click on the Network tab (it's the most revealing for us!) - of course other browsers have their Developer tools hidden in other menu options but find it for your favourite browser

🚩Great for diagnosing 'network' delay issues with web apps - note the milliseconds taken to download certain parts of the page...saved my bacon a time or two!

Now open that 'www.bbc.co.uk' page....and watch the hundreds of connections within the Web Console - html pages, images, javascript code, CSS for the layout of the pages, adverts from other sites (I got an insurance advert at the top of my BBC webpage?!).

So our class-map needs to use the Application Visibility & Control feature 'match protocol' to match as many of these as possible!

It's like a custom NBAR entry but defined within a QoS class-map - NBARv2 would simply allow the Netflow records to have the right application ID attached, whereas the 'match protocol' allows us to use the NBARv2 application recognition directly within QoS!

Pretty neat!

So let's see my rudimentary answer within the class-map and look at the positives and potential pitfalls with it (for my lab it demonstrated the principles of what was needed even if it didn't catch all possible traffic!)

!

class-map match-any GLOBAL_INET_DEST

 match protocol http referer "*.bbc.co*"

 match protocol http host "*www.bbc.co.uk*"

 match protocol http host "*static.bbci.co.uk*"

 match protocol http host "www.bbc.com*"

 match protocol http host "*.bbc.co*"

!

It's not a perfect answer for such a complex website (and we're only looking at one page!)

But it's a start...

The 'match protocol http host' entries are straightforward...click on any of the Console's Network tab entries and see the HTTP header information that we can pattern match with our protocol statements (at the time I think I hit around 80% of the content from the page with the 'http host' entries!).

But what's the 'http referer' entry? Well say our webpage calls some Google Ads - the HTTP host for these requests may be something like 'https://googleads4.g.doubleclick.net' - we don't wanna include all these odd things in our match protocol but those entries usually have a HTTP Request referer entry that points back to where the originating webpage is (in our case mostly 'www.bbc.com').

That's improved our success rate on directing traffic to about 80-90% with a 5 line match protocol class-map. No guarantees it will work like this for your customer situation but use the new tools you have to do the best job you can... 

I hope I opened your eyes about web traffic and gave you some tips around how to deal with it via NBARv2's close cousin 'match protocol'...that's the Control part of AVC!

Beards signing off...I'll come back to how to make custom NBAR entries in a future blog!

? : {)