This is the second Huawei VRP segment routing blog post, I never configured SRv6 using this particular router platform, here VRP. Everything is configured from scratch using availbe documentation ressources from 2 different competing routing vendors. The networking topology is taken out of the BRKSPG-2203 Cisco's SRv6 uSID Cisco Live presentation, using the Huawei's NE5000E virtual GNS3 appliance.

Huawei calls its SRv6 implementation SRv6 BE, the BE stands for best effort, but it is SRv6. Best effort is a configuration command found and used in the VRP operating system:

segment-routing ipv6 best-effort

The command is part of the the VRP bgp configuration section.

The network topology and its IP addressing is taken out of the the Cisco's BRKSPG 2203 presentation linked at the bottom in the references part end of the blog entry. Did not find any VRP documentation about the usage and configuration of uSID F3216 in the official Huawei documentation. Configuring a IPv6 link-local SRv6 locator works and the network topology forwards IP packets form end to end just fine. There is no debugging and protocol analysing included, it was hard enough to gather all the information available and build this network topology. If you find errors write me an email, and I will try to correct these spotted errors.

The configurations shown work. Configurations can be copy pasted and will result immediately in a IPv4 forwarding SRv6 topology.

VRP version used in this SRv6 netlab running on all provider routers.

Network topology

      PE2
       |
       |
PE1 -- P1 -- PE3
       |
       |
      RRv6

The network topology is the same as in the previous blog entry except there is no migration implemented from LDP to SRv6. I did not bother cluttering the example and configured the final SRv6 state. The RRv4 BGP route reflector has been lef out of the example to make it more easy to follow. There is no migration path from LDP to SRv6 shown. Additionally the IPv6 addressing is_slightly adjusted for few routers to make it more easy to recognize and follow, once it is running.

click for more

Having never configured and netlab-ed Huawei's VRP, i have been courios if this operating system supports SR-MPLS and how it is documented. This netlab uses a 6 years old VRP NE40 appliance to find this out. At the point of writing and constructing this netlab I had no information about the state of implementation of SR MPLS on VRP operating system. This is the 2nd version of the netlab. The 1-st netlab which is not documented here in my blog used the CE12800 GNS3 appliance to find it out, and failed horribly. Use a NE40 Huawei router appliance for this GNS3 setup, or any router appliance you have available. The CE Huawei appliance does not work, actually it can be setup and configured to have SR-MPLS, but the IP forwarding or label switching using SR-MPLS using the CE12800 switches fails.

Huawei nomenclature uses:

• NE - NetEngine - router platform
• CE - CloudEngine - switch platform

The CE term used here in this blog entry, when used means Customer Edge router, not CloudEngine.

This is plane SR-MPLS configuration using the Huawei's NE40 router. Trying to find out how far the Segment Routing is supported among all big router vendors. And if I am lucky maybe the SRv6 for IPv4 and IPv6 if I get it working, but this will be explained in a separate blog entry. This netlab will be know for experienced network engineers using the old-school (now deprecated) LDP protocol, here LDP is replaced with SR-MPLS.

NE40 image supports SR-MPLS out of the box. This is the version used over here in GNS3:

If you happen to build this network topology use routers, not switches.

Network topology

The topology is a star topology, all links are point to point using /31 IPv4 addressing:

      PE2
       |
       |
PE1 -- P1 -- PE3
       |
       |
      RRv4

IPv4 loopback0 address overview plus the according SR index, or MPLS label index and IS-IS NSAP addressing overview:

All PE routers have internal BGP neighorship to the BGP route reflector.

click for more

Recent lostintransit.de blog post called Adding Arista switch to CML was a source of inspiration to the vEOS running in GNS3. The vEOS appliance runs in QEMU/KVM in GNS3. Follow lostintransit's instructins to download the Aboot and vEOS images from Arista's download portal to run. Arista offers free vEOS downloads after a email registration.

Information might be useful to other GNS3 users tinkering in GNS3 with the vEOS appliance installation starting. Having booting issues myself right at the start found following GNS3 community discussion thread called - Arista vEOS Fails to boot. This thread gives a generic overview which GNS3 appliance configuration settings are mandatory to get the installation routine of vEOS in GNS3/QEMU in first place.

Local application versions running:

GNS3

QEMU

click for more

In previous VyOS post Using freeRtr AAA daemon for VyOS the TACACS+ support has been added at that time, middle of the year 2023. The netlab explains the VyOS RADIUS Authentication and Authorisation method. The RADIUS service runs on a freeRtr appliance. A year later the rolling releases of VyOS include a working TACACS+ prototype.

Knowing that the VyOS TACACS+ support has been added a year ago, suspecting there is not much yet there. But for simple authentication and most simple authorization the building block should be already there.

Terms

Using term server in this context is problematic and leads to misunderstanding. These are the technical terms used here. The AAA TACACS+ server will be referred as AAA daemon:

Since a NAS is sometimes referred to as a server, and a daemon is also often referred to as a server, the term server has been avoided here in favor of the less ambiguous terms NAS and Daemon.

IP addressing

Basic setup. One broadcast domain, network topology with following IP addressing:

VyOS configuration

This is the image used in the configration process, latest release.

IP setup

Basic configration to have reachability and make VyOS managable using SSH:

config
set system host-name R180
set interfaces ethernet eth1 address 10.100.100.180/24
set protocols static route 0.0.0.0/0 next-hop 10.100.100.1
set service ssh
commit
save

Reachability established.

TACACS+ configuration

The TACACS+ configuration is short and simple

• daemon IP and key
• daemon TCP/IP port
• NAS source interface

Configurations commands to get TACACS+ support working:

config
set system login tacacs server 192.0.2.1 key '123-my_tacacs_key'
set system login tacacs server 192.0.2.1 port '49'
set system login tacacs source-address '10.100.100.180'
commit
save

click for more

MACsec linux configuration using iproute2.

This is how configure the MACsec IEEE 802.1AE using linux standard toolkit iproute2. Unlike a RFC, the IEEE 802.1AE is a technical standard. MACsec was standardised in 2006 by IEEE (standard IEEE 802.1AE-2006). Using MACsec frames are switched using secure channels SC supported by secure associations SA. Each secure associations SA uses a separate randomly generated key.

The ip macsec command subset is used to configure transmit secure associations and receive secure channels and their secure associations on a MACsec device created with the ip link add command using the macsec type. The ip macsec implementation came to linux in around the year 2016 and has been implemented by Sabrina Dubroca.

Network topology

Network topology with IP addressing:

    +-------+                                   +-------+
    |       | eth0                         eth0 |       |
    |  C1   +-----------------------------------+  C2   |
    |       | .1                             .2 |       |
    +-------+ ::a                           ::b +-------+

2 linux nodes. Point to point network. Linux nodes are directly connected. Basic setup. Both nodes are connected using the eth0 NIC.

IP addressing:

IP addressing is attached to the macsec0 interface:

• C1 - macsec0 - 192.0.2.1/30 - 2001:db8::a/127
• C2 - macsec0 - 192.0.2.2/30 - 2001:db8::b/127

PCAP

A random packet dump will show following sequence of headers, when using A ICMP ping test:

• Frame
• Ethernet II
• Internet Protocol
• ICMP [...]

The MACsec packet dump will show following sequence of headers. This is the same ICMP output:

• Frame
• Ethernet II
• 802.1AE Security tag (SecTAG)
• Data (payload) [...]

• Physical Source/DestinationMAC address between both endpoints
• the payload, including ETYPE is encrypted using GCM-AES
• encrypted payload put between the SecTAG and ICV.
• MACsec sends frame using own ethernet type ETYPE 0x88E5

click for more

Binding DHCP services to specific IP addresses or interfaces, does not always succeed. It depends on the application. A rather typical answer found on the internet regarding ISC DHCP is found here:

Citation from the as correct marked on this popular website answer:

The ISC DHCP server will only work when it binds to the all zeros address. Keep in mind that the DHCP server must communicate with clients that have no IP address, so binding to the IP associated with a specific interface doesn't make a lot of sense.

The all zeros address sentence in this answer is even technically correct, I will show comparable output displaying when actually dnsmasq will work via lo interface only. Binding a service or daemon to one specific IP addressing or interface makes technically sense.

This specific ISC DHCP server configuration setting is possible reading the dhcp-users mailing list entry:

You can also use the local-address statement, but beware the special requirements. [...] Note also that since this bind()s all DHCP sockets to the specified address, that only one address may be supported in a daemon at a given time.

Binding linux services and daemons to IP addresses makes sense. Not only for the DHCP service, I would say for almost all linux daemons it makes lots of sense being available using particular IP addressing only. Using dnsmasq and binding its DHCP service to the linux interface lo works, and servicing DHCP clients also works using this setting. The setup is explained below, mentions all that dnsmasq configurations that does not work first, and listing configurations or parts of it leading to nothing. Failed configuration listing. Finally at the end, one particular dnsmasq configuration setting makes it work. Found this configuration by accident, while tinkering with dnsmasq trying it to force to listen to a particular IP address only. The configuration setting does not make sense at first sight. But I try to explain why it would work from the point of view of IP stack and the application, shown the given DHCP debug output of the participating DHCP nodes and applications. Without knowing anything in particular about dnsmasq code or coding design.

