IPv6 Tutorial: The overview

I will start from the beginning; two weeks ago I wrote a post claiming that IPv4 is depleting and IPv6 is coming soon; and since we are considering deploying IPv6 soon in our network, I thought it might be useful to write about IPv6 migration and transition strategies. Although, this is important but I think [...] No related posts. Related posts brought to you by Yet Another Related Posts Plugin.

vPC and VSS features and Comparison

Seems like other than IPv6 allot of the talk lately (in the Datacenter anyways) is about MEC, or multi-chassis etherchannel. Using something like this in the aggregation part of the Datacenter not...

[[ Summary content only, you can read everything now, just visit the site for full story ]]

How Network Operators can cooperate: the NLNOG RING

In December 2010 I started a project with a few friends to make life for network engineers in the Netherlands better.

I noticed that there are a lot of friendly 'shell access' exchange deals between dutch network operators. This makes it easier for parties to debug network issues and troubleshoot from the outside. A point of view outside your network is absolutely essential, seeing what others see is a useful thing for a variety of network problems. Well known examples are "it works for even numbered ip address, but not for odd numbered ip address via this and this route".

The NLNOG RING tries to do this in a more organized way, basically the deal is "donate 1 machine, and gain access to all other machines in the ring". So far already 10 organisations are participating.

How useful is the ring exactly? A very nice example is executing a traceroute from ten different autonomous systems: nlnog ring example.

More information about the NLNOG RING can be found on the website we've launched today: ring.nlnog.net.

Ticket #16 – Repubished

Next ticket, Ticket 17, which will be about IGP and EEM will be published on CCIEFlyer.com, then it will be republished here again. ... • R1 is configured with redundant bidirectional connection between R3 and R4's Lo0. ... • R1 is using NAT to allow connectivity, exposing R3 as and 

L2 is now in the TS section

L2 is now in the TS section of the R&S lab: https://learningnetwork.cisco.com/docs/DOC-10859 ...L2 is in the TS workbook from day one because the TS workbook was written not just to prepare the students for the TS section of the lab, but also to summarize, test and sharpen the skills of the CCIE R&S students. Please notice that although the TS section is the first section of the lab, I recommend to practice the TS section after doing technology focused labs and moc labs.

Troubleshooting OSPFv2 Neighbors (Part 1)

Tackling one of the simplest OSPFv2 adjacency problems to the trained eye. Yet, it’s really incredible how often it can escape even the most seasoned veteran. Getting right to the point,...

[[ Summary content only, you can read everything now, just visit the site for full story ]]

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 http://snijders-it.nl/ios-rss/.

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.

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 Continue reading

Ticket #15 – Repubished

I am reposting here Lab 15, which was published on ccieflyer.com. Next ticket, Ticket 16, which will be about IP services will be published on CCIEFlyer.com, then it will be republished here again. ...The network was configured with multicast-helper to transport the RIP broadcast over the multicast network to R6.

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

Solaris as an Open Source alternative to Linux

When I left Solaris after the Sun/Oracle marger, it was because I wanted to try some new things in life possibly based on OpenSolaris. I had led Solaris in networking and network virtualization space for a long time and wanted to make a bigger mark in that space compared to what Oracle might have wanted. But my hope was that Solaris as a Open Source Operating System would continue to prosper and I could possibly use OpenSolaris as a base for whatever I decided to do next. Well, the exodus from Solaris has continued over the past few months and now Mike has also decided to call it quits. Mike was one of my counterparts, running the storage side of the house (other leaders in storage and filesystem space, like Jeff and Bryan had already bailed out of Solaris few months after I left).

So at this point, I am forced to consider the fact that Solaris and OpenSolaris are on the brink of death unless something serious is done about it. Having spent so much time and energy in last 15 years on Solaris (including bringing it back from life after the last tech bust when Solaris had been Continue reading

IS-IS Single-Topology vs Multi-Topology

Today I’m covering a little topic that seems to trouble some people. Mainly because IS-IS is really only used in provider environments, but I happen to like it. It’s a fairly stable...

[[ Summary content only, you can read everything now, just visit the site for full story ]]

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 Continue reading

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 Continue reading

eBGP triggered blackhole for customers

Very many large scale transit providers, if not most of them support eBGP remote triggered blackhole via separate multihop eBGP session. I suspect this is, because they've used for very long time single shared route-map for transit customers, and it is not immediately obvious how you can support blackholing without customer specific route-map. Requiring customer specific route-map would probably be less than minor change in their provisioning systems. However, it is perfectly doable and same idea works just the same in JunOS and IOS, here is pseudoIOShy example how to do it:

router bgp N neighbor eBGP peer-group neighbor eBGP route-map eBGP-IN in neihgbor eBGP disable-connected-check neighbor CUSTIP peer-group eBGP neighbor CUSTIP prefix-list C-CUSTID-IN in ! route-map eBGP-IN permit 100 match community BLACKHOLE set ip next-hop BLACKHOLE set community BLACKHOLE additive route-map eBGP-IN permit 200 match ip address prefix-list eBGP-TRANSIT-FULL set community full-transit additive route-map eBGP-IN permit 300 match ip address prefix-list eBGP-TRANSIT-PARTIAL set comunity partial-transit additive route-map eBGP-IN permit 400 set ip address prefix-list eBGP-PUNCHOLE set community no-export additive ! ip prefix-list C-CUSTID-IN permit le 32 ip prefix-list C-CUSTID-IN permit le 32 ip prefix-list eBGP-TRANSIT-FULL permit ip prefix-list eBGP-PUNCHOLE Continue reading