Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Cisco > BGP and OSPF Asymmetry

Reply
Thread Tools

BGP and OSPF Asymmetry

 
 
Darren Green
Guest
Posts: n/a
 
      09-05-2008
I have a network where I have traffic coming in from various AS No's
into a Core AS call it AS 100.

At the bottom end I have 2 x links out of AS 100 into a Co-Lo using a
private AS 65001. All remote AS's have to traverse AS 100 to reach my
Co-Lo.

In my Co-Lo I have 4 x routers. The WAN element (2 x routers) connects
AS65001 to AS100. On the inside of my WAN routers I have LAN
connections to a pair of 6509's (one is active for all HSRP
addresses). The connections between WAN and LAN devices are crossed
over so each WAN router connects to each 6509. These connections are
configured as /30 links. There is no iBGP internally just equal cost
path OSPF links.

My problem is that OSPF is set to load share traffic back out to the
remote locations. As traffic can come in down either WAN link, how can
I get OSPF to route it back the same way.

I need a way to tag routes coming into AS100 differently based on my
own scheme but route-maps donít allow this. How can I ensure that OSPF
understands which BGP route my traffic has entered on, to allow it to
route back the same way. If I canít find the answer I will just have
to live with the probability of asymmetric traffic.

Regards

Darren
 
Reply With Quote
 
 
 
 
fugettaboutit
Guest
Posts: n/a
 
      09-05-2008
Darren Green wrote:
> I have a network where I have traffic coming in from various AS No's
> into a Core AS call it AS 100.
>
> At the bottom end I have 2 x links out of AS 100 into a Co-Lo using a
> private AS 65001. All remote AS's have to traverse AS 100 to reach my
> Co-Lo.
>
> In my Co-Lo I have 4 x routers. The WAN element (2 x routers) connects
> AS65001 to AS100. On the inside of my WAN routers I have LAN
> connections to a pair of 6509's (one is active for all HSRP
> addresses). The connections between WAN and LAN devices are crossed
> over so each WAN router connects to each 6509. These connections are
> configured as /30 links. There is no iBGP internally just equal cost
> path OSPF links.
>
> My problem is that OSPF is set to load share traffic back out to the
> remote locations. As traffic can come in down either WAN link, how can
> I get OSPF to route it back the same way.
>
> I need a way to tag routes coming into AS100 differently based on my
> own scheme but route-maps donít allow this. How can I ensure that OSPF
> understands which BGP route my traffic has entered on, to allow it to
> route back the same way. If I canít find the answer I will just have
> to live with the probability of asymmetric traffic.
>
> Regards
>
> Darren


