Huawei’s NE40 line, especially the M2K and M2K-B models, has become the new “darling” of ISPs in Brazil, allowing several cost-effective scenarios, both at the Core Network layer (BGP, Aggregation Routers, and the like) and at the Access layer (BNGs IPoE, PPPoE…).
Recently at Made4IT, we had a case where a customer with an NE40E-M2K-B needed a virtualization at the Chassis level, so that a partner could also take advantage of the box resources but with a certain level of segregation.
With our knowledge and expertise with the vendor, we suggested and designed a Virtual System in the box for this purpose, and, following the vendor’s recommendation, we informed the customer that the communication between the “virtual-systems” should be through dedicated network ports, where we would have a “physical loop” to deliver data to the partner’s “virtual-system”. Here in the company, we have come to affectionately call this feature the “coffin strap” (laughs).
With this, the first way to link two VS is simply to connect a cable between two ports on the same router, allocating each port to a single VS.
Se quer saber mais sobre virtualização de roteadores Huawei, consulte o post Roteadores Virtuais (VS / Virtual-System) no Huawei NE
In this same scenario, a while back we did an implementation where his need was simple, being basically:
“My carrier is approaching me on 2 different pieces of equipment in my network being BGP and an MPLS Switch that I have 40km away. The carrier wants to use MPLS with me. I need to route MPLS on my NE40 where the carrier will deliver the circuits to me on some VPWS’es.”
In this case the deployment went smoothly, using the “Virtual Ethernet ” feature where the “layer2” side and the “layer3” side have distinct interfaces to work the VPWS and do the IP connectivity respectively.
If you don’t know about MPLS on NE routers, or if the concept of “layer2 side” or “layer3 side” didn’t make sense, see the post L3 Interfaces in L2 MPLS Tunnels on Huawei NE Router (How to configure MPLS with IP on Huawei)
The other way to link…
In our constant, daily exchanges of experience between the N2 and N3 teams, one of our consultants had an insight in a moment of reverie (usually in the shower, in the bathroom, opening the fridge, walking, etc):
“We know that a virtual-ethernet has its layer2 side and its layer3 side.
And we know that we can put one of these sides on a virtual-system other than admin because, virtual-ethernets can only be created in vs admin. Now imagine, if we made 2 different ve-groups and used a circuit-cross-connection (CCC) from MPLS to join those 2 layer2 sides, would it be possible to make the virtual-systems talk to each other in layer3 without needing the coffin strap ?“
Just to name a few, CCC is the most basic, non-signaling way to connect two services via a VPWS.
Then we set out to test the interconnection of two local VS via an MPLS CCC.
Interconnecting two VS via VPN VPWS CCC
Scenario:
For our tests we will use two VE-GROUPs, interconnect the L2 of the VE-GROUPs via CCC VPWS, and keep one side L3 in Admin-VS while the other side L3 we will put in VS1.
Settings:
First, we will create the interfaces that will be part of L2:
# Admin-VS
! Side L2 Admin-VS
Virtual-Ethernet0/2/100 interface
ve-group 100 l2-terminate
Virtual-Ethernet0/2/100,100 interface
vlan-type dot1q 100
! Side L2 VS1
Virtual-Ethernet0/2/200 interface
ve-group 200 l2-terminate
Virtual-Ethernet0/2/200.100 interface
vlan-type dot1q 100
After that we will interconnect VLAN 100 via VPN VPWS CCC:
! MPLS CCC VPWS Interconnection
ccc test interface Virtual-Ethernet0/2/100,100 tagged out-interface Virtual-Ethernet0/2/200,100 tagged
With layer2 configured, we can move on to activating the L3 services:
# Admin-VS
! Side L3 Admin-VS
Virtual-Ethernet0/2/101 interface
mac-address c4b8-b434-ab45
ve-group 100 l3-access
interface Virtual-Ethernet0/2/101.100
vlan-type dot1q 100
ip address 10.1.1.1 255.255.255.252
! Side L3 VS1
interface Virtual-Ethernet0/2/201
ve-group 200 l3-access
interface Virtual-Ethernet0/2/201.100
vlan-type dot1q 100
Finally, we will insert only the L3 subinterface for VS1.
# Admin-VS
admin
virtual-system vs1 pvmb slot 3
port-mode port
assign interface Virtual-Ethernet0/2/201.100
# VS1
! Side L3 VS1
interface Virtual-Ethernet0/2/201.100
vlan-type dot1q 100
ip address 10.1.1.2 255.255.255.252
Scenario Considerations
Some considerations of the scenario:
- It was only possible to add a vlan subinterface in the virtual-system, it did not allow the entire virtual-ethernet
- It was necessary to change the mac-address of the Virtual-Ethernet on one side, because the VS inherits the mac from the chassis
Validations
CCC between virtual-ethernets up:
<HUAWEI>display vll ccc
total ccc vc : 1
local ccc vc : 1, 1 up
remote ccc vc : 0, 0 up
name: test, type: local, state: up,
intf1: Virtual-Ethernet0/2/100.100 (up), access-port: false
intf2: Virtual-Ethernet0/2/200.100 (up), access-port: false
VC last up time : 2020/02/17 14:40:58
VC total up time: 0 days, 0 hours, 16 minutes, 37 seconds
Ping between the two VS:
Admin-VS:
<HUAWEI>ping 10.1.1.2
PING 10.1.1.2: 56 data bytes, press CTRL_C to break
Reply from 10.1.1.2: bytes=56 Sequence=1 ttl=255 time=1 ms
Reply from 10.1.1.2: bytes=56 Sequence=2 ttl=255 time=1 ms
Reply from 10.1.1.2: bytes=56 Sequence=3 ttl=255 time=1 msd
Reply from 10.1.1.2: bytes=56 Sequence=4 ttl=255 time=1 ms
Reply from 10.1.1.2: bytes=56 Sequence=5 ttl=255 time=1 ms
--- 10.1.1.2 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 1/1/1 ms
VS1:
<HUAWEI-vs1>ping 10.1.1.1
PING 10.1.1.1: 56 data bytes, press CTRL_C to break
Reply from 10.1.1.1: bytes=56 Sequence=1 ttl=255 time=1 ms
Reply from 10.1.1.1: bytes=56 Sequence=2 ttl=255 time=1 ms
Reply from 10.1.1.1: bytes=56 Sequence=3 ttl=255 time=1 ms
Reply from 10.1.1.1: bytes=56 Sequence=4 ttl=255 time=1 ms
Reply from 10.1.1.1: bytes=56 Sequence=5 ttl=255 time=1 ms
--- 10.1.1.1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 1/1/1 ms<HUAWEI>ping 10.1.1.2
PING 10.1.1.2: 56 data bytes, press CTRL_C to break
Reply from 10.1.1.2: bytes=56 Sequence=1 ttl=255 time=1 ms
Reply from 10.1.1.2: bytes=56 Sequence=2 ttl=255 time=1 ms
Reply from 10.1.1.2: bytes=56 Sequence=3 ttl=255 time=1 msd
Reply from 10.1.1.2: bytes=56 Sequence=4 ttl=255 time=1 ms
Reply from 10.1.1.2: bytes=56 Sequence=5 ttl=255 time=1 ms
--- 10.1.1.2 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 1/1/1 ms
Test with a BGP session and adjacent OSPFv2 and OSPFv3:
<HUAWEI>displ bgp peer
BGP local router ID : 192.168.88.100
Local AS number : 11111
Total number of peers : 1 Peers in established state : 1
Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv
10.1.1.2 4 22222 25 25 0 00:19:38 Established 0
<HUAWEI>displ ospf peer brief
(M) Indicates MADJ neighbor
OSPF Process 1 with Router ID 10.0.0.1
Peer Statistic Information
Total number of peer(s): 1
Peer(s) in full state: 1
-----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 VE0/2/101.100 10.0.0.2 Full
<HUAWEI> displ ospfv3 peer
OSPFv3 Process (1)
OSPFv3 Area (0.0.0.0)
Neighbor ID Pri State Dead Time Interface Instance ID
10.0.0.1 1 Full/DR 00:00:38 VE0/2/201.100 0
Finally that’s it folks, we don’t know the performance or impact on the box, but the basic services worked normally.
If you test it with traffic, let us know! Share your results with us.
Hugs,
Rafael Ganascim, Gabriel Henrique and Kevin Walters
IT Consulting Team – Made4it
