Pages

Wednesday, December 22, 2010

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.

Wednesday, November 24, 2010

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.

Wednesday, November 10, 2010

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.

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:

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:

Wednesday, October 27, 2010

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.

Wednesday, October 6, 2010

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.

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

( ) 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

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.

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)