Wednesday, December 22, 2010

New Cisco IOS releases in an RSS feed

Over the last few days we've been spending some time on an RSS feed generator which can help you stay on top of new IOS releases. It takes regular expressions as input and can be useful for a quick search or generating an RSS feed for your favorite news reader.

The database is built upon a public md5 database Cisco publishes roughly every week. I cannot vouch for the accuracy of this information.

You can find the quick search & rss generator at

Wednesday, November 24, 2010

LISP + GETVPN as alternative for DMPVN+OSPF+GETVPN

Originally LISP was developed to address the issues and concerns raised by the growth of the internet routing table, but LISP turns out to possess appealing features that can be of interest to Service Providers like my friends at InTouch.

At the Cisco NAG2010 conference in San Jose I talked about using LISP as a transport mechanism instead of regular manual GRE tunnels or a DMVPN design. I believe that provisioning and debugging a LISP based virtual private network will be easier and simpler than current approaches.

Some fair warnings are in order here: this setup runs on beta IOS and NXOS images, this design and the configuration syntax are very likely to change a little with every IOS release, for Cisco's LISP implementation is under very active development. The most important aspect of this design is that it's not a multi-tenant architecture. Multi-tenancy will probably be available in a few months, after which I'll post an updated version with more comments on the specifics.

View the slides online at slideshare: LISP+GETVPN or download the PDF from my website: Job_Snijders-InTouch-LISP_GETVPN.pdf.

Wednesday, November 10, 2010

libvirt & KVM & unnumbered bridge setup

This is an ubuntu/debian recipe to use an 'unnumbered bridge' to save on the amount of IP addresses needed to connect your virtual machines on a libvirt host to other networks.

I'm assuming you want the host to be a router between the VM's and the external network. The advantage of this is that you can firewall traffic between the virtual machines and other networks on the host.

A setup like this can be used if your ISP provides you with a /29 and you want to be able to use every IP address out of that /29, and not waste IP's on the network, broadcast and gateway address.

This image shows the various elements involved:

The /etc/network/interfaces file on the host:
auto virbr0
iface virbr0 inet manual
  bridge-ports none
  bridge_stp off
  bridge_maxwait 1
  post-up ip route add dev virbr0
The above configuration will configure a bridge interface without an IPv4 address and route the /29 that was assigned to you by your ISP to that interface. This will force Linux to ARP for every IP from that /29 on this particular virbr0 interface.

The following virsh commands will remove the default network settings, you can enter them on a root prompt:
virsh net-destroy default
virsh net-undefine default
Virtlib's /etc/qemu-ifup script needs to be replaced with the following:
/sbin/ifconfig $1 up
/usr/sbin/brctl addif ${switch} $1
The above will make sure that any tap interface associated with a virtual machine will be added to the correct bridge. The default /etc/qemu-ifup file will try and guess the correct bridge, which is not desirable.

You can edit the XML describing the virtual machines interface with the following command: 'virsh edit NAME_OF_VM'. You could also just type this command:
virsh attach-interface NAME_OF_VM bridge virbr0
This is what the XML could like like:
<interface type="'bridge'">
  <mac address="'52:54:00:51:8b:ad'/">
  <source bridge="'virbr0'/">
  <target dev="'vnet0'/">
The last step is to configure the network settings inside the virtual machine (VM1). This is an example /etc/network/interfaces. Notice the pointtopoint statement and the subnet mask:
# The primary network interface
auto eth0
iface eth0 inet static
To wrap it all up:
  • /etc/network/interfaces on the host takes care of creating the virbr0 bridge
  • libvirt will make a vnetX interface (so don't worry about it)
  • /etc/qemu-ifup adds tap interfaces to the correct bridge when booting the virtual machine
  • thanks to ARP the machines will figure out who is where
  • /etc/network/interfaces inside the virtual machine will force traffic towards the host

I'd like to thank Sten Spans for providing some essential hints.

Wednesday, October 27, 2010

Cogent (AS174) does not have a full ipv6 table yet

As of date Cogent (AS174) still has not entered into a peering agreement with Hurricane Electric (AS6939), resulting in significantly less prefixes than most IPv6 transit providers will give you. I've compiled a list of prefixes that are missing in Cogent's table.

Most IPv6 transit providers will give you roughly 3500 prefixes, but Cogent only carries around 2500 prefixes.

If you want to be reachable from all over the world over IPv6, it's best to get a second and third IPv6 transit provider that give you a full IPv6 routing table. In other words, avoid having a Cogent-only network.

txt file: ipv6-prefixes-that-cogent-misses-as-of-27-Oct-2010.txt

Saturday, October 9, 2010

compilation of internet exchange memberlists

I'm compiling a list of internet exchange member lists. Please help expand the compilation by contributing urls to public CSV, TSV or files in other formats!

You can find it here: Internet Exchange memberlists

Wednesday, October 6, 2010

DTAG (AS3320) seems to not prefer customer routes by default

I noticed that DTAG's best path selection differs from most transit suppliers I know. Most transit providers will prefer routes received from their customers above routes they receive from peers. This type of policy ensures that traffic will flow over the most profitable links. It seems that DTAG on the other hand, by default, assigns a local preference value of 100 to every route they receive through eBGP.

It could mean that DTAG is actively turning down money by not filling up links that are sold on a 'per mbit' basis. Also, it could lead to confusion, which I'll try to explain with the following example:

You are AS65001, you buy transit from AS65555. You have a sister company (AS65002) with which you swap your full routing table. That sister company buys transit from DTAG (AS3320). DTAG and AS65555 peer with each other. AS65002 will announce the routes originated by AS65001 to DTAG.

DTAG now has to choose between two paths: a 'peering' path 65555_65001$ and a 'customer' path 65002_65001$. Both paths by default will have a local preference value of 100. So if for some reason the 'peering' path is chosen (because it's older, or the router-id of that peer is lower, or whatever) DTAG will not announce the AS65001 prefixes to its peers, because it has a 'better' path through peering. Obviously this can have impact on latency.

Fortunately, this behaviour is not set in stone. DTAG's local preference values can be influenced with communities or you can use prepending trickery.

Friday, October 1, 2010

Location / Separation Protocol Checklist

This list can be useful when assessing LISP, ILNP, RANGI, Ivip, hIPv4, NOL, CRM, LMS, GLI-Split, TIDR, EEMDP or IRON-RANGER. :-) Location / Identifier Separation Checklist:

Your post advocates a

( ) technical ( ) legislative ( ) market-based ( ) vigilante ( ) political

approach to reducing the growth of the internet routing table (e.g. the DFZ). Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws.)

