1 / 67

Routing II: Protocols (RIP, EIGRP, OSPF, PNNI, IS-IS)

Routing II: Protocols (RIP, EIGRP, OSPF, PNNI, IS-IS). Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu Based in part upon slides of Prof. Raj Jain (OSU), S. Keshav (Cornell), J. Kurose (U Mass). RIP, RIPv2, EIGRP OSPF, PNNI, IS-IS: LS efficiency & robustness

Jims
Download Presentation

Routing II: Protocols (RIP, EIGRP, OSPF, PNNI, IS-IS)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Routing II: Protocols (RIP, EIGRP, OSPF, PNNI, IS-IS) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute shivkuma@ecse.rpi.edu Based in part upon slides of Prof. Raj Jain (OSU), S. Keshav (Cornell), J. Kurose (U Mass)

  2. RIP, RIPv2, EIGRP • OSPF, PNNI, IS-IS: LS efficiency & robustness • Link state distribution, DB synchronization, NBMAs etc • Refs: Chap 16,14 • Books: “Interconnections” by Perlman, “OSPF” by John Moy, “Routing in Internet” by Huitema. • Reference: RFC 2328: OSPF Version 2: In HTML • Reading: Notes for Protocol Design, E2e Principle, IP and Routing: In PDF • Reading: Routing 101: Notes on Routing: In PDF | In MS Word • Reference: Tsuchiya, "The Landmark Hierarchy: A New Hierarchy for Routing in Very Large Networks" Overview

  3. RIP: Routing Information Protocol • Uses hop count as metric (max: 16 is infinity) • Tables (vectors) “advertised” to neighbors every 30 s. • Each advertisement: upto 25 entries • No advertisement for 180 sec: neighbor/link declared dead • routes via neighbor invalidated • new advertisements sent to neighbors (Triggered updates) • neighbors in turn send out new advertisements (if tables changed) • link failure info quickly propagates to entire net • poison reverse used to prevent ping-pong loops (infinite distance = 16 hops)

  4. RIPv1 Problems (Continued) • Split horizon/poison reverse does not guarantee to solve count-to-infinity problem • 16 = infinity => RIP for small networks only! • Slow convergence • Broadcasts consume non-router resources • RIPv1 does not support subnet masks (VLSMs) • No authentication

  5. RIPv2 • Why ? Installed base of RIP routers • Provides: • VLSM support • Authentication • Multicasting • “Wire-sharing” by multiple routing domains, • Tags to support EGP/BGP routes. • Uses reserved fields in RIPv1 header. • First route entry replaced by authentication info.

  6. E-IGRP (Interior Gateway Routing Protocol) • CISCO proprietary; successor of RIP (late 80s) • Several metrics (delay, bandwidth, reliability, load etc) • Uses TCP to exchange routing updates • Loop-free routing via Distributed Updating Alg. (DUAL) based on diffused computation • Freeze entry to particular destination • Diffuse a request for updates • Other nodes may freeze/propagate the diffusing computation (tree formation) • Unfreeze when updates received. • Tradeoff: temporary un-reachability for some destinations

  7. Link State vs. Distance Vector • Link State (LS) advantages: • More stable (aka fewer routing loops) • Faster convergence than distance vector • Easier to discover network topology, troubleshoot network. • Can do better source-routing with link-state • Type & Quality-of-service routing (multiple route tables) possible • Caveat: With path-vector-type (paths instead of distances) DV routing, these differences blur…

  8. Link State Protocols • Key: Create a network “map” at each node. • 1. Node collects the state of its connected links and forms a “Link State Packet” (LSP) • 2. Flood LSP => reaches every other node in the network and everyone now has a network map. • 3. Given map, run Dijkstra’s shortest path algorithm (SPF) => get paths to all destinations • 4. Routing table = next-hops of these paths. • 5. Hierarchical routing: organization of areas, and filtered control plane information flooded.

  9. Link State Issues • Reliable Flooding: sequence #s, age • LSA types, Neighbor discovery and maintainence (hello) • Efficiency in Broadcast LANs, NBMA, Pt-Mpt subnets: designated router (DR) concept • Areas and Hierarchy • Area types: Normal, Stub, NSSA: filtering • External Routes (from other ASs), interaction with inter-domain routing. • Advanced topics: incremental SPF algorithms

  10. Reliable Flooding…

  11. Topology Dissemination • A.k.a LSP distribution • 1. Flood LSPs on links except incoming link • Require at most 2E transfers for n/w with E edges • 2. Sequence numbers to detect duplicates • Why? Routers/links may go down/up • Issue: wrap-around, larger sequence number is not the most recent!

  12. Sequence Number Space Organization • Circular space: S1 > S2 > S3 > S1 • Accidental bit errors in switch memory caused this problem in ARPANET • Lollipop sequence: Start with S0, increment till you reach circle and then view it as a circular space • No ambiguity in lollipop handle • Linear space: OSPFv2. • If Smax reached, expicitly delete Smax LSA before wrapping around

  13. Topology Dissemination (Continued) • Checksum field: • Drop packet if in error, get retransmission from neighbor • Age field (similar to TTL) • Number of seconds since LSA originated • Periodically incremented after acceptance • Originating router refreshes LSA after 30 min • Delete if Age = MaxAge • Low age field + large seq # => that LSA is flapping or frequently changing …

  14. Recovering from a partition • On partition, LSP databases can get out of synch • Databases described by database descriptor records • Routers on each side of a newly restored link talk to each other to update databases (determine missing and out-of-date LSPs) => selective synchronization

  15. LSA-types, Neighbor & flooding Adjacencies in Different Subnets

  16. OSPF Router-LSA: Scenario

  17. Neighbor Discovery & Relationship • Every OSPF router sends out 'hello' packets • Hello packets used to determine if neighbor is up • Hello packets sent periodically (short intervals) • HelloInterval = 10s (in example) • Assumes neighbor dead if no response within • RouterDeadInterval = 40s (in example) • This is also called an “adjacency” • Note that adjacency is a logical routing relationship and is more than physical connection. • It consumes bandwidth and computation resources • Becomes an issue if large number of adj need to be maintained

  18. Neighbor … • Once an adjacency is established, trade information • Neighbor relationship is bi-directional as a result of OSPF hello packets • Local topology information is packaged in a "link state announcement“ (LSA) • Multiple types of LSAs: (detail later) • Initial DB synchronization • New announcements are sent ONCE, and only updated if there's a change • Or every 45mins...

  19. Hello: Packet Format

  20. Router-LSA:

  21. Database Synchronization • LS Database (LSDB): collection of the Link State Advertisements (LSAs) accepted at a node. • This is the “map” for Dijkstra algorithm • When the connection between two neighbors comes up, the routers must wait for their LS DBs to be synchronized. • Else routing loops and black holes due to inconsistency • OSPF technique: • Source sends only LSA headers, then • Neighbor requests LSAs that are more recent. • Those LSAs are sent over • After sync, the neighbors are said to be “fully adjacent”

  22. Recap: IP Subnet Model • Each subnet assigned one or more address prefixes. • Each address prefix is called an IP subnet • IP routes to subnets, not to individual hosts • Two hosts on different IP subnets have to go through one or more routers. • Even if they are on the same “physical” network

  23. IP Subnet Model (Contd) • Two hosts or routers on a common subnet can send packets “directly” to one another • Two routers cannot exchange routing information directly unless they have one or more IP subnets in common • All these issues will be strained as we study OSPF adjacency operation over different subnets

  24. Broadcast Media Issues • Multiple (N) OSPF routers attached to a common subnet • Problems: • One “physical link” vs N*(N-1) “adjacencies” • How many “links” to be counted for Dijkstra algo?

  25. Broadcast net: # links for DIjkstra • Each router is assumed to be “linked” to every other router for the purposes of Dijkstra. • Hello protocol optimization: • Each node multicasts Hello to 224.0.0.5 (multicast address “AllSPFRouters”) • The Hello multicast message also indicates acks for other routers’ Hellos by listing their RouterIDs • “Link” relationship for purposes of Dijkstra maintained by each node sending a single Hello packet, instead of N packets. • What about “flooding adjacencies”, I.e., • Whom to send (flood) LSAs when a router generates or learns a new LSA? • Does it need to synchronize DBs with all nodes ?

  26. Flooding Adjacencies : option 1 • Using Router-LSAs … • O(N) Router-LSAs, with O(N2) adjacency info • Multicast of Router-LSAs does not solve O(N2) DB synchronization issue

  27. Flooding Adjacencies: option 2 • New LSA-type: Network-LSA … • O(N) Router-LSAs + 1 network-LSA+ O(N) adjacencies • Converted O(N2) adjacency problem into O(N) problem

  28. Recap: O(N2) model  O(N) model  Question: Who creates the network-LSA?

  29. Designated Router (DR) • One router elected as a designated router (DR) • Each router maintains flooding adjacency with the DR, I.e., sends acks of LSAs to DR • DR informs each router of other routers on LAN • DR generates the network-LSA on subnet’s behalf after synchronizing with all routers

  30. DR, BDR … continued • Backup DR (BDR) also syncs with all routers, and takes over if DR dies (typically 5 s wait) • Total: 2N – 1 adjacencies • Multicast-based optimization: • New LSAs, Hellos sent to AllSPFRouters avoids DR re-advertising new information • LSA acks sent to AllDRRouters avoids separate copies to be sent to DR and BDR • DR election: • First router on net = DR, second = BDR • RouterPriority: [0, 127] indicated in Hello packet=> highest priority router becomes DR • If network is partitioned and healed, the two DRs are reduced to one by looking at RouterPriority

  31. Network-LSA Example: Summary DR

  32. What if subnet does not support broadcast? • Non-Broadcast Multiple Access (NBMA) media • NBMA segments may support more than 2 routers, and allow any two routers to communicate directly, but do not support data-link broadcast/mcast capability • Eg:X.25, SMDS, Frame-Relay, ATM etc • Connection-oriented (VC-based) communication • Each VC is costly => setting up full mesh for Hellos is prohibitively expensive • Two flooding adjacency models in OSPF: • Non-Broadcast Multiple Access (NBMA) model • Point-to-Multipoint (pt-mpt) Model • Different tradeoffs…

  33. NBMA Subnet Model • Neighbor discovery: manually configured • Dijkstra SPF views NBMA as a full mesh! • Most routers assigned a RouterPriority = 0 • Other routers: eligible to become DRs => • ID of all routers in the NBMA configured • Maintains VCs and Hellos with all routers eligible to become DRs (RouterPriority > 0) • Enables election of new DR if current one fails • DR and BDR only maintain VCs and Hellos with allrouters on NBMA • DB synchronization works same as broadcast subnet • Flooding in NBMA always goes through DR • Multicast not available to optimize LSA flooding. • DR generates network-LSA just like broadcast subnet

  34. NBMA vs Pt-Mpt Subnet Model • Key assumption in NBMA model: • Each router on the subnet can communicate with every other (same as IP model) • But this requires a “full mesh” of expensive PVCs at the lower layer! • Many organizations have a hub-and-spoke PVC setup, a.k.a. “partial mesh” • Conversion into NBMA model requires multiple IP subnets, and complex configuration (see fig on next slide) • OSPF’s pt-mpt subnet model breaks the rule that two routers on the same network must be able to talk directly • Can turn partial PVC mesh into a single IP subnet

  35. Partial Mesh F-Relay: NBMA model

  36. Partial Mesh F-Relay: pt-mpt model

  37. Pt-Mpt Subnet Model • Each router: single OSPF interface, but multiple neighbor relationships • Note that neighbor relationships not formed to nodes to which direct PVC does not exist. • Key differences: • No DRs or BDRs! Just hellos over the PVCs. Make sure that the communication is bi-directional. • I.e. Partial mesh is viewed in Dijkstra as a partial mesh. Full mesh view not forced like in NBMA model. • Sometimes auto-configuration is possible. • Loss in efficiency because the DB synchronization has to be done between every peer. • O(n^2) if full mesh. So, in true full PVC mesh situations, it is better to operate subnet as an NBMA

  38. Hierarchical Routing

  39. Why Hierarchy? • Information hiding (filtered) => computation, bandwidth, storage saved => efficiency => scalability • Address abstraction vs Topology Abstraction • Multiple paths possible between two areas 

  40. Hierarchical OSPF

  41. Area • Configured area ID • A set of address prefixes • Do not have to be contiguous • So a prefix can be in only one area • A set of router IDs • Router functions may be interior, inter-area, or external

  42. Hierarchical OSPF • Two-level hierarchy: local area, backbone. • Link-state advertisements only in area • each nodes has detailed area topology; only know direction (shortest path) to nets in other areas. • Two-level restriction avoids count-to-infinity issues in backbone routing. • Area border routers (ABR):“summarize” distances to nets in own area, advertise to other Area Border routers. • Backbone routers: uses a DV-style routing between backbone routers • Boundary routers (AS-BRs): connect to other ASs (generate “external” records)

  43. Sample Area Configuration 10.2.0.0/24

  44. Summary-LSA Example

  45. Externals and Aggregation 1 • A full ISP routing table has approximately 100K routes! • But will you do anything differently if you know all of them and have a single ISP? • Multiple ISP situations call for complex OSPF and BGP design • Never redistribute IGPs into BGP! (later…) • Redistribute BGP into IGPs with extreme care

  46. Externals & Aggregation 2 • In an enterprise • Limit externals from subordinate domains (e.g., RIP) to be within area (area-scope) • Flood only in area 0 and in area with ASBR • Allow externals from Internet, peer domains to go outside Area 0… • Only when there will be significant path differences • Do things with defaults where possible

  47. Type 1 and Type 2 externals • Type 2: • Default type for routes distributed into OSPF • EGP costs very different from IGP costs • Exit based on external (EGP) cost only • Type 1 • Needs to be set explicitly: not default • IGP costs can be compared and summed • Selects exit based on internal + external costs

  48. Stubbiness: A Means of Controlling Externals

  49. Normal Areas • Flood AS-external-LSAs (type 5) across area-boundaries (AS flooding scope) • ASBR-summary-LSAs (type 4) advertises location of ASBR (area flooding scope)

  50. Stub Areas • AS-external-LSAs (type 5) not flooded into stub areas • Summary-LSA flooded only optionally • Default route to ABR for all non-area prefixes • Paths may be inefficient, cannot place an ASBR in stub areas

More Related