att_abstract={{Knowing what paths packets are taking within a network is crucial for several network management tasks. When the network is running OSPF, determining paths is supposedly straight-forward, since OSPF is basically a link-state protocol, and with link-state protocols, a packet follows the shortest path in terms of link weights from its source to the destination. However, OSPF allows a network to be divided into areas for scalability, and this makes it more than a link-state protocol. As a result, though packets still follow shortest paths within an area, this is not guaranteed to be the case across areas. In fact, paths followed by packets with areas can often be unexpected and non-intuitive. Some recent extensions to OSPF, namely multi-area adjacencies (RFC 5185) and alternative implementation of border routers (RFC 3509), have further exacerbated the situation. This presentation illustrates such cases with examples, while providing insights into why OSPF paths can look so strange with areas. }},
	att_authors={da1287, cl9862, as1818},
	att_copyright_notice={{(c) ACM, 2012. This is the author's version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in NANOG 54 {{, 2012-02-06}}.
	att_tags={OSPF, Intra-domain routing, OSPF areas},
	author={David Applegate and Carsten Lund and Aman Shaikh},
	institution={{NANOG 54}},
	title={{Why OSPF paths aren�t always shortest}},