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

The topic sound really great, and it really is for me too. But at the bottom it is about building a switch using 6 routers. At the beginning of February 2024 I have been visiting the Cisco Live 2024 in Amsterdam. The sessions visited were only SR - Segement Routing focused. The Service Provider sessions are all good and technical to the bottom, mostly protocol and hardware focused, more protocol. Long term solution orientation. Visited one session presented by Emerson Moura - BRKSP-2275 - Rethink your Edge Routing Architecture. Emerson talked about new alternative networking designs in operation that are possible using SR or SRv6. If easy enough design is used vendor agnostic solutions based on SR or SRv6, ar possible for service providers. It is possible to replace highly redundant, chassis-based routers to, protocol based, cheaper, one HU pizza-box routers,running SR, you need at least 5 or 6 of them, but all are independent from the control plane of view. Nowadays LACP using separate control plane is possible, i did not know of that. SRvR using ELAN - RFC draft. All protocol based using SRv6 on IOS-XR and works. It is a technical use case. Separating functions into distinct areas and moving away from chassis design to protocol based design to bunch of protocol rich and capable 1 height unit SR routers. For running many SR routers and operating them a smart design necessary.

This is a netlab in GNS3 made using currently available and implemented technologies and protocols using the free freeRtr router. This will be a attempt to take a already very well written and full of interesting SR MPLS network designs article following document here., written by Phil Bedard.

The solution is made using freeRtr. To be able to configure and verify protocols used following freeRtr examples were based on following test scenarios:

• freeRtr - SR MPLS example 01
• freeRtr - EVPN/BGP with BGP example
• RARE Example: IS-IS with SR
• RARE Example: IS-IS with SRGB SR
• RARE Example: IS-IS ECMP connection

Configuring a EVPN BGP IX peering, based on the xrdoc.io blog entry using freeRtr free router implementation. This is a 1-st approach creating a networking solution without having deep insight into freeRtr or experience at all. The IPv6 part in the freeRtr configuration is without any functionality. The pmsitun BGP template configuration is nice to have, you need to decide if your network has a use-case for it. Read the RFC reference put in the section. The reason having this unnecessary part here is, configuration is taken primarily from the both linked examples above. Leave that parts out to make your netlab more easy to configure.

The protocols setting used in this freeRtr IX-peering solution:

IPv4 and IPv6 (IP dual-stack):

• VRF v1
• IS-IS
• SR
• • label index 1 - 20
• • v4 label base - 16000
• • v6 label base - 20000
• BFD
• • 100ms 100ms 3

IPv4:

• BGP EVPN
• • bridge1
• • bvi1
• • vxlan1
• internal BGP - AS65000

No BGP route reflector used in example. Internal BGP full-mesh network consisting of:

• PE11
• PE12
• PE13
• PE14

Network topology

The freeRtr appliances have 4 ports allocated eth1 - eth4. A fabric network design is a specific

• P1, P2
• PE1, PE2, PE3, PE4

Network topology with IP addressing:

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

• +4 - physical ethernet port number

click for more

In the FRRouting routing protocol debugging blog entry, there is a debugging approach explained how to get routing protocol debugging messages in FRRouting. This kind of debugging works for all versions of FRRouting, WHEN you have the possibility to leave the vtysh shell and use a regular system shell, like f.e. bash or zsh. If there is no possibility to leave the vtysh then there is no way getting routing protocol debug messages using FRRouting.

But, since FRRouting version 9 it is possible to get the routing debugging protocol messages using the terminal monitor command. This works without leaving the vtysh. It works the same way as it works in Cisco IOS products.

If using IOS, NX-OS or IOS-XR network operating system, the debug routine works simply, like in shown example below. Exactly 2 commands are needed to use interactive protocol debugging while being in need of troubleshoot in some situation:

configure terminal
 logging console
end

Enable specific IOS protocol debugging option:

terminal monitor
debug ip ospf adj

Using FRRouting, the routing debugging routine will work the same. vtysh has now the option to interactive write protocol debug to the vtysh prompt.

This article is a simple demonstration using the RIPng, OSPF6 and IS-IS routing protocol debugging, to show the different debug options in action.

Enable the routing protocol debugging in the FRR vtysh. First example below is showing a RIPNG routing protocol debug.

This is working using since:

Hello, this is FRRouting (version 9.0.1).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

debug ripng

click for more

Using the previous blog entry Using freeRtr as an GNS3 AAA appliance freeRtr configuration, this netlab explains the configuration of VyOS and configuring AAA using the RADIUS protocol VyOS is a free available firewall appliance. VyOS uses the RADIUS VSA's of Cisco IOS. In the login VyOS documentation there is a remark pointing out exactly this, here is a citation in case this remark will be removed or rewritten:

