BGP and OSPF Asymmetry

Discussion in 'Cisco' started by Darren Green, Sep 5, 2008.

  1. Darren Green

    Darren Green Guest

    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
     
    Darren Green, Sep 5, 2008
    #1
    1. Advertising

  2. 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!
     
    fugettaboutit, Sep 5, 2008
    #2
    1. Advertising

  3. Darren Green

    Darren Green Guest


    >>
    >> 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
     
    Darren Green, Sep 5, 2008
    #3
  4. Darren Green

    Darren Green Guest

    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
     
    Darren Green, Sep 6, 2008
    #4
  5. Darren Green

    Darren Green Guest

    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
     
    Darren Green, Sep 6, 2008
    #5
  6. 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" <> wrote in message
    > news:48c19bd4$...
    >>>> 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

    >
    >
     
    fugettaboutit, Sep 6, 2008
    #6
  7. 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" <> wrote in message
    > news:48c19bd4$...
    >>>> 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

    >
    >
     
    fugettaboutit, Sep 6, 2008
    #7
  8. Darren Green

    Stephen Guest

    On Fri, 5 Sep 2008 22:32:51 -0400, "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.


    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" <> wrote in message
    >news:48c19bd4$...
    >>
    >>>>
    >>>> 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

    - replace xyz with ntl
     
    Stephen, Sep 6, 2008
    #8
  9. Darren Green

    Stephen Guest

    On Fri, 5 Sep 2008 22:32:51 -0400, "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.


    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" <> wrote in message
    >news:48c19bd4$...
    >>
    >>>>
    >>>> 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

    - replace xyz with ntl
     
    Stephen, Sep 6, 2008
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Magistrator

    BGP routing asymmetry

    Magistrator, Jul 5, 2005, in forum: Cisco
    Replies:
    1
    Views:
    597
    Barry Margolin
    Jul 6, 2005
  2. Christopher Heer
    Replies:
    5
    Views:
    5,811
    Charlie Root
    Mar 22, 2006
  3. German R

    Routes received by BGP and OSPF

    German R, Feb 5, 2007, in forum: Cisco
    Replies:
    1
    Views:
    475
    Thrill5
    Feb 6, 2007
  4. Replies:
    12
    Views:
    13,747
  5. morse_d3d

    BGP and OSPF Load Balance

    morse_d3d, Nov 17, 2010, in forum: Hardware
    Replies:
    1
    Views:
    1,627
    adeelasher
    Dec 28, 2010
Loading...

Share This Page