Devices: 2 x S5720-LI V200R010C00SPC600.
Summary:
When we use physical hairpinnin, we have ping connectivity but we cannot access with Telnet/SSH between the switches Vlanifs.
Connection is back-to-back 2xS5720 switches through a trunk interface and we define VLAN3 and Vlanif 3 on both switches (/30 addressing).
On each switch we connect 2 ports with a wire. This is what we call ‘hairpinnin’. One of the ports is a trunk interface (with allowed vlans 3 and 1001). The other port is dot1q-tunnel interface, and stacks the VLAN 333 to all frames. So, we are performing QinQ on the device (Outer_VLAN=333, Inner_VLAN=3).
So in the end we allow only Outer_VLAN=333 on the trunk interface connecting botw switches.
U turn or U hair pin it was initially used and designed for Spoke to Spoke connection in firewalls but later was also used for other purposes, like QnQ. Sometimes is also called NAT loopback.
So it can be used for redirecting tunneled traffic of one interface to the same tunnel interface or tunneled traffic from one interface to un-tunneled traffic on the same interface.
Handling process:
From the initiator device, seems that the connection is established, but it’s not working (finally the remote end drops the session)
<S5720>telnet 3.3.3.2
Trying 3.3.3.2 ...
Press CTRL+K to abort
Connected to 3.3.3.2 ...
Info: The connection was closed by the remote host.
<S5720>
On the remote end we enable telnet debugging, but no messages are shown (only the final messaged for ending session)
<Intermediate_switch>term mon
Info: Current terminal monitor is on.
<Intermediate_switch>term deb
Info: Current terminal debugging is on.
<Intermediate_switch>debug telnet
<Intermediate_switch>
Oct 1 2000 00:23:03 Intermediate_switch %SHELL/4/LOGINFAILED(s)[0]:Failed to login. (Ip=3.3.3.1, UserName=**, Times=1, AccessType=TELNET, VpnName=)
<Intermediate_switch>
We started to test in our lab and ping between Vlanif3 on both ends work OK from each switch;
<S5720>display current-configuration interface Vlanif 3
#
interface Vlanif3
ip address 3.3.3.1 255.255.255.252
#
return
<S5720>ping 3.3.3.2
PING 3.3.3.2: 56 data bytes, press CTRL_C to break
Reply from 3.3.3.2: bytes=56 Sequence=1 ttl=254 time=1 ms
Reply from 3.3.3.2: bytes=56 Sequence=2 ttl=254 time=1 ms
Reply from 3.3.3.2: bytes=56 Sequence=3 ttl=254 time=1 ms
Reply from 3.3.3.2: bytes=56 Sequence=4 ttl=254 time=1 ms
Reply from 3.3.3.2: bytes=56 Sequence=5 ttl=254 time=1 ms
--- 3.3.3.2 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 1/1/1 ms
Then checked MAC and ARP are learned ok;
<S5720>display arp interface Vlanif 3
IP ADDRESS MAC ADDRESS EXPIRE(M) TYPE INTERFACE VPN-INSTANCE
VLAN
------------------------------------------------------------------------------
3.3.3.1 xxxx-xxxx-xxxx I - Vlanif3
3.3.3.2 yyyy-yyyy-yyyy 6 D-1 GE1/0/2
3
------------------------------------------------------------------------------
Total:2 Dynamic:1 Static:0 Interface:1
<S5720>display mac-address vlan 3
-------------------------------------------------------------------------------
MAC Address VLAN/VSI Learned-From Type
-------------------------------------------------------------------------------
yyyy-yyyy-yyyy 3/- GE1/0/2 dynamic
-------------------------------------------------------------------------------
Total items displayed = 1
<S5720>
We noticed that when try to ssh or telnet to 3.3.3.2 from 3.3.3.1 the double vlan tag packet will arrive on g0/0/13 and it will be send to CPU directly. But it should not when he have two VLAN tags.
So we analyzed and noticed that this is related to a feature called ALP, Active Link Protection and by default, ALP is enabled on FTP, IPv6 FTP, HTTP, HTTPS, IP-CLOUD, IKE, IPSEC-ESP, SSH, TELNET, and TFTP packets and disabled on BGP, BGP4+, ISIS, OSPF, and OSPFv3 packets.
In this specific setup of U turn we need to configure this command undo cpu-defend application-apperceive enable. Then it will be send to cpu by the ge0/0/11 interface .
Solution:
Disable ALP by command:
undo cpu-defend application-apperceive enable
Source: https://support.huawei.com/hedex/hdx.do?docid=EDOC1100126530&id=EN-US_CLIREF_0177117963&lang=en
