DD2490 p4 20 Lecture 4: OSPF Link-state routing and Open Shortest Path First Olof Hagsand KTH CSC OSPF is the routing protocol that we deal with in most detail in this course. OSPF is a complex protocol, more so than many other protocols. Still, the main reason for going into details in OSPF is to understand the principles guiding the design of any routing protocol, most principles being general to other routing protocols.
Literature RFC 2328: Browse through Section. Section 2 gives a very good understanding of OSPF issues. The example is realistic (complex) and the section can be quite hard to get through. But it is well worth the reading. In particular, the figures can be difficult to get a grasp of since they are written in ASCII. Section 2.. can be skipped. Section 3 introduces areas to the previous example. Again, the example is quite demanding, but a thorough reading of this section will give you a good understanding of OSPF areas. Section 3.5, only the last two paragraphs, the rest discusses CIDR: you should know this already. 2 There are whole books about OSPF, but the RFC is actually quite readable.
Comparison with Distance-Vector Link-state uses a distributed database model Distance-vector uses a distributed processing model Link-state pros: More functionality due to distribution of original data, no dependency on intermediate routers Easier to troubleshoot Fast convergence: when the network changes, new routes are computed quickly Less bandwidth consuming Distance-vector pros: Less complex easier to implement and administrate Needs less memory 3 Distributed database means that a link-state protocol distributes the data-structures between all nodes. Each node then composes all datastructures into one common whole (a database) which is equal between nodes of a domain(area). All computation, eg Dijkstra is then made on the resulting database. One could in principle have used a replicated database between all peers.
Link-state routing Obtain info about locally connected links and spread this information to the neighbours. Flood this information to every router in the routing domain so that every router has knowledge of the entire network topology. Local operations: Using Dijkstra's algorithm, the shortest path to each prefix in the network is calculated Construct OSPF Routing table Merge with other routing protocols: RIB Compile forwarding table: FIB 4
N4 N 3 RT N3 RT4 8 8 7 RT5 6 8 8 8 N3 N2 N2 3 RT2 2 6 8 6 RT3 Ia 7 RT6 N4 Network example from RFC2328 Fig 2 N5 Ib 6 6 2 9 RT0 3 RT7 N H 3 0 RT9 RT2 2 N9 RT 2 N8 RT8 N6 4 N0 N7 5
N4 N 3 RT 0 0 0 N3 0 RT4 8 8 RT5 7 8 6 8 8 N3 N2 N2 3 RT2 2 RT3 8 6 6 RT6 7 External N4 Database, graphical form All routers have this db after flooding 5 Ia 7 Ib N5 N H 3 0 RT9 0 RT2 2 N0 0 N9 0 RT 2 5 3 0 N8 RT0 0 6 0 0 N6 0 RT8 4 N7 2 9 RT7 6
N4 N 3 RT 0 0 N3 0 RT4 RT5 8 8 8 N3 N2 N2 3 RT2 2 RT3 6 6 RT6 7 N4 7 Ib SPF after Dijkstra from RT6 Ia 5 N5 N H 3 0 RT9 0 RT2 2 N0 0 N9 5 3 0 RT N8 RT0 0 N6 0 RT8 4 N7 2 RT7 9 7
Building a routing table Local routing table (RIB) computed from Dijkstra shortest path calculation Next-hop routing: only nexthop router even if complete path is known Example: RT6 Local destinations Destination Next Hop Distance N RT3 0 N2 RT3 0 N3 RT3 7 N4 RT3 8 Ib * 7 Ia RT0 2 N6 RT0 8 N7 RT0 2 N8 RT0 0 N9 RT0 N0 RT0 3 N RT0 4 H RT0 2 RT5 RT5 6 RT7 RT0 8 Remote Destination Next Hop Distance N2 RT0 0 N3 RT5 4 N4 RT5 4 N5 RT0 7 8
Original OSPF requirements These original requirements were set when IETF specified OSPFv2 in the early 90s. The requirements were based on experience with distance-vector protocols: A more descriptive routing metric Link metric: -65535 Equal-cost multipath Multiple best paths: load balance Routing hierarchy Two-level routing scheme: areas Separate internal and external routes External routes can be imported from eg BGP Security Cryptographic authentication 9 These original requirements were set when IETF specified OSPFv2 in the early 90s. The requirements were based on experience with distance-vector protocols, such as RIP. IS-IS actually already existed but was not seen as an option by IS-IS since it belonged to the competing OSI protocols at the time. Some of these requirements are now of less importance, including the security extension, which is better achieved by other means. ECMP has been retro-fitted into most RIP implementations in practice. The routing hierarchy (areas) is maybe less important now as routing processors are much more powerful and can handle quite large Dijkstra routing domains.
OSPF Network Topology Area 0 is the backbone area. All (inter-area) traffic goes via the backbone. All other areas are connected to the backbone (-level hierarchy) An Area Border Router (ABR) has one interface in each area. An AS Boundary Router (ASBR) redistributes external routes Backbone router at least one interface in backbone area External AS boundary router: External routing Area Border Router: Interfaces in different areas Area AS2 0 Internal router All areas connected to backbone area Area Area 2 Area 3 Internal router + ASBR External 0 Compare this to IS-IS areas: the area border is 'passes through' routers in OSPF and links in IS-IS. The routing state therefore gets more complicated in OSPF since every router may be member of several areas. Not so in ISIS. Note that an ASBR does not really have to be a border router in the AS/BGP sense. It is actually only a redistributing router that imports external routes from another protocol. External routes can be redistributed static routes, RIP routes, or something else. A 'true' ASBR would be a router that runs BGP and peers externally to another BGP speaker in a separate AS. Note also that an ASBR does not have to be in the backbone. That is, a router that imports routes to OSPF can be within a non-backbone area as is shown in Area 3 in the figure.
Protocol parts and messages. The hello protocol Detection of neighboring routers Election of designated routers Detection of failure of link and neighbors Messages: Hello 2. The exchange protocol Exchange database between neighbours Messages: Database Description, Link-State Request, Link-state update 3. Reliable flooding When links change/age send: update to neighbours and flood recursively. Messages:Link-State Update, Link-State Acknowledge 4. Shortest path calculation Dijkstra's algorithm Compute shortest path tree to all destinations The first three points (-3) are different parts of the actual protocol, each part has different OSPF message types. The fourth point is not really a part of the protocol, this is achieved by the router when it has received all LSAs in a routing domain. One could also add an initial OSPF point (0) as detecting which links a router is connected to - its local link-state.
OSPF Encapsulation OSPF runs directly on IP Needs its own reliable protocol The flooding protocol No port numbers Need to run as root raw sockets No checksum Computes its own checksum or digest Since it runs on IP (IS-IS runs on the link-level) OSPF messages can be routed tunneled or routed by some other protocol 2 If OSPF is unreliable and IP-based, why does it not run on UDP? Good question, with UDP, OSPF could have used port numbers and run separate OSPF instances. The argument of running as root providing better 'security' is not really a valid argument. In retrospect, this is probably a misdesign. The fact that you need to use 'raw sockets' is an argument valid on the BSD socket interface that is common on most operating systems today. That is, you cannot use the more convenient 'stream' or 'datagram' sockets that you use when programming TCP or UDP protocol code. Note that running directly on IP has some consequences (in comparison with ISIS). Routing OSPF messages themselves (recursive routing) may be flexible, but OSPF then needs another routing protocol to send the OSPF messages,...
OSPF header 0 2 3 0 2 3 4 5 6 7 8 9 0 2 3 4 5 6 7 8 9 0 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version # Type Packet length +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Router ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Area ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Checksum AuType +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authentication +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authentication +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP OSPF common header OSPF specific header 3 This is the common header part that all OSPF messages starts with after the IP header. All multi-byte integer fields are in 'network byte order' = 'big-endian' = 'most significant byte first'.
OSPF common header Version 2 for IPv4 3 for IPv6 Type Hello DD database description Link-State Request Link-State Update Link-State Acknowledge Router ID A unique number within the domain Area ID Backbone: 0.0.0.0 Other areas, eg: 2.3.4.5 Checksum Standard IP checksum AUtype NULL Simple password Cryptographic authentication 4 Note that the router ID can be any unique number. But it is typically an IP address on the router which by definition should be unique within the routing domain (or even globally). It is also typically an address on a loopback interface to ensure that the address is always reachable. But this is recommended practice, the router-id does not have to be a reachable IP address for OSPF. Other protocols (eg PIM) may have stronger requirements.
Cryptographic authentication 0 2 3 0 2 3 4 5 6 7 8 9 0 2 3 4 5 6 7 8 9 0 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 Key ID Auth Data Len +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cryptographic sequence number +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authentication field (see figure) Checksum field set to zero Create message digest from complete packet Eg, MD5 Append digest to packet Set key (if many keys are used), seq#, and digest length. IP OSPF common header OSPF specific header Digest 5 Instead of each protocol having its own authentication, one can use IPSEC or other mechanisms to authenticate OSPF messages. Note that there is also LSA checksum which is separate from actual message authentication (see later slide)
Part : The Hello protocol How does a router know who its neighbours are? By sending each other Hello packets Multicast to AllSPFRouters (224.0.0.5) Hello is typically sent every 0 seconds Hello interval Three failed Hello attempts result in a link failure report. Router dead interval You can reduce Hello periods but it is difficult to make OSPF detect errors insub-second realm For sub-second failure detection, OSPF can use BFD Hello:s are also used to negotiate some options between neighbors Designated router, router dead interval, etc 6 BFD (Bidirectional Forwarding Detection) can also be used to support other protocols on the router with fault detection.
The Hello packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Network Mask +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HelloInterval Options Rtr Pri +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RouterDeadInterval +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Designated Router +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Backup Designated Router +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Neighbor +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... IP OSPF common header Hello 7 Conflicting fields in hello packets between peers result in negotiation, or ultimately loss of connection.
Adjacency on a broadcast network N-squared problem: too many adjacencies if the network is fully meshed: n(n-)/2 We elect one router to represent the network Designated router (DR) We elect one router to take over in case of failure Backup designated router (BDR) OSPF communication From a router to the DR and BDR Multicast: AllDRouters (224.0.0.6) The DR sends messages to other neighbours Multicast: AllSPFRouters (224.0.0.5) Data traffic still forwarded directly! 8 This means that a router connected to a transit network (eg an Ethernet) only forms adjacency with the DR. The DR however, keeps track of all nodes connected to the network.
Electing designated router Election algorithm First router always DR Second router always BDR Only in case of failure change DR/BDR Elect DR and BDR from router priority If equal prio => Highest router ID Routerprio is 0 => can never be DR/BDR Why is a BDR necessary? For fast failover if DR fails The BDR runs in parallelwith the DR Note that this method is undeterministic 9 This algorithm is non-deterministic if the start of individual routers is unknown. DR and BDR election depends on which order the routers are initiated. You can never know in advance which router is DR and BDR. Unless you set router priority. Note that DR election is deterministic in IS-IS and therefore preemptive.
Variants of multi-point networks Broadcast networks The link-layer is broadcast capable Non-Broadcast Multiple Access (NBMA) Any two routers can communicate but no broadcast X.25, ATM, FR Neighbour detection via configuration Point-to-Multipoint Not all routers can communicate Packet radio, cloud of point-to-point links No DR/BDR, treated more like many point-to-point protocols. Can be modelled as a set of point-to-point links 20 A large part of the OSPF RFC deals with different variants of multipoint networks. In this course we only deal with broadcast networks such as Ethernet and Wavelan. The big advantage with broadcast networks is their ability to send link-supported multicast that reaches all nodes in the network. You may not have this capability in the other variants.
Part 2: Database exchange When two routers has established adjacency, the databases need to get synchronized. First: mutually send summary to each other's databases. The Database description packet includes a list of Linkstate headers Only database headers not actual entries. Then: Request explicitly database entries Link-State requests Last: Send database entries Link-state updates 2 In the database exchange phase, several messages are used: database description (DD), link-state request and link-state updates. The DD packet can be seen as an index of which LSAs appear in the database. Database exchange can be seen as an optimization of flooding - to quickly get synchronized with a neighbor instead of waiting for flooding of LSAs to occur.
Part 3: Flooding of link-state LSAs are the elements of the distributed database Sometimes called LSPs (Link-State packets) A router describes its environment in the form of networks that it is connected to Fundamental task in OSPF: Distribute the LSAs to all nodes in a reliable way Then, each node can compute Dijkstra on the same database Every router spreads its LSAs to all its peers That is, all information about its own links All routers forward the LSAs to its other peers LSAs are acknowledged When a link changes, a new instance of the LSA is distributed Periodic updates every 30 minutes Flood a new instance 22 LSAs are described in detail in later slides.
Reliable flooding example () A link-state changes in the originator The originator floods an LSA over the network Update is resent until acknowledged u u 23 The router in the lowest part of the network originates the link-state. 'u' denotes OSPF link-state update messages which are sent to all adjacent links/neighbors.
Reliable flooding example (2) An update already received is taken as an implicit acknowledgement Updates not sent on links where they were received (unless designated router - later) u u u 24 The two middle routers receive updates on the link, and treat them as implicit acknowledgements (no need to resend).
Reliable flooding example (3) LS Acknowledgements sent after timeout Several acks can be sent in one LS acknowledgement a a a 25 'a' denote OSPF link-state acknowledgement messages. The middle routers can send acks to the originator before receiving acks from the upper router.
Flooding in a transit network () In a transit network, the roles of the designated router (and backup designated router) are important DR BDR u 26 More info about transit networks later (see Router LSA: transit network).
Flooding in a transit network (2) From peer to DR and BDR Using multicast address AllDRRouters (224.0.0.6) Only DR and BDR listen to AllDRRouters DR BDR a u u 27 Multicast is used for scaling purposes: if there are many nodes in a transit network, fewer OSPF signaling messages need to be sent. Note however that OSPF routers keep state about its neighbors, but neighbors are defined using the DR concept. That is, the leftmost router in the network is only aware of the DR (and BDR) as neighbor.
Flooding in a transit network (3) From designated routers to all others Using multicast address AllSPFRouters (224.0.0.5) All OSPF routers listen to AllSPFRouters Acks sent by unicast If the BDR does not hear an update from the DR, it assumes the DR has crashed and takes over DR BDR u u u u u 28 Link-state acknowledgements will be sent back after this stage (not shown)
LSA structure summary Identifer Age Sequence Advertising Router Checksum Type Router point-to-point link transit link stub link virtual link Network Network Summary ASBR Summary AS External 29 This summary is meant as an overview of the following detailed OSPF description of an LSA. You can see an LSA as one piece of a puzzle describing one component of a network topology. All LSAs in a routing domain is the completed puzzle that describes the complete network topology. This individual piece of a puzzle need to be expressable: you should be able to express anything an IP network may consist of, such as different kind of links, metrics, error cases, etc. The structure of an LSA is therefore somewhat complex.
LSA header Every LSA has a common header The rest is different depending on LSA type LSA headers appear in DD, LS update and LS ack 0 2 3 0 2 3 4 5 6 7 8 9 0 2 3 4 5 6 7 8 9 0 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LS age Options LS type +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link State ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Advertising Router +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LS sequence number +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LS checksum length +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LSA hdr LSA body IP OSPF common header LSA LSA 2... LSA n 30 Several LSAs may be a part of an OSPF message. This adds some complexity in comparison to ISIS where there is exactly one LSA per packet (LSP). It also increases the flexibility. An advantage is that one can form larger and flexible packets by concatenating LSAs, fewer messages may be sent. A drawback is that several layers of checksums are necessary, one per LSA and one per message. IS-IS have atomic LSPs that can simply be forwarded. In the following slides, most field in the LSA header are described
The link-state ID field The identifier of the LSA that is unique within a domain The ID is different for different types: Type Router LSA: Router ID /eg a loopback address) Type 2 Network LSA: IP address of Designated Router) Type 3 - Destination IP network Type 4 - Router-id of ASBR Type 5 - Destination IP network 3 The link-state id is a 4-byte unique identifier of the LSA. Note that router-ids are by definition unique, but destination IPv4 networks in four bytes may not be unique. For example, 0.0.0.0/24 and 0.0.0.0/6 have the same 4-byte identifier. To make these unique the host bits are used, according to an algorithm that is beyond the scope of this course,...
The age field An LSA is valid up to 30 minutes When an LSA reaches 30 minutes, the originating router makes a new instance New instance: increment sequence number If not refreshed, the LSA will be deleted after one hour (MaxAge) Premature aging is used to flush LSAs from the database Age == MaxAge is the same as delete! If deleted by another router that router floods the LSAs with MaxAge To ensure that all deletes the LSA at the same time 32 Note that age and sequence are different. The age denotes how long a particular instance of an LSA has existed. That is, the age of an LSA with a particular sequence number. Such an instance cannot change: If you change the LSA you need to increment the sequence number, and thus reset the age to 0. The age provides a way to flush old data from a system.
Sequence numbers Sequence numbers are incremented when the link-state changes. An originating router also increments the sequence ~every 30 minutes - when age has expired But how do you define larger if sequence numbers wrap? Original ARPANET: Circular OSPFv: Lollipop OSPFv2: Linear Initial sequence number: 0x8000000, max: 0x7fffffff When sequence number reaches max, the router deletes LSA By flooding of a prematured aged LSA (0x7fffffffff) And then reintroduce the LSA Sequence number is 32-bits, if router updates sequence # every 5 seconds it takes 600 years to wrap-around! circular lollipop linear 33 Note that if the content of the LSA does not change, a new LSA with new sequence number is introduced anyway att approximately age 30 minutes. It is only if an LSA changes (a field in the LSA) that sequence numbers are upgraded more often than that. A flapping link that goes up and down several times a second, for example, can cause bursts of sequence numbers updates.
The LSA checksum The LSA checksum ensures that the LSA data has not changed in transit. The originator computes the checksum The LSA checksum is separate from message authentication, A single LSA can be a part of several OSPF messages (flooding of LSAs) Several LSAs can be a part of a single OSPF message. 34 The LSA checksum is different from the OSPF message authentication
Metric The metric is dependent on LSA and is not in the common header The metric is a scalar - 65536 It can mean anything: hops,, delay, load,... Metrics are asymmetric On many systems, default metric is inversely proportional to link bandwidth: 0^8 / <linkbw> Eg 0Mb eth has metric 0 E (serial 2Mbps) has metric 50 Juniper does not have this by default 35
The type field )Router LSA Describes all locally connected links (including IP route information) of a router 2)Network LSA Describes a transit (broadcast) link 3) Network Summary LSA Describes an aggregated route 4) ASBR Summary LSA Special form of route: an ASBR that occurs in another area 5) AS External LSA Describes a redistributed, external route 6) Group Membership LSA (MOSPF) 7) NSSA external information LSA 8) External attributes LSA 36 The type field defines which type this LSA has. We will go through each LSA type in detail in the following slide and later (look for LSA type, LSA type 2, etc)
LSA type : Router LSA A list of links that a true router is connected to The router LSA consists of a set of links with the following types: Link to stub networks No other router Link to a point-to-point network Link to transit networks Broadcast, NBMA or point-to-multipoint Virtual link Tunnel to other router Used in error cases and to keep the backbone connected LSA hdr Router LSA hdr Link # Link #2 Link #n 37 The router LSA is the central and most complex LSA. It describes the links a single router is connected to. The complexity comes from the fact that there are several types of links, and they are modelled somewhat differently. The following slides will go through each link type of a router LSA in detail. Thereafter we will go to LSA type 2. Every router in an OSPF domain (actually within an area) constructs and distributes a router LSA describing its local environment throughout an area. Outside of an area, the router LSA is not visible
Router LSA: Stub network RFC 2328, fig a Stub network: only one entry point Represented by IP address and network mask Note that the database arrow is not bidirectional Network view RT7 LSA (database) view RT7 N3 N3 RT7's router LSA (part of a LS update) LSA hdr Packet view Router LSA hdr Stub Link: N3 38
Stub networks and passive interfaces A stub network denotes an IP sub-network where there are no other OSPF routers with which the router communicates. Where do these occur? Pure host networks. Maybe customer networks without routers. AS border Packets are forwarded on a stub-network, but OSPF signaling messages are not sent. You declare an interface as passive -> network is modelled as a stub. Security issues: if you speak HELLO on an access network or towards another AS, another (bad) OSPF router may inject routes into your internal network leading to black-holing or other DOS attacks Always declare interfaces as passive on the border of your OSPF domain! 39 Always declare DMZ towards other ASs as passive. Always declare interfaces to customers or untrusted host networks as passive.
Router LSA: Point-to-point A point-to-point link simply points to the router-id to the other router The router connected on the other side of the p-t-p link But often (like in our labs) point-to-point links have addresses and sometimes sub-networks. These sub-networks are modelled as stub networks. The example below is a combination of p-t-p and stub links 0.0.0.0/24 RT RT2 RT RT2 0.0.0.0/24 RT's router LSA LSA hdr Router LSA hdr P-t-p link:rt2 Stub Link: 0.0.0.0/24 RT2's router LSA LSA hdr Router LSA hdr P-t-p link:rt Stub Link: 0.0.0.0/24 40 The example shows two routers interconnected with a point-topoint link. RT and RT2 are denoted by a router LSA each, as seen in the picture. Each such router LSA contains a point-to-point link containing the router-id of the other router. Thus, RT points to RT2 and RT2 point to RT. Furthermore, since there are addresses (sub-networks) on the pointto-point link (this is not necessary for un-numbered interfaces), each router LSA also contains a stub-link (previous slide), indicating the addresses to the subnetwork 0.0.0.0/24 Alternatively, you can have individual unrelated addresses (Ia and Ib) on a point-to-point link. This is modelled as shown. RT points to Ia and RT2 to Ib, this is an obcurity of OSPF. Ia Ib RT RT2 RT RT2 Ia Ib
Router LSA: Transit network The link points to a transit network's IP address The address of the designated router Example: Ethernet, token ring, Wavelan,... RT3 RT4 RT3 RT4 RT4 RT6 N2 N2 RT5 RT6 RT3's router LSA LSA hdr Router LSA hdr Transit link:n2 4 A transit network is a multi-point network (two end-points is pointto-point), where nodes can communicate between each other. See earlier slide for different variants of multi-point networks.
Router LSA: Virtual link The link points to a remote router connected by an IP network Similar to point-to-point, but remote peer is not physically connected Used to keep the backbone connected We will talk more about virtual links in the area section 42 This is where OSPF adjacency actually can be formed over an IP routed network not routed by the protocol itself (recursive routing). This means that the virtual link needs to be set up by some other mechanism, typically static routing or some other internal protocol (RIP?).
LSA Type 2: Network LSA Links of a transit network distributed from a designated router The designated router distributes the information on behalf of the connected routers Metric on entry to network but zero cost to leave Example: (RT3 is DR) DR RT3 RT4 RT3 RT4 RT4 RT6 N2 N2 RT5 RT6 RT3's network LSA LSA hdr Network LSA hdr RT3, RT4, RT5, RT6 43
External routes An external route is a prefix that OSPF has learnt from another protocol (or static route) Has been redistributed into OSPF External routes come in two flavors based on the metrics: External Type (E): use same metrics as internal External Type 2 (E2): external metric takes precedence If RIP routes are imported as E, and OSPF uses hop-count metric, then OSPF and RIP can work seamlessly BGP routes are imported as E2, where metric is AS-path length 44
AS External- LSA (Type 5) But how are the external routes communicated to the network? Router and network LSAs are not applicable AS External LSAs Originated by AS boundary routers Announces an external particular prefix Redistributed route from another protocol A forwarding address (may be different than AS boundary router) External route tag Eg an BGP AS path would enable the use of OSPF instead of IBGP AS External LSAs are flooded throughout the AS RT3 RT3 N N ASBR ASBR RT3's AS External LSA LSA hdr AS External LSA hdr N 45 Important that external routes are flooded throughout a whole OSPF domain, regardless of areas (though there are exceptions -see totally stub area). The LSA ID of an external LSA is the destination network itself. But since the external network is not unique (see earlier slide) the host-bits may be used to distinguish between IDs.
Exercise 3.3.3.0/24 A B C..2.3....0/30.2.2.3.0/27 G.2 D DR E BDR F 2.4..0/30..2.3. 2.3.4.0/28 Create an LSA table for the network above Type LSAId AdvRouter LSA Specific data Solution on web after lecture 46 Solution will appear on web after the lecture.
OSPF Areas Divides the OSPF domain into smaller zones Smaller link-state database in each zone Also decreases signaling traffic Routers have limits on processing power and memory Router CPUs are typically much slower than PCs CISCO used to recommend ~80 routers as a limit in a single area You need a large network to benefit from areas Typical large companies Example: KTHLAN used OSPF with 5-20 routers used to have areas but now only uses area 0. However, areas are less used today. 47
Smaller database Using areas makes the database smaller That is, fewer and more compact LSAs The destinations inside the area is still fully described by type- router and type-2 network LSAs Full Dijkstra algorithm But destination networks outside the area are summarized Transit networks (Network LSAs) Stub networks (Router LSA stub links) Router-LSAs are not distributed outside an area Unless they are ASBR Only the (cumulative) metric and prefix necessary Not full link state This leads to a smaller database and less processing to compute shortest path 48
Summary LSAs: types 3 and 4 To distribute the summary information, we need two new LSAs Type 3 Network summary LSA Destination, network mask and cumulative metric Type 4 ASBR Summary LSA 8 Same as type 3, but destination is an AS boundary router Next hop for external routes Why is LSA type 4 needed? Because type 5 AS external LSAs are flooded throughout the AS, but the ASBR might not be visible from inside an area N ABS R 49
N 4 N N 2 3 3 RT RT2 N 3 2 RT4 RT3 8 8 8 6 7 RT5 6 Ia 7 6 8 8 8 RT6 N 3 N 2 Area N 4 N 5 N H Area 3 3 RT9 RT2 0 2 N0 N 9 RT0 3 2 RT N8 Area 2 RFC 2328 fig 6 Ib 6 RT8 N 6 4 N7 6 2 9 RT7 50
Comment : Route summarization When the details of an area has been hidden it makes sense to aggregate the prefixes Typically, all networks within an area, can be summarized into one LSA Routes can also be summarized at redistribution to/from another protocol The metric uses the max of all summarized metrics In the example, area 3's routes are summarized: N9-N, H With max cost (to H) 5
Comment 2: Virtual links The backbone must be logically connected But it does not have to be physically connected You can use virtual links (tunnels) to make the backbone virtually connected Traffic passing in the backbone may then physically use a non-backbone area: this is called a transit area. Example: A virtual link is (manually) configured between RT0 and RT For robustness, RT7 and RT may also have a virtual link 52
Virtual link example A virtual link is (manually) configured between RT0 and RT, and RT7 and RT0 Area 2 is now a transit area RT0 3 RT7 2 RT Area 2 N8 RT8 N 6 4 N7 53
Example: Areas in 0 and Note : The Area Border Routers (RT3 and RT4) injects summaries both Into Area from the backbone and other areas Into Area 0 (backbone) from area Note 2: The external routes are flooded through all areas Note 3: Area has two points of exits Internal routers can make intelligent decisions, and load balance between exit points Example: RT uses RT4 to N6, and load balances to N8! 54
Backbone Database: RFC 2328 fig 8 N N 2 N 3 RT4 8 RT3 8 8 RT5 7 8 6 6 RT6 7 6 8 8 N 4 N 3 N 2 N 4 Area Ib Max of all individual metrics 5 Ia 5 RT0 3 2 6 9 RT7 N 5 N9-N, H Area 3 RT 2 N 6 Area 2 N7 N8 55
Area 's database: RFC 2328 fig 7 LSA Type : Router N N 2 Area LSA Type 2: Network 3 RT 0 3 RT2 0 0 N 3 0 N 4 LSA Type 4: ASBR Summary 2 RT4 RT3 8 4 4 LSA Type 3: Network Summary 8 8 LSA Type 5: AS External 2 0 RT5 RT7 Ia 2 N9-N, H 8 9 Ib N 6 N8 8 8 N7 N 4 N 3 N 2 N 5 56
Stub areas A problem with flooding external LSAs: Suppose many external routes are injected into OSPF Maybe the core carries transit traffic (between other AS:s) High performance routers But large parts of the areas do not Simpler routers This will give a high burden on the smaller routers In a stub area, the ABR does not flood external LSAs into the area Instead, one (or many) default routes are injected Then all external traffic must use the default route announced by the ABRs But the inter-area networks are still announced by summaries from the ABRs 57
Stub area example N 4 N N 2 3 3 RT RT2 N 3 default 2 RT4 RT3 8 8 8 6 7 RT5 6 6 8 8 8 RT6 N 3 N 2 Area N 4 2 6 9 N 5 RT7 58
Motivation for NSSA Sometimes, the restrictions on stub areas are too strict: You would like to import a limited number of external routes Example: You want to block large routing tables from transit traffic, but want to import a small number of routes But in stub areas, you cannot import any external routes. 59
Example: NSSA motivation A Peering with other AS C Large amount of transit routes Area Want to import routes from C but not from A and B Area 0 Peering with other AS B 60
Not-So-Stubby Area (NSSA) RFC 30 NSSA allows to inject external routes into a stub area LSA type 7 are spread through the NSSA At ABRs, the Type-7 LSA are translated to Type-5 (External-AS LSA) and spread through the AS But other External-AS LSAs are still not inserted in the NSSA 6
Example: NSSA solution A Peering with other AS C Area Area 0 Routes from C spread as Type-7 LSA Routes from C translated to Type-5 LSAs Peering with other AS B 62
Totally stub areas Totally stub area In addition to external routes, do not distribute inter-area routes into an area Just use default route CISCO-specific Like IS-IS L without leaking NSSA totally stub area Combination of NSSA and totally stub area 63
Summary of LSAs: regular areas Regular area Area 0 AB R -----> -----> 3* 2 -----> -----> 3 3 ----->x 4 ----->x 5 -----> -----> 4 -----> 5 (stub links) Regular area Area 0 AB R 3* <----- <---- 3 <----- <---- 2 3 <----- <---- 3 4 <----- <---- 4 5 <----- <---- 5 4 <----- Note: (*) Only stub links of type translated to type 3 Type 5 passes through but generates a new type 4 (ASBR) Type 3 and 4 from other areas passes through but changes origin (to ABR) Summaries (3 and 4) are not forwarded into backbone 64
Summary of LSAs: stub areas Stub area Area 0 AB R -----> -----> 3* 2 -----> -----> 3 3 ----->x 4 ----->x 5 ----->x (stub links) Stub area Area 0 AB R 3* <----- <---- 3 <----- <---- 2 3 <----- <---- 3 x<---- 4 x<---- 5 0/0 <----- Note: All type 5 blocked. Replaced with default route (in a type 3 LSA) 65
Summary of LSAs: not-so-stubby areas Stub area Area 0 Stub area Area 0 -----> -----> 3* 2 -----> -----> 3 3 ----->x 4 ----->x 5 ----->x 7 -----> -----> 4 -----> 5 3* <----- <---- 3 <----- <---- 2 3 <----- <---- 3 x<---- 4 x<---- 5 0/0 <----- x<---- 7 66
Opaque LSA Option RFC 2370 For Future extensibility Standard LSA header Followed by application-specific information Three new LSA, difference in scope: Type 9-LSA: Link-local scope Type 0-LSA: Area-local scope Type -LSA: AS-local scope 67
Traffic Engineering extensions RFC 2370 It adds bandwidth and administrative constraints So that a (network) manager can control traffic in more detail Distribute it in an area Uses Type-0 opaque LSA, area scope Call it Traffic Engineering LSA The LSA payload contains nested TLVs, for example: Traffic engineering metric Maximum bandwidth Maximum reservable bandwidth Unreserved bandwidth Administrative group 68
OSPFv3 OSPF for IPv6 is OSPFv3 Unchanged: Flooding, DR election, area support, SPF calculations, etc Authentication removed (use IPSEC) New LSAs for IPv6 addresses Addressing semantics removed from basic LSAs and msgs Avoid IPv4/IPv6 addresses prefer RouterID Network-protocol independence Renaming: Type-3 summary LSA -> Inter-Area-prefix LSA Type-4 summary-las -> Inter-Area-router LSA 69
Summary This was OSPF essentials But there are many more issues, for more reading consult: RFC 2328 J Moy, OSPF Anatomy of an Internet Routing Protocol Lots of vendor documentation 70
Homework fe-/0/ RTB4.2 92.68.2.4 fe-/0/0.0 92.68.2.8/30 AS 65000 fe-/0/.9 72.6.2.0/30 fe-2/0/0 RTE4 RTB..2 AS 6502 92.68.2. fe-/0/0.7 72.7.20.0/24 92.68.2.6/30 72.7.2.0/24 fe-/0/.8 92.68.3.0/29 fe-/0/ RTB3.3 92.68.2.3 fe-/0/0 RTB2. 92.68.2.2 Write a table as follows: LS Type LS Id Adv Router LSA specific data 7