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.
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?
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?
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.
""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.
>
> >
> >Is the above possible?
> >
> >regards,
> >Ming.
>
> _________________________________
> FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
