Techtip – Determining Optic connectors using Cisco IOS

Something that has frustrated me in the past is using the cumbersome method of determining the connectors required to terminate a particular optic’s fibres. We would determine the optic part code (show inventory, show module, etc) and then looked up the partcode on CCO. This was incredibly inefficient and I always felt that there had to be a way of doing this through the command line so, after many CCO documents, I found the following.

show idprom int <interface>

will show the connector type.


The following is an output from a 7600. The cards in slot 1 and 2 are LAN based (67xx) cards. The ES+ in slots 3 and 4 are Ethernet Services cards, which behaves less like a classic LAN interfaces and more like a genuine router interface, with support for CBWFQ / MQC and other features commonly found on Cisco’s software router platforms, such as a 7200.

Router#sh mod
Mod Ports Card Type                              Model              Serial No.
--- ----- -------------------------------------- ------------------ -----------
  1    8  CEF720 8 port 10GE with DFC            WS-X6708-10GE
  2   24  CEF720 24 port 1000mb SFP              WS-X6724-SFP
  3    2  7600 ES+                               7600-ES+2TG3CXL
  4    4  7600 ES+T                              76-ES+T-4TG

Some examples (filtered just to show the relevant connector lines):

Router#show idprom int tengig 1/1 | i connector
Optical connector type               :0x1 =SC
Router#show idprom int gig 2/1 | i Connector   
 Connector         : LC [0x07]
Router#show idprom int tengig 3/1 | i Connector
  Connector type                            = LC.
Router#show idprom int tengig 4/1 | i Connector
  Connector type                            = LC.


CRS is (of course) different:

RP/0/RP0/CPU0:Router#show diag 0/0/CPU0  | i Connector
Fri Jul  1 13:45:21.768 UTC
  Connector type:  SC

With these commands you’ll be able to determine what your connector types are without referring to product sheets.


Cisco LISP – Multihoming

This is part of a series of posts – The Lisp Papers.


One of the key functions of the LISP implementation is baked-in multihoming and traffic engineering. EID spaces can be connected to the RLOC environment via several ETRs. The ETR responding to the querying ITR can offer a list of ETRs to be used. The LISP designers had two objectives when they were determining how this should function.

Firstly, the design should offer a preference of some ETRs over others. This allows some systems to act as primary ETRs and others as backups. This is implemented using the Priority field, with lower Priority systems being (counterintuitively) preferable over higher systems.

Secondly, the design should allow traffic distribution to be controlled. Once the priority comparison has taken place and, assuming that a number of systems with the lowest priority have been identified, the weight is considered. Traffic will be distributed between ETRs in the ratio of their weights. For example, ETR A might have a weight of 80 and ETR B might have a weight of 20. Traffic will be distributed between them in a ratio of 4:1.

Cisco LISP Network

In order to fully explore the design, the topology used in the previous post has been modified as follows:

In this case, the “MF” device combines Mapping Server and Mapping Resolver functionality (MF = Multi-Function). In addition, it peers with xTR3.1 and xTR3.2, which act as dual homing xTRs for Customer C. In this topology, xTR1 and xTR2 register with MS and xTR3.1 and xTR3.2 with MF for Mapping Server functionality. xTR1 and xTR2 use MR and xTR3.1 and xTR3.2 use MF to resolve EID to RLOC addresses. MF has GRE tunnels and BGP peers to both MS and MR. This allows the EID prefixes to be disseminated throughout the network and for Mapping Requests to to be delivered to the correct RLOC address.

Design thought

This is a far more realistic topology than the one considered in the previous post for several reasons. The dual xTRs offer a resilient connection to Customer C. There remains a single point of failure in MF, which could be resolved by deploying a second MF and attaching it to a separate part of the core network. The MS and MR functionality are combined, which makes sense at a superficial level. This is for the practical reason that to separate the functions and provide resilience would require 4 systems (resilient MS and resilient MR), which would probably be an overkill for all but the largest environments. Perhaps there are scaling, security or topological reasons to separate MS and MR functionality.

The Mapping Request is routed over the ALT network, as described in the previous post, to one of the RLOCs registered for a specific EID space. The xTR that this corresponds to will respond with a list of RLOCs with associated priorities and weights.

MF’s LISP configuration looks as follows:

router lisp
 site CustomerC
  authentication-key cisco
  eid-prefix accept-more-specifics
 ipv4 map-server
 ipv4 map-resolver
 ipv4 alt-vrf LISP

xTR3.1 and xTR3.2 have matching configurations:

router lisp
!database mapping for xTR3.1
 database-mapping priority 2 weight 50
!database mapping for xTR3.2
 database-mapping priority 2 weight 50
!Configuring MF's loopback as Mapping Resolver
 ipv4 itr map-resolver
 ipv4 itr
!Configuring MF's loopback as Mapping Server
 ipv4 etr map-server key cisco
 ipv4 etr

Pitfall alert

ETRs must be configured with all the EID address space database mappings for which they are authoritative for. In the above example, xTR3.1 is configured with database mappings for both xTR3.1 and xTR3.2. This makes sense when you consider that any ETR could respond to a mapping request and will need to respond with the addresses, priority and weight for the associated ETR RLOC addresses for a required EID address space. If you only configure xTR3.1 with the database mappings for xTR3.1, it will only respond with its own RLOC address and no load-balancing or resilience will be delivered.

Examining the LISP EID database table on MF shows that both xTRs have registered with it:

MF#sh lisp site detail 
LISP Site Registration Information

Site name: CustomerC
Allowed configured locators: any
Allowed EID-prefixes:
    First registered:     00:47:03
    Routing table tag:    0x0
    Origin:               Configuration, accepting more specifics
    Registration errors:  
      Authentication failures:   0
      Allowed locators mismatch: 0
    ETR, last registered 00:00:41, no proxy-reply, no map-notify
                   TTL 1d00h
      Locator       Local  State      Pri/Wgt  no     up           2/50  yes    up           2/50 
    ETR, last registered 00:00:53, no proxy-reply, no map-notify
                   TTL 1d00h
      Locator       Local  State      Pri/Wgt  yes    up           2/50  no     up           2/50 

If Customer A wishes to communicate with Customer C, xTR1 will send a Mapping Request to MR. MR will forward this over the ALT network, via the GRE tunnel between itself and MF, to the Customer C address, as detailed in the following packet trace:

Frame 1: 126 bytes on wire (1008 bits), 126 bytes captured (1008 bits)
Ethernet II, Src: ca:00:16:79:00:8c (ca:00:16:79:00:8c), Dst: ca:03:16:79:00:1c (ca:03:16:79:00:1c)
Internet Protocol, Src: (, Dst: (
Generic Routing Encapsulation (IP)
Internet Protocol, Src: (, Dst: (
User Datagram Protocol, Src Port: lisp-control (4342), Dst Port: lisp-control (4342)
Locator/ID Separation Protocol
    0001 .... .... .... .... .... = Type: Map-Request (1)
    .... 0... .... .... .... .... = A bit (Authoritative): Not set
    .... .1.. .... .... .... .... = M bit (Map-Reply present): Set
    .... ..0. .... .... .... .... = P bit (Probe): Not set
    .... ...0 .... .... .... .... = S bit (Solicit-Map-Request): Not set
    .... .... 0... .... .... .... = p bit (Proxy ITR): Not set
    .... .... .0.. .... .... .... = s bit (SMR-invoked): Not set
    .... .... ..00 0000 000. .... = Reserved bits: 0x000000
    .... .... .... .... ...0 0000 = ITR-RLOC Count: 0
    Record Count: 1
    Nonce: 0x0f5c25e246fd29d7
    Source EID AFI: 1
    Source EID: (
    ITR-RLOC 1:
        ITR-RLOC-AFI: 1
        ITR-RLOC Address: (
    Record 1:
        Reserved bits: 0x00
        Prefix length: 32
        Prefix AFI: 1
    Map-Reply record
        EID prefix:, TTL: 1440, Authoritative, No-Action
            0000 .... .... .... = Reserved: 0x0000
            .... 0000 0000 0000 = Mapping Version: 0
            Local RLOC:, Reachable, Priority/Weight: 2/50, Multicast Priority/Weight: 255/0

You will notice that the above packet trace contains a GRE header sourced by MR and destined to MF. This is because the packet capture occured between Core and MF. The response below from xTR3.1 is not sent via the ALT (therefore no GRE header) and includes two RLOCs, a local RLOC (for xTR3.1) and an additional RLOC (xTR3.2):

Frame 2: 94 bytes on wire (752 bits), 94 bytes captured (752 bits)
Ethernet II, Src: ca:03:16:79:00:1c (ca:03:16:79:00:1c), Dst: ca:00:16:79:00:8c (ca:00:16:79:00:8c)
Internet Protocol, Src: (, Dst: (
User Datagram Protocol, Src Port: lisp-control (4342), Dst Port: lisp-control (4342)
Locator/ID Separation Protocol
    0010 .... .... .... .... .... = Type: Map-Reply (2)
    .... 0... .... .... .... .... = P bit (Probe): Not set
    .... .0.. .... .... .... .... = E bit (Echo-Nonce locator reachability algorithm enabled): Not set
    .... ..00 0000 0000 0000 0000 = Reserved bits: 0x000000
    Record Count: 1
    Nonce: 0x0f5c25e246fd29d7
    EID prefix:, TTL: 1440, Authoritative, No-Action
        0000 .... .... .... = Reserved: 0x0000
        .... 0000 0000 0000 = Mapping Version: 0
        Local RLOC:, Reachable, Priority/Weight: 2/50, Multicast Priority/Weight: 255/0
        RLOC:, Reachable, Priority/Weight: 2/50, Multicast Priority/Weight: 255/0

Use the following table to decipher the traces, or for more detail, refer to the detailed diagram and configurations:

Customer CEID10.1.0.255

Examining the FIB on xTR1 shows that both RLOCs are used:

xTR1#sh ip cef
  nexthop Null0
xTR1#sh ip cef det, epoch 0, flags subtree context, check lisp eligibility
  SC owned: LISP remote EID - locator status bits 0x00000003
  LISP remote EID: 4 packets 400 bytes fwd action encap
  LISP source path list
    nexthop LISP0
    nexthop LISP0
  2 IPL sources [active source]
   Dependent covered prefix type inherit cover
  recursive via
    attached to Null0

You might have observed that the interface LISP0 on xTR1 has an extra line of config.

interface LISP0
 ip load-sharing per-packet

This will share packets in a round-robin fashion between xTR3.1 and xTR3.2. This is probably not desirable as using different paths within a stream could cause out of sequence errors and excessive retransmissions, which is why the default is per-destination.


In the networks of today, load-balancing and resilience is predominantly delivered by the crude tools of deaggregation and AS Path prepending. LISP offers a much more subtle and manageable toolkit in a way that doesn’t beggar thy neighbour.


My top 5 tools

I regularly use tools in my workaday life. The following 5 tools are those that I wouldn’t want to work without.

5 – KeePass Password Safe

As the recent Gawker password leak has proved, using one password everywhere is not smart. I used to use 4 passwords. The first was a throwaway, used anywhere where I didn’t mind someone gaining access. Make me use a password to make a comment on Gawker and out comes the old favourite. Funnily enough, it was actually rather similar to the number 1 password revealed by the gawker hack (although not the same, still uppercase and lowercase letters and numbers). I used this for anything I didn’t care about. Then I had my email password. This I used on all my email accounts (and isn’t it ridiculous how many we have these days), twitter, facebook, etc. Then I had my SECURE password. This was something I’ve been using for about 10 years, and only for money sites, like ebay, paypal, banking, Amazon, etc. Finally, I had my PC login password.

However, a couple years ago I decided that this wasn’t really secure enough. So I did a little research into password safes. I had 3 requirements.

  1. It had to be open source. I don’t mind paying for software, but really don’t believe that security software should be closed source. It should be open to scrutiny. Which, of course, is a rule I break in tool number 1 below. But I’m pragmatic, not dogmatic, which sounds better than saying “I know I’m a hypocrite”.
  2. It had to be portable. That is to say, it had to run in a secure fashion from a USB stick on any machine I might have in front of me, without installation.
  3. It had to be supported by both Mac and Windows

KeePass does all of this. A master password is used to access a password database, and I use the Savernova password card for the database password. This uses a random jumble of characters and letters laid out on an alphanumeric grid. Select a starting point and count off the number of letters.

What’s great about this system is:

  1. Every site uses a unique, long and secure password. One website being compromised will not result in a cascade of compromised sites. Just search acacia berries on twitter to see gawker users’ twitter accounts compromised by the recent hacks.
  2. The password is never typed – this avoids key loggers (likely for anyone) or even laser microphone and acoustic snooping (less likely).
  3. This is a form of two-factor security. Something I know (location on password sheet) and something I have (password sheet and database). Of course, you might remember your master password (good going if it is over 20 characters) but you will never remember the passwords you use for an individual site, as you never type it.
  4. When you have to change your password every couple days by overzealous sysadmins, it won’t affect you. You didn’t know the previous one anyway.

Of course, backing up your password database is crucial. Lose that, and you lose everything! Backing up the database and Savernova password file is fine, as it is just a random jumble unless you know where to start.

KeePass runs on a whole mass of different systems, including my Blackberry.

4 – Notepad++

Another great tool is Notepad++. Tabbed windows, language detection, syntax highlighting and multiple undos (by itself an improvement over notepad sans ++) are just some of the reasons I love this tool for configuration preparation. If you’ve developed a lot of config scripts using windows notepad, you’ll know the experience of accidentally highlighting some code, typing something, which deletes the code and then messing up the undelete. With notepad, you only get one. With notepad++, you get a lot.

3 – Beyond Compare

Every single change I do, I use Beyond Compare. Quite simply, this is the single best tool I use to ensure that I haven’t gone nuts during a change.

My personal change process is:

  1. I open a log file to log my change. SecureCRT does this automatically for me – see below.
  2. I display the starting configuration which is captured into the log
  3. I make the change.
  4. I display the changed configuration which is captured into the log

I then take the start configuration and changed configuration and do a diff using Beyond Compare. This diff can be saved as an HTML file and sent to the change management / operations team after the change. Rollback is simply undoing all of the configuration change.

I also use Beyond Compare for paired-device comparisons. Dual-homed sites often use resilient routers to terminate sites. I have wondered why a virtual router protocol hasn’t been developed. I don’t mean a First Hop Redundancy Protocol (a.k.a. HSRP / VRRP), but rather something like 6500 VSS or ASA failover, but for software routers like the 7200s. Without this, there are always opportunities for these paired devices’ configs getting out of sync. Use Beyond Compare for offline configuration comparisons.

Another use is for comparing routers that have a similar function at different locations. P routers at one location should have similar IS-IS configuration. PE routers should probably peer with route reflectors in a similar way. Redundant route reflectors should be very similar.

A final use is with troubleshooting. Why is one router misbehaving? I’m no IOS-XR expert but recently I fed the config of one working and one faulty P-node CRS into Beyond Compare and found the offending line of code in minutes.

2 – GNS3

It never fails to surprise me the number of environments that don’t have a solid lab to trial changes. I often use GNS3 to ensure that my config is solid. It is also really useful to figure out how new IOS features operate.

It isn’t rock solid as anyone who uses it for any length of time would attest to. For example, I have found that BFD doesn’t work on Dynamips 0.2.8. (the current version used by GNS3). It is, however, something that I really wouldn’t want to live without. Most people use it, so I don’t need to over-elaborate. Greg Ferro over at Etherealmind suggests that we should be getting this functionality from our vendors and I wholeheartedly agree. Until we do, GNS3 is as good as it gets.

1 – SecureCRT

Without a doubt, the most important software that I use. Of course, it isn’t free. However, until Putty allows me to define the right-click action, I won’t consider using it. Hopefully, this won’t inspire a war à la vi versus emacs. Ever clicked a screen and pasted a whole lot of stuff to the wrong router by accident? I have, using Putty.

5 more reasons why SecureCRT is brilliant:

  1. Tabbed session. Putty Connection Manager provides something similar, but I found it clunky. SecureCRT provides per-session settings overrides, multiple session editiong, entire folder (containing any number of sessions) launching and more.
  2. Dynamip port forwarding and Socks proxy support. This is fabulous for connecting through bastion / jump hosts.
  3. Scripting in jscript, vbscript, perlscript or python.
  4. Support for SFTP, SSH1 and SSH2, Telnet, serial and IPv6.
  5. Autologging. Every session gets recorded automatically to a new log file.
  6. Now there is support for Macs.
  7. Portability is possible using U3. With some companies, installing your own software isn’t an option. ThatHowever, if the company is really security conscious, they may have disabled USB drives. If this results in me not being able to use SecureCRT, I would have to have a chat with the desktop support team. The next time they insist on that switch port being opened urgently to bring that critical service on-line I would explain how much more efficient I could be if they installed my software.

Okay – so I really couldn’t stop myself at just 5. The above list might also be partially covered with software like teraterm, putty, iterm or other terminal software. None do all or as well as SecureCRT. I am a fan. So much so that I feel  elaborating on point 2 and 3 may require an entire post. I’ll leave that for next time.


Internet Routing Table – the ugly

So, is it getting worse?

Over the past few posts (the good and the bad), I have considered the various causes for a non-optimal Internet Routing Table. And now on to the question of whether it is getting worse.

Enterprise deaggregation (click for full size)

The graph above (source) shows the deaggregation by Enterprise ASes. Enterprises represent the vast majority of the edge of the Internet. As such, they are by far the largest source of deaggregation. According to this, the level of deaggregation has not increased significantly.

However, the following graph (source) shows a significant increase in the deaggregation factor.

Deaggregation by RIR

(click for full size)

The discrepancy appears to be as a result of definition. The 1st graph is based on allocations (maximum aggregation is bound by RIR allocation size) , while the second is based on best-case aggregation (idealised aggregation to maximum possible per AS). These are very different. It is therefore getting worse and has increased from 1.27 in 1999 to 2.18 today. This represents an increase of over 70% in deaggregation.

What solutions are there. Well – a whole whack have been developed. However, how many are viable? This humorous post actually captures a stack of the issues.

Further Reading

BGP Aggregation & The Deaggregation Report

Evolution of Internet Address Space Deaggregation: Myths and Reality


This is part of a series of posts – The Lisp Papers.


Internet Routing Table – the bad

In the previous post, I considered the legitimate uses of deaggregation. Here are some examples of deaggregation for either indefensible reasons or through simple stupidity.

The New Internet

A deaggregation factor, developed by Philip Smith and reported in the BGP Routing Table Analysis (current prefixes / prefixes after maximum aggregation), shows to what extent an allocation is deaggregated.

Regional Internet RegistryTotal PrefixesTotal Prefixes after Maximum AggregationDeaggregation factor
The “new” Internet (APNIC – 2.92, AfriNIC – 3.95 and LACNIC – 4.22) have reasons for deaggregating but the scale is significant. For every prefix they should advertise, LACNIC’s subscribers produce 4.22 prefixes.

Fragmented address allocation

As discussed earlier, with unlimited addressing, the 35575 active ASes could be allocated a single large address block. This would be the lower bound for addressing allocations. As the address pool has shrunk, so the rules governing the allocation of addressing have tightened. The unintended consequence of this is that poorly administered and documented networks have not been able to justify large address allocations. This has meant that they have been issued with smaller and smaller blocks, and have in turn requested address allocations more frequently, all of which has been fragmented. The top 100 unaggregatable ASes (no aggregates can be created with any of their advertised addresses) add over 3k prefixes:

Unaggregateable ASes Top 100

ASAS NamePrefixesAfter Aggregation# removed
Top 100 Total3088
786JANET The JANET IP Service1901900
33668CMCS - Comcast Cable Communications, Inc.95950
158ERI-AS - Ericsson Network Systems, Inc.88880
7016CCCH-3 - Comcast Cable Communications Holding74740
3307BANETELE-NORWAY BaneTele AS (formerly Enitel)59590
17561SERVICENET-AP Internet service provision to W51510
2554IDC2554 Yahoo Japan Corporation46460
13649ASN-VINS - ViaWest46460
12312ECOTEL ecotel communication ag42420
28571Universidade de Sao Paulo - USP42420
33660CMCS - Comcast Cable Communications, Inc.42420
5413AS5413 Vialtus Solutions Ltd.39390
12654RIPE-NCC-RIS-AS RIPE NCC RIS project39390
766REDIRIS RedIRIS Autonomous System38380
29550SIMPLYTRANSIT Simply Transit Ltd37370
553BELWUE Landeshochschulnetz Baden-Wuerttemberg36360
8473BAHNHOF Bahnhof AB35350
9644SKTELECOM-NET-AS SK Telecom., Ltd.35350
29308GSD-AS Gesellschaft fuer Systemforschung35350
6079RCN-AS - RCN Corporation34340
21844THEPLANET-AS - Internet Service32320
25668CIPHERKEY - Cipherkey Exchange Corp.32320
2381WISCNET1-AS - WiscNet31310
12843TELEMAXX TelemaxX Telekommunikation GmbH Auto31310
13432ASN-CXA-LV-13432-CBS - Cox Communications Inc31310
30217DESYNC - Desync Networks31310
16445ISPACE - Wave2Wave Communications, Inc30300
25577C4L-AS C4L main AS30300
33654CMCS - Comcast Cable Communications, Inc.30300
2129HP-EUROPE-AS-TRADE Hewlett-Packard29290
2527SO-NET So-net Entertainment Corporation29290
7497CSTNET-AS-AP Computer Network Information Cen28280
9650CITEC-AU-AP QLD Government Business (IT)28280
15576NTS NTS workspace AG, Bern, Switzerland28280
16718EMBARQ-HMBL - Embarq Corporation28280
19169Telconet S.A28280
6428CDM - CDM27270
9891CSLOX-IDC-AS-AP CS LOXINFO Public Company Lim27270
12350VTX-NETWORK VTX Services SA27270
16097HLKOMM HL komm Telekommunikations GmbH27270
33665CMCS - Comcast Cable Communications, Inc.27270
46837VRCT-BOS - SunGard VeriCenter Inc27270
4691DTI Dream Train Internet Inc.26260
6171WORLDGATE - WorldGate26260
6315XMISSION - XMission, L.C.26260
17402EMBARQ-CHSK - Embarq Corporation26260
33655CMCS - Comcast Cable Communications, Inc.26260
2611BELNET AS for BELNET, The Belgian National Re25250
3265XS4ALL-NL XS4ALL25250
13000LEON-AS Leon sp. z o.o.25250
32613IWEB-AS - iWeb Technologies Inc.25250
9947SIMNET-AS-KR Simulation Multimedia Network24240
25180EXPONENTIAL-E-AS Exponential-e Ltd24240
31406ESIDE Bucharest, Romania24240
790EUNETFI EUnet Finland23230
4264CERNET-ASN-BLOCK - California Education and R23230
31313STS Serviciul de Telecomunicatii Speciale23230
31400ACCELERATED-IT Accelerated IT Services GmbH23230
33656CMCS - Comcast Cable Communications, Inc.23230
3475LANT-AFLOAT - Navy Network Information Center22220
7341VELOCITY - The Velocity Network22220
15623CYBERLINK Cyberlink AG22220
29551HGCOMP-ASN Aixit GmbH22220
3249ESTPAK Elion Enterprises Ltd.21210
12968CDP Crowley Data Poland, sp. z o.o.21210
14910EMBARQ-FTMY - Embarq Corporation21210
16245NGDC NetGroup A/S21210
20500GRIFFIN Griffin Internet European Network21210
25176AC-NET LaNet Vasterbotten Data och Tele AB21210
37914UNIVNET Advanced Software Technology & Mechat21210
47965SATLYNX_AG Satlynx AG21210
1761TGSCNET - General Services Commission20200
1811CSC-300-AS1810-AS1815 - Computer Sciences Cor20200
11252ISU-NET-AS - Idaho State University20200
14155RURAL-TELEPHONE-SVCCO - Rural Telephone Servi20200
22958FIDELITY-001 - Fidelity Access Networks, LLC20200
23481HCTC-LINK1 - Hill Country Telephone Cooperati20200
30081CACHENETWORKS - CacheNetworks, Inc.20200
31822CITY-UNIVERSITY-OF-NEW-YORK - City University20200
42652DELUNET inexio Informationstechnologie und Te20200
1741FUNETAS FUNET autonomous system19190
1901EUNETAT-AS eTel Austria Gesmbh u. CO KG19190
8680Cable & Wireless Channel Island Network19190
9167WEBPARTNER WEBPARTNER A/S is a Danish Interne19190
9708PKNU-AS Pukyong National University19190
13193ASN-NERIM Nerim SAS19190
14793API-DIGITAL - API Digital Communications Grou19190
16095JAYNET a/s19190
18117HARBOURMSP-AU-AP Harbour MSP Pty. Ltd19190


In all, over 10,000 ASes advertise 2 or more ASes of which none are aggregatable. This group of ASes add over 40k routes. The entire list of Unaggregateable ASes is available here (an up to date source is available at CIDR report)

For detailed information regarding the prefixes advertised, enter an AS here to generate an aggregation report for the AS – e.g. “786″

Poor configuration

There are two other reasons that contribute to the problem. The first is a lack of knowledge of CIDR. The application of /16 and /24 to allocated aggregates (“to match the class”) by well-meaning but misguided staff is a source of deaggregation.

Another “reason” put forward is fear of Denial of Service attacks by neighbouring ISPs falsely announcing longer prefixes. This is a beggar thy neighbour policy, as all routers have to carry these additional routes. Taken to an extreme, all networks should advertise /32s, as these could never be hijacked by longer prefixes. Of course, this would result in over a billion routes, so clearly not a serious recommendation! Even deaggregating everything to /24 will result in over 5 million prefixes.

How many prefixes do top deaggregators contribute? The top 1% of deaggregators inject 10% of the prefixes in the Internet. Deaggregating ASes contribute nearly 50% of the routing table size. At NANOG 50, the following example of routes direct from your favourite coffeemaker, Starbucks:

route-server>sh ip bgp longer-prefixes | i 98.96|98.97

*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?
*                          0 7018 ?

I’ll leave it up to you to decide whether there could be any legitimate reason for advertising their routing in this fashion.

So, we’ve looked at two categories of deaggregation, the “good” and “bad”. With a classic sense of the cliché, the next blog will consider how extensive the problem really is, a.k.a. the “ugly”.

This is part of a series of posts – The Lisp Papers.


Copyleft(ↄ) 2014. Text is available under the Creative Commons Attribution-ShareAlike license

Pattinson Consulting Limited