[j-nsp] Multipath BGP issue
Paul Stewart
paul at paulstewart.org
Thu Jun 2 10:38:02 EDT 2011
Thanks Krasi... that's exactly what the issue was - appreciate the response
;)
Paul
-----Original Message-----
From: Krasimir Avramski [mailto:krasi at smartcom.bg]
Sent: Thursday, June 02, 2011 9:30 AM
To: Paul Stewart
Cc: juniper-nsp List
Subject: Re: [j-nsp] Multipath BGP issue
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