CDQ: Basic BGP prefix ingress filtering

I’ve been doing a lot of BGP lately. I’ve seen some config that has made me cringe. I’ve also seen a bunch of routing loops and other tomfoolery because people weren’t cleaning their prefixes properly.

This is a very quick inbound prefix list that should be the minimum that you apply to your peers. This is a basic sanity check and is in no way exhaustive.


ip prefix-list BasicPrefixFilterIn deny 0.0.0.0/8 le 32
ip prefix-list BasicPrefixFilterIn deny 10.0.0.0/8 le 32
ip prefix-list BasicPrefixFilterIn deny 100.64.0.0/10 le 32
ip prefix-list BasicPrefixFilterIn deny 127.0.0.0/8 le 32
ip prefix-list BasicPrefixFilterIn deny 169.254.0.0/16 le 32
ip prefix-list BasicPrefixFilterIn deny 172.16.0.0/12 le 32
ip prefix-list BasicPrefixFilterIn deny 192.0.2.0/24
ip prefix-list BasicPrefixFilterIn deny 192.168.0.0/16 le 32
ip prefix-list BasicPrefixFilterIn deny 198.18.0.0/15 le 32
ip prefix-list BasicPrefixFilterIn deny 198.51.100.0/24
ip prefix-list BasicPrefixFilterIn deny 203.0.113.0/24
ip prefix-list BasicPrefixFilterIn deny 224.0.0.0/4 le 32
ip prefix-list BasicPrefixFilterIn deny 240.0.0.0/4 le 32
ip prefix-list BasicPrefixFilterIn permit 0.0.0.0/0 ge 8 le 24
ip prefix-list BasicPrefixFilterIn deny 0.0.0.0/0 le 32

The list starts with RFC5735 (special use) address space being denied. Then, allow things that have a prefix length between a /8 and a /24 (inclusive). Lastly, block everything else.

NOTE: this list will block the default route. Be warned.

This post was inspired by the sample config file that the folks over at OpenBGPd distribute. You guys rock!

CDQ: NTP will save you time.

In my second edition of Cisco Done Quick (CDQ) I will talk about how NTP – the network time protocol – will save you time.

Debugging network problems can be challenging. It’s made even worse by time zones and daylight savings time.  Worse still by a clock that has drifted.

Some older Cisco IOSes don’t know the current rules for daylight savings. They can be configured, if necessary. Start with setting a timezone and setting the rules for Mountain Daylight Time (or your time zone as appropriate):

clock timezone MST -7 0
clock summer-time MDT recurring 2 sunday march 02:00 1 sunday november 02:00 60

Next, setup NTP, if you don’t already have it:

ntp server [vrf MANAGEMENT] aaa.bbb.ccc.ddd
[ntp source gig 0/0]
[ntp logging]

Setting the VRF and source interface are only needed if you are using a dedicated management interface. The “ntp logging” line is only useful for debugging information. Remember to TURN IT OFF once you’re satisfied that everything is working.

Doing a “show clock” will tell you whether or not NTP has been able to update your clock.

So how does this save you time?

Well, with properly annotated timezone information and a synchronized clock, you’ll spend less time debugging and converting times or correcting for a drifting system clock.

UPDATE – 26 November 2012:

If your device is already using DNS, rather than hard-coding an IP address for the NTP server, I suggest you pop on over to ntp.org.  For Canadian NTP servers, look here.

Using the NTP servers in a pool will make things a little more fault tolerant.  It will help with:

  • NTP server drift (yes, it does happen)
  • NTP server outages (this happens more regularly)

The config will end up looking more like this:

ntp server [vrf MANAGEMENT] 0.ca.pool.ntp.org
ntp server [vrf MANAGEMENT] 1.ca.pool.ntp.org
ntp server [vrf MANAGEMENT] 2.ca.pool.ntp.org
ntp server [vrf MANAGEMENT] 3.ca.pool.ntp.org

 

CDQ: VRF Management Interface

This is the first post in a series that I’m calling Cisco Done Quick (CDQ).

Have you ever had a Cisco router that didn’t have a wired management interface? Serial is all fine and good, but sometimes you don’t have a Serial Console Server but you do have a management network.

If the router supports VRFs, you can easily create a VRF just for management traffic. This is a great option and can be quickly accomplished with a few commands:

Basic config:

In configure mode:

ip vrf MANAGEMENT
 exit
interface GigabitEthernet0/0
 ip vrf forwarding MANAGEMENT
 ip address dhcp
 exit

This creates the VRF named “MANAGEMENT” and assigns a single interface to it. Rather than using DHCP, I’d usually statically assign an IP, but you get the idea.

TFTP and other standard protocols:

Let’s say you want all TFTP traffic to use the new management interface… that’s easy with the “ip xxxx source-interface” set of commands:

ip tftp source-interface gi 0/0

Syslog:

logging host aaa.bbb.ccc.ddd vrf MANAGEMENT

NTP:

ntp server vrf MANAGEMENT aaa.bbb.ccc.ddd
ntp source gig 0/0
ntp logging

Conclusion

I’m a big advocate for separation of management and production traffic. It eases some of my security concerns. These steps are simple and in my experience quite useful. Enjoy.

Linux-based serial console server

Introduction

Serial links certainly aren’t as common as they once were. They used to be used for long-haul networking, connecting a modem to a PC or router, accessing a management interface, and I’m sure there are many other things that I can’t think of.

These days there are still several devices that use serial ports for various applications. Just to be clear – I’m not talking about USB, or RS-422/485. I’m talking about good old fashioned TIA-232 (formerly known as RS-232). These ports topped-out at around 256kbps. The most common speed that I see in the networking realm is still good old 9600bps.

I recently wanted to setup a serial console server while spending minimal cash in the process. I found that some of the documentation that used to be readily available (late 1990′s) has since disappeared. This post summarizes the steps I took to get a serial console server operational under Unbuntu 10.4 LTS.

What is a serial console?  Rather than using a keyboard and monitor to interact with a device (in this case, a computer), it is sometimes possible to send and receive data from a device over a single serial connection.  This is a fantastic option when high-throughput, low-latency connections are not available.  In fact, it’s possible to configure Linux, Solaris, OpenBSD and many other platforms to use a serial console instead of, or in addition to, the normal keyboard & monitor.

Serial consoles are still used for managing many routers and switches (Cisco, HP).  Some hardware manufacturers equip their gear with only a serial port to act as a console – thus saving cost on video ports (Soekris).

In my case, I often find myself managing a rack or two of switches and routers that are all capable of using a serial console.  The problem is that many new servers don’t come with a serial port – let alone eight.  Cash was tight for this project, so I didn’t opt for a pre-built multiport serial console server and instead decided to build my own.  Here’s how I did it.

Hardware

I’ve used equipment from Axxeon before.  I’ve been pretty happy with it.  If you’re in need of reasonably priced switching gear for harsh environments, they can help.  It also turns out that they sell multiport serial cards for a PCI-e bus:
http://www.aaxeon.com/products/pci-express-cards/multiport-serial/rs-232/1762
Eight ports was all I needed for this particular application, and the price was reasonable.

This card uses the very well supported “Oxford” serial chipset.  Drivers exist for this chipset natively in Ubuntu 10.4.

Be careful not to over-tighten the thumbscrews on the breakout cable.  They are *tiny* and can’t handle much torque.  I managed to snap one on a previous install while tightening by hand.

I used a small PC for this particular setup.  The low-profile PCI-e back plate made install a breeze.

No other changes were required to get this card to work.

Linux Distribution

For a base OS, like I said, I used Ubuntu 10.4 LTS.  You may notice that the current version of LTS is 12.  I’m a little late in doing this writeup.  I would assume that not much would need to change between 10.4 and 12.  If I setup another with 12, I’ll try to remember to update this post.

Kernel

Ubuntu’s kernel isn’t configured to natively handle more than four serial ports.  There are two ways to fix this:

  1. adjust and re-compile the kernel
  2. pass the kernel a parameter that enables it to use more

I opted for the second option.  It’s been a long time since I built a kernel, and I’d rather not get into that.  All that was necessary was another line in /boot/grub/grub.conf:

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.

GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX="8250.nr_uarts=16"

Hint – it was the last line in the above output.  The “8250″ was a common serial chipset back in the day.  This line tells the kernel to work with up to 16 serial ports.

After running ‘update-grub’ and rebooting, dmesg had the appropriate information:

