blog/ archives/ 2020/ 01
FRRouting basic IS-IS router configuration

The FRR project recent changelog entries suggest to take a look at the router appliance. Segment routing in kernel is already working, what would be needed would be a control plane for segment routing using FRR? The first implementation is already there in FRR7.x, but at the moment I would rather not to write about it because it is not ready yet. To use segment routing a link-state routing protocol is needed, like OSPF or IS-IS.

To try out FRR version 5 grab a tinycore FRR appliance distributed by Brezular. Thanks to him making suckless virtual appliance using tinycore Linux. Otherwise build a tinycore FRR appliance from scratch.

The networking lab scenario is easy. Two directly connected FRR routers, via the eth1 interface. A direct point to point connection. Each router has additionally configured an IPv6 loopback address. No dedicated physical interface addressing is used, the default link-local addressing only.

    loopback                                    loopback  
2001:db8:1111::/128                         2001:db8:2222::/128
    +-------+                                   +-------+
    |       | eth1                         eth1 |       |
    |  R1   |-----------------------------------|  R2   |
    |       |                                   |       |
    +-------+                                   +-------+

At the end of the networking lab scenario both routers will have a running IS-IS routing instance, and propagate IPv6 routes using the IS-IS routing protocol.

read more

FRRouting SR Segment Routing tech demo

Segment Routing, in short called SR too, has been implemented in a range of network operating systems. First successful working implementation happened in year 2014. I have been curious about the state of SR in FRR since some time but did not have the right router appliance that would be easy enough to setup and easy to maintain. Now this is possible, the blog article is over here. Building a small FRRouting router in less than 10 minutes.

The FRR implementation lacks at the moment lots of functionality, many things are not working so do not await anything fancy from it. But it is good enough for a networking lab to see how things are supposed to work, and what how things are actually implemented in FRR router daemon.

The SR implementation in FRR is a demo tech presentation using the OSPF process. It shows it has been put work and first effort to get segment routing running in FRRouting daemon.

📘 Note
This is an experimental implementation of segment routing in FRR. It was never meant for use in production networks.

In a previous blog entry a setup routine is explained, how to create a small FRR virtual router appliance for networking labs. This particular FRR appliance is used in explained examples.

Following steps explained below are necessary be applied to the router appliance additionally to get segment routing working. SR works in FRR only for IPv4. SR relies on the MPLS linux kernel modules to be available and loaded in the kernel.

read more

Summarize IP routing entries

Route summarization for IP networks is the way to make things more sufficient, to make things easier, to save resources. I had to summarize 30000 IPv4 route entries but the tool that has been used could not summarize more entries than 8092 in a row. This has been the call to write my personal IP route route summarization tool, but a quick search with a search engine revealed there are people out there that had the idea and have written their tools.

This is a perl script written by Adrian Popa, a network engineer. It does only one job, summarizing a lot of IP network entries into supernets. Here is Adrian Popa's route sumarization perl script.

read more

The new uname -a linux output

To show the current running version of the linux kernel one usually executes the uname -a command. The output might look like below:

uname -a
Linux host 5.5.0-linux-x86_64 #1 SMP Mon Jan 27 12:54:01 EST 2020 x86_64 Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz GenuineIntel GNU/Linux

However if you really want to know how your processor does right now, you should be using following command:

root # grep -r . /sys/devices/system/cpu/vulnerabilities

/sys/devices/system/cpu/vulnerabilities/mds:Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable /sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion /sys/devices/system/cpu/vulnerabilities/itlb_multihit:Processor vulnerable /sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and user pointer sanitization /sys/devices/system/cpu/vulnerabilities/spectrev2:Mitigation: Full generic retpoline, STIBP: disabled, RSB filling /sys/devices/system/cpu/vulnerabilities/specstore_bypass:Vulnerable /sys/devices/system/cpu/vulnerabilities/meltdown:Vulnerable

Another example of a processor that has chosen security over performance:

root # grep -r . /sys/devices/system/cpu/vulnerabilities

/sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT disabled /sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: Load fences, usercopy/swapgs barriers and user pointer sanitization /sys/devices/system/cpu/vulnerabilities/spectrev2:Mitigation: IBRS (kernel), IBPB /sys/devices/system/cpu/vulnerabilities/specstore_bypass:Mitigation: Speculative Store Bypass disabled via prctl and s ccomp /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI

Thanks to gentoo developer Chithanh who suggested this as a joke. I hope it might help someone out there.