Maybe I don't have a full picture of what you're doing, but does the
asymmetry matter? Are you transporting voice traffic? If I understand,
you want the internal WAN links to send the return packets of a given
flow over the same ingress pipe (from the co-lo's perspective). I'd say
that if it is an issue of transporting traffic that would be sensitive
to reordering, perhaps ensuring per-flow switching would be the way to
go. Otherwise, I'm not sure worrying about the return trip is an issue
unless you have some other management policy you need to adhere to, or
as I just mentioned, packet reordering (non-TCP) is of concern

Sorry if I totally misunderstood the issue!

Good Luck!

 
Reply With Quote
 
 
 
 
Darren Green
Guest
Posts: n/a
 
      09-05-2008

>>
>> I need a way to tag routes coming into AS100 differently based on my
>> own scheme but route-maps donít allow this. How can I ensure that OSPF
>> understands which BGP route my traffic has entered on, to allow it to
>> route back the same way. If I canít find the answer I will just have
>> to live with the probability of asymmetric traffic.
>>
>> Regards
>>
>> Darren

>
> Maybe I don't have a full picture of what you're doing, but does the
> asymmetry matter? Are you transporting voice traffic? If I understand,
> you want the internal WAN links to send the return packets of a given
> flow over the same ingress pipe (from the co-lo's perspective). I'd say
> that if it is an issue of transporting traffic that would be sensitive
> to reordering, perhaps ensuring per-flow switching would be the way to
> go. Otherwise, I'm not sure worrying about the return trip is an issue
> unless you have some other management policy you need to adhere to, or
> as I just mentioned, packet reordering (non-TCP) is of concern
>
> Sorry if I totally misunderstood the issue!
>
> Good Luck!
>


Thanks for the response.

You were spot on in your understanding. I had sort of got to the point
that the asymmetric traffic would be OK, I suppose many networks have
such an element anyway. Just wanted to avoid it if possible.

There is no voice at present but there is some Citrix which I believe
will be OK in this type of environment. If voice comes along I will
likely do some prepending and OSPF manipulation to ensure that the
traffic routes in and out the way I want it.

Kind regards

Darren
 
Reply With Quote
 
Darren Green
Guest
Posts: n/a
 
      09-06-2008
Thrill5 wrote:
> Asymmetric traffic flows are never a problem. Do you think traffic is
> symmetric on the Internet? If you do, then you are very, very mistaken.
>
> If traffic from point 1 to point 2 ALWAYS follows path A, and traffic from
> point 2 back to point 1 ALWAYS follows path B, then packets never arrive out
> of order because packets in each direction always flows through the same
> path. If path A and B are the same, great, if not, who cares? Out of order
> packets CAN occur when you load-balance traffic across two links. Using
> the previous example, if PATH B has a load-balanced link, we'll call the
> first link path B1, and traffic across the other B2. Now if B1 and B2 go to
> two different routers the transit time on one of them is going to be shorter
> than the other. (the odds that the packet travel times are exactly the
> same, (within a few microsecond variance) is extremely unlikely). The
> packets going down the shorter path, are going to arrive at the destination
> before the longer path and every other packet will be out of order. This
> causes issues with TCP traffic because the earlier packet has to be buffered
> on the receive side until the later packet arrives. If the difference in
> transit times between the two paths is very close, few problems occur, but
> if it is significant (significant being relative to the total bandwidth and
> delay of the two paths) then you can have retransmissions. In the case of
> UDP traffic, out of order packets can be very very bad depending on the type
> of traffic. For SNMP traffic it doesn't matter, but for voice you will have
> significant voice quality issues. Even if load-balanced links terminate on
> the SAME router, you can still have packets out of order if there is any
> queuing on either interface. Because of the out-of-order problem, Cisco
> defaults to load-balancing based upon destination, and makes it very
> difficult to not to always send ALL packets of a flow out only one link of a
> load-balanced path.
>


Thanks Thrill5.

I have been doing quite a bit of reading on CEF in the last few hrs on
CEF and per destination v per packet and I can see why Cisco default to
per destination.

Out of interest, when CEF creates the flow do you happen to know how
long the flow stay in the flow table. I would have thought the answer
was until the flow is finished, however, I would be interested to know
if there is a finite time before a flow disappears under CEF.

This is quite important to me because there are a lot of remote sites /
devices and I know this chews up memory.

I can't seem to find a value for this.

Regards

Darren
 
Reply With Quote
 
Darren Green
Guest
Posts: n/a
 
      09-06-2008
Thrill5 wrote:
> Asymmetric traffic flows are never a problem. Do you think traffic is
> symmetric on the Internet? If you do, then you are very, very mistaken.
>
> If traffic from point 1 to point 2 ALWAYS follows path A, and traffic from
> point 2 back to point 1 ALWAYS follows path B, then packets never arrive out
> of order because packets in each direction always flows through the same
> path. If path A and B are the same, great, if not, who cares? Out of order
> packets CAN occur when you load-balance traffic across two links. Using
> the previous example, if PATH B has a load-balanced link, we'll call the
> first link path B1, and traffic across the other B2. Now if B1 and B2 go to
> two different routers the transit time on one of them is going to be shorter
> than the other. (the odds that the packet travel times are exactly the
> same, (within a few microsecond variance) is extremely unlikely). The
> packets going down the shorter path, are going to arrive at the destination
> before the longer path and every other packet will be out of order. This
> causes issues with TCP traffic because the earlier packet has to be buffered
> on the receive side until the later packet arrives. If the difference in
> transit times between the two paths is very close, few problems occur, but
> if it is significant (significant being relative to the total bandwidth and
> delay of the two paths) then you can have retransmissions. In the case of
> UDP traffic, out of order packets can be very very bad depending on the type
> of traffic. For SNMP traffic it doesn't matter, but for voice you will have
> significant voice quality issues. Even if load-balanced links terminate on
> the SAME router, you can still have packets out of order if there is any
> queuing on either interface. Because of the out-of-order problem, Cisco
> defaults to load-balancing based upon destination, and makes it very
> difficult to not to always send ALL packets of a flow out only one link of a
> load-balanced path.
>


Thanks Thrill5.

I have been doing quite a bit of reading on CEF in the last few hrs on
CEF and per destination v per packet and I can see why Cisco default to
per destination.

Out of interest, when CEF creates the flow do you happen to know how
long the flow stay in the flow table. I would have thought the answer
was until the flow is finished, however, I would be interested to know
if there is a finite time before a flow disappears under CEF.

This is quite important to me because there are a lot of remote sites /
devices and I know this chews up memory.

I can't seem to find a value for this.

Regards

Darren
 
Reply With Quote
 
fugettaboutit
Guest
Posts: n/a
 
      09-06-2008
Thrill5 wrote:
> Asymmetric traffic flows are never a problem. Do you think traffic is
> symmetric on the Internet? If you do, then you are very, very mistaken.
>


-----> I would have to disagree if the goal were to ensure a particular
traffic class utilized a specific link (for auditing, accounting, or
some other non-technical reason). Would this be normative? No, but it
could be useful to have traffic controlled like this in a somewhat
unusual circumstance. Another gotcha might be traffic flow context. If
I'm utilizing some sort of stateful inspection or processing (e.g.
firewalls, IDS/IPS, application proxies, etc.) the systems needs to take
the different paths into account.

I certainly agree on the point of Internet asymmetry.

> If traffic from point 1 to point 2 ALWAYS follows path A, and traffic from
> point 2 back to point 1 ALWAYS follows path B, then packets never arrive out
> of order because packets in each direction always flows through the same
> path.


-----> I don't think this is accurate in all circumstances, specifically
situations involving policing. Out-of-profile traffic could be marked
down and assigned to a different transmit queue on the outbound
interface. I suppose one could use individual flow policing instead of
aggregate policing to help mitigate this situation from a "global"
perspective (minimize damage to other flows), or, classify specific
traffic (e.g. voice) to use a specific queuing strategy (strict
priority/LLQ, EF 46 DSCP marking). I don't know if it would be
appropriate for him to police at this point in the network, but again, I
can't say...my point is that it's just something to keep in mind.


If path A and B are the same, great, if not, who cares? Out of order
> packets CAN occur when you load-balance traffic across two links.


-----> I didn't ask him this, but I assumed he wasn't using MLPPP, and
thus the ordering issue would be moot. I just assumed independent L3
transit links.

Using
> the previous example, if PATH B has a load-balanced link, we'll call the
> first link path B1, and traffic across the other B2. Now if B1 and B2 go to
> two different routers the transit time on one of them is going to be shorter
> than the other. (the odds that the packet travel times are exactly the
> same, (within a few microsecond variance) is extremely unlikely). The
> packets going down the shorter path, are going to arrive at the destination
> before the longer path and every other packet will be out of order. This
> causes issues with TCP traffic because the earlier packet has to be buffered
> on the receive side until the later packet arrives. If the difference in
> transit times between the two paths is very close, few problems occur, but
> if it is significant (significant being relative to the total bandwidth and
> delay of the two paths) then you can have retransmissions. In the case of
> UDP traffic, out of order packets can be very very bad depending on the type
> of traffic. For SNMP traffic it doesn't matter, but for voice you will have
> significant voice quality issues. Even if load-balanced links terminate on
> the SAME router, you can still have packets out of order if there is any
> queuing on either interface. Because of the out-of-order problem, Cisco
> defaults to load-balancing based upon destination, and makes it very
> difficult to not to always send ALL packets of a flow out only one link of a
> load-balanced path.


-----> Agreed...

>
> "Darren Green" <(E-Mail Removed)> wrote in message
> news:48c19bd4$(E-Mail Removed)...
>>>> I need a way to tag routes coming into AS100 differently based on my
>>>> own scheme but route-maps donít allow this. How can I ensure that OSPF
>>>> understands which BGP route my traffic has entered on, to allow it to
>>>> route back the same way. If I canít find the answer I will just have
>>>> to live with the probability of asymmetric traffic.
>>>>
>>>> Regards
>>>>
>>>> Darren
>>> Maybe I don't have a full picture of what you're doing, but does the
>>> asymmetry matter? Are you transporting voice traffic? If I understand,
>>> you want the internal WAN links to send the return packets of a given
>>> flow over the same ingress pipe (from the co-lo's perspective). I'd say
>>> that if it is an issue of transporting traffic that would be sensitive to
>>> reordering, perhaps ensuring per-flow switching would be the way to go.
>>> Otherwise, I'm not sure worrying about the return trip is an issue unless
>>> you have some other management policy you need to adhere to, or as I just
>>> mentioned, packet reordering (non-TCP) is of concern
>>>
>>> Sorry if I totally misunderstood the issue!
>>>
>>> Good Luck!
>>>

>> Thanks for the response.
>>
>> You were spot on in your understanding. I had sort of got to the point
>> that the asymmetric traffic would be OK, I suppose many networks have such
>> an element anyway. Just wanted to avoid it if possible.
>>
>> There is no voice at present but there is some Citrix which I believe will
>> be OK in this type of environment. If voice comes along I will likely do
>> some prepending and OSPF manipulation to ensure that the traffic routes in
>> and out the way I want it.
>>
>> Kind regards
>>
>> Darren

>
>

 
Reply With Quote
 
fugettaboutit
Guest
Posts: n/a
 
      09-06-2008
Thrill5 wrote:
> Asymmetric traffic flows are never a problem. Do you think traffic is
> symmetric on the Internet? If you do, then you are very, very mistaken.
>


-----> I would have to disagree if the goal were to ensure a particular
traffic class utilized a specific link (for auditing, accounting, or
some other non-technical reason). Would this be normative? No, but it
could be useful to have traffic controlled like this in a somewhat
unusual circumstance. Another gotcha might be traffic flow context. If
I'm utilizing some sort of stateful inspection or processing (e.g.
firewalls, IDS/IPS, application proxies, etc.) the systems needs to take
the different paths into account.

I certainly agree on the point of Internet asymmetry.

> If traffic from point 1 to point 2 ALWAYS follows path A, and traffic from
> point 2 back to point 1 ALWAYS follows path B, then packets never arrive out
> of order because packets in each direction always flows through the same
> path.


-----> I don't think this is accurate in all circumstances, specifically
situations involving policing. Out-of-profile traffic could be marked
down and assigned to a different transmit queue on the outbound
interface. I suppose one could use individual flow policing instead of
aggregate policing to help mitigate this situation from a "global"
perspective (minimize damage to other flows), or, classify specific
traffic (e.g. voice) to use a specific queuing strategy (strict
priority/LLQ, EF 46 DSCP marking). I don't know if it would be
appropriate for him to police at this point in the network, but again, I
can't say...my point is that it's just something to keep in mind.


If path A and B are the same, great, if not, who cares? Out of order
> packets CAN occur when you load-balance traffic across two links.


-----> I didn't ask him this, but I assumed he wasn't using MLPPP, and
thus the ordering issue would be moot. I just assumed independent L3
transit links.

Using
> the previous example, if PATH B has a load-balanced link, we'll call the
> first link path B1, and traffic across the other B2. Now if B1 and B2 go to
> two different routers the transit time on one of them is going to be shorter
> than the other. (the odds that the packet travel times are exactly the
> same, (within a few microsecond variance) is extremely unlikely). The
> packets going down the shorter path, are going to arrive at the destination
> before the longer path and every other packet will be out of order. This
> causes issues with TCP traffic because the earlier packet has to be buffered
> on the receive side until the later packet arrives. If the difference in
> transit times between the two paths is very close, few problems occur, but
> if it is significant (significant being relative to the total bandwidth and
> delay of the two paths) then you can have retransmissions. In the case of
> UDP traffic, out of order packets can be very very bad depending on the type
> of traffic. For SNMP traffic it doesn't matter, but for voice you will have
> significant voice quality issues. Even if load-balanced links terminate on
> the SAME router, you can still have packets out of order if there is any
> queuing on either interface. Because of the out-of-order problem, Cisco
> defaults to load-balancing based upon destination, and makes it very
> difficult to not to always send ALL packets of a flow out only one link of a
> load-balanced path.


-----> Agreed...

>
> "Darren Green" <(E-Mail Removed)> wrote in message
> news:48c19bd4$(E-Mail Removed)...
>>>> I need a way to tag routes coming into AS100 differently based on my
>>>> own scheme but route-maps donít allow this. How can I ensure that OSPF
>>>> understands which BGP route my traffic has entered on, to allow it to
>>>> route back the same way. If I canít find the answer I will just have
>>>> to live with the probability of asymmetric traffic.
>>>>
>>>> Regards
>>>>
>>>> Darren
>>> Maybe I don't have a full picture of what you're doing, but does the
>>> asymmetry matter? Are you transporting voice traffic? If I understand,
>>> you want the internal WAN links to send the return packets of a given
>>> flow over the same ingress pipe (from the co-lo's perspective). I'd say
>>> that if it is an issue of transporting traffic that would be sensitive to
>>> reordering, perhaps ensuring per-flow switching would be the way to go.
>>> Otherwise, I'm not sure worrying about the return trip is an issue unless
>>> you have some other management policy you need to adhere to, or as I just
>>> mentioned, packet reordering (non-TCP) is of concern
>>>
>>> Sorry if I totally misunderstood the issue!
>>>
>>> Good Luck!
>>>

>> Thanks for the response.
>>
>> You were spot on in your understanding. I had sort of got to the point
>> that the asymmetric traffic would be OK, I suppose many networks have such
>> an element anyway. Just wanted to avoid it if possible.
>>
>> There is no voice at present but there is some Citrix which I believe will
>> be OK in this type of environment. If voice comes along I will likely do
>> some prepending and OSPF manipulation to ensure that the traffic routes in
>> and out the way I want it.
>>
>> Kind regards
>>
>> Darren

>
>

 
Reply With Quote
 
Stephen
Guest
Posts: n/a
 
      09-06-2008
On Fri, 5 Sep 2008 22:32:51 -0400, "Thrill5" <(E-Mail Removed)>
wrote:

>Asymmetric traffic flows are never a problem. Do you think traffic is
>symmetric on the Internet? If you do, then you are very, very mistaken.
>
>If traffic from point 1 to point 2 ALWAYS follows path A, and traffic from
>point 2 back to point 1 ALWAYS follows path B, then packets never arrive out
>of order because packets in each direction always flows through the same
>path. If path A and B are the same, great, if not, who cares? Out of order
>packets CAN occur when you load-balance traffic across two links.


specifically per packet load balancing.
If you have something that works at session or via hashing then each
flow follows a consistent path, and the load balancing is not visible
within each flow.

Using
>the previous example, if PATH B has a load-balanced link, we'll call the
>first link path B1, and traffic across the other B2. Now if B1 and B2 go to
>two different routers the transit time on one of them is going to be shorter
>than the other. (the odds that the packet travel times are exactly the
>same, (within a few microsecond variance) is extremely unlikely). The
>packets going down the shorter path, are going to arrive at the destination
>before the longer path and every other packet will be out of order.


reality is this still happens with 2 links with exactly the same
delay. All it needs is 2 packets, and the one which starts 2nd is
shorter than the 1st and it can overtake even with no differences in
load or queuing on the 2 paths.

again since load on 2 parallel links may aggregate from different
sources, the loads may not be balanced and so the queues in the
attached devices may run at different depths - the result is out of
order packets....

This
>causes issues with TCP traffic because the earlier packet has to be buffered
>on the receive side until the later packet arrives. If the difference in
>transit times between the two paths is very close, few problems occur, but
>if it is significant (significant being relative to the total bandwidth and
>delay of the two paths) then you can have retransmissions. In the case of
>UDP traffic, out of order packets can be very very bad depending on the type
>of traffic. For SNMP traffic it doesn't matter, but for voice you will have
>significant voice quality issues. Even if load-balanced links terminate on
>the SAME router, you can still have packets out of order if there is any
>queuing on either interface. Because of the out-of-order problem, Cisco
>defaults to load-balancing based upon destination, and makes it very
>difficult to not to always send ALL packets of a flow out only one link of a
>load-balanced path.


you can balance based on source + dest adr + socket numbers - even on
a Cat 6500 where it is all done in hardware.

But yes, asymmetric loading can be a pain, which is why 1 link at
twice the speed is usually better than 2 in parallel - at least for
raw performance.
>
>"Darren Green" <(E-Mail Removed)> wrote in message
>news:48c19bd4$(E-Mail Removed)...
>>
>>>>
>>>> I need a way to tag routes coming into AS100 differently based on my
>>>> own scheme but route-maps donít allow this. How can I ensure that OSPF
>>>> understands which BGP route my traffic has entered on, to allow it to
>>>> route back the same way. If I canít find the answer I will just have
>>>> to live with the probability of asymmetric traffic.
>>>>
>>>> Regards
>>>>
>>>> Darren
>>>
>>> Maybe I don't have a full picture of what you're doing, but does the
>>> asymmetry matter? Are you transporting voice traffic? If I understand,
>>> you want the internal WAN links to send the return packets of a given
>>> flow over the same ingress pipe (from the co-lo's perspective). I'd say
>>> that if it is an issue of transporting traffic that would be sensitive to
>>> reordering, perhaps ensuring per-flow switching would be the way to go.
>>> Otherwise, I'm not sure worrying about the return trip is an issue unless
>>> you have some other management policy you need to adhere to, or as I just
>>> mentioned, packet reordering (non-TCP) is of concern
>>>
>>> Sorry if I totally misunderstood the issue!
>>>
>>> Good Luck!
>>>

>>
>> Thanks for the response.
>>
>> You were spot on in your understanding. I had sort of got to the point
>> that the asymmetric traffic would be OK, I suppose many networks have such
>> an element anyway. Just wanted to avoid it if possible.
>>
>> There is no voice at present but there is some Citrix which I believe will
>> be OK in this type of environment. If voice comes along I will likely do
>> some prepending and OSPF manipulation to ensure that the traffic routes in
>> and out the way I want it.
>>
>> Kind regards
>>
>> Darren

>

--
Regards

http://www.velocityreviews.com/forums/(E-Mail Removed) - replace xyz with ntl
 
Reply With Quote
 
Stephen
Guest
Posts: n/a
 
      09-06-2008
On Fri, 5 Sep 2008 22:32:51 -0400, "Thrill5" <(E-Mail Removed)>
wrote:

>Asymmetric traffic flows are never a problem. Do you think traffic is
>symmetric on the Internet? If you do, then you are very, very mistaken.
>
>If traffic from point 1 to point 2 ALWAYS follows path A, and traffic from
>point 2 back to point 1 ALWAYS follows path B, then packets never arrive out
>of order because packets in each direction always flows through the same
>path. If path A and B are the same, great, if not, who cares? Out of order
>packets CAN occur when you load-balance traffic across two links.


specifically per packet load balancing.
If you have something that works at session or via hashing then each
flow follows a consistent path, and the load balancing is not visible
within each flow.

Using
>the previous example, if PATH B has a load-balanced link, we'll call the
>first link path B1, and traffic across the other B2. Now if B1 and B2 go to
>two different routers the transit time on one of them is going to be shorter
>than the other. (the odds that the packet travel times are exactly the
>same, (within a few microsecond variance) is extremely unlikely). The
>packets going down the shorter path, are going to arrive at the destination
>before the longer path and every other packet will be out of order.


reality is this still happens with 2 links with exactly the same
delay. All it needs is 2 packets, and the one which starts 2nd is
shorter than the 1st and it can overtake even with no differences in
load or queuing on the 2 paths.

again since load on 2 parallel links may aggregate from different
sources, the loads may not be balanced and so the queues in the
attached devices may run at different depths - the result is out of
order packets....

This
>causes issues with TCP traffic because the earlier packet has to be buffered
>on the receive side until the later packet arrives. If the difference in
>transit times between the two paths is very close, few problems occur, but
>if it is significant (significant being relative to the total bandwidth and
>delay of the two paths) then you can have retransmissions. In the case of
>UDP traffic, out of order packets can be very very bad depending on the type
>of traffic. For SNMP traffic it doesn't matter, but for voice you will have
>significant voice quality issues. Even if load-balanced links terminate on
>the SAME router, you can still have packets out of order if there is any
>queuing on either interface. Because of the out-of-order problem, Cisco
>defaults to load-balancing based upon destination, and makes it very
>difficult to not to always send ALL packets of a flow out only one link of a
>load-balanced path.


you can balance based on source + dest adr + socket numbers - even on
a Cat 6500 where it is all done in hardware.

But yes, asymmetric loading can be a pain, which is why 1 link at
twice the speed is usually better than 2 in parallel - at least for
raw performance.
>
>"Darren Green" <(E-Mail Removed)> wrote in message
>news:48c19bd4$(E-Mail Removed)...
>>
>>>>
>>>> I need a way to tag routes coming into AS100 differently based on my
>>>> own scheme but route-maps donít allow this. How can I ensure that OSPF
>>>> understands which BGP route my traffic has entered on, to allow it to
>>>> route back the same way. If I canít find the answer I will just have
>>>> to live with the probability of asymmetric traffic.
>>>>
>>>> Regards
>>>>
>>>> Darren
>>>
>>> Maybe I don't have a full picture of what you're doing, but does the
>>> asymmetry matter? Are you transporting voice traffic? If I understand,
>>> you want the internal WAN links to send the return packets of a given
>>> flow over the same ingress pipe (from the co-lo's perspective). I'd say
>>> that if it is an issue of transporting traffic that would be sensitive to
>>> reordering, perhaps ensuring per-flow switching would be the way to go.
>>> Otherwise, I'm not sure worrying about the return trip is an issue unless
>>> you have some other management policy you need to adhere to, or as I just
>>> mentioned, packet reordering (non-TCP) is of concern
>>>
>>> Sorry if I totally misunderstood the issue!
>>>
>>> Good Luck!
>>>

>>
>> Thanks for the response.
>>
>> You were spot on in your understanding. I had sort of got to the point
>> that the asymmetric traffic would be OK, I suppose many networks have such
>> an element anyway. Just wanted to avoid it if possible.
>>
>> There is no voice at present but there is some Citrix which I believe will
>> be OK in this type of environment. If voice comes along I will likely do
>> some prepending and OSPF manipulation to ensure that the traffic routes in
>> and out the way I want it.
>>
>> Kind regards
>>
>> Darren

>

--
Regards

(E-Mail Removed) - replace xyz with ntl
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
BGP static route from ISP and redistribute into OSPF alejabad@gmail.com Cisco 12 03-26-2008 09:23 AM
Routes received by BGP and OSPF German R Cisco 1 02-06-2007 01:30 AM
Redist. OSPF into BGP -- matching and prepending Christopher Heer Cisco 5 03-22-2006 11:27 AM
BGP routing asymmetry Magistrator Cisco 1 07-06-2005 03:01 AM
reason for jaxp dom asymmetry? Hoff, Todd XML 0 10-24-2003 12:58 AM



Advertisments