Skip to content

Packet Over SONET: Does It Have A Use?

2011/11/03

I’m contributing to the packetpushers.net blog, where I’ve posted some Packet Over SONET analysis.  Feel free to check it out.  I’ll post a link after it goes up.

Update:

Packet Pushers has published my blog.  Visit: http://packetpushers.net/packet-over-sonet-good-for-nothin/

My Favorite Error Messages

2011/10/27

On a 6500 with the Sup7 I received the following…

%BGP-6-BIGCHUNK: Big chunk pool request (454) for aspath. Replenishing with malloc

Is that “malloc” or “malice”?  I have to wonder.

On an IOS router…

Feb  6 12:19:23.370: ISAKMP:(1019):deleting node -898763971
  error TRUE reason "Delete Larval"

You get this messages when you have a lot of dead leaves and moisture surrounding your router.

And the final error message is not an error message but a usefull command.  Man, I hate it when my peers fail me!

Router(config)#ntp access-group serve-only 2 ?
  kod  Send a Kiss-o-Death packet for failing peers
  <cr>

OSPF Router-ID

2011/10/21

OSPF is a link-state routing protocol.  That makes it vastly superior to EIGRP (go ahead and comment!)  Each node requires a unique ID, which is just a 32-bit number.  It’s unfortunate that Cisco routers (and other vendors) represent it as a dotted decimal number so it looks just like an IP address.  That’s the start of the confusion.

Here’s an example of the problem.  The show ip ospf database router command is the starting point for inspecting the configuration of the network.  In this truncated output we have one router with one loopback address and one stub network of 10.40.1.0/24.

Router#show ip ospf database router
            OSPF Router with ID (10.40.0.1) (Process ID 1)
                Router Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 1798
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 10.40.0.1
  Advertising Router: 10.40.0.1
  LS Seq Number: 80009BCC
  Checksum: 0xA5A5
  Length: 60
  AS Boundary Router

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.40.0.1
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.40.1.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

Without manually specifying a router-id the router will just select the highest IP address assigned to an interface.  That’s not stable (interface addresses can change) so Cisco will select an available loopback address before selecting an address from other interfaces.  That makes the process a little more deterministic.

Problem 1:
The loopback address gets added to the database as a stub network (as you can see in the above output as 10.40.0.1/32.)  If you’re running a network with n number of routers that’s n additional stub networks in your database.  That’s not a big deal; we have lots of DRAM in modern day routers.  It’s bad in a sense that a good engineer likes things clean, concise and minimal.  It also makes it more difficult if you are searching through the database to confirm its proper operation (or searching for a problem.)

Yes, I know sometimes you need a loopback address anyway, e.g., BGP peering, GRE source addresses, etc.  Yes, I know you can selectively run the OSPF process on certain interfaces and not select the loopback.  That potentially means multiple network statements instead of one, which sometimes creates more complexity than necessary.

Problem 2:
The router-id looks like an IP address!  Furthermore, it matches one of our stub networks.  This was quite confusing for me when I first started working with the OSPF show commands.  It could have been displayed as 170,393,601 or 0x10400001, which would have been the same 32-bit number.  Instead, they decided to be confusing.

Solution:
We can specify the router-id manually.  Plenty of network nerds have found this command but let’s use it to do something creative.  We can’t configure an interface with the address 0.0.0.1/24 (RFC 5735) but we can use that 32-bit number as a router-id.  Now the output looks like the following.

Router#show ip ospf database router
            OSPF Router with ID (0.0.0.1) (Process ID 1)
                Router Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 1798
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 0.0.0.1
  Advertising Router: 0.0.0.1
  LS Seq Number: 80009BCC
  Checksum: 0xA5A5
  Length: 60
  AS Boundary Router
  Number of Links: 3

   Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.40.1.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

It pops.  You can visually pick out quickly what part of the output is the router-id and what part is referencing the networks.   We also lost that pesky loopback address from the database.  Clean.

Operational Surprise #1
Can we use 0.0.0.0 as a router-id?  It would be nice to start at the beginning.  Nope.  Invalid.

Operational Surprise #2
Some vendors are not as permissive as Cisco for router-id.  I just worked with a vendor who was using the HP A7500 switches.  This switch is from the 3Com acquisition.  I asked the vendor to use router-id 0.0.0.2, which the A7500 said was invalid.  We unfortunately had to use router-id 1.0.0.2 and it worked fine.

Summary
So far these “weird” looking router-ids work great.  I’ve used them on Cisco Layer-3 switches and the ASA5500 platforms without a hitch.  Does anyone else have any insights on their use?

Post 0

2011/10/20

Welcome to the Packet Forward blog where I hope to be talking about technology as we approach the singularity.  I’ll be mostly writing about computer networks with the occasional foray into operating systems and tech in general.  Please feel free to comment.