If you want to have admin users to authenticate via RADIUS it is essential to sent the Cisco-AV-Pair shell:priv-lvl=15 attribute. Without the attribute you will only get regular, non privilegued, system users.

Using this particular piece of information the authentication and authorization configuration process will be easy to handle. Either the authenticating user gets the privilege level at the authentication and will be authorized to configure, or not.

VyOS recently implemented also the AAA TACACS+ protocol, this document focuses only using AAA using RADIUS. One minor note before moving on to netlab. You can use only one protocol for AAA at time on a NAS, either RADIUS is used OR TACACS+ is used. It is not possible to use both at same time. There might be some few exceptions for networking gear operating system but until now I have not spot or discovered any.

Terms

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

• AAA daemon - AAA appliance
• NAC - Network Access Client
• NAS - Network Access Server

Configuration

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

click for more

Configuring and using freeRtr as an AAA appliance. While there are many commercial AAA appliances that eat huge amounts of CPU and RAM and storage if ran in GNS3. There is a lack of easy to use AAA appliances, and these that are offered in the GNS3 store, are not handy. Here is an approach configuring a AAA appliance without getting into to much into details on applications and operating systems and software dependencies. Actually this tiny AAA appliance is available in the GNS3 store, the only thing that is lacking is a easy setup and documentation. No hard feelings on lacking documentation, if everything else is working perfectly behind the lines.

It make no difference if AAA is ran using a big commercial appliance or using freeRtr. The protocols and the debugging process are the same. Only the configuration is different. Using the explained approach the AAA appliance will be ready in 5 minutes, literally. No needless waiting for the GUI to open up and no web interfaces needed, no certification warnings, no smart browsers preventing you from connecting to the control plane. Everything is done using the command line interface CLI.

Here in particular as a RADIUS daemon. Setup is for authentication and authorisation . There are a few ways to configure authorisation. This is the 2-nd easy way to configure authorisation by assigning a NAS default preset, the priv-lvl. Assigning priv-lvl works with following NAS or network operating systems:

• IOS (Cisco) Vendor ID = 9
• RGOS (Ruijie networks) Vendor ID = 4881
• EXOS (Extreme networks) Vendor ID = 6307

But using RADIUS Vendor Specific Attributes (VSA)'s this explained approach will work only for Cisco IOS. Swapping the Vendor ID and the Vendor type prefix should get you going to migrate this to other vendors. Honestly I did not try it out, yet.

Terms

These are the technical terms used here. The AAA RADIUS will be referred as AAA daemon:

• AAA daemon - AAA appliance
• NAC - Network Access Client
• NAS - Network Access Server

AAA is either RADIUS or TACACS+. Here AAA stands for RADIUS.

Configuration

Configuration of the AAA appliance, specifically how to configure Authentication and Authorisation, and how both parts of the freeRtr configuration work together.

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

click for more

This is a overview of the most popular command line crypto hash generation tools available on the linux platform, especially gentoo. There are probably much more tools for that purpose, but these are used here. It was hard to find a tool that generates blowfish hashes out of the box. There are hardly tools for that, one of the most popular tools is shipped with the apache2 server. If you find additonal toold especially for bcrypt, write me an email, I'll update the list.

These tools work Out of the box.

htpasswd

The one and only linux tool that generates Blowfish hash out of the box after the installation. httppasswd generates $2y prefixed Blowfish hashes. The prefix is not interesting in sense of encryption. Every implementation works the same, if done correctly. The prefix is to distinguish between bugged and fixed hashes among already created. Apache specific and related to the used implementation. If you sight a different prefix, it is related to its implementation on a specific platform or version of the software used.

13 rounds is now the default set in the templates of the linux distribution used here (gentoo). Here a example how to generate a hash, with -cost of 15, sometimes referred as rounds:

user@host % htpasswd -bnBC 15 "" password | tr -d ':\n'
$2y$15$38yZWnqA5TklswRQfMzFUeyq/S4jc2ZEpB3.8Kq.M0HBL1zERFEZW%

Testing authentication with 15 rounds. Test it, there is no silver bullet for every hardware platform (CPU). Using rounds is a thing of give and take, the question here is, how long can the user wait for a successful authentication. The authentication delay using 15 rounds is already long. This is the reason for using cost 10 in the netlabs. This example has already a very noticeable delay during authentication. -cost 15 is expensive. Try it out creating a local test user, and replacing the standard SHA-512 to Blowfish hash generated with that cost. Then authenticate using SSH on localhost for a test.

mkpasswd

mkpasswd has the libcrypt standard hashes included:

Bcrypt is missing from that list.

SHA-512

3DES

DES or 3DES, the is the question, not sure which one is created, I hope 3DES:

OpenSSL

OpenSSL has the same amount of amount of crypto hashes like mkpasswd, and includes some extra options either for the architecture or the software used: