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

VLL and VSI isn't up on S9312 because many TC packets in the network

Publication Date:  2012-07-27 Views:  53 Downloads:  0
Issue Description
Customer found vll session broken between S9312 and NE20E, after shut/undo shut interface, delete configuration/ re-configure operation not help, but after switchover to slave on S9312 service is recovered for some time.


Alarm Information
Logfile
Nov 15 2011 12:06:27 grz001_s9312 %%01mstp/6/receive_mstitc(l): mstp received bpdu with tc, mstp process 0 instance 0, port name is gigabitethernet3/0/16.
Nov 15 2011 12:06:29 grz001_s9312 %%01mstp/6/receive_mstitc(l): mstp received bpdu with tc, mstp process 0 instance 0, port name is gigabitethernet3/0/16.
Nov 15 2011 12:06:31 grz001_s9312 %%01mstp/6/receive_mstitc(l): mstp received bpdu with tc, mstp process 0 instance 0, port name is gigabitethernet3/0/16.
Nov 15 2011 12:06:33 grz001_s9312 %%01mstp/6/receive_mstitc(l): mstp received bpdu with tc, mstp process 0 instance 0, port name is gigabitethernet3/0/16.
Nov 15 2011 12:06:35 grz001_s9312 %%01mstp/6/receive_mstitc(l): mstp received bpdu with tc, mstp process 0 instance 0, port name is gigabitethernet3/0/16.
Nov 15 2011 12:07:28 grz001_s9312 %%01mstp/6/receive_mstitc(l): mstp received bpdu with tc, mstp process 0 instance 0, port name is gigabitethernet3/0/16.
Nov 15 2011 12:07:30 grz001_s9312 %%01mstp/6/receive_mstitc(l): mstp received bpdu with tc, mstp process 0 instance 0, port name is gigabitethernet3/0/16.
Nov 15 2011 12:07:32 grz001_s9312 %%01mstp/6/receive_mstitc(l): mstp received bpdu with tc, mstp process 0 instance 0, port name is gigabitethernet3/0/16.
Nov 15 2011 12:07:34 grz001_s9312 %%01mstp/6/receive_mstitc(l): mstp received bpdu with tc, mstp process 0 instance 0, port name is gigabitethernet3/0/16.
Nov 15 2011 12:07:35 grz001_s9312 %%01mstp/6/receive_mstitc(l): mstp received bpdu with tc, mstp process 0 instance 0, port name is gigabitethernet3/0/16.
Nov 15 2011 12:08:29 grz001_s9312 %%01mstp/6/receive_mstitc(l): mstp received bpdu with tc, mstp process 0 instance 0, port name is gigabitethernet3/0/16.



Handling Process
Check log file from S9312 (in alarm information) many TC message were received. Most part messages came from interface GE3/0/16.
TC message function: under enabled mstp, after TC is received, relative mstp instances will be advertised, in order to mac entry and arp will be refreshed. Further get info from different devices, it was found GRZ001_S9312, CHRNRCH001_S9303, GRZ004_S9306, GRZ005_S9303 received many TC messages from some interfaces (check attachments).
When S9300 receive TC message, he will check VLAN under received messages interface whether fulfill below 2 conditions: vlan-if interface was built and vsi was bound in the vlan-if. If such conditions can be meet at the same time system will inform the VSI to send mac-withdraw message. According to real network configuration int GE3/0/16 receive TC messages mac-withdraw message will be sended.

#
interface gigabitethernet3/0/16
description *ring n2*
port link-type trunk
undo port trunk allow-pass vlan 1
port trunk allow-pass vlan 102 391 403 491 501 600 961 to 962 1000 1007 to 1008 1030 to 1031
port trunk allow-pass vlan 2010 to 2019
broadcast-suppression 20
#
interface vlanif501
l2 binding vsi 501
#
One VSI have many peer's, each TC message will trigger every peer and send mac-withdraw message:
#
vsi 961 static
pwsignal ldp
vsi-id 961
peer 10.11.0.31
peer 10.11.0.28
peer 10.11.0.42
peer 10.11.0.25
peer 10.11.0.27
peer 10.11.0.43
peer 10.11.0.26
peer 10.11.0.39
peer 10.11.0.34
peer 10.11.0.22
peer 10.11.0.41
peer 10.11.0.38
peer 10.11.0.3
peer 10.11.0.24
peer 10.11.0.21
peer 10.11.0.37
peer 10.11.0.36
traffic-statistics enable
#
Above all, due to GRZ001_S9312 received many TC messages, system will inform relative VSI to send mac-withdraw message, but to opponent devices message will be sent also. Due to l2vpn mac-withdraw message sending and receiving locate in same queue, GRZ001_S9312 received and sent many mac-withdraw messages, hardware queue cannot processed timely. It caused l2 vpn messages were overstocked and mapping message cannot be processed, to lead mpls l2vc cannot be up.



Root Cause
In s9300, PW cannot be built because label mapping message didn’t receive from NE20E. I have check VLL tunnel information:
disp mpls l2vc 496
total ldp vc : 1 0 up 1 down

*client interface : vlanif496
session state : up
ac status : up
vc state : down
vc id : 496
vc type : vlan
destination : 10.11.0.25
local vc label : 23608 remote vc label : 0
control word : disable
forwarding entry : not exist
local group id : 0
manual fault : not set
active state : active
link state : down
local vc mtu : 1500 remote vc mtu : 0

Remote VC label is zero.
After I've try to delete VLL configuration and configure it again from debug didn't see any messages.
After checked message queue, was found that there are many mac-withdraw message didn't proces timelly.
[grz001_s9312-hidecmd]_display l2vpn message-info verbose
queue message number: 332888
mapping message : 27
withdraw message : 4
release message : 1
request message : 38
notification message : 0
ldpsession down message : 0
ldpsession up message : 0
ldpsession gr up message : 0
ldpsession gr down message : 0
ldp gr start message : 0
ldp gr end message : 0
ldp macwithdraw message : 332818
interface up message : 0
interface down message : 0
interface delete message : 0
interface hotplugin message : 0
interface hotplugout message : 0
interface linkencaptypechange message : 0
interface portjoinvlan message : 0
interface portleavevlan message : 0
interface rprchange message : 0
interface trunkportchange message : 0
interface hotinserted message : 0
interface cevidadd message : 0
interface mtuchange message : 0
interface statusup message : 0
interface statusdown message : 0
interface eventflowup message : 0
interface eventflowdown message : 0

After opened signal debugging, I saw almost all VSI peer's are receiving mac-withdraw messages.


Suggestions
First check network link to be stable for avoid TC message sendind. Disable STP on user interfaces where it not required. On device GRZ001_S9312 make follow configuration:
#
stp timer hello 100
stp instance 0 root primary
stp enable
Need to add:
stp timer hello 1000 - default value is 200 (2s), customer configure 100 (1s), to modify 1000 (10s).
stp instance 0 root primary
stp enable
stp tc-protection - TC protection defaule value is 2s, default processing count are 3 times.
stp tc-protection treshold 1 - processing time should be modified 1 time, based on before configuration stp timer hello 1000, TC suppressing unit time will be modified 1 message can be processed within 10s.

 



END