This way the applications on the running node or computer, in the network topology this is DHCP-67, do not need to be in a specific IP subnet. Mostly that subnet configured on eth0 interface. And the application running is not sticked to one geographic location. The eth0 prefix is only the for transport and routing adjacency. No need to have stretched L2 broadcast domain across large, long distances. Running a dynamic routing protocol, of your choice is involved on the appliance plus the one application. But this is the only effort that is needed. Compared to the effort to have L2 connectivity across geographic locations, operational effort, specific hardware needed, planning, designing, upgrading, migrating, building one, huge failure domain across large distances, ... lots more of resources are needed and experience running that L2 network.

Network topology

Network topology with IP adressing:

                                                   lo
   DCHP client                                 203.0.113.67
    +-------+                                   +-------+
    |       |                                   |       |
    |  C1   |                                   |DHCP-67|
    |       |                                   |       |
    +---+---+                                   +---+---+
   eth0 |                                    +--->  | eth0
        |                                    |      |
        |                                  OSPF     |
        |                                    |      |
  Gi0/2 | 10.100.200.1/24                    +--->  | Gi0/1
    +---+---+                                   +---+---+
    |       |                                   |       |
    |  R0   +-----------------------------------+  R1   |
    |       | Gi0/0     <-- OSPF -->       Gi0/0|       |
    +-------+                                   +-------+
       lo                                          lo
    192.0.2.0                                   192.0.2.1

The GNS3 appliance DHCP-67 runs following:

• linux
• FRRouting
• dnsmasq

The DHCP server - DHCP-67 is first, a OSPF router advertising its lo IPv4 prefix. Additionally the dnsmasq DHCP IPv4 server is running and bound to the configured IP prefix - 203.0.113.67/32. The reachability of the IP prefix and the DHCP protocol are the main focus in this GNS3 netlab.

The goal is achieved if the service - operating the DHCP protocol, is bound to one IP address and runs as a service using this one IP prefix only.

The appliance used in example is available in Building 64bit alpine linux GNS3 FRRouting appliance. You can even setup this netlab using only the linked article appliance, running FRRouting Router appliances instead. Everything will work the same.

click for more

How to setup a MAC address routing peering, in a nutshell. This is the a simple network and protocol setup using FRRouting daemon. The netlab is found here in previous blog entry and is build using freeRtr SR ISIS EVPN iBGP-IX-peering-fabric.

The network topology and idea is based on the modernizing-IXP-design article, written by Phil Bedard on xrdocs.io.

This is a blind try out what is possible using a free router implementation, at this point I have no clue what can be configured and how and to what degree.

I need to put here some information before. This configuration uses IS-IS and SR MPLS. Everything is based on IPv4 only. The segment routing in this network topology will get interesting as soon as the TI-LFA and path protection will be computed based on the network topology and the available information.

The fast convergence setup part here is only important for the IS-IS, underlay. BFD is not used for BGP.

This configuration does not explain any dynamic routing protocol basics. You need to be familiar with all dynamic routing protocols, setup and operation.

The appliance used in example is available in Building 64bit alpine linux GNS3 FRRouting appliance.

Network topology

The FRRouting appliances have 9 ports allocated eth0 - eth8. 4 ethernet ports per GNS3 appliance are sufficient to build shown example, but then it is fixed and no routers could be added at all.

• P1, P2
• PE11, PE12, PE13, PE14

Network topology with IP addressing:

      lo                  lo                   lo
  192.0.2.11           192.0.2.1            192.0.2.13
  +-------+            +-------+            +-------+
  +0     7+------------+1     3+------------+7     0+
  | PE11  |            |  P1   |            |  PE13 |
  |      8+-+  +-------+2     4+-+  +-------+8      |
  +-------+ |  |       +-------+ |  |       +-------+
            |  |                 |  |
            +--(-----+           +--(-----+
               |     |              |     |
  +-------+    |     | +-------+    |     | +-------+
  |      7+----+     +-+1     2+----+     +-+7      |
  | PE12  |            |  P2   |            |  PE14 |
  +0     8+------------+2     3+------------+8     0+
  +-------+            +-------+            +-------+
     lo                   lo                   lo
  192.0.2.12           192.0.2.2            192.0.2.14

The interface link IP addressing between the routers in the topology are point-to-point /30. The appliance physical port number is f.e.: +7 for eth7

Configuration overview

Building a L2 MAC address BGP EVPN routing IX-fabric using 6 FRR routers. The routers will forward MAC address only, there is no IP interface involved or SVI. Only Layer2 ethernet MAC addresses. The solution works like the switch or bridge at your home.

ALL topology routers use following protocols:

• IPv4
• IS-IS
• SR MPLS
• MPLS-TE

PE router only:

• BGP
• EVPN
• VXLAN
• ethernet bridge

If there are any useless configuration steps that could be removed from the setup to keep it as simple as possible, write me an email. It will be removed. Learning BGP EVPN configuration and writing this blog entry about it.

The FRRouting version used for the setup:

FRRouting 9.1 (P1) on Linux(6.6.16-0-virt).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

click for more