Requirement
|
|
Overview
We all have our habits that are inherited from our past experience. Some people are used to IOS, IOS-XR, NX-OX, IOS-XE others prefer Junos etc. Using freeRouter provides a different user experience. Some feature such as show/view/watch/differ diagnosis commands are pretty unique to freeRouter. However, freeRouter have some cards in its sleeves in order to provide you a familiar experience.
Article objective
In this article, we will focus on these features:
- monitor
- length
- width
- spacetab
- tablemode
- timestamps
- colorized
Basically these commands are accessed through freeRouter user mode. If you need to use them from config mode, please use the "do" keyword.
[ #003 ] - "monitor/length/width/spacetab/tablemode/timestamps/colorized"
"terminal colorized" will simply color your prompt
Discussion
monitor/length/width/spacetab/tablemode/timestamps/colorized is a set of feature meant to ease your experience with freeRouter in mimic'ing well know behaviour and proposing you additional convenient features. One main behaviour is that all command issue from the CLI is instantly taken into account.
Conclusion
In this 3rd article:
- We presented freeRouter monitor/length/width/spacetab/tablemode/timestamps/colorized terminal customization command
- These are very useful if you come from Cisco or Junos world as it mimic some termnal behaviour.
Final words
As said, these are terminal commands are not specific to freeRouter. Some behaviour are mimic'ed from IOS and Junos. Anyway, these have been developed for one purpose:
"Make network engineers feel at ease and provide then an enjoyable operation experience "
Feel free to try and use them according to your environment taste!
Last but not least, you can play with these different mode from this sandbox:
telnet dl.nop.hu Trying 193.224.23.5... Connected to dl.nop.hu. Escape character is '^]'. XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXX XXXXX XXX XXX XXX XX XX XXXX XXXXXXXXXXXXXXXXXXX XXXX XXXX XX XXXX XX XXXX XX XX XX XXXX XXXXX/~~~~~~\XXXXXX XXXX X XXX XX XXXX XX XXXX XX XX XX XXXX XXXX| player |XXXXX XXXX XX XX XX XXXX XX XXX XX XXXX XXXXX\______/XXXXXX XXXX XXX X XX XXXX XX XXXXXXX XX XX XXXX XXXXXXXXXXXXXXXXXXX XXXX XXXX XX XXXX XX XXXXXXX XX XX XXXX XXXXXXXXXXXXXXXXXXX XXXX XXXXX XXX XXX XXX XXX XX XXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX welcome line ready menu lab: # - reboot router1 $ - reboot router2 % - reboot router3 1 - connect to router1 2 - connect to router2 3 - connect to router3 ^ - rebuild routers l - connect to lg.nop.dn42 x - exit choose:1 - attach vdc lab1 welcome line ready yourname#terminal ? colorized - sending to ansi terminal length - set terminal length monitor - log to this terminal no - negate a parameter spacetab - treat space as tabulator tablemode - select table formatting mode timestamps - put time before each executed command width - set terminal width yourname#terminal ...
In order to exit the sandbox session use the following escape sequence: Ctrl-c + Ctrl-x
Requirement
|
|
Overview
As previously mentioned in the precedent article, when you log into a network equipment such as a router, you tend to have some automatic reflex. You usually:
- Check router configuration: show run or sh conf
- Check ipv4 / ipv6 / or LFIB forwarding table
- So you basically issue diagnosis, troubleshooting command
- An then you want to configure the router
Article objective
In this article, we will focus on the 3rd bullet point and will present you freeRouter available diagnosis command. They are grouped into 5 categories:
- show
- view
- watch
- display
- differ
Basically these commands are accessed through freeRouter user mode. If you need to use them from config mode, please use the "do" keyword.
[ #002 ] - "show/view/watch/display/differ"
You would mostly be familiar with the "show" command. It is very good and can basically be used to get output from control plane object. Most of the time this can be used against static object like config.
Let's assume that I would like to get BGP config from my home router:
show running-config bgp4 router bgp4 42 vrf dn42 local-as 4242421975 router-id 172.22.105.65 address-family unicast multicast other flowspec vpnuni vpnmlt vpnflw ovpnuni ovpnmlt ovpnflw vpls mspw evpn mdt srte mvpn omvpn neighbor 172.23.215.177 remote-as 4242421955 neighbor 172.23.215.177 description NOP.DN42 neighbor 172.23.215.177 local-as 4242421975 neighbor 172.23.215.177 address-family unicast multicast other flowspec vpnuni vpnmlt vpnflw ovpnuni ovpnmlt ovpnflw vpls mspw evpn mdt srte mvpn omvpn neighbor 172.23.215.177 distance 20 justadvert loopback42 exit
But I can also check the status of BGP peering into VRF dn42
show ipv4 bgp 42 summary as learn done ready neighbor uptime 4242421955 517 518 true 172.23.215.177 00:38:18
Check the same BGP peering but now for IPv6
r1#show ipv6 bgp 42 summary as learn done ready neighbor uptime 4242421955 351 352 true fd40:cc1e:c0de::151 00:40:40 show ipv4 bgp 42 summary as learn done ready neighbor uptime 4242421955 517 518 true 172.23.215.177 00:38:18
Let's see some BGP prefix received in VRF dn42 bgp table:
so my screen is too small for all the IPv6 BGP prefix into DN42 VRF
As a last example, something we usually do as network operators is to check ongoing interface traffic level:
r1#sh int sdn1
sdn1 is up (since 09:41:21, 2 changes)
description: mjolnir@LAN1[01:00.0]
type is sdn, hwaddr=003b.7671.764f, mtu=1500, bw=8000kbps, vrf=inet
ip4 address=192.168.0.90/24, netmask=255.255.255.0, ifcid=10013
ip6 address=2a01:e0a:159:2850::666/64, netmask=ffff:ffff:ffff:ffff::, ifcid=10013
received 52013 packets (17638316 bytes) dropped 5 packets (448 bytes)
transmitted 80765 packets (15101696 bytes) promisc=false macsec=false
r1#sh int sdn1
sdn1 is up (since 09:41:22, 2 changes)
description: mjolnir@LAN1[01:00.0]
type is sdn, hwaddr=003b.7671.764f, mtu=1500, bw=8000kbps, vrf=inet
ip4 address=192.168.0.90/24, netmask=255.255.255.0, ifcid=10013
ip6 address=2a01:e0a:159:2850::666/64, netmask=ffff:ffff:ffff:ffff::, ifcid=10013
received 52013 packets (17638316 bytes) dropped 5 packets (448 bytes)
transmitted 80766 packets (15101778 bytes) promisc=false macsec=false
r1#sh int sdn1
sdn1 is up (since 09:41:24, 2 changes)
description: mjolnir@LAN1[01:00.0]
type is sdn, hwaddr=003b.7671.764f, mtu=1500, bw=8000kbps, vrf=inet
ip4 address=192.168.0.90/24, netmask=255.255.255.0, ifcid=10013
ip6 address=2a01:e0a:159:2850::666/64, netmask=ffff:ffff:ffff:ffff::, ifcid=10013
received 52015 packets (17638418 bytes) dropped 5 packets (448 bytes)
transmitted 80766 packets (15101778 bytes) promisc=false macsec=false
In the last example we repeatedly issue the "sh int sdn1" command and try to see if TX/RX packets counters increment or not.
This command can be improved in order to be less chatty:
r1#sh int sdn1 | i received|transmitted received 52256 packets (17681204 bytes) dropped 5 packets (448 bytes) transmitted 81130 packets (15162642 bytes) promisc=false macsec=false r1#sh int sdn1 | i received|transmitted received 52256 packets (17681204 bytes) dropped 5 packets (448 bytes) transmitted 81130 packets (15162642 bytes) promisc=false macsec=false r1#sh int sdn1 | i received|transmitted received 52260 packets (17681496 bytes) dropped 5 packets (448 bytes) transmitted 81132 packets (15162790 bytes) promisc=false macsec=false
Same goes if want want interface traffic for all interface
show interfaces summary interface state tx rx drop loopback0 up 65856 0 0 loopback42 up 65856 0 0 ethernet0 up 31071917 33183183 0 hairpin41 up 85806 85552 0 hairpin42 up 85806 85552 0 sdn1 up 15200591 17703953 448 sdn2 up 15563546 8000994 794 sdn3 admin 0 0 0 sdn4 admin 0 0 0 sdn5 admin 0 0 0 sdn6 admin 0 0 0 sdn998 up 5850 0 0 sdn999 up 23268 18666 0 tunnel1965 up 5222281 7124950 0
Above was to check interface status related to software switched packet. What if I want to check hardware switched packet counters switched by P4 or DPDK ?
show interfaces hwsummary interface state tx rx drop hairpin41 up 0 0 0 hairpin42 up 0 0 0 sdn1 up 317902736 590402538 1162971 sdn2 up 574923844 310497399 203 sdn3 admin 0 0 0 sdn4 admin 0 0 0 sdn5 admin 0 0 0 sdn6 admin 0 0 0 sdn998 up 9062 0 0 sdn999 up 103804 64470 0 tunnel1965 up 0 1301312 0
Note
As a network operator, the "show" command is your best friend, your wingman. Just explore now from freeRouter CLI using "show ?" and you'll understand the amazing list of diagnosis command available.
In my previous examples, the output of "show ipv4 bgp 42 unicast database" command could not fit my window. Say hello to "view" keyword then !
Let's now try to get hardware counters as above:
r1#view ipv4 bgp 42 unicast database ...
Then you'll be able to see READ-ONLY text buffer where you can navigate and check the output that are beyond boundaries of your screen !
Note
"view" is similar to "show" but it will let you deal with a fixed buffer. "view" buffer won't be refreshed.
As mentioned above, "show" gives you diagnosis instant photo of a control plane object. In order to see counter increment, you'd have to issue "show" repeatedly. In order to avoid that, let me introduce you the "watch" command
Let's now try to get hardware counters as above:
r1#watch interfaces hwsummary ...
It will clear the terminal session and gives you the same outout as above but with counter updated in a regular basis
So in this example you'll see a live output with counter incrementing. In the screenshot it is not noticeable, but in real life this is bluffing. See watch interface pretty much like Junos "monitor" keyword.
So needless to say that "watch" is applicable to every control plane object such as BGP:
Amazing, don't you think ?
In my previous examples, the output of "show ipv4 bgp 42 unicast database" command could not fit my window. Say hello to "display" keyword then !
r1#display ipv4 bgp 42 unicast database ...
Then you'll be able to see READ-ONLY text buffer where you can navigate and check the output that are beyond boundaries of your screen !
As a side note, you can benefit from online help by pressing <f1>
You can press Ctrl+q in order to exit the editor. As the viewer is a READ-ONLY buffer
Note
Use "display" for output that have output that does not fit into your screen. "display" shows a buffer that is auto-refreshed similar to "watch". But instead the output is thrown into a buffer where you can navigate. But display, very useful to diagnoses object such as huge:
- ACL
- prefix-list
- route policy list
- route-map
As opposed to "view", "display" proposes an auto-refresh version of the buffer !
Last but not list. "differ" , this will split the window in 2 buffers reflecting the same output but with different version and it it signal line lines that have changed.
r1#diff ipv4 bgp 42 bestpath ...
With this view you can easily spot the differences between 2 advertisements interval.
To be honest, when i used this feature for the first time I was totally stumbled and said: Waouw ...
Simply amazing ...
Discussion
show/view/watch/display/differ is pretty unique to freeRouter, and is really meant to provide you the best user experience as a network operator ! These command have proven to be helpful, especially if you deal with huge feed. However, be careful when you are working with very big output such BGP full feed. This won't crash the router of course as we used to when we issued "debug ip packet" but it will for sure imply a high CPU usage due to regular refresh at the control plane level.
Conclusion
In this 2nd article:
- We presented freeRouter show/watch/display/differ diagnisis command
- These are very useful when you have to deal with huge command output buffer.
Final words
As said, these are diagnosis commands are specific to freeRouter. 2 decades of know how and network experience have been pushed into these feature codes. These have been developed for one purpose:
"Provide a unique operation experience to network engineers"
Feel free to try and use them according to your environment taste!
Last but not least, you can play with these different mode from this sandbox:
ssh dl.nop.hu -l random_user Warning: Permanently added 'dl.nop.hu,193.224.23.5' (RSA) to the list of known hosts. random_user@dl.nop.hu's password: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXX XXXXX XXX XXX XXX XX XX XXXX XXXXXXXXXXXXXXXXXXX XXXX XXXX XX XXXX XX XXXX XX XX XX XXXX XXXXX/~~~~~~\XXXXXX XXXX X XXX XX XXXX XX XXXX XX XX XX XXXX XXXX| player |XXXXX XXXX XX XX XX XXXX XX XXX XX XXXX XXXXX\______/XXXXXX XXXX XXX X XX XXXX XX XXXXXXX XX XX XXXX XXXXXXXXXXXXXXXXXXX XXXX XXXX XX XXXX XX XXXXXXX XX XX XXXX XXXXXXXXXXXXXXXXXXX XXXX XXXXX XXX XXX XXX XXX XX XXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX welcome line ready menu lab: # - reboot router1 $ - reboot router2 % - reboot router3 1 - connect to router1 2 - connect to router2 3 - connect to router3 ^ - rebuild routers l - connect to lg.nop.dn42 x - exit choose:l - telnet 172.23.199.110 23 /telnet - connecting to 172.23.199.110 23 - securing connection hi there! try the following: show ipv4 route dn42 show ipv6 route dn42 show ipv4 bgp 65535 vpnuni summary show ipv6 bgp 65535 vpnuni summary show ipv4 bgp 65535 vpnuni database show ipv6 bgp 65535 vpnuni database show ipv4 bgp 65535 vpnuni allroute <prefix> 65535:42 show ipv6 bgp 65535 vpnuni allroute <prefix> 65535:42 show ipv4 logger 42 flapstat 10 show ipv6 logger 42 flapstat 10 show ipv4 bgp 65535 vpnuni flapstat 10 show ipv6 bgp 65535 vpnuni flapstat 10 show ipv4 bgp 65535 vpnuni flappath <prefix> 65535:42 show ipv6 bgp 65535 vpnuni flappath <prefix> 65535:42 have fun! mc36 welcome line ready player-dn42> player-dn42> ...
Then issue a "diff" command:
player-dn42>diff ipv4 bgp 65535 vpnuni database 10.11.160.0/20 65535:42 ...
You'll be rewarded by this diff out related to the command which means:
"show me the prefix status of 10.11.160.0/20 within BGP process 65535 with rd: 65535:42"
After a quick look at VRF definition indicates that rd 65535:42 is tied to VRF dn42:
player-dn42>sh start vrf vrf definition dn42 rd 65535:42 rt-import 65535:42 rt-export 65535:42 source4route all source6route all mdt4 mdt6 exit vrf definition rtbh rd 65535:666 rt-import 65535:666 rt-export 65535:666 exit vrf definition vpn rd 65535:1 rt-import 65535:1 rt-export 65535:1 mdt4 mdt6 exit ...
In order to exit the sandbox session use the following escape sequence: Ctrl-c + Ctrl-x
Requirement
|
|
Overview
Even in the era of zero touch configuration where everything can be modelled by YANG and automated by Ansible, CLI configuration mode is essential and will take a special important place into network engineers' heart.
Any network engineer in the room who never issued this command ?
conf t ...
Article objective
In this article, we will present you freeRouter available configuration mode. This is an essential article as it will help you in your potential daily operation task.
Diagram
[ #001 ] - "configure <mode>"
"configure viewer" is a very interesting mode as it gives you the possibility to review the router configuration from a viewer inspired from "mcedit" (Norton Midnight Commander)
r1#configure viewer ...
Then you'll be able to read your configuration from a READ-ONLY text buffer:
As a side note, you can benefit from online help by pressing <f1>
But what if I just want to view a specific object ? Let's find out how to check ONLY BGP configuration @ home:
r1#configure viewer bgp4 ...
So in this case It'll just throw my IPv4 bgp config snippet onto the viewer buffer
Same if I want to only view all interface sdn<x> from the router config:
r1#configure viewer sdn ...
This is so cool, isn't ?
Note
In big TELCO Service Provider environment, most of the time you have Technical Project Manager that just need to perform some checks related to specific customer VPN deployment. So some times, I received some calls: "Can you please that from customer the HUB site prefix 1.2.3.0/24 is configured and advertised into BGP for customer ABC in VRF YXZ ?" With "configure viewer <object>", the TPM can just check it for himself without bothering you at all ! And this without the fear to alter router configuration by accident.
PS: For that you'll need to create a aaa security config with:
- proper router aaa security policy with privilege level 1
- with or without TACACS/RADIUS authentication / authorisation and accounting
- and apply it to a specific OOBM SSH/telnet server in a specific VRF,
but this is not in the scope of the the present article and it will be the object of further articles.
In SP environment, you should not be surprised to see router configuration that has 100k lines or even more. In these environment, I've seen config with countless amount of VRF, NAT, DLSW, GRE, IPSEC tunnels, BGP peers ... "config viewer" is a great tools when you want to verify a specific stanza on a per customer or object basis and in bonus without any risk the Provider Edge router configuration.
"configure viewer" gives you the possibility to view the config or some parts of the config in read-only mode. "configure editor" gives you simply the possibility to edit also the specific running-config config stanza.
r1#configure editor ...
Then you'll be able to edit your configuration from a READ-WRITE text buffer:
As a side note, you can benefit from online help by pressing <f1>
You can press Ctrl+q in order to exit the editor. As you did not change anything it will exit the editor.
But what if I just want to edit a specific object ? Let's find out how to check ONLY BGP configuration @ home:
r1#configure editor bgp4 ...
So in this case I'll just throw my IPv4 bgp config onto the editor buffer
In this buffer let's just create a description for BGP neighbor 172.23.215.177.
Now just press Ctrl-q (as per the online help accessible using <f1>). However, freeRouter detect the buffer changed has we added BGP description configuration. Therefore it will ask you if you want to save the buffer change into the running-config and apply it.
At that moment you'll be displayed a small recap of what has been applied.
Even more cool no ?
Warning
Even if "config editor" is seducing and seems more appealing especially for beginners. This is absolutely not the case. "configure editor" mode is meant for advanced users who knows freeRouter CLI by heart. Why, you might say ? Just try to edit a gigantic BGP configuration without any contextual help just by writing a textual file and you'll understand the risk behind using "config editor". Therefore it is no recommend to use it against complex control plane object.
Please take note that "config editor" alter the running-configuration directly when you saved the editor buffer !
Note
So what's the point of having this cool feature ? This feature is powerful when it comes to simple control plane object or big repetitive object. This is very practical to use this feature against: ACL / Prefix-List / Route Policy Object / Route Map etc.
- ACL
- prefix-list
- route policy list
- route-map
but nothing to prevent you to edit BGP stanza if you feel that your freeRouter-fu needs to be challenged 
Same as "config editor", but instead of working against the running-config you are editing the startup-config. Which is more safe ... till the next reload
r1#configure startup ...
"configure reload" as its name implies is not about reloading a router whatsoever 
r1#configure reload ? <url> - source url r1#configure reload ...
This command take a <url> as argument. Basically it will fetch router configuration from the specified <url> and load it into the startup-config. It is an equivalent to Cisco "copy <url> start". From that point:
- it is up to the network operator to check the startup configuration
- and issue a reload warm in order to restart the router and test that connectivity is resuming as expected
- Check the running-config is aligned to startup-config
Warning
(repetition is not harmful) As said before "configure reload" does not reload the router. It just load the config from specified <url> into the startup-configuration. And this steps precedes a reload that has to be triggered manually by the operator after having checked the config.
Note
in day to day operation, startup-config is usually not altered directly. In TELCO SP environment, IIRC, I used it mainly to retrieve configuration from a CMDB server during 2 situations:
- Router first time installation after basic configuration staging enabling minimum connectivity
- Router hardware replacement
Note that in SP environment, as VPN owner we could handle a portfolio of customer (~10). Each customer could have ~ 2000 CPEs. You can see why "config reload" can be very handy.
"configure banner" is one of my favorite mode. It will display an editor allowing you to edit the banner of your router.
r1#configure banner ...
Press Ctrl-q and then y in order to save the banner.
Log in to you router again in order to check your new banner:
Note
in day to day operation, this banner can be written in configuration using banner encoded command
banner encoded ICAgX18gICAgICAgICAgICAgICBfX19fICAgICAgICAgICAgIF8NCiAgLyBffF8gX18gX19fICBfX198ICBfIFwgX19fICBfICAgX3wgfF8gX19fIF8gX18NCiB8IHxffCAnX18vIF8gXC8gXyBcIHxfKSAvIF8gXHwgfCB8IHwgX18vIF8gXCAnX198DQogfCAgX3wgfCB8ICBfXy8gIF9fLyAgXyA8IChfKSB8IHxffCB8IHx8ICBfXy8gfA0KIHxffCB8X3wgIFxfX198XF9fX3xffCBcX1xfX18vIFxfXyxffFxfX1xfX198X3wNCiAgXyBfXyBfX18gICBfX198IHwgX19fX18gIHwgfA0KIHwgJ19fLyBfIFwgLyBfX3wgfC8gLyBfX3wgfCB8DQogfCB8IHwgKF8pIHwgKF9ffCAgIDxcX18gXCB8X3wNCiB8X3wgIFxfX18vIFxfX198X3xcX1xfX18vIChfKQ0KDQo=
the command corresponds to the banner mentioned above.
Discussion
Most of you will simply use the basic "conf t" mode, but keep in mind that depending on your context, all the other modes are proven to be very handy. The possibility to configure 1000 router with one single config file using "config network" is a savior. Having the possibility to trigger automatic definitive router staging using "conf reload" is tremendously useful when you have to deploy 10 routers a day. As said "config view" can give non operation staff to check if some configs are there or not ... "config editor" is very powerful when you want to edit a never ending access-list, but remember to avoid to use it for complex BGP config... You have been warned !
Conclusion
In this 1st article:
- We presented freeRouter config mode
- Most of these are useful in various different context
Final words
All these modes are not new. IOS, IOS-XR, IOX-XE, NW-OX, JUNOS have their own config mode that are somewhat similar. In any case freeRouter config mode implementation is meant to address all needs from the network operators perspective. As you can observe, configure mode has an impressive list of mode. Feel free to try and use them according to your environment taste!
Last but not least, you can play with these different mode from this sandbox:
telnet dl.nop.hu 1 ↵ Trying 193.224.23.5... Connected to dl.nop.hu. Escape character is '^]'. XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXX XXXXX XXX XXX XXX XX XX XXXX XXXXXXXXXXXXXXXXXXX XXXX XXXX XX XXXX XX XXXX XX XX XX XXXX XXXXX/~~~~~~\XXXXXX XXXX X XXX XX XXXX XX XXXX XX XX XX XXXX XXXX| player |XXXXX XXXX XX XX XX XXXX XX XXX XX XXXX XXXXX\______/XXXXXX XXXX XXX X XX XXXX XX XXXXXXX XX XX XXXX XXXXXXXXXXXXXXXXXXX XXXX XXXX XX XXXX XX XXXXXXX XX XX XXXX XXXXXXXXXXXXXXXXXXX XXXX XXXXX XXX XXX XXX XXX XX XXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX welcome line ready menu lab: ...
ssh dl.nop.hu -l random_user 1 ↵ Warning: Permanently added 'dl.nop.hu,193.224.23.5' (RSA) to the list of known hosts. random_user@dl.nop.hu's password: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXX XXXXX XXX XXX XXX XX XX XXXX XXXXXXXXXXXXXXXXXXX XXXX XXXX XX XXXX XX XXXX XX XX XX XXXX XXXXX/~~~~~~\XXXXXX XXXX X XXX XX XXXX XX XXXX XX XX XX XXXX XXXX| player |XXXXX XXXX XX XX XX XXXX XX XXX XX XXXX XXXXX\______/XXXXXX XXXX XXX X XX XXXX XX XXXXXXX XX XX XXXX XXXXXXXXXXXXXXXXXXX XXXX XXXX XX XXXX XX XXXXXXX XX XX XXXX XXXXXXXXXXXXXXXXXXX XXXX XXXXX XXX XXX XXX XXX XX XXX XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX welcome line ready menu lab: # - reboot router1 $ - reboot router2 % - reboot router3 1 - connect to router1 2 - connect to router2 3 - connect to router3 ^ - rebuild routers l - connect to lg.nop.dn42 x - exit choose:1 - attach vdc lab1 yourname# yourname#configure ? <cr> banner - edit the banner editor - configure from editor file - append to running configuration network - append to running configuration overwrite-network - overwrite the running configuration reapply - !!!EXPERiMENTAL!!! try to reapply current configuration reload - overwrite the startup configuration replace - overwrite the running configuration revert - revert to startup configuration rollback - configure within auto-revert session startup - edit the startup configuration terminal - configure from this terminal viewer - view current configuration yourname#configure ...
In order to exit the sandbox session use the following escape sequence: Ctrl-c + Ctrl-x
Another method to access the sandbox, by click here, this will open a terminal webapp into your browser:
Requirement
|
|
Overview
RARE project objective is to provide a routing platform proposing various solutions addressing multiple use cases in the R&E landscape. In the picture below you see in purple the different use cases:
As you can notice, each use case will run on different hardware that potentially can have different dataplanes. As we were starting from a clean slate environment without much choice, especially with P4 programmability - the first dataplane or P4 target considered was BMv2. BMv2 is an excellent way to learn P4, it is also the first target we use in order to program and validate new features. After 6 months of practising our "P4-fu" we developed:
- a P4lang repository for ubuntu bionic and focal
- a debian 10 repository
- had our first RARE/FreeRouter prototype powered by a P4 BMv2 dataplane !
Our initial work, considering FreeRouter's Java nature, was to write a Java P4Runtime GRPC client that would be able to program the entries in the tables exposed by BMv2 via the P4Info file. However, this would have intimately tied FreeRouter code to P4Runtime gRPC code. Even if it's more natural to choose this solution, going in that direction implied that dataplanes other than BMv2 would be compliant to P4Runtime. It turns out that this is not the case. We then opted for a simple message API via a bi-directional raw UNIX socket. We will see what this means later in this blog.
Motivated by the successful experience with BMv2, we then decided to move forward and started to study TOFINO as a target. We were greedy and eager to apply our P4 code against multi-terabits traffic. After a few P4 program compilations, the first impression from my personal perspective was ... mind blowing ! INTEL/BAREFOOT TOFINO effectively opened the door to multi-terabits packet processing... Just to have at the tip of your finger the possibility to process traffic at these traffic levels was exciting !
As a side note, the journey was not without suffering and pain... We had to port our BMv2 code - and to port to TOFINO was not "Une lettre à la poste"... It is not that TOFINO programming is gratuitously painful. It is just that it is p4c-tofino's job to make sure that our packets are processed at silicon lighting speed. Imagine you are asked to convey parcels by driving from Paris to Amsterdam with a car that has an infinitely sized trunk, with an infinite gas tank and no particular speed constraint along the road. And then you are asked to do the same trip, but with an actual real car that has a trunk with a fixed size and with a 50 litre gas tank, and of course you'll have to follow speed signs along the road.
In the first case, you would put as many parcels as you would like and you even won't bother looking at your gas tank level and maybe you'd set the speed to 200 Km/h. The second case forces you to carefully think about how many parcels you can put in your trunk, check to see if one completely full tank can be sufficient for the trip and of course, you would have to follow the speed signs.
If you allow me this comparison, this is where BMv2 and TOFINO programming differs.
But, this pain was not in vain, it was for the greater good... You can't imagine the inherent joy when you see the TOFINO compiler displaying the DONE word ! For the veterans who can remember, it is the same feeling when you manage to compile your first program in the ADA language. The compiler is not so strict that compiling an ADA program is in itself a feat. No wonder why this language is used in Spatial rocket (Ariane).
Back to our dataplane interface story, even TOFINO and BMv2 share some roots, while BMv2 had P4Runtime as a northnound interface, INTEL/BAREFOOT pushed into TOFINO platform with P4_16 their gRPC interface counterpart: BfRuntime.
Our best bet paid off as FreeRouter message API was unchanged and without much effort we could add a new dataplane "wingman" to the FreeRouter control plane.
To recap:
- For BMv2: Our interface yields P4Runtime RPC calls. This program is called: forwarder.py
- For TOFINO: Our interface yields BfRuntime RPC calls. This program is called witout too much originality: bf_forwader.py
At that point we were starting to have a decent LSR/LER router for CORE and Aggregation use cases.
But we still had nothing at the EDGE/AGGREGATION layer in terms of a solution proposal, deploying P4 hardware might be way too expensive in specific contexts such as small R&E institutions like primary schools or small R&E labs. To that purpose, we started to study new targets such as VMWARE XDP and a very promising project: T4P4S ELTE. While we could not use XDP without a lot of P4 code rewriting and compromise, T4P4S ELTE was from our perpective very promising. But due to a compilation issue, we could not move forward.
FPGA was also a solution that we considered but had no access to any FPGA hardware that was P4 compliant.
As a result, we were a little bit bitter and started to read the DPDK library. And we started to play with DPDK examples... These examples were tremendously useful as it sparked some DPDK development into the RARE team. Csaba, the FreeRouter lead developer, step by step came up with this GENIUS idea: why don't we just use emulate P4 RARE P4 dataplane program ? We can still revert to using T4P4S ELTE when it will be ready ?
P4emu/P4dpdk was then born !
To conclude this short story, RARE/FreeRouter has now 3 completely different dataplanes: (in order of appearance)
- BMv2
- TOFINO
- DPDK
Unique RARE/FreeRouter feature
However, please note that FreeRouter message API is common to the three dataplanes listed above. You'll see further how this structure make the solution: an open modular, interchangeable solution.
Article objective
In this article, let's present RARE/FreeRouter platform structure and focus on the interface(S) between FreeRouter control plane and various dataplane.
Diagram
[ #001 ] - Modular design
As said in the beginning of the article, freeRouter control plane would have to deal with dataplane of different nature. And we concluded in mentioning that for now, freeRouter has three dataplanes. Each of these dataplanes have their own northbound interface, whether this is P4Runtime for BMv2, BfRuntime for TOFINO or P4DPDK for system compatible with DPDK and having DPDK complinnt NIC.
For BMv2 we just had to write an interface that would translate freeRouter API message into P4Runtime GRPC calls. For BMv2 this interface is called forwarder.py:
For TOFINO we just had to write an interface that would translate freeRouter API message into BfRuntime GRPC calls. For TOFINO this interface is called bf_forwarder.py:
For DPDK we just had to write an interface that would translate freeRouter API message into DPDK primitives. This interface is included into DPDK dataplane bundled into freeRouter binaries: p4dpdk.bin
It is just as simple as that !
Discussion
One thing that we did not experience, but this can be maybe one day a reality.
What if you have your own control plane and that you absolutely want to keep it, but would like to re-use BMv2/TOFINO or DPDK RARE dataplane ?
Well this is possible !
Long time ago I met Thomas MANGIN (yet another cool and nice French guy ) which is the author of Exa-BGP, i did not talk to him about this and I don't want to give him bad idea, but what if he would like to hook a TOFINO P4 dataplane to Exa-BGP ?
Well, he actually would just have to teach exaBGP to handle entry ADD/DELETE/MODIFY message according to the message API above.
I also love the work DONE at the SoNIC project level and I know that SoNIC has already a P4 dataplane called switch.p4. I doubt it will be the case one day but, what if SoNIC project wanted to re-use RARE dataplane for especially for Service Provider capability ?
OK, this sounds crazy, but the modular design we proposed here is valid and can make the RARE dataplane available for other control plane.
Of course, we strongly suggest you to stick with FreeRouter as you will just realize IMHO that in the TELCO Service Provider space there is no match. You'll have the venerable IOS-XR and JUNOS, but these are not Open Source counterparts.
Conclusion
In this 1st article you:
- had a 10K feet view description of RARE/FreeRouter modular design
- This design allow rapid dataplane addtion without altering whatsoever FreeRouter code base
- In case you would like to re-use BMv2/TOFINO/P4DPDK dataplane, this has been never implemented but this is possible !
Message API documentation
From the time being this API message is not yet publicly documented. However, it is available and buried inside forwarder.py or bf_forwarder.py source code. This is work in progress but if you feel an urgent need to use it feel free to read the code.
PS: We will publish this document ASAP, but time plays against us ...
Requirement
|
|
Overview
We will deal with a series of article related to APS Networks® BF2556X-1T P4 switch. The key highlight of this box is:
- It is a P4 TOFINO NPU based switch
- TOFINO version has 2 cores (i.e. 2 pipes) and can manage up to 2 Tbps
- It offers multiple connection types and rates:
- 48x25GSFP28 and 8x100GQSFP28
- SFP28 port [1 - 16] can configure into 1G/10G/25G
- SFP28 port [17 - 48] can configure into 10G/25G
- QSFP28 port [49 - 56] Each QSFP28 port can configure into 1x100G,2x50G,4x25G, 1x40G or 4x10G Mode.
- 48x25GSFP28 and 8x100GQSFP28
- SyncE and 1588 support
Article objective
In this article, we will just do a basic introduction of the BF2556X-1T
[ #001 ] - BF2556X-1T in a nutshell
Parcel
What's in the box
Included items
Quick Installation guide
Front panel
Back panel
APS Networks® BF2556X-1T Racked
APS Networks® BF2556X-1T alongside to his P4 brothers: Edgecore WEDGE100BF32X
Discussion
Conclusion
In this 1st article you:
- had a brief description APS Networks® BF2556X-1T hardware platform
- The hardware provide p4 connectivity at 1GE capacity (16x1GE ports is available)
- In addition to 1GE it also provide 10/25/40/50/100G connectivity
RARE hardware plarform: [ BF2556X-1T #001 ] - key take-away
- From RARE/FreeRouter point of view, BF2556X-1T is very good candidate for PE (Provider Edge) router.
The 8x100G ports can make as a strong in a collapse core architecture (P function merge with PE functions), the box can also be used a a BGP route as it boast with 32 GB of RAM (~10 full BGP feeds), but you won't leverage the ports availability. It can be used to implement BRAS/BNG use case but would be also a good candidate as a ToR in Data Center envionment with BGP/MPLS capability and the possibility to provide 1GE connection to existing server purchased beforehand.
- SyncE 1588 support is a key features if your application needs precision provided by PTP
As we will discover the box, we will explain in further articles how to benefit from this features.
- RARE/freeRouter @design can coexist with Virtualisation technology BF2556X-1T
We just started our experience with this box. You'll find further, a series of article dedicated to BF2556X-1T depicting:
- How to proceed to initial OS installation
- Proceed to APS Networks® BF2556X-1T software installation (TOFINO SDE and Gearbox) installation
- Port operations on TOFINO ports SFP28 port 16-47 and QSFP28 port 48-56
- Port operations on GearBox ports SFP28 port 1-16 (1G/10G/25G)
- How to benefit from SyncE 1588 support
- RARE/freeRouter effective installation
The installation will be implemented should be compliant to ISP TELECOM standard. (It should survives power outage, easy upgrade features, start automatically at boot time without any human intervention)