This week's tip will take a brief look at the implementation of OSPF from the perspective of two well known vendors: Cisco and Juniper. We will take a look at not only the obvious configuration differences which exist, but also the slight differences in vendor interpretation of the IETF documentation which you'll need to know when attempting multi-vendor implementations.
Do you know the standards?
Requires Free Membership to View
OSPF version 2 is defined in RFC
2328. Like all protocol standards it details every aspect of the protocol. And like all
protocol standards it leaves just enough room for vendor interpretation. Here is an example from
RFC 2328 that outlines the use of a hello protocol for establishing adjacencies:
The Hello Protocol is responsible for establishing and maintaining neighbor relationships. It also ensures that communication between neighbors is bidirectional. Hello packets are sent periodically out all router interfaces. Bidirectional communication is indicated when the router sees itself listed in the neighbor's Hello Packet. On broadcast and NBMA networks, the Hello Protocol elects a Designated Router for the network. (Section 7.1)
Notice what is left open to interpretation. The line which states packets are sent out on all interfaces at periodic intervals does not in fact give us the interval itself, although further within the document there are a few suggestions. So each vendor now has decisions to make on how often Hello Packets are sent out on a router's various interfaces. My point in all of this is to identify why certain protocol or technology implementations between vendors can be different. Generally, the first one to implement the standard paves the way for the rest. Since this little detail within the Hello Packet determines whether or not OSPF speaking devices will create a neighbor relationship, both Cisco and Juniper have identical timers on Broadcast/Non-Broadcast interfaces.
Some subtle differences
Because OSPF has several checks and balances in regards to neighbor adjacencies, and because those
adjacencies are essential for actual routing, their defaults remain the same between the two
vendors. These include authentication (except in the case of OSPFv3), hello/dead intervals and area
types. One note about authentication: in Cisco IOS when area authentication (either MD5 or Simple)
is configured at the protocol level it triggers the bit in the AuType field within the header. This
means that without a like configuration on neighboring routers, adjacencies will not be created.
Juniper does not, at the protocol level, trigger the AuType bit unless the key is configured within
the interface.
In the examples below, both configurations will change the AuType to 2 which would satisfy one of the adjacency requirements. Of course if we were trying to get these two to "neighbor-up" it wouldn't work.
Cisco Example
router ospf 1 area 0.0.0.0 authentication message-digest end
Juniper Example
protocols ospf { area 0.0.0.0 { authentication-type md5; interface ge1/0/1.0{ authentication { md5 1 key juniper; } } } }
Another difference lies within the functions of stub ABRs. This is a classic difference between routers made for enterprise operations and routers made for the provider industry. In Cisco IOS a stub router which is configured to either allow summary route or inject just one summary (totally stubby) will do just that. In Juniper land, that particular function is optional and must be configured using the "default-metric" command.
On broadcast/multi-access media such as Ethernet, OSPF elects a Designated Router (DR) to act as the originator of network advertisements and synchronizing of link-state databases. The election process involves the comparison of OSPF priority values and Router-IDs. On a data link the highest priority wins the election. Each vendor has a default priority and each vendor recognizes that a priority of 0 does not allow that interface to be considered in an election. Cisco has a default priority of 1 and Juniper has a default of 128. This means of course, that if you put Cisco and Juniper on the same broadcast segment, Juniper will by default become the designated router.
Real world application
Knowing the vendor's interpretation and application of a complex protocol such as OSPF can help
lead you to successful multi-vendor environments. I touched upon some of the subtle differences
between Cisco and Juniper but, of course, there are many more. Features which affect the functions
of sub-components such as HelloIntervals and AuTypes can have adverse and unexpected results if
used without proper planning. Remember that "standards" documentation such as RFC's can outline
many details about the workings of a protocol, but there are always those "open to interpretation"
sections as well.
Doug Downer (CCIE #9848) is a Sr. Consultant with Callisma, INC, a wholly owned subsidiary of SBC Communications. Doug has over 7 years in the industry and currently provides high level business and technology consulting for various federal clients in the Washington D.C. area. He can be reached at ddowner@callisma.com.
This was first published in December 2004