( ) Requires immediate total cooperation from everybody at once
( ) There is no centralized authority that will force people to carry out your plan
( ) Requires every host to be upgraded to a newer version of their netstack
( ) Nobody wants to rewrite all applications to support your plan
( ) your mapping system consumes more memory then available on planet earth
( ) New complicated IP allocation policies must be set by the RIRs
( ) People won't give up their current allocations
( ) Your plan is incomplete or contains too much "needs to be further discussed." phrases
( ) No one can agree on the definition of an EID

Specifically, your plan fails to account for

( ) IPv4
( ) IPv6
( ) Layer-2 multi-pathing
( ) Vendor Lock-in
( ) Running code within the next 12 months
( ) Vendor bickering
( ) Jurisdictional problems
( ) Scalability
( ) Public reluctance to accept weird new forms of routing
( ) Huge existing investment in hardware, software or licences
( ) The trouble associated with changing gazillion hosts to understand your plan
( ) Willingness of users to renumber to new IP space
( ) No universal guaranteed MTU and the monster that PMTUD is
( ) Extreme profitability when abused
( ) Technically illiterate politicians
( ) The vendors have too many bugs
( ) Extreme stupidity on the part of people who do business over the Internet

and the following philosophical objections may also apply:

( ) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
( ) Any proposal that requires all routers connected to the Internet to be upgraded on the same day is unacceptable
( ) Why should we have to trust you and your claim about the locations of nodes
( ) There is no money to be made
( ) Tunnels are evil but dynamic encapsulation is okay
( ) You suffer from the "Not Invented Here"-syndrome
( ) Must have a MIB designed first

Furthermore, this is what I think about you:

( ) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your house down!

Wednesday, September 15, 2010

Re: A High-Level overview of LISP

This is a response to Petr's well articulated discussion of LISP: "A High-Level overview of LISP"

He captured some of the key points that make LISP compelling, including the discussions about hierarchical routing (and associated problems with address allocations and multi-homing), the "level of indirection" enabled by LISP - due to the separation of host addresses (EIDs) and routing locators (RLOCs) - and the "push" vs. "pull" aspects of various mapping and routing systems.

There are a several areas that I think deserve greater explanation, however. The most important is regarding the LISP mapping system. "Core routing table size reduction" was the initial focus (and instigation) of LISP. But core routers are not the only ones taking full routes, some people might want the full routing table to be available on more places to have more granular control over egress traffic. Because BGP is a "push" technology, the FIB must be populated with full routes and be available in the "forwarding path" (data plane) of packets. This leads to the need for expensive silicon and memory on each line card. Where LISP helps is in two main areas. First, the LISP ALT routing table is decoupled from expensive forwarding silicon. In a similar manner to DNS, which holds millions of entries in very cheap servers and memory, the LISP mapping system holds EID prefixes in an out-of-band control plane. And like DNS, the forwarding hardware dynamically adds only the necessary EID-to-RLOC mappings on-demand (a "pull" event) when needed. Second, this isn't just "moving the problem" from one BGP table to another. Because EIDs are decoupled from the underlying topology, there is significant opportunity for aggregation in the ALT.

Petr also mentions:

"... re-numbering the core to allow for better aggregation."
Renumbering of the core is not required at all. The core should contain only Provider Assigned addressing, which by definition are highly aggregatable. No renumbering is required whatsoever (and as demonstrated by the fairly extensive LISP network that is in operation today). The core actually has no idea that LISP exists, it's all over-the-top to the core.

Then further on this is mentioned:

"... the requirement of keeping EID space strictly hierarchical in LISP-ALT seriously impacts 'true mobility'."
This is also not the case. There is a significant difference between a home-agent in the control plane (i.e. with LISP) vs. in the data plane (like with Mobile IPv6). Because the mobility event is only updated in the control plane, the map-server doesn't need to change with the move event and a stretch of one can always be maintained. LISP actually provides the mechanisms for true mobility.

Finally, i have to respond to:

"... added complexity for companies at the 'edge' due to the need of renumbering and implementing an overlay topology."
Customers at the "edge" have no need at all to implement the LISP-ALT overlay technology. It's transparent to the end user, as they communicate with the LISP mapping system (ALT) via Map Servers and Map Resolver, basically boxes that are analogous to a DNS resolver. It's that simple. Only the Mapping Service Providers need to deploy ALT infrastructure and maintain the overlay network.

There are many "motivators" for first-adopters of LISP, as we've seen with Facebook, Cisco, and others on the LISP network, including: low OpEx multi-homing, ingress traffic engineering, prefix portability, and IPv6 transition support (not to mention many "private" LISP use-cases)

Thank you Petr, I hope you write more about LISP in the future!