No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

BGP Failed in Learning Routes Reflected from the New RR Because of an RR Cluster Conflict

Publication Date:  2013-10-30 Views:  66 Downloads:  0
Issue Description

The following figure showed the networking of an IPRAN reconstruction project. In the project, two NE40E-X8 NEs were added to the metropolitan network (MAN) as the egress nodes (MR1 and MR2) to the provincial backbone network. The NE40E-X8 NEs were of the V600R005C00SPC900 version.

 

The two added MR nodes also functioned as route reflectors (RRs) to replace the original BGP RRs GN1 and GN2. The services on GN1 and GN2 were migrated to MR1 and MR2 and 3G related services were newly configured on the MAN by deploying BGP/MPLS L3VPN.Functioning as provider edges (PEs) on the MAN, GN1, GN2, and x3 were connected to the third-party MGW1, MGW2, and GS server (GS1) respectively.

 

Customers found that MGW2 failed to ping GS1 successfully and GN2 did not learn the routes leading to GS1 that were sent by X3.However, GN1 did learn the routes. The details were provided as follows:

MGW2>ping 10.1.143.18

Ping 10.1.143.18: 32 data bytes, Press Ctrl_C to break

Request timeout!

Request timeout!

Request timeout!

Request timeout!

Request timeout!

--- 10.1.143.18 ping statistics ---

  5 packet(s) transmitted

  0 packet(s) received

  100.00% packet loss

<NE80E-PS-GN2>disp ip rout vpn 3G_IUPS

Route Flags: R - relay, D - download to fib

------------------------------------------------------------------------------

Routing Tables: 3G_IUPS

         Destinations : 2        Routes : 2        

Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface

     10.1.143.8/30  Direct  0    0           D   10.1.143.9      GigabitEthernet6/0/1

     10.1.143.9/32  Direct  0    0           D   127.0.0.1       GigabitEthernet6/0/1

<NE80E-PS-GN1>disp ip rou vpn 3G_IUPS

Route Flags: R - relay, D - download to fib

------------------------------------------------------------------------------

Routing Tables: 3G_IUPS

         Destinations : 4        Routes : 4        

Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface

     10.1.143.0/30  Direct  0    0           D   10.1.143.1      GigabitEthernet6/0/1

     10.1.143.1/32  Direct  0    0           D   127.0.0.1       GigabitEthernet6/0/1

     10.1.143.8/30  IBGP    255  0          RD   10.243.87.57     GigabitEthernet6/0/10

    10.1.143.16/30  IBGP    255  0          RD   10.243.86.246   GigabitEthernet6/0/2

 

The third-party MGW2 failed to be connected to GS1 and reported alarms, but no alarms were reported on NE40E NEs.
Handling Process

Huawei analyzed the possible causes of the issue:

1. The routes to GS1 were not imported into the 3G VPN.

Huawei excluded the factor because MGW1 could ping GS1 successfully.

2. The routes to GS1 were not advertised to GN2.

3. GN2 failed to learn the routes to GS1.

This may be caused by:

a. The VPN route advertisement policy configured on X3 was incorrect.

b. The BGP peer on GN2 was working abnormally.

c. The VPN route receiving policy configured on GN2 was incorrect.

d. An error occurred in BGP route receiving on GN2.

 

Huawei performed the following steps to further identify the cause:

1. Checked the routes on GN2 and found no routes to GS1.

[NE80E-PS-GN2]disp ip rout vpn 3G_IUPS 10.1.143.18

[NE80E-PS-GN2]

2. Checked the VPNv4 BGP peer status and found that the BGP peer relationships between GN2 and MR1 and between GN2 and MR2 were working properly.

[NE80E-PS-GN2]disp bgp vpnv4 all peer

 BGP local router ID : 10.243.87.57

 Local AS number : 64816

 Total number of peers : 2                Peers in established state : 2

  Peer            V          AS  MsgRcvd  MsgSent  OutQ  Up/Down       State PrefRcv

  10.243.86.247   4       64816       18       14     0 00:10:22 Established       0

  10.243.86.248   4       64816       17       13     0 00:09:49 Established       0

[NE80E-PS-GN2]

3. Checked the routes learned from RRs through BGP on GN2 but found no routes.

[NE80E-PS-GN2]disp bgp vpnv4 all routing-table peer 10.243.86.247 received-routes

[NE80E-PS-GN2]

[NE80E-PS-GN2]disp bgp vpnv4 all routing-table peer 10.243.86.248 received-routes 

[NE80E-PS-GN2]

4. Checked the VPN routing policy on GN2 and found no restrictions. Also found no restrictions in the VPN routing policy on X3.

[NE80E-PS-GN2]dis cu

#

ip vpn-instance 3G_IUPS

 ipv4-family

  route-distinguisher 64816:332030

  vpn-target 64816:232010 64816:232100 export-extcommunity

  vpn-target 64816:232010 64816:232100 import-extcommunity

#

5. Checked the BGP configuration on GN2 and found that the original RR configuration was not deleted.
Therefore, when GN2 received routes reflected form the new RR, it discarded the route with a cluster-id the same as its own.

[HBWH-XGL-NE80E-PS-GN2]dis cu conf bgp

#

bgp 64816

 router-id 10.243.87.57

 peer 10.243.86.247 as-number 64816

 peer 10.243.86.247 connect-interface LoopBack0

 peer 10.243.86.248 as-number 64816

 peer 10.243.86.248 connect-interface LoopBack0

 #

 ipv4-family unicast

  undo synchronization

  peer 10.243.86.247 enable

  peer 10.243.86.248 enable

 #

 ipv4-family vpnv4

  reflector cluster-id 20

  undo policy vpn-target

  peer 10.243.86.247 enable

  peer 10.243.86.248 enable

 #

 ipv4-family vpn-instance 3G_IUPS

  import-route direct

#
Root Cause
The cluster-id of the new RR was set the same as that of the route receiving equipment.
Solution
Huawei changed the cluster-id of the newly deployed equipment.
Suggestions

1. You should be aware of the impact on the entire AS before deploying new RRs to replace the original ones.

2. If a pair of RRs is configured, delete the related configuration on the original two RRs before the replacement and ensure that the configuration on the new RRs is complete and correct.

END