Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[MX] BGP route selection using router-ID in a multipath configuration

0

0

Article ID: KB36430 KB Last Updated: 05 Feb 2021Version: 2.0
Summary:

In a multipath network where the same routes are being learned from two different sides of the network BGP route selection using router-id as the preferred route preference will be explained.

Symptoms:

Customer has a eBGP setup that peers with ISP connections on four different routers on opposite sides of the network (R1-R4) and eBGP to their core router R5. The same routes being learned on routers R1-R4 are seen on router R5 as explained in the topology below.

Routers R6 and R7 are underlay routers only used to help with loopback advertisements to form BGP on the overlay of the topology.

Routers R1 and R2 have eBGP with R5 and the ISP's. R3 and R4 also have eBGP on the overlay with R5 and routers R3 and R4 have eBGP with the ISP's. Example route 60.0.0.0/20 is being learned by R1, R2, R3 and R4. Router R5 learns this route from all four routers.

BGP selection process is equal across all paths and router-id is used for route selection preference.

Refer to Understanding BGP Path Selection for an explanation.

Customer lost uplink eBGP from router R1 to ISP causing a new state.

Due to multipath preference, the route to 60.0.0.0/20 was now preferred to R3 and R4.

When the state of eBGP from R1 to ISP was restored, the customer assumed that due to router-id 1.1.1.1 in our example that the path to 60.0.0.0/20 would be restored to R1 and R2 which was not the case reason explained below.

Cause:

In this case, the network is working as expected. When eBGP is lost to the ISP a network change event happened causing the new path to R3 and R4 that was chosen as this became the active path for the routes because of the multipath configuration. When reviewing the route table after the route convergence we see that the new preferred path is using router-id as 5.5.5.5 and backup is 6.6.6.6. This path was chosen over R2 even with R2 having a lower router-id due to a single exit path to R2 for external routes when eBGP to R1 flapped or was lost.

The router-id associated to R2 would not play into the route selection process due to lack of multipath to the left side of the diagram.

When eBGP was restored to R1 the customers’ expectations was that the routes would return to R1 and R2 because of the router-id of R1 being 1.1.1.1 and multipath reestablished in that direction. The reason that this did not happen is until a new active path is seen the path to R3 and R4 would remain until a network event occurred causing either no path or a single path to exit the network on the right side of the diagram.

If this network event was due to a BGP flap, there is no logic to cause R1 and R2 to be preferred for routes when BGP established and it is possible that BGP would still form first with R3 and R4 causing the route selection active path to exit the network via R3 and R4.

If an interface were lost from R5 or any of the other routers on the right side that helped form multipath and eBGP, then the routes would have a new active multipath to R1 and R2 and R1 being the preferred exit point due to router-id being lower than that of router R2.

In our lab we tested this from router R5 by flapping BGP in both directions and shutting down interfaces. What we found is that when BGP first forms it must go through a series of events to form BGP with its peers. There is no underlying logic to tell the router to form BGP with R1 and R2 before it formed BGP with R3 and R4 so it becomes timing issue.

We saw when BGP formed first with R3 and R4 from R5 the active path for the routes was to the right side of the network diagram and the router-id selection was preferred as 5.5.5.5.
When BGP formed first with R1 and R2 from R5 than the active path for the routes was to the left side of the network diagram and the router-id selection was preferred as 1.1.1.1

Multipath sample output:

60.0.0.0/20      *[BGP/170] 00:00:27, localpref 300, from 129.152.34.137
                      AS path: 7160 7150 I, validation-state: unverified
                      to 129.152.34.137 via xe-0/0/0.1
                    > to 129.152.34.139 via xe-0/0/1.0
                    [BGP/170] 00:00:27, localpref 300
                      AS path: 7160 8150 I, validation-state: unverified
                    > to 129.152.34.139 via xe-0/0/1.0
                    [BGP/170] 00:00:24, localpref 300, from 192.168.14.8
                      AS path: 14506 7120 I, validation-state: unverified
                      to 192.168.1.2 via xe-0/0/2.0, Push 300944, Push 301136(top)
                      to 192.168.2.2 via xe-0/0/3.0, Push 300944, Push 301072(top)
                      to 192.168.1.2 via xe-0/0/2.0, Push 300864, Push 301152(top)
                    > to 192.168.2.2 via xe-0/0/3.0, Push 300864, Push 301088(top)
                    [BGP/170] 00:00:24, localpref 300, from 192.168.14.9
                      AS path: 14506 9120 I, validation-state: unverified
                      to 192.168.1.2 via xe-0/0/2.0, Push 300864, Push 301152(top)
                    > to 192.168.2.2 via xe-0/0/3.0, Push 300864, Push 301088(top)

Route details. 
Output truncated:
Path 60.0.0.0 from 129.152.34.137 Vector len 4.  Val: 0
        *BGP    Preference: 170/-301
                Accepted Multipath
                Localpref: 300
                Router ID: 1.1.1.1 >>>>>>>>>>active route router-id
         BGP    Preference: 170/-301
                State: <NotBest Ext>
                Inactive reason: Not Best in its group - Router ID
                Router ID: 2.2.2.2>>>>>>>>>>inactive route router-id
         BGP    Preference: 170/-301
                Inactive reason: Router ID>>>>>>>>>>inactive reason
                Localpref: 300
                Router ID: 5.5.5.5
         BGP    Preference: 170/-301
                Inactive reason: Not Best in its group - Number of gateways >>>>>>>>>>inactive reason
                Local AS: 31898 Peer AS: 14506
                Age: 32         Metric2: 0
                Validation State: unverified
                Task: BGP_14506.192.168.14.9
                AS path: 14506 9120 I
                Communities: 7160:300 target:7160:1001001
                Import Accepted MultipathContrib
                Localpref: 300
                Router ID: 6.6.6.6

Solution:

In a network environment where multipath is used and the router-id is the preferred method of network path selection and where routes learned are from multiple sources, using the router-id as a method of selecting the preferred path this is not best practice.

The solution is to create a policy that will restore the path to the left side of the diagram in our example that when eBGP is restored back to the ISP or from routers R1, R2 to router R5 than the policy would take effect and move the routes back to the preferred path.

Router-ID will still play a role in the selection process once the active path is where you need this to be.

There are many ways to accomplish this.

​We tested with a route preference policy that told the network to use routers R1 and R2 as the preferred path leaving in the router-id selection as the preferred router to use for the ISP routes.

Modification History:
 
 
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search