When you configure OSPF network statements, IOS orders them most-specific to least-specific then does a top-to-bottom match of the interfaces. It doesn’t matter which order you put them in, the configuration will always be ordered with the longest prefix matches first.  Lab time!

I have router R1 with these interfaces.

R1#sh ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            10.0.0.1        YES manual up                    up
FastEthernet0/1            unassigned      YES unset  administratively down down
Loopback100                10.0.101.1      YES manual up                    up
Loopback200                10.2.101.1      YES manual up                    up

Let’s add the OSPF configuration where 10.0.0.0/8 is in area 2 then check what OSPF thinks is happening.

While walking through the World of Solutions, we ran across a big black truck with lots of antennas all over it.  It was obviously an emergency communications vehicle of some kind, but I was really surprised to see it was a Cisco truck.  It turns out that Cisco has a Tactical Operations group (Twitter) that was formed to provide disaster responders with much-needed communications for EMAs, fire, police, medical, etc.

The big truck was the NERV - the Network Emergency Response Vehicle (PDF link).  It’s full of traditional HF, VHF, and UHF radios that the ham radio operators usually bring to these disasters.  This is a necessity when all phones, cell, and Internet are down.  It could be the only way fire fighters are able to call for reinforcements or the only way a hospital can call for more supplies.  The NERV, though, takes it to the next level.  On top of the radio gear, it is equipped with satellite uplinks for Internet access, wifi, and digital voice and video through UCS Express, IP phones, and Telepresence.  Analog voice is always the first method of communications restored via battery- or generator-powered gear, but an area will eventually need a network with voice and video.  That’s where the NERV comes in.

Corrections are always welcome.

Broadcast : Think an Ethernet segement

DR/BDR? : Yes Default hello interval : 10 sec Neighbor config required? : No

Point-to-point : Physical point-to-point links, frame-relay point-to-point subifs

DR/BDR? : No Default hello interval : 10 sec Neighbor config required? : No

Nonbroadcast Multiaccess : Frame-relay multipoint or physical

DR/BDR? : Yes Default hello interval : 30 sec Neighbor config required? : Yes

Point-to-multipoint : Partial mesh networks like a frame-relay hub-and-spoke configuration

I’m way behind in talking about this, but Jeremy Stretch over at Packetlife.net has a community lab that is free to use.  This is a great resource for those of us who are too poor to have their own physical devices for Cisco studies.  All you need is an account on the site and a sense of community.

There are two labs to reserve, and each contains a firewall, routers, and switches.  This is plenty of stuff to get your feet wet with the gear, let you research some functionality that Cisco promised is great, and to lab out something you’re looking to implement.  The lab is offered for free, but Jeremy is giving his time and money for this lab.  I think it would be a great idea to drop a few dollars to him via his donate link if you use his stuff.   If you’re a regular user and don’t donate, I ask that you do a moral inventory on yourself so you might see just how bad you are being.

This is a great one that I have to share.

A couple of coworkers walk in today and ask for some help on an issue.  It seems that a business unit was having latency problems with a web app, and, after research by the product team and sysadmins, nothing wrong could be found.  Lots of sites use the product, and only this one was having issues.  Also, the site was having no problems getting to other web sites and apps like Yahoo! or Google.