FAQ-Are there any suggestions for L3VPN deployment when there are a large number of VPN routes

5

For S series switches (except S1700 switches), are there any suggestions for L3VPN deployment when there are a large number of VPN routes?

In V200R003 and earlier versions, each L3VPN route is assigned a label. As the label space is limited, it is recommended that labels be assigned on a per VPN basis when there are more than 6.5K VPN routes. This label distribution method can be configured using the [undo] apply-label per-instance command in the VPN instance view.

Other related questions:
FAQ-How private network labels are distributed on an L3VPN
For S series switches (except S1700 switches), private network labels are distributed on an L3VPN using either of the following ways: 1. One label per VPN instance 2. One label per VPN route (default method) When a large number of VPN routes exist on a network, many private network labels are required if the default label distribution method is used. These private network labels may use up all entries. In this case, each VPN instance can be allocated a private network label to reduce the chip entries used.

Reason for the failure to report alarms by boards in a subrack when a large number of SHELF_AREA_POWER_OVER alarms are reported
The SHELF_AREA_POWER_OVER alarm indicates that the nominal power consumption of a subrack section exceeds the specified threshold. This alarm is reported when the total nominal power consumption of boards in a subrack section of an NE is greater than or equal to the power consumption threshold of the subrack section. This alarm is reported on the system control boards, such as SCC and 16XCH/16UXCM. If the alarm is present, the subrack is overloaded. When this occurs, you need to remove boards from the corresponding subrack section as required. If the subrack is running in overloaded state for a long time, the power supply to the subrack may be abnormal or interrupted.

FAQ-Why does traffic forwarding fail when the L3VPN label distribution method changes from per-route label to per-instance label
For S series switches (except S1700 switches), why does traffic forwarding fail when the L3VPN label distribution method changes from per-route label to per-instance label? When this problem occurs, check whether a large number of BGP LSPs exist on the switch before the change of the label distribution method. (BGP LSPs occupy resources in the MPLS decapsulation table.) In V200R003 and earlier versions, the per-route label distribution method is used for L3VPN. The number of entries in the MPLS decapsulation table of a switch is limited. Besides, the MPLS decapsulation table is a hash table and may encounter hash collisions. When there are a large number of local routes for an L3VPN, many entries in the MPLS decapsulation table are occupied. The per-instance label distribution method is recommended in this case. When the label distribution method changes from per-route label to per-instance label, new BGP LSPs are generated in the VPN instance. If a large number of BGP LSPs exist on the switch before the change, the new BGP LSPs may cause hash collisions in the MPLS decapsulation table. As a result, traffic forwarding fails in the L3VPN. Operation Notes: Before changing the label distribution method to per-instance label on the switch, check the number of existing BGP LSPs. If there are a large number of BGP LSPs, withdraw local routes in the L3VPN to reduce the number of BGP LSPs, and then change the label distribution method.

Why routes cannot be imported when AS numbers on the BGP/MPLS IP VPN are the same
When the AS number in the Update message to be received by the EBGP-enabled device is the same as the AS number on the device, the device does not receive the Update message. This prevents routing loops. In some scenarios, the device needs to receive a Update message that carries the same AS number as the AS number on the device. In Hub and Spoke networking, when the Hub-PE and Hub-CE use EBGP, the Update message received by the Hub-CE contains the AS number of the Hub-PE. To prevent the Hub-PE from discarding such Update message, run the peer allow-as-loop command to set the number of times for the repeated AS number.

Why the number of routes in the OSPF routing table of the OSPF VPN multi-instance is less than the predicted number
In the OSPF VPN multi-instance, loops may occur if PEs and CEs learn BGP and OSPF routes from each other. You can set the DN in Type3, Type5, or Type7 LSAs advertised by PEs to 1 so that CEs ignore the LSAs with the DN value of 1. These LSAs are not used in route calculation, which prevents loops. If the preceding method is used to prevent loops, the number of routes in the OSPF routing table is less than the predicted number. To use the LSAs with DN 1 in route calculation, run the vpn-instance-capability simple command on CEs to disable routing loop detection.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top