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>Search


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


Main/backup switchover didn't occurr in NE40-X3 when main BRAS went down

Publication Date:  2019-07-05 Views:  262 Downloads:  9

Issue Description

Customer  Network has two separate POPs in Merseberg. One POP located  . (the main one) and another POP in Große Ritter Straße (the backup one). The main POP in Ikarusstr. Include one NE40e-X3 (called BRAS0), two S6700EI switches (SW01B and SW02B) and a fiber connection from the switches towards forty five Dslams distributed across several locations. Similarly, the backup POP in Große Ritter Straße includes one NE40e-X3 (called BRAS1), two S6700EI switches (SW01R and SW02R) and a fiber connection from the switches towards the same forty five Dslams. Each directly connected switch (SW01B and SW01R) has two separate uplinks to BRAS in order to carry user traffic (one link for VoIP and another for Internet)

The second switch in each POP (SW02B and SW02R) is cascaded to the first one (SW01B and SW01R) via one Giga link that carry all kinds of traffic (Voice, Internet and management) but separated via separate VLANS. Each BRAS (in each POP) has a separate connection to U2000 for Dslam management and another connection to the company Muth Radius server (via Fortinet firewall) as per the attached pdf/visio drawing.
The link between BRAS0 and BRAS1 is a layer-3 link created for the iBGP connection in order to exchange iBGP routes between both BRAS and the same link is used to exchange user info for main/backup swithcover.

The customer is using the following VLAN schemas for separating different traffic types as follows:







Components-Management / DSLAM / MSAN



Huawei -BRAS



Firewall SWM



Firewall SWM




Huawei -BRAS



Huawei -BRAS





Huawei -BRAS

Traffic for CPE management (VLAN 200) and CPE-VoIP (VLAN 201) are getting an IP address from Firma Muth DHCP server and not from BRAS. In this case, the Huawei switches SW01B (for main) and SW01R (for Backup) are configured to act as a DHCP-relay agent. BRAS is transparent during the DHCP Phase. Keeping in mind that the DHCP Server from Firma Muth assigns the IP address as gateway for CPE-Managment, and assigns the IP address as the gateway for CPE VoIP. For this reason, both IP’s are configured as a Virtual IP in both BRAS under VRRP 5 and 6 respectivly.

Furthermore, we had the following VRRP instances configured in every BRAS as follows:

The goal of this VRRP 2 is to manage both BRAS remotely via Huawei Citrix during Project delivery phase. This is done by configuring Giga 1/1/7 of each BRAS with a  Virtual IP of, and configuring a higher priority of 120 on BRAS0 to remain the main while leaving the Backup BRAS with the default Priority of 100. Both  Firewalls in each POP has the same virtual IP of

This VRRP instance is for the management VLAN. All management traffic should be sent to (The Virtual IP configured in both BRAS). Similarlly, the Priority of this VRRP is 120 for BRAS0 and it tracks the uplinks to HLKomm so if the Internet or Voice link to HLKomm went down, the priority is reduced -30 so it becomes 90 and hence less preferred so that BRAS1 becomes the main.

Similarly, we have done the same for VRRP instance 5 and 6 where both BRAS had a Virtual IP of (for CPE managment vlanif 200) and (for CPE VoIP vlanif 201).
When main BRAS failed, we have noticed that VRRP didn't help to perform a switch over from the main BRAS to the Backup BRAS and service outage occured.


I have noticed that VRRP traffic for main/backup can not take place via the Layer-3 link between both BRAS. This Layer-3 link is used for iBGP traffic exchange.
I have fixed the issue by creating a new fiber link between the swithc SW01B and SW01R to perform as a layer-2 link created mainly for main and Backup senario to perform via VRRP id 4.

VRRP 4  is a new instance configured together with VLAN 300, where VLAN 300 is used to allow VRRP multicast packets to be exchanged between both BRAS’s via the layer-2 link between SW01B and SW01R (XGigaE 0/0/47).

The new VRRP 4 instance is is configured under the subinterface of Giga 1/0/0.2 in both BRAS as shown below:

[POP0BRAS-GigabitEthernet1/0/0.2]disp this


interface GigabitEthernet1/0/0.2

 vlan-type dot1q 300

 ip address x.x.0.2

 vrrp vrid 4 virtual-ip x.x.0.1

 admin-vrrp vrid 4

 vrrp vrid 4 priority 120

 vrrp vrid 4 track interface GigabitEthernet1/0/0.1 reduced 30

 vrrp vrid 4 track interface GigabitEthernet1/1/1 reduced 30

 vrrp vrid 4 track interface GigabitEthernet1/1/4 reduced 30

 vrrp vrid 4 track interface GigabitEthernet1/1/6 reduced 30


While on Backup BRAS1, the VRRP 4 instance is configured as follows:

[POP1BRAS-GigabitEthernet1/0/0.2]disp this


interface GigabitEthernet1/0/0.2

 vlan-type dot1q 300

 ip address x.x.0.3

 vrrp vrid 4 virtual-ip x.x.0.1

 admin-vrrp vrid 4


the result on both NE40-X3 for VRRP status was as follows:


<POP0BRAS>disp vrrp brief

Type:VRRP      Total:5     Master:5     Backup:0     Non-active:0

VRID  State        Interface                Type     Virtual IP


2     Master       GE1/1/7                  Admin

3     Master       Vlanif100                Admin

4     Master       GE1/0/0.2                Admin

5     Master       Vlanif200                Admin

6     Master       Vlanif201                Admin

Backup BRAS1 VRRP instances are:

<POP1BRAS>disp vrrp brief

Type:VRRP      Total:5     Master:0     Backup:5     Non-active:0

VRID  State        Interface                Type     Virtual IP


2     Backup       GE1/1/7                  Admin

3     Backup       Vlanif100                Admin

4     Backup       GE1/0/0.2                Admin

5     Backup       Vlanif200                Admin

6     Backup       Vlanif201                Admin