Good Tool To verify Assymmetrical Routing

[LADONNA EVANS-DUHART]

I was wondering if anyone could help me with some steps to prove that Assymmetrical routing is occuring.

Also if there was a best practice is fixing the assymmetrical routing issue.

Thx

[Collin Clark]

show interface is probably the best command that I know of. Asymmetrical routing is not always a bad thing. What problems are you experiencing?

[LADONNA EVANS-DUHART]

I am confused with the response of shore interface.  I am having problems with traffic that delayed based on the timing required from a request.  Multiple test have been performed.  There are multiple ISPs used for www traffic.  I recently ran a test...one isp at a time.  The first two providers in place by themselves return very slow response times for downloads and database queries.  Third query returns results within acceptable time frames. When multiple (2) providers are plugged up results of downloads and queries are delayed.

[Richard Burts]

I agree that I am not clear how show interface will help to demonstrate whether or not asymmetric routing is being used. In my experience one way to demonstrate this would be to do a traceroute from your source to some destination and then have someone at the destination do a traceroute to your source. If the two paths are different then there is asymmetric routing. The difficulty with this is that it requires access to the destination device or cooperation from someone at the destination.

HTH

Rick

[Peter Paluch]

Hi Rick,

I believe that a ping towards the destination with the Record Route option could potentially be used to detect asymmetric routing. However, the usability of this approach is limited as there can be at most 9 hops recorded in an IPv4 header if I my memory serves me. Nevertheless, as a tool, it may be interesting to know about it.

Best regards,

Peter

[Collin Clark]

show interface will tell you the utilization of the tx and rx of the interface. With asymmetrical routing, typically the outgoing interface on a router will have significantly higher transmit utilization than receive. You should be able to see the reverse on a parallel router.

[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

Also if there was a best practice is fixing the assymmetrical routing issue.

Hmm, unsure there's any best practice about fixing asymmetrical routing, as I wouldn't consider asymmetrical routing "broke".

Currently I work within a rather large ISP and we often have many parallel paths.  A couple of months back, I was working an issue with one hop that had 16 outgoing paths!  With such, it's quite common that return traffic won't flow across the same links that the outgoing traffic did.  Additionally different flows for the same source/destination (same direction) are unlikely to flow across the same path.

The only thing that you can usually count on, same flow (same direction) will use the same path (except if there's a topology change).

[LADONNA EVANS-DUHART]

I could see how multiple paths helps from a redundancy stand point.  In my case I have certain applications that has been suffer from extended delays.  Basically it allows us to query a database over the Internet.  When it takes an extended amount of time to retrieve its content is classified as a failure.  Under normal circumstance between 30-45 seconds is classified as acceptable.

I started by disconnected 2 of our three ISPs.  I ran the test test with failure.  I then tried the other isp and again another failure.  I then plugged the last ISP up and the test ran great consecutively.  When I look back at my logs and bgp play I notice how this ISP has added additional peers making my traffic ultimately lean in that direction.

As another test I plugged two of the three ISPs up.  Particularly one with the ISP that has provided great success.  When I ran the report again it failed.  I noticed the traffic egresses out of the ISP that provided failure by itself  even with an PBR in place pushing it out of the successful ISP.  I ran the test again to find that the successful ISP by itself allows my query and report to run successfully.  Similar test were run with the other ISP and I got the same results.  This is leading me to believe even if I push the traffic out the good ISP it is clearly not coming back on the same.....causing failure of the query...hence looking like ASRouting.

[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

The multiple paths are not just for redundancy, they are also for providing additional bandwidth.

You don't have any kind of stateful device, e.g. firewall or NAT, that's might be "confused" if return traffic comes back from a different ISP?

I've used multiple ISPs without issue.  From what you describe, either there's some issue on your ISP termination that make your network sensitive to asymmetrical routing or there's an issue with one or more of your ISPs (note - they make mistake too).

PS:

BTW, if your equipment supports it, and if applicable to your topology, you might want to look into Cisco's PfR.  If insures your traffic, and any destination, selects the outgoing path that provide the best performance.  (PfR can also "influence" inbound too, but that's much more complex to setup.)