tpb@serial:~$ dmesg | grep ttyS
[    0.770319] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    0.770410] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[    0.770826] 00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    0.770948] 00:07: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[    0.771645] ttyS4: detected caps 00000700 should be 00000100
[    0.771650] 0000:08:00.0: ttyS4 at MMIO 0xd5efd000 (irq = 17) is a 16C950/954
[    0.771716] ttyS5: detected caps 00000700 should be 00000100
[    0.771720] 0000:08:00.0: ttyS5 at MMIO 0xd5efd200 (irq = 17) is a 16C950/954
[    0.771782] ttyS6: detected caps 00000700 should be 00000100
[    0.771786] 0000:08:00.0: ttyS6 at MMIO 0xd5efd400 (irq = 17) is a 16C950/954
[    0.771847] ttyS7: detected caps 00000700 should be 00000100
[    0.771851] 0000:08:00.0: ttyS7 at MMIO 0xd5efd600 (irq = 17) is a 16C950/954
[    0.771912] ttyS8: detected caps 00000700 should be 00000100
[    0.771916] 0000:08:00.0: ttyS8 at MMIO 0xd5efd800 (irq = 17) is a 16C950/954
[    0.771977] ttyS9: detected caps 00000700 should be 00000100
[    0.771981] 0000:08:00.0: ttyS9 at MMIO 0xd5efda00 (irq = 17) is a 16C950/954
[    0.772042] ttyS10: detected caps 00000700 should be 00000100
[    0.772046] 0000:08:00.0: ttyS10 at MMIO 0xd5efdc00 (irq = 17) is a 16C950/954
[    0.772108] ttyS11: detected caps 00000700 should be 00000100
[    0.772112] 0000:08:00.0: ttyS11 at MMIO 0xd5efde00 (irq = 17) is a 16C950/954
tpb@serial:~$

A couple things to notice:

  1. There is a gap in numbering between the on-board serial and the first PCI-e serial port.
  2. There is no guarantee that the first PCI-e serial port will align with the first port on the break-out cable.  You will need to do some trial-and-error testing to map the logical ports to the physical ports.

Software

There are two “conserver” packages in Ubuntu. The conserver-server package includes the client and the daemon.

tpb@serial:/etc$ apt-cache search conserver
conserver-client - connect to a console server
conserver-server - connect multiple user to a serial console with logging

Rather than using an /etc/init.d/ script to start and stop the daemon, I opted to just throw the command into /etc/rc.local:

tpb@serial:/etc$ cat rc.local
...

conserver -C /etc/conserver/conserver.cf

Conserver Configuration

The config is fairly straight forward. I used the Alias directive to match the tty number to the octopus cable port number. Because this is a serial console server in a lab, I opted to allow all local users full access to all ports.

tpb@serial:/etc/conserver$ cat conserver.cf
# The character '&' in logfile names are substituted with the console
# name.
#
config * {
        logfile /data/conserver.log;
        sslrequired off;
        daemonmode yes;
        primaryport 3109;
}

access * { trusted localhost; }

default * {
        master localhost;
        type device;
        baud 9600;
        parity none;
        logfile /data/console/&.log;
        timestamp "";
        rw *;
}

console c2950 {
        #alias on-board
        device /dev/ttyS0;
}
console c2960 {
        #alias P1
        device /dev/ttyS4;
}
console c2800-bottom {
        #alias P2
        device /dev/ttyS5;
}
console c3825 {
        #alias P3
        device /dev/ttyS6;
}
...
...

Tab Completion

To finish things off nicely, I decided to configure BASH tab completion for the “console” command:

tpb@serial:/etc/bash_completion.d$ cat console
complete -W "`cat /etc/conserver/conserver.cf | grep ^console | sed -e "s/^[^ ]* //" -e "s/ .*//"`" console

Conclusions

Setting up a serial console isn’t too rough. There are ways to improve the setup:

  • Use RADIUS authentication rather than allowing all users to have access
  • Allow remote telnet connections in so that users don’t need local accounts

Hopefully this will help either myself or some other future admin do things a little faster and a little less painfully.  If you have any suggestions for how to improve this serial console server, please let me know!

FreeRADIUS – a step toward a more secure network

Introduction

FreeRADIUS is a general purpose RADIUS daemon.  RADIUS enables administrators to centralize user accounts (among many other features).  This is quite handy when you have many devices that you are administering.  Imagine updating a couple-hundred switches and routers because an administrator needs to change their password.  With RADIUS, you update a central location rather than each and every node.  When it is time to login, the device you are connecting to can check your credentials against the central RADIUS server to determine whether or not access should be granted.

Installation

tpb@$ sudo apt-get install freeradius

That’s it (for Ubuntu, anyway).  What next?  Read the docs: http://freeradius.org/doc/

My focus here isn’t a step-by-step setup guide for FreeRADIUS.  My focus is bridging the gap between FreeRADIUS and the Cisco realm.  That said, here’s what I came across:

  • In Ubuntu the daemon isn’t called “radiusd”, instead it’s “freeradius” (lives in /usr/sbin/).
  • Config files are in /etc/freeradius/
  • To restart the daemon (after, say, editing the ‘users’ file) run: “/etc/init.d/freeradius restart”

Wait, this is on a Linux server, why not just use the database on the server for authentication information?  Good idea:

root@xbmcsrv:/etc/freeradius# head users
DEFAULT   Auth-Type = System
...

Great – we have users setup.  What next?  Well, I seem to recall needing to generate keys to talk between hosts.  Yep, back to the docs: http://wiki.freeradius.org/Basic-configuration-HOWTO.  Here’s the good news, it’s just one file: /etc/freeradius/clients.conf and the syntax is pretty easy.  Here’s what I added:

client router1 {
        ipaddr = 192.168.1.109
        secret = ThisIsASecret001
}

On the Cisco side, I had to do a little more work. Did I read documentation? Of course I did! http://wiki.freeradius.org/Cisco

aaa new-model
!
aaa authentication login default group radius local
radius-server host 192.168.1.2 auth-port 1812 acct-port 1813 key ThisIsASecret0

This is a VERY basic configuration.  You can get into groups, privileges, heck you can even have the enable password looked up against RADIUS.

A Quantitative Analysis of Effectiveness of Two Ad Blocking Engines

MINT 709, Capstone Project Report

A Quantitative Analysis of Effectiveness of Two Ad Blocking Engines

(Edited for Web)

Prepared by: Mark Leonard

Prepared for: Dr. M. MacGregor

December 2011

 

Abstract

In the past, the target audience of traditional advertising (such as newspapers, magazines, and billboards) has not incurred costs associated with the ads.  This is not necessarily the case when it comes to online advertising.  Presumably, online ads increase the total size of webpages that are downloaded – the extra throughput due to the embedded images and other content inherent in advertising.  Online ads also represent a potential increase in the time required to load web pages.  For companies who pay for Internet usage, increases in page size caused by advertising could have financial consequences.

With some configuration, ad blocking engines can reduce total web page size by approximately 10%.  With poor configuration, it is possible to see an increase in total page size due to filtering.

Acknowledgements

I would like to express my sincere gratitude to Dr. M. MacGregor for his guidance and encouragement in the completion of this report.  I would also like to thank my parents for their continued support and cooperation throughout my studies.  My sisters deserve thanks for their gracious hospitality and accommodations whenever I was in Edmonton for classes and research.

Continue reading

Redundant Connectivity for a Server Management Network

CPSC 550 Project
By J. Ryan Woo
and Mark Leonard

(Originally written April 2010)

Background

Both servers and networks experience problems with configuration and ongoing operation.  It is the role of the network and system administration team to be able to determine the nature of these problems and resolve them as quickly as possible.  To this end, many organizations have deployed “management networks” that allow operators to manage their servers and network infrastructure without the need for physical access to the equipment.  In some cases, access to these management networks is provided through a VPN service over the Internet.  This begs the question – what does an administrator do if the problem interferes with connectivity to the management network?  Is the only option available to fall back to physical access to the infrastructure?  If your network connection is offline, how can you receive alerts about a problem?

The first goal of this project is to evaluate a couple different methods of accessing a management network without needing physical access.  The second goal was to establish a method of delivering Nagios alerts in the event that upstream network connectivity is offline.  It should be stated that on neither of these fronts is this document to be considered complete, authoritative, nor exhaustive.  There are no doubt many other methods of doing both of the above without using the methods described herein.

Continue reading