Thanks Krasi... that's exactly what the issue was - appreciate the response ;)
Paul -----Original Message----- From: Krasimir Avramski [mailto:[email protected]] 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 <[email protected]> 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] > > [email protected]# 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] > > [email protected]# 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) > > > > [email protected]> 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 > > > > [email protected]> 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? > > > > > > [email protected]> 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 > > > > [email protected]> 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 > > > > [email protected]> 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 [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
