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

How to solve VRRP problem, voice traffic is lost after reboot PE

Publication Date:  2012-10-30 Views:  35 Downloads:  0
Issue Description
Version Device is NE40E&80E V600R001C00SPC800 with patch NE40E&80E V600R001C00SPC025
Working as PE in provider network, to connect Core devices UMG and SS to the backbone. Using VRRP for PE redundance, when rebooting one of the two peers, traffic is switched to the other PE and works fine. After the reboot is completed, the second PE goes up and the traffic and the voice call is lost.
PE are connected with an etertrunk link. Use VRRP for redundancy

VRRP configuration example:

PE1
interface Vlanif200
 description call-signaling
 ip address 10.167.209.3 25
 vrrp vrid 1 virtual-ip 10.167.209.1
 vrrp vrid 1 priority 120
 vrrp vrid 1 preempt-mode timer delay 80
 vrrp vrid 1 timer advertise 15

PE2
interface Vlanif200
 description call-signaling
 ip address 10.167.209.4 25
 vrrp vrid 1 virtual-ip 10.167.209.1
 vrrp vrid 1 timer advertise 15

Both
interface Eth-Trunk1
 description to-PE
 portswitch
 port link-type trunk
 port trunk allow-pass vlan 200

interface GigabitEthernet1/0/1
 negotiation auto
 description to-CoreVoice-device
 undo shutdown
 portswitch
 port link-type access
 port default vlan 200

interface GigabitEthernet7/0/1
 negotiation auto
 description to-PE-EthT
 undo shutdown
 eth-trunk 1 

interface GigabitEthernet7/0/2
 negotiation auto
 description to-PE-EthT
 undo shutdown
 eth-trunk 1 







All routing protocols and neighbors are established but "display vrrp brief" shows that the two PE are master in all VRRP groups.
( virtual IP is customer confidential information)

<PE1>dis vrrp brief
VRID State       Interface         Type    Virtual IP    
--------------------------------------------------------
1    Master      Vlanif200         Normal  x.x.x.x
2    Master      Vlanif200         Normal  y.y.y.y 
3    Master      Vlanif201         Normal  z.z.z.z
4    Master      Vlanif201         Normal  w.w.w.w
5    Master      Vlanif300         Normal  v.v.v.v
<ma1-1vpe-1>  
 

<PE2>dis vrrp brief
VRID State       Interface         Type    Virtual IP    
--------------------------------------------------------
1    Master      Vlanif200         Normal  x.x.x.x
2    Master      Vlanif200         Normal  y.y.y.y 
3    Master      Vlanif201         Normal  z.z.z.z
4    Master      Vlanif201         Normal  w.w.w.w
5    Master      Vlanif300         Normal  v.v.v.v
<ma1-1vpe-2>











Handling Process
When rebooting one PE, the other PE is master in all VRRP groups and traffic swicthes to this peer. Communication remains OK.
When the rebooted device goes up again and finishes the booting sequence and establishes routing protocols as expected, all ongoing voice traffic is lost and calls are lost

"display vrrp brief" shows that the two PE are master in all VRRP groups.
This makes voice traffic to be lost 

 




Root Cause
The root cause is related to the slot boot sequence of NE and port layout.
NE starts slot booting in sequence.
Host ports are in the slot 1, while B2B link between peers is located in slot 7

1) When slot 1 is up, all access ports are up, and the related vlanif is up.
2) This makes VRRP protocol start
3) Ethertrunk port are located in slot 7, that is not yet ready, so the two VRRP peer can not see each other
4) Both PE consider itself as master in VRRP group 1, for vlan 200. And traffic is lost
Solution
The solution to this problem is modify the layout. And make at least one of the ethertrunk links belong to slot 1.

In this case the vlanif interface and the back-to-back links for PE interconnection go up at the same time.
And when PE start VRRP, can negotiate master-slave roles

Suggestions
Layout of PE NE must ensure that back-to-back link will be ready before VRRP negotiation starts.
Make at least one of the back-to-back ports to be on the same slot that CE ports.
Before port assignment for the layout, try to make sure the order sequence of the slots after the booting process

END