>Hi Howard,
>
>Thanks for the reply! The problem that I'm trying to solve is that an
>enterprise customer is seeing application performance problems possibly
>caused by asymmetric routing. The application uses TCP/IP and generates
>request/ack pairs for each transaction.
>
>The areas are normal areas, with an internal Cat5k with RSM as an internal
>area router connecting to the 2 ABRs. Initially, RSM was performing
>per-packet load balancing which now has been turned off ( I believe this
>would have contributed the most to the application latency). We have now
>activated fast switching to allow per-destination load balancing.
Yes, you are probably right that the switching mode affects the
situation. CEF, which does source-destination load balancing, will
probably improve the situation even more.
>
>Question:
>1. Is this commonly seen in other enterprise networks where the use of 2
>ABRs per area causes (becoz of asymmetric routing) significant latencies for
>certain applications?
It depends how asymmetrical the topology will be in the nonzero area.
When I design areas, especially with multiple ABRs, I try to have
their internal topology reasonably symmetrical, so the latency out
either path won't be all that different. In general, I'd suspect a
different cause inside a well-designed enterprise network, as opposed
to the public Internet.
>
>2. Is there a way to measure the impact of asymmetric routing on application
>latency apart from setting up both (1) asymmetric and (2) symmetric
>scenarios and comparing the response times? Can we monitor this on Cisco
>boxes?
Netsys, or other modeling tools, probably are the best approach. I'm
not even sure what you are thinking of in monitoring asymmetry --
routers don't know they are involved in asymmetric routing, because
asymmetry only can be defined with respect to multiple routers.
>
>3. As for solutions, will static routes and/or route maps applied at the
>internal gateways such as the RSM described above do the trick (to force
>symmetric routing)? I understand that this will need to be similarly
>applied to all areas.
They could help, but I really wonder if asymmetric paths are really
the problem, assuming you are not filtering routes in any of the
areas involved. You might be encountering "pinhole congestion" due
to per-destination load balancing. In pinhole congestion, with a
small number of hosts, the random caching may cause most of the
traffic flow to go to one path, leaving the other underutilized. As I
mentioned, CEF might help.
A lot more analysis is needed, including looking at the servers
themselves - is there a need, for example, for TCP connection-level
load balancing across a server farm (e.g., a Local Director
application)?
>
>
>""Howard C. Berkowitz"" <[EMAIL PROTECTED]> wrote in message
>news:p05001903b6e8de93d093@[63.216.127.100]...
>> >Hi all,
>> >
>> >Need to find out if there is a method for avoiding asymmetric routing
>> >between 2 areas both with 2 ABRs and equal capacity links (E1 -
>2.048Mbps).
>>
>>
>> First, what is the problem you are trying to solve? Asymmetric
>> routing is a reality in most hierarchical networks that use dynamic
>> routing. In most cases, it's best to work within its limits.
>>
>> When there are strict latency or other requirements that really
>> demand symmetrical routing, you probably need explicit static routes
>> or MPLS paths in both directions.
>>
>> >
>> >I'm looking to influence flow of traffic to certain destinations to
>remain
>> >on a single link, and not have traffic to lets say 10.32.0.0/12 go out on
>> >link A (ABR A) and return on link B (ABR B).
>>
>>
>> In the OSPF world, a starting point would be to avoid all stubby
>> areas, so the ingress routers can consider the end-to-end path to the
>> destination.
>>
>> >If I have a range of addresses 10.0.0.0/12, I know I can split it between
>> >ABR A (10.0.0.0/13) and ABR B (10.8.0.0/13) - using area summary
>statements.
>> >But the difficulty is actually configuring the other ABR as a backup for
>the
>> >same routes. I.e. ABR A backs up ABR B's range 10.8.0.0/13 and vice
>versa.
>>
>> Cisco and Bay/Nortel took different approaches to ABR summarization.
>> Both approaches have good and bad features, and I really wish each
>> vendor would offer both methods.
>>
>> Cisco's assumption is that stability is most important. Once an ABR
>> is programmed with less-specific summaries, it will always announce
>> those to area 0.0.0.0 even if some or all of the intra-area
>> more-specifics are down. It will announce them even if that means
>> some traffic is blackholed.
>>
>> Bay/Nortel's approach is that precision is most important. If some
>> of the constituent more-specifics of an aggregate go down, the ABR
>> will stop advertising the summary and only advertise the
> > more-specifics.
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
