Saturday, December 10, 2011
Open Source Routing Research Notes
If you've ever used Vyatta before you've probably noticed its very Cisco-ish syntax even though it clearly has a Linux heritage. I've been working on a project that has required a better understanding of how this is ultimately achieved. Quagga, Bird and Xorp came into my sights after a preliminary search as well as a number of other 'younger' projects.
Initially, Bird/Xorp configuration seems to be a lot less readable than Quagga but simpler in that it relies on only one file. Edge to Quagga, then Bird and finally Xorp. Research indicates that Xorp may have been the default open source routing engine prior to Quagga. Whitepapers suggest that open source routing software on commodity hardware is able to achieve similar or superior speeds/performance to that of proprietary solutions at a fraction of the cost. Learning curve is reduced by use of similar syntax of Cisco/JUNOS CLI and of course open nature of routing protocols. Documentation for all options seem to be reasonable.
"zebra is an IP routing manager. It provides kernel routing table updates, interface lookups, and redistribution of routes between diﬀerent routing protocols.", http://www.quagga.net/docs.php
# and ! used to mark comments in configuration files.
telnet direct to 2601 (telnet to higher ports to configure/monitor the other protocols) and configure/monitor using a Cisco like CLI interface. Like Cisco/JUNOS CLI interface, modes (enable, global config, interface, etc...), commands (show, no, router, etc...), and auto-completion of commands are also supported.
Most protocols major protocols catered for except for proprietary ones such as IGRP and EIGRP. For example, RIP (v1/v2), RIPng (handles IPv6), OPSF (v2/v3 which handles IPv6), BGP, even ISIS is supported.
Cisco style access-list command and complete support for IPv6 available.
If you're familiar with the Cisco CLI then you'll be completely at home with the Quagga interface. Commands are identitical in most cases. In fact, its a fairly good way of revising for CCNP BSCI, and other Cisco certification exams if you don't have access to actual equipment or simulation software.
Although I haven't attempted to use this apparently 'SMUX' allows you to reference information from the various Quagga services by providing a bridge between SNMP and Quagga. A more apt description would be that, "SMUX is the snmp multiplexing protocol (RFC 1227). It can be used by an snmp agent to query variables maintained by another user-level process."
While I was doing all this I decided to 'clean up' a number of other anomalies on my system. For example, 'kdump' was not starting on boot. Obvious solution would be to simply remove kdump package but I just wanted to make it work. Thought it was just a non-configuration issue. Went through the uncommenting of the default options but it still wasn't starting. Went through the relevant 'init' file. Noticed that it required a 'crashkernel' parameter (eg. crashkernel=128M@128M) in order for it to work (/proc/cmdline contains kernel boot parameters if you're curious. While other /proc files can be written to this file was not responsive to chmod and being written to even if you are root). Ultimately, only way to test is to modify kernel boot parameters via /boot/grub/menu.1st. However, then noticed that kernel wasn't configured with this option available. Hence, boot was not possible. Had to update kernel and kernel source (required for my work with other packages). Thereafter, kdump startup was now possible (if you're curious "echo 1 > /proc/sys/kernel/sysrq", "echo c > /proc/sysrq-trigger" can be used to create a kernel crash situation if you're curious).
yum update kernel
yum update kernel-headers
yum update kernel-devel
Once again, noticed that performance when MTU is 1392 is much better than 1500 during download of packages via yum. Upgrade of kernel 'broke' my VirtualBox setup though. Obviously, suspected kernel module issues so went to /usr/src/vbox_host-* and had to re-run 'make' to re-recompile the relevant kernel modules and re-register relevant modules. Noticed later on that there was an option for the vboxdrv init file (setup) which was 'more correct' though. Used this and VirtualBox startup was all good again. It was a bit easier with VMWare Server though. Kernel modules are automatically re-compiled/re-registered and setup on startup.
Following is useful if you're interested in more about about kernel dump analysis,
While completing all of the above, I remembered previous work regarding PKI certificates to setup OpenVPN. Looked for mkcert.sh/CA.pl and found but also noticed tinyca2 and openvas-mkcert. tinyca2 is a very simple GUI based application for managing certificates while openvas-mkcert is CLI based. Haven't tried using these certificates with OpenVPN as yet though. Will experiment another time.
- you read some of the articles out there about recruitment practices and things sound so simple... I've watched the recruitment proces...
- many people are often critical of choices that are often made in other countries. If you think carefully about it, massive loops have bee...
If you're like many others on the planet you probably can't be bothered purchasing a new piece of software in order to test an appl...