Which Routing Protocol? IPv4 and IPv6 Perspective

Transcription

1

2 Which Routing Protocol? IPv4 and IPv6 Perspective Wim Verrydt

3 The Questions Is one protocol better than the others? Which routing protocol should I use in my network? Should I switch from the one I m using? Do the same selection rules apply to IPv4 and IPv6? How will my IPv4 and IPv6 routing protocols coexist? IPv4 Ends Merge IPv6

4 The Questions Is one routing protocol better than any other protocol? Define Better! Converges faster? Uses less resources? Easier to troubleshoot? Easier to configure? Scales to a larger number of routers, routes, or neighbors? More flexible? Degrades more gracefully? 4

5 The Questions Should I change my routing protocol? The answer is yes if: The network is complex enough to bring out a protocol s specific advantages You can define a specific feature (or set of features) that will benefit your network tremendously 5

6 The Questions Should I change my routing protocol? But, then again, the answer is no! Every protocol has some features and not others, different scaling properties, etc Let s consider some specific topics for each protocol... 6

7 Before That The Twist! Most likely the IPv6 IGP will not be deployed in a brand new network and just by itself Most likely the existing IPv4 services are more important at first since they are generating most of the revenue Redefine Better! Are the characteristics of an IPv6 IGP similar or different from an IPv4 IGP? What is the impact on the convergence of IPv4? How are the resources shared between the two protocols? Are the topologies going to be congruent? How easy is it to manage parallel IPv4 / IPv6 environments? Opportunity to adopt a new IGP for IPv6? 7

8 Which Routing Protocol? Abstract and Pre-requisite This session focuses on Internal Routing Protocol (IGP) selection and aims to answer the following questions: - What are the IPv6 counterparts of the most used IPv4 IGPs and where are they similar or differ? - Is one protocol better than the others? - Which routing protocol should I use in my network? - Should I switch from the one I m using? - Do the same selection rules apply to IPv4 and IPv6? - How will my IPv4 and IPv6 routing protocols coexist? The session will compare link state (OSPF and IS-IS) and DUAL (EIGRP) routing protocols applying a number of considerations, such as convergence speed and network design and topology. Additionally, it will provide an overview of the IPv6 counterparts of the most used IPv4 IGPs and discuss the similarities and differences between the twin routing protocols. Finally, the co-existence of IPv4 and IPv6 routing protocols will also be discussed. As a pre-requisite for this session, attendees should have a reasonable understanding of IPv4 IGP routing protocol design and operation. 8

9 Which Routing Protocol? Agenda IPv4 and IPv6 IGPs Convergence Speed Design and Topology Considerations Protocol Features and Evolution Summary 9

10 IPv4 and IPv6 IGPs A Comparative Overview

11 IPv6 Is an Evolutionary Not a Revolutionary Step and this is very clear in the case of routing which saw minor changes even though most of the Routing Protocols were completely rebuilt. Ciprian Popoviciu 11

12 The IPv4 IPv6 Parallel RIP OSPF IS-IS EIGRP RIPv2 for IPv4 RIPng for IPv6 Distinct but similar protocols with RIPng taking advantage of IPv6 specificities OSPFv2 for IPv4 OSPFv3 for IPv6 Distinct but similar protocols with OSPFv3 being a cleaner implementation that takes advantage of IPv6 specificities Extended to support IPv6 Natural fit to some of the IPv6 foundational concepts Supports Single and Multi Topology operation Extended to support IPv6 Some changes reflecting IPv6 characteristics For all intents and purposes, the IPv6 IGPs are very similar to their IPv4 counterparts IPv6 IGPs have additional features that could lead to new designs ipv6 unicast-routing is required (IOS) 12

13 RIPv2 vs. RIPng Summary RIPv2 (RFC 2453) RIPng (RFC 2080) Type Distance vector Distance vector Metric Hop count (1-15) Hop count (1-15) Loop prevention Split horizon Split horizon Administrative distance L3 transport S/D IPv4 unicast / IPv6 LL unicast / FF02::9 L4 transport UDP 521 UDP 521! interface Loopback0 ip address ! interface Ethernet0/0 ip address ! router rip version 2 network !! ipv6 unicast-routing! interface Loopback0 ipv6 address 2001:DB8:1000::1/128 ipv6 rip CISCO enable! interface Ethernet0/0 ipv6 address 2001:DB8::1/64 ipv6 rip CISCO enable! ipv6 router rip CISCO! 13

14 EIGRPv6 Implementation Important Differences Notes Three new TLVs: IPv6_REQUEST_TYPE (0X0401) IPv6_METRIC_TYPE (0X0402) IPv6_EXTERIOR_TYPE (0X0403) New Protocol Dependent Module (PDM) 32 bit Router ID which must be explicitly configured if no IPv4 address Same Protocol Number, Metrics Hellos are sourced from the link-local address and destined to FF02::A (all EIGRP routers); this means that neighbors do not have to share the same global prefix (with the exception of explicitly specified neighbors where traffic is unicasted) Automatic summarization disabled by default and not configurable for IPv6 (same as in IPv4 now CSCso20666) No split-horizon in the case of EIGRP for IPv6 local routes (because IPv6 supports multiple prefixes per interface) The IPv6 EIGRP process must be enabled explicitly ( no shutdown under the process) in older IOS version. In current versions, the default is that IPv6 EIGRP is enabled (CSCso90068) 14

15 EIGRP vs. EIGRPv6 Summary EIGRP EIGRPv6 Type Distance vector Distance vector Metric Composite (in practice: bandwidth and delay) Composite (in practice: bandwidth and delay) Loop prevention DUAL, split horizon DUAL, split horizon Administrative distance 5 (sum.), 90 (int.), 170 (ext.) 5 (sum.), 90 (int.), 170 (ext.) L3 transport S/D IPv4 unicast / IPv6 LL unicast / FF02::A L4 transport IP 88, RTP (reliable multicast) Next Header 88, RTP! interface Loopback0 ip address ! interface Ethernet0/0 ip address ! router eigrp 1 network passive-interface Loopback0! ipv6 unicast-routing! interface Loopback0 ipv6 address 2001:DB8:1000::1/128 ipv6 eigrp 1! interface Ethernet0/0 ipv6 address 2001:DB8::1/64 ipv6 eigrp 1! ipv6 router eigrp 1 passive-interface Loopback0 eigrp router-id

16 IS-IS for IPv6 Implementation Operational Considerations Two new TLVs: - IPv6 Reachability TLV (0xEC): Describes network reachability (IPv6 routing prefix, metric information and option bits) - IPv6 Interface Address TLV (0xE8): Contains 128 bit address. Hello PDUs, must contain the link-local address but for LSP, must only contain the non link-local address A new Network Layer Protocol Identifier (NLPID): Allows IS-IS routers to advertise IPv6 prefix payload using 0x8E value (IPv4: 0xCC). Carried in Protocols Supported TLV (0x81). Single Topology (default for all protocols supported) - potentially beneficial in saving resources (same topology and same SPF) Multi Topology (RFC 5120) - Independent IPv4 and IPv6 topologies (MT ID 0,2), independent interface metrics. Wide metrics. New TLVs! Transition mode available - both types of TLVs are advertised Standardization: Notes Single Topology: Multi Topology: Evolution Multi Instance: 18

17 IS-IS for IPv4 and IPv6 Summary IS-IS for IPv4 (RFC 1195) IS-IS for IPv6 (RFC 5308) Type Link state Link state Metric (Narrow / Wide) Cost (1-63 / ) Cost (1-63 / ) Loop prevention Dijkstra Dijkstra Administrative distance L3 / L4 transport CLNS CLNS! interface Loopback0 ip address ip router isis CISCO isis circuit-type level-1 isis metric 10000! interface Ethernet0/0 ip address ip router isis CISCO isis circuit-type level-1 isis metric 10000! router isis CISCO net metric-style wide log-adjacency-changes all! ipv6 unicast-routing! interface Loopback0 ipv6 address 2001:DB8:1000::1/128 ipv6 router isis CISCO isis circuit-type level-1 isis ipv6 metric 10000! interface Ethernet0/0 ipv6 address 2001:DB8::1/64 ipv6 router isis CISCO isis circuit-type level-1 isis ipv6 metric 10000! router isis CISCO net metric-style wide log-adjacency-changes all ipv6 unicast-routing! interface Ethernet0/0 ipv6 address 2001:DB8::1/64 ipv6 router isis CISCO isis circuit-type level-1 isis ipv6 metric 10000! router isis CISCO net metric-style wide log-adjacency-changes all! address-family ipv6 multi-topology exit-address-family 19

18 OSPFv3 Implementation Similar Concepts as OSPFv2: - Runs directly over IPv6 (Next Header 89) - Uses the same basic packet types - Neighbor discovery and adjacency formation mechanisms are identical (All OSPF Routers FF02::5, All OSPF DRs FF02::6) - LSA flooding and aging mechanisms are identical - Same interface types (P2P, P2MP, Broadcast, NBMA, Virtual) Independent process from OSPFv2 OSPFv3 Is Running per Link Instead of per Node (and IP Subnet) Important Differences Support of Multiple Instances per Link: - New field (instance) in OSPF packet header allows running multiple instances per link - Instance ID should match before packet is being accepted - Useful for traffic separation, multiple areas per link Generalization of Flooding Scope: - Three flooding scopes for LSAs (link-local scope, area scope, AS scope) and they are coded in the LS type explicitly 22

19 OSPFv3 Comparative overview Important Differences (cont.) Address Semantic Changes in LSA: - Router and Network LSA carry only topology information - Router LSA can be split across multiple LSAs; Link State ID in LSA header is a fragment ID - Intra area prefixes are carried in a new LSA payload called intra-area-prefix- LSAs - Prefixes are carried in the payload of inter-area and external LSA Explicit Handling of Unknown LSA: - The handling of unknown LSA is coded via U-bit in LS type - When U bit is set, the LSA is flooded within the corresponding flooding scope, as if it was understood - When U bit is not set, the LSA is flooded within the link local scope Authentication Is Removed from OSPF: - Authentication in OSPFv3 has been removed and OSPFv3 relies now on IPv6 authentication header since OSPFv3 runs over IPv6 - Autype and Authentication field in the OSPF packet header therefore have been suppressed 23

20 OSPFv3 Important Differences (cont.) Notes OSPF Packet Format has Been Changed: - The mask field has been removed from Hello packet - IPv6 prefixes are only present in payload of Link State update packet Two New LSAs Have Been Introduced: - Link-LSA has a link local flooding scope and has three purposes Carry IPv6 link local address used for NH calculation Advertise IPv6 global address to other routers on the link (used for multi-access link) Convey router options to DR on the link - Intra-area-prefix-LSA to advertise router s IPv6 address within the area Standardization: Main standard: Support for multiple AFs (multiple instance): Evolution: Multi Topology routing in OSPFv3: 24

21 OSPFv3 LSA Types LSA Function Code LSA Type Code Router-LSA 1 0x2001 Network-LSA 2 0x2002 Inter-Area-Prefix-LSA 3 0x2003 Inter-Area-Router-LSA 4 0x2004 AS-External-LSA 6 0x4005 NSSA-LSA 7 0x2007 Link-LSA 8 0x0008 Intra-Area-Prefix-LSA 9 0x2009 LSA Type Code encodes Flooding Scope S1 S2 Flooding Scope 0 0 Link-Local 0 1 Area 1 0 AS 1 1 Reserved 25

22 OSPFv2 vs. OSPFv3 Summary OSPFv2 (RFC 2328) OSPFv3 (RFC 5340) Type Link state Link state Metric Cost ( ) Cost ( ) Loop prevention Dijkstra Dijkstra Administrative distance L3 transport S/D IPv4 unicast / IPv4 unicast / IPv6 LL unicast / FF02::5 IPv6 LL unicast / FF02::6 L4 transport IP 89 Next Header 89! interface Loopback0 ip address ! interface Ethernet0/0 ip address ! router ospf 1 network area 0 passive-interface loopback0! ipv6 unicast-routing! interface Loopback0 ipv6 address 2001:DB8:1000::1/128 ipv6 ospf 1 area 0 instance 11! interface Ethernet0/0 ipv6 address 2001:DB8::1/64 ipv6 ospf 1 area 0 instance 11! ipv6 router ospf 1 router-id passive-interface loopback0 26

23 IPv4 and IPv6 IGP Implementation Summary Implementation Multi Topology Multi Instance Multi Process Processes Single Single Multiple Topologies / SPFs Multiple Multiple Multiple Adjacencies Single Single Multiple EIGRPv6 / EIGRP IS-IS OSPFv3 / OSPFv2 OSPFv3 with AF support (RFC 5838) Yes. (ST IS-IS requires identical topology / SPF for IPv4 and IPv6) Yes (IPv4 and IPv6 support) Yes (same protocols, different PDMs) Yes (different protocols) 27

24 The Version Agnostic Perspective The similarities between the IPv4 and IPv6 IGPs lead to similar network design considerations as far as routing is concerned For the rest of the presentation, the analysis is IP version AGNOSTIC! IPv6 specific considerations are noted where relevant The implementation of the IPv6 IGPs achieves parity with the IPv4 counterparts in most aspects but this is an ongoing development and optimization process Co-existence of IPv4 and IPv6 IGPs is a very important design consideration 28

25 Convergence Speed Scenarios and Considerations

26 Convergence Speed Equal Cost Convergence Link State Convergence EIGRP Convergence Convergence Summary 30

27 Convergence Speed Which protocol converges faster? IS-IS vs OSPF vs EIGRP IS-IS and OSPF have the same characteristics, from a high level, so we ll consider them both as link state Is DUAL faster, or Dijkstra? Rules of Thumb The more routers involved in convergence, the slower convergence will be The more routes involved in convergence, the slower convergence will be 31

28 Convergence Speed Five steps to convergence 1. Detect the failure 2. Flood the failure information 3. Calculate new routes around the topology change 4. Add changed routing information to the routing table (RIB) 5. Update the FIB (possibly distributed) Steps are similar for any routing protocol, so we ll only look at steps 2-3 But, it s important to keep in mind steps 1-4-5, since they often impact convergence more than the routing protocol does 32

29 Equal Cost Start with B>C>E and B>D>E being equal cost A If C fails, B and E can shift from sharing traffic between C and D to sending traffic to D only B Number of routers involved in convergence: 2 (B and E) C D Convergence time is in the milliseconds E F 33

30 Link State C fails B and E flood new topology information A SPF All routers run SPF to calculate new shortest paths through the network B and E change their routing tables to reflect the changed topology Number of routers involved in convergence: 2 (B and E) SPF C B E F D 34

31 Link State Within a single flooding domain A single area in OSPF A single flooding domain in IS-IS Convergence time depends on flooding timers, SPF timers, and number of nodes/leafs in the SPF tree What happens when we cross a flooding domain boundary? 35

32 Link State E floods topology changes to C and D C and D summarize these topology changes (removing the topology information), and flood it to B B builds a summary from the summary flooded to B, and floods it into area 2 A calculates a route to B, then recurses C onto B C A B E Area 2 Area 0 D Area 1 F 36

33 Link State Between flooding domains, link state protocols have distance vector characteristics This can have negative or positive impacts on convergence time in a large network + Reduces tree size + Allows partial SPFs, rather than full SPFs - Introduces translation and processing at the flooding domain boundaries The impact is primarily dependant on the network design 37

34 Link State Fast Convergence OSPF Carrier Delay Hello/dead timers (fast hellos) Bidirectional Forwarding Detection(BFD) LSA packet pacing Interface event dampening Exponential throttle timers for LSA & SPF MinLSArrivalInterval Incremental SPF ISIS Carrier Delay Hello/dead timers (fast hellos) Bidirectional Forwarding Detection (BFD) LSP pacing Interface event dampening Exponential throttle timers for LSP & SPF PRC interval Incremental SPF 38

35 Time Time Time Link State Convergence Data Convergence time with default timers and tuned timers IPv4 and IPv6 IGP convergence times are similar The IPv6 IGP implementations might not be fully optimized yet Not all Fast Convergence optimizations might be available Tuned IPv4 ISIS, Tuned IPv6 ISIS Tuned IPv4 OSPF, Untuned IPv6 OSPF Number of Prefixes Tuned IPv4 OSPF, Tuned IPv6 OSPF IPv4 OSPF IPv6 OSPF Linear (IPv IPv4 ISIS IPv6 ISIS Linear (IPv IPv4 OSPF IPv6 OSPF Linear (IPv Number of Prefixes Number of Prefixes 39

36 Link State Convergence - Summary Within a flooding domain The average convergence time, with default timers, is going to be in the order of seconds With fast timers, the convergence time can be in the 100s of milliseconds There are large networks (consisting out of multiple 100s of nodes) with subseconds convergence times Outside the flooding domain Network design and route aggregation are the primary determining factors of convergence speed 40

37 EIGRP DUAL works on a simple geometric principle: If my neighbor s cost to reach a given destination is less than my best cost, then the alternate path cannot be a loop B>D>E>F is 35 B>C>E>F is 30 D>E>F is 20, which is less than the best path, 30, so B>D>E>F cannot be a loop A B C E 10 F D 20 41

38 EIGRP B will install the path through C, and mark the path through D as a feasible successor When C fails, B looks for alternate loop free paths Finding one, it installs it Convergence time is in the milliseconds Number of routers involved in convergence: 2 (B and E) A 10 B C E 10 F D 42

39 EIGRP If the second path cannot be proven loop free B and E detect the failure, and have no alternate path A B B queries A and D C D A replies that it has no path D replies with its alternate path E queries D and F E F replies that it has no path D replies with its alternate path F 43

40 EIGRP Fast Convergence Local repair is becoming an essential element for high availability and convergence EIGRP through feasible successor always had the concept of local repair. This provides extremely fast convergence Failure detection mechanisms depend on techniques other then just routing protocols BFD can provide very fast failure detection Updating and repair are immediate 44

41 EIGRP Convergence Summary For paths with feasible successors, convergence time is in the milliseconds The existence of feasible successors is dependent on the network design For paths without feasible successors, convergence time is dependant on the number of routers that have to handle and reply to the query and on the number of prefixes that require querying Queries are blocked one hop beyond aggregation and route filters Query range is dependant on network design Good design is the key to fast convergence in an EIGRP network 45

42 Milliseconds Convergence Summary IS-IS with default timers OSPF with default timers EIGRP without feasible successors OSPF with tuned timers IS-IS with tuned timers EIGRP with feasible successors IPv4 IGP Convergence Data Routes 46

43 Convergence Summary It s possible to converge in under one second using any protocol, with the right network design Rules of Thumb: More aggregation leads to better performance for EIGRP Less aggregation leads to better performance for link state protocols If you re going to use link state protocols, tune the timers; but if you tune the timers, be careful with HA features, like GR/NSF 47

44 Time Time Time The IPv4 / IPv6 Co-existence Twist IPv6 IGP impact on the IPv4 IGP convergence Aggressive timers on both IGPs will highlight competition for resources Tuned IPv4 OSPF, Untuned IPv6 OSPF IPv4 OSPF IPv4 OSPF w/ IPv6 OSPF Is parity necessary from day 1? Number of Prefixes Tuned IPv4 ISIS, Tuned IPv6 ISIS Tuned IPv4 OSPF, Tuned IPv6 OSPF IPv4 ISIS IPv4 ISIS w/ IPv6 ISIS IPv4 OSPF IPv4 OSPF w/ IPv6 OSPF Number of Prefixes Number of Prefixes 48

45 Design and Topology Considerations

46 Topology Hub and Spoke Full Mesh Support for Hierarchy Topology Summary 50

47 Link State Hub and Spoke OSPF and IS-IS are similar when designing for hub and spoke topologies, so we ll look at them together Link state protocols rely on every router within a flooding domain having the same view of the network s topology to calculate loop free paths Link state flooding rules have implications for scaling and design in hub and spoke networks 51

48 Link State Hub and Spoke Although B can only reach C through A, it still receives all of C s routing information As the number of remote sites increases, the amount of information each remote site must process and store also increases B A reachability only through A D This limits scaling in link state hub and spoke networks C all link state information is flooded to B 52

49 /24 Link State Hub and Spoke Controlling route distribution Area 0 There s no way to allow C and D to receive information about /24, and not E and F A B F Area 1 E D C 53

50 Link State Hub and Spoke Transiting remote sites C and D issue summaries containing /24 A chooses D as it s best path to the summary The D to E link fails How can we prevent D from using the link through F to reach /24? /16 C /24 E /24 B A D F /24 54

51 Link State Hub and Spoke Place a link between C and D within the same area as the hub and spoke network The link cost between C and D should be lower than the link cost through F, causing D to route through this new link /16 C /24 B A D New link E /24 F /24 55

52 Link State Hub and Spoke For each hub and spoke flooding domain you add to the hub routers, you need an additional link between the hub routers in that domain You can use virtual links, such as Ethernet VLANs This can become difficult to manage in a large scale hub and spoke network Two Links, One in Each Flooding Domain 56

53 EIGRP Hub and Spoke Summary black holes C and D are both advertising /16 towards A and B C and D are advertising a default only to E and F A chooses D s path When the D to E link fails, D is still advertising /16 (based on /24 from F) Traffic forwarded to from A will be dropped /16 C /24 E /24 B A D F /24 57

54 EIGRP Hub and Spoke You can resolve this by placing A a link between C and D, without summarization /16 B New link C D /24 E /24 F /24 58

55 /24 EIGRP Hub and Spoke Controlling query range If A loses its connection to /24, it builds and transmits five queries: one to each remote, and one to B A B Each of the remote sites will query B B must process and reply to five queries 59

56 /24 EIGRP Hub and Spoke Prevent transit traffic through spokes A B If these spokes are remote sites, they have two connections for resiliency, not so they can transit traffic between A and B A should never use the spokes as a path to anything, so there s no reason to learn about, or query for, routes through these spokes Don t Use These Paths 60

57 /24 EIGRP Hub and Spoke To signal A and B that the paths through the spokes should not be used, the spoke routers can be configured as stubs A B router#config t# router(config)#router eigrp 100 router(config-router)#eigrp stub connected router(config-router)# 61

58 /24 EIGRP Hub and Spoke Marking the spokes as stubs allows them to signal A and B that they are not valid transit paths A B A simply will not query the remotes, reducing the total number of queries in this example to 1 62

59 /24 EIGRP Hub and Spoke Marking these remotes as stubs also reduces the topological complexity (meshiness) of the network A B Without spokes configured as stub routers, B believes it has five paths to /24, so it has to maintain five topology table entries 63

60 /24 EIGRP Hub and Spoke Routers which are configured as stubs will only advertise locally connected or redistributed destinations A B These remotes will not pass A s advertisement of /24 to B B will only have one path to /24 64

61 Hub and Spoke Design and Topology Summary For Your Reference Scaling Potential Issues Link State All remote sites receive all other remote site link state information; moderate scaling capability No effective means to control distribution of routing information Care must be taken to prevent transiting traffic through remote sites EIGRP Stub remote routers with filtering and aggregation; excellent scaling capability Care must be taken with summary black holes 65

62 Time (minutes) EIGRP Hub and Spoke How Many Neighbors (Initial Convergence)? The green line shows the rate at which the convergence time increases as EIGRP neighbors are added to hub routers and does not pass 500. The red line shows the convergence time if the neighbors added are all configured as EIGRP stub routers and scales to over 1000 peers. Measure initial bring up convergence until all neighbors are established and queues empty Dual Homed Remotes, NPE-G1 with 1G RAM, 3000 prefixes advertised to each spoke 9 Non-Stub EIGRP Stub 5 Test performed with 12.3(14)T Number of Neighbors 66

63 Time (minutes) EIGRP Hub and Spoke Failover Time? The green line with the steep slope shows the rate at which the failover convergence time increases as EIGRP neighbors are added to a single hub router The red line shows the failover convergence time if the neighbors added are all configured as EIGRP stub routers and is extremely linear in behavior. Primary Hub failed, time measured for EIGRP to complete failover convergence Dual Homed Remotes, NPE-G1 with 1G RAM, 3000 prefixes advertised to each spoke 60 Non-Stub 15 Test performed with 12.3(14)T1 1 EIGRP Stub Number of Neighbors 67

64 Seconds EIGRP OSPF EIGRP OSPF Hub and Spoke OSPF vs. EIGRP In the field, we see up to 800 dual homed remotes with EIGRP, and up to about 250 with OSPF Tested initial convergence and hard failover times 600 dual homed remote sites For hard failover, primary hub was 2 powered down Initial Failover 600 remotes 68

65 Full Mesh Full mesh topologies are complex: 2 routers = 1 link 3 routers = 3 links 4 routers = 6 links 5 routers = 10 links 6 routers = 15 links Adjacencies = links(links-1)/2 69

66 Link State Full Mesh Flooding routing information through a full mesh topology is also complicated Each router will, with optimal timing, receive at least one copy of every new piece of information from each neighbor on the full mesh There are several techniques you can use to reduce the amount of flooding in a full mesh New Information 70

67 Link State Full Mesh OSPF and IS-IS can both use mesh groups to reduce the flooding in a full mesh network Mesh groups are manually configured designated routers on the full mesh 71

68 Link State Full Mesh Pick two routers to flood into the mesh, and block flooding on the remainder This will reduce the number of times information is flooded over a full mesh topology This isn t a commonly used configuration For Your Reference These Routers Still Flood on each serial interface: interface serial x ip ospf database-filter all out... 72

69 Link State Full Mesh For Your Reference In IS-IS, each interface is placed in a mesh-group These Routers Still Flood Any LSPs received will not be retransmitted back out any other interface on the router in the same mesh-group To block all LSP flooding out of an interface, use isis meshgroup blocked This isn t a commonly used configuration On Each Serial Interface: interface serial x isis mesh-group

70 EIGRP Full Mesh Routes must be advertised between every pair of peers in the mesh so each router has the correct next hop and routing information Summarize Summarize Summarize Number the links so they can be summarized to a single advertisement at the edge Number the links so the link information can be filtered out at the edge Summarize Summarize Summarize 74

71 Summarization OSPF Support for Hierarchy OSPF has a hard edge at flooding domain borders Summarization and filtering can occur at this border Summarization and filtering can also be configured at routers redistributing routes into OSPF In a two layer hierarchy, the flooding domain border naturally lies on the aggregation/core boundary area 0 76

72 OSPF Support for Hierarchy In a three layer hierarchy, the decision of where to place the area border is more difficult Typically, the best option is to flow around complex areas of the network, attempting to separate them into different areas Examples would include full mesh areas, data centers with a large amount of parallelism, and large hub and spoke deployments High Degree of Complexity High Degree of Complexity 77

73 IS-IS Support for Hierarchy IS-IS has a hard edge at flooding domain borders, as well, but it s softer than OSPF s because the L2 routing domain can (and normally does) overlap with the L1 domains L1 L2 Summarization and filtering can occur at this border Summarization and filtering can also be configured at redistribution points L1 In a two layer hierarchy, the flooding domain border naturally lies on the aggregation/core boundary L1 78

74 IS-IS Support for Hierarchy In a three layer hierarchy, the decision of where to place the area border is more difficult Typically, the best option is to flow around complex areas of the network, attempting to separate them into different areas Examples would include full mesh areas, data centers with a large amount of parallelism, and large hub and spoke deployments High Degree of Complexity High Degree of Complexity 79

75 Summarization EIGRP Support for Hierarchy The depth of the hierarchy doesn t alter the way EIGRP is deployed; there are no hard edges Summarize at every boundary where possible Divide complexity with summarization points Distribution Core Access 81

76 Hierarchical Division Points Summary OSPF IS-IS EIGRP Hard flooding domain, summarization, and filtering border; area borders need to be considered when designing or modifying the network Softer flooding domain, summarization, and filtering border; L2 overlaps L1 domains, providing some flexibility; network design needs to consider flooding domain border Summarization and filtering where configured, no hard or soft borders other than what the network dictates (But this doesn t imply the network doesn t need to be designed!) 82

77 Design and Topology Considerations Summary Rules of Thumb EIGRP can perform better in large scale hub and spoke environments Link state protocols perform better in full mesh environments, if tuned correctly EIGRP tends to perform better in strongly hierarchical network models, link state protocols in flatter networks Note: With IPv6 a great deal of emphasis is placed on hierarchical addressing schemes. In certain environments, EIGRP becomes a good option to support such designs. 83

78 The IPv4 / IPv6 Co-existence Twist Single Process / Single Topology Single Process / Multi Topology Multi Process / Multi Topology Protocols IS-IS ST IS-IS MT OSPFv2 + OSPFv3 EIGRP + EIGRPv6 IP topologies Flooding + router/network resources Single (IPv4+IPv6) Congruent Multiple Non-congruent Multiple Non-congruent Common Common Multiple protocol instances on given link SPF Single Multiple Multiple (OSPF) LS databases / topology tables Control plane Single Large - Common - Less resource intensive - More deterministic IPv4/IPv6 co-existence Single Large - More separation - Protocol-specific optimization possible - More resource intensive Multiple - Clear separation - Protocol-specific optimization possible - More resource intensive 84

79 Protocol Features and Evolution Considerations

80 Other Considerations in IGP Selection Features improving performance, scalability and manageability - Fast Convergence Optimization - Graceful Restart (GR) - Routing Policy - On the Wire Efficiency - Unequal Cost Load Sharing - Metrics - Protocol Management Protocol evolution, new developments, agility in development Standardization 86

81 Graceful Restart Graceful Restart (GR) allows a router s control plane to reset without impacting (global) routing A Control Data Consider two routers connected over a single circuit Router A loses its control plane for some period of time It will take some time for Router B to recognize this failure, and react to it B Control Data 87

82 Graceful Restart During the time that A has failed, and B has not detected the failure, B will continue forwarding traffic through A A Control reset Data Once the control plane resets, the data plane will reset as well, and this traffic will be dropped NSF reduces or eliminates the traffic dropped while A s control plane is down B Control Data 88

83 Graceful Restart If A is NSF capable, the control plane will not reset the data plane when it restarts A Control no reset Data Instead, the forwarding information in the data plane is marked as stale Any traffic B sends to A will still be switched based on the last known forwarding information B Control Data mark forwarding information as stale 89

84 Graceful Restart While A s control plane is down, B s hold timer counts down A has to come back up and signal B before B s hold timer expires, or B will route around it When A comes back up, it signals B that it is still forwarding traffic, and would like to resynchronize This is the first step in Graceful Restart (GR) Hold Timer: A B Control Control Data Data 90

85 Graceful Restart For Your Reference GR Signaling Resynchronization OSPF (LLS/OOB) Link Local Signaling (LLS), Extending Hellos to Add Optional Information Out Of Band Synchronization (OOB), Creates a New Form of Synchronization (Similar to Standard Database Synchronization) OSPF (opaque LSAs) Grace LSA (Opaque LSA Carrying Neighbor State) Grace LSA (Opaque LSA Carrying Database Information) IS-IS Added TLV in Hello Packet Normal Database Synchronization IS-IS (Cisco) No Protocol Extensions Normal Database Synchronization EIGRP Added Bits in Hello Packet (Standard Format) Normal Topology Table Advertisement 91

86 IPv6 Fast Convergence and GR Summary (IOS) LSA/LSP generation exponential backoff throttling SPF execution exponential backoff throttling Bidirectional Forwarding Detection (BFD) OSPFv3 IS-IS for IPv6 EIGRPv6 Y Y N/A Y Y N/A Y Y (through IPv4 BFD) Y (CSCtk04807) Graceful Restart (GR) Y Y Y 93

87 Conclusions

88 What were the Questions? Is one protocol better than the others? Which routing protocol should I use in my network? Should I switch from the one I m using? Do the same selection rules apply to IPv4 and IPv6? How will my IPv4 and IPv6 routing protocols coexist? 120

89 So what are the Answers? There is no right answer! Consider: Your business requirements Your network design The coexistence between IPv4 and IPv6 Intangibles The three advanced IGP s are generally pretty close in capabilities, development, and other factors 121

90 Expertise (Intangible) What is your team comfortable with? What escalation resources and other support avenues are available? But remember, this isn t a popularity contest you don t buy your car based on the number of a given model sold, do you? An alternate way to look at it: what protocol would you like to learn? 122

91 Standardization (Intangible) Who s standard? OSPF: Standardized by the IETF IS-IS: Standardized by the ISO and the IETF EIGRP: Cisco Standard! Standardization is a tradeoff Promises interoperability Larger number of eyes looking at problems and finding new features Politics often influence standards and causes compromises New features are often difficult to push through standards committees, slowing their release 123

92 Memory (bytes) IPv4/IPv6 Coexistence Targeting parity is natural but consider the tradeoffs during the early phases of integration IPv4 and IPv6 can be decoupled offering a unique opportunity to try a new design with IPv6. Look at both congruent and non-congruent topology approaches Evaluate the additional resources required by IPv6 Take advantage of the IPv6 addressing resources show route afi-all summary Number of Routes IPv4 Unicast: Route Source Routes Backup Deleted Memory (bytes) connected local local SMIAP static ospf Total IPv6 Unicast: Route Source Routes Backup Deleted Memory (bytes) connected local ospf Total IPv4 IPv6 Linear 124

93 Topology and Hiearchy IP Version Agnostic Rules of Thumb Mesh Hub and Spoke Link State Flat Hierarchy EIGRP Flat Aggregated 125

94 Key Takeaways Your choice of routing protocol depends on the type of network you have and the requirements you have for it Based on specific requirements and criteria, one routing protocol can be better suited than another one. The step from IPv4 to IPv6 routing protocols is evolutionary rather than revolutionary The same selection rules will apply for the IPv6 IGP as for the IPv4 IGP. Potential IPv4 / IPv6 routing protocol co-existence issues need to be understood and analysed. 126

95 Recommended Reading for 127

96 Call to Action Visit the Cisco Campus at the World of Solutions to experience the following demos/solutions in action: Borderless Networks Get hands-on experience with the following Walk-in Labs Advanced DMVPN, FlexVPN in Practice, Configuring and Connecting to an IPv6 enabled ASA, IPv4 via IPv6: MAP and DS-Lite Lab Meet the Engineer I m available 29-31/1 Discuss your project s challenges at the Technical Solutions Clinics 128

97 129

98 Thank You!

99