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

Reminder

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

upgrade
Knowledge Base

S9300 binding static ARP in public network tunnel caused layer 3 business cannot be forwarded

Publication Date:  2012-11-20  |   Views:  188  |   Downloads:  0  |   Author:  c00222574  |   Document ID:  EKB1000019787

Contents

Issue Description

Refering device and version: S9300V100R003C00SPC200+patch S9300V100R003SPH007
Topology:CE1-- S9300------network cloud---------s8016---------CE2
Phenomenon:S93 connecting CE1 cannot interconnect with far side PE connecting CE, but CE1 can ping S9300, but s9300 with source address(CE1 gateway)can ping far side CE2.

Alarm Information

NULL

Handling Process

1.Check the route information on the device, it found the far side CE route information:
<5S.WN-ccx.HW9306>dis ip routing-table vpn-instance vpn-oa 210.87.130.100 verbose
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : vpn-oa
Summary Count : 1
Destination: 0.0.0.0/0
Protocol: BGP Process ID: 0
Preference: 255 Cost: 0
NextHop: 210.87.130.7 Neighbour: 210.87.131.5
State: Active Adv Relied Age: 02h52m10s
Tag: 0 Priority: low
Label: 11265 QoSInfo: 0x0
IndirectID: 0xcb
RelayNextHop: 10.104.2.21 Interface: Vlanif10
TunnelID: 0x121d7 Flags: RD

2. local side VPNV4 entry is correct,S9300 PE and CE1 route protocol configuration is correct,so the route can transfer to CE1 side.

[5S.WN-ccx.HW9306]dis bgp vpnv4 vpn-instance vpn-oa routing-table 210.87.130.100
BGP local router ID : 210.87.130.93
Local AS number : 65535
Paths: 1 available, 1 best, 1 select
BGP routing table entry information of 0.0.0.0/0:
Label information (Received/Applied): 11265/NULL
From: 210.87.131.5 (210.87.131.5)
Route Duration: 2d08h20m06s
Relay Tunnel Out-Interface: Vlanif10
Relay token: 0x121d7
Original nexthop: 210.87.130.7
Qos information : 0x0
Ext-Community:RT <3 : 3>
AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, valid, internal, best, select, active, pre 255
Originator: 210.87.130.7
Cluster list: 210.87.131.5
Not advertised to any peer yet
3. R&D confirm on the hidden mode that, check chip forwarding related entry, public LSP destination mac releasing failed:
[5S.WN-ccx.HW9306-hidecmd]display adp-mpls nhlfe-info lsptoken 2076 slot 1
nhlfe.ulNextHop is 10.104.2.21;
nhlfe.ucLspOperation is LSPM_LABEL_PUSH;
nhlfe.usVrfIndex is 0;
nhlfe.ulOutLabel[0] is 1095;
nhlfe.ulOutLabel[1] is 0;
nhlfe.ulOutLabel[2] is 0;
nhlfe.ulOutLabel[3] is 0;
nhlfe.ulLspToken is 2076;
nhlfe.ulPdtIndex is 0xffffffff;
nhlfe.ulFrrLspToken is 4294967295;
nhlfe.usNextHopIndex is 1375;
nhlfe.ucFake is 3;
nhlfe.usTtlFlag is 1;
nhlfe.ucDomainId is 0;
nhlfe.ucQosMode is 3;
nhlfe.ucQosFlag is 0;
nhlfe.ucExpCopyFlag is 0;
the product index are F, it means the destination mac and outbound information found failure when the product getting lsp outbound encapsulation information. although it has configured lsp outbound interface and mac information by static ARP(arp static 10.104.2.21 0819-a624-f5cf vid 10 interface GigabitEthernet1/0/1),but the code process does not support handling for static Arp, it lead S9300 cannot forward the received packet.
4.Delete static ARP binding on S9300 public tunnel outbound interface, the problem solved.


Root Cause

1.Configuration problem
2.Device hardware problem

Suggestions

Notice:S9300 V100R006 and V100R006 front version does not support public LSP tunnel as static ARP binding, it should use dynamic learning arp entry forwarding.