[j-nsp] Multipath BGP issue

Krasimir Avramski krasi at smartcom.bg
Thu Jun 2 09:30:09 EDT 2011


Hi,

Do you have per-flow load balancing enabled ???

If you are in default  per prefix load balancing mode then you have
both next-hops in active route (because of multipath):
Next hop: xx.124.46.74 via xe-4/3/0.68
Next hop: xx.124.7.98 via xe-4/3/0.67, selected

Since you are receiving only one route from customer  there is no
chance to balance per prefix to eligible 2 next-hops.

Krasi

On Thu, Jun 2, 2011 at 3:52 PM, Paul Stewart <paul at paulstewart.org> wrote:
> Hey folks.
>
>
>
> I'd like to know if I'm being dumb or if my problem is legit ;)  MX480
> platform running 10.0R3.10.
>
>
>
> Customer has BGP connection from us - been in service for long time and
> works fine.  Customer now added a second BGP connection to us and we've run
> into a problem.  Traffic from us to the customer (inbound Internet from
> customer perspective) will only prefer one path.
>
>
>
> So obvious answer I thought was multipath in the configuration (which has
> always been present) however see the config and output below..
>
>
>
> First configuration (customer AS changed to 12345 to protect the innocent):
>
>
>
> {master}[edit protocols bgp group transit-customers-v4]
>
> paul at core1.toronto1# show
>
> type external;
>
> description IP_Transit_Customers_Full_V4;
>
> advertise-inactive;
>
> export [ ospf_bgp outbound-transit-v4 ];
>
> multipath;
>
> neighbor xx.xxx.x.98 {
>
>    description xxxxxxxxxxxxxxx;
>
>    import inbound-iaw;
>
>    peer-as 12345;
>
> }
>
> neighbor xx.xxx.x.74 {
>
>    description xxxxxxxxxxxxxxxxxxxx;
>
>    import inbound-iaw;
>
>    peer-as 12345;
>
> }
>
>
>
> {master}[edit policy-options policy-statement inbound-iaw]
>
> paul at core1.toronto1# show
>
> term iaw1 {
>
>    from {
>
>        prefix-list ASxxxxx;
>
>    }
>
>    then {
>
>        local-preference 300;
>
>        community add customer_nets;
>
>        accept;
>
>    }
>
> }
>
> term iaw2 {
>
>    then reject;
>
> }
>
>
>
>
>
> The same policy is applied on both sessions - original session works fine
> and the second session shows the same route being accepted (both BGP
> sessions have an active route accepted)
>
>
>
> paul at core1.toronto1> show route receive-protocol bgp xx.xxx.7.98
>
>
>
> inet.0: 362929 destinations, 835229 routes (362908 active, 21 holddown, 18
> hidden)
>
>  Prefix                  Nexthop              MED     Lclpref    AS path
>
> * xx.49.32.0/19           xx.124.7.98          0                  12345 I
>
>
>
> paul at core1.toronto1> show route receive-protocol bgp xx.xxx.46.74
>
>
>
> inet.0: 362933 destinations, 835221 routes (362906 active, 27 holddown, 18
> hidden)
>
>  Prefix                  Nexthop              MED     Lclpref    AS path
>
>  xx.49.32.0/19           xx.124.46.74         0                  12345 I
>
>
>
>
>
> So this is where things start to fall apart - had a JTAC ticket open on this
> since yesterday morning and they are still "digesting" my configuration and
> various captures.  You can see that only one path is being preferred but
> why?
>
>
>
>
>
> paul at core1.toronto1> show route xx.49.32.0/19
>
>
>
> inet.0: 362924 destinations, 835210 routes (362912 active, 12 holddown, 18
> hidden)
>
> + = Active Route, - = Last Active, * = Both
>
>
>
> xx.49.32.0/19      *[BGP/170] 1d 10:18:43, MED 0, localpref 300
>
>                      AS path: 12345 I
>
>                      to xx.124.46.74 via xe-4/3/0.68
>
>                    > to xx.124.7.98 via xe-4/3/0.67
>
>                    [BGP/170] 1d 10:18:43, MED 0, localpref 300
>
>                      AS path: 12345 I
>
>                    > to xx.124.46.74 via xe-4/3/0.68
>
>                    [BGP/170] 17:39:04, MED 100, localpref 200, from
> xxx.32.245.78
>
>                      AS path: xxxxx 12345 I
>
>                    > to xxx.32.245.56 via xe-4/3/0.56
>
>
>
> paul at core1.toronto1> show route forwarding-table destination xx.49.32.0/19
>
> Routing table: default.inet
>
> Internet:
>
> Destination        Type RtRef Next hop           Type Index NhRef Netif
>
> xx.49.32.0/19      user     0
>
>                   user     0 xx.124.7.98        ucst  1681     4
> xe-4/3/0.67
>
>
>
> paul at core1.toronto1> show route xx.49.32.0/19 detail
>
>
>
> inet.0: 362928 destinations, 835260 routes (362898 active, 30 holddown, 18
> hidden)
>
> xx.49.32.0/19 (3 entries, 1 announced)
>
>        *BGP    Preference: 170/-301
>
>                Next hop type: Router
>
>                Next-hop reference count: 2
>
>                Source: xx.124.7.98
>
>                Next hop: xx.124.46.74 via xe-4/3/0.68
>
>                Next hop: xx.124.7.98 via xe-4/3/0.67, selected
>
>                State: <Active Ext>
>
>                Local AS: 11666 Peer AS: 12345
>
>                Age: 1d 10:34:01        Metric: 0
>
>                Task: BGP_12345.xx.124.7.98+179
>
>                Announcement bits (4): 0-KRT 5-BGP RT Background 6-Resolve
> tree 1 9-RT
>
>                AS path: 12345 I (Atomic) Aggregator: 12345 xx.49.32.226
>
>                AS path:
>
>                AS path: Recorded
>
>                Communities: 11666:4000
>
>                Accepted Multipath
>
>                Localpref: 300
>
>                Router ID: xx.49.32.226
>
>         BGP    Preference: 170/-301
>
>                Next hop type: Router
>
>                Next-hop reference count: 1
>
>                Source: xx.124.46.74
>
>                Next hop: xx.124.46.74 via xe-4/3/0.68, selected
>
>                State: <NotBest Ext>
>
>                Inactive reason: Not Best in its group - Update source
>
>                Local AS: 11666 Peer AS: 12345
>
>                Age: 1d 10:34:01        Metric: 0
>
>                Task: BGP_12345.xx.124.46.74+179
>
>                AS path: 12345 I (Atomic) Aggregator: 12345 xx.49.32.226
>
>                AS path:
>
>                AS path: Recorded
>
>                Communities: 11666:4000
>
>                Accepted
>
>                Localpref: 300
>
>                Router ID: xx.49.32.226
>
>
>
> Is there a legit issue here somewhere?  JTAC seemed to indicate they wanted
> to further investigate my import policy but I don't see anything wrong
> here.. ?
>
>
>
> Thanks for any input - this list is typically MUCH faster than JTAC for
> answers and I have a very anxious customer on my hands ;)
>
>
>
> Paul
>
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



More information about the juniper-nsp mailing list