Routing Protocols. Recap & Concepts

Transcription

1 Routing Protocols Recap & Concepts Before we start to look at routing protocols, let s review what we know so far. Each interface connects to a link: The most common link technology today is an Ethernet, a multi-access link. There can be many hosts and routers connected to the link. To send an IP packet to another system on the same link, the packet must be wrapped in a frame with the appropriate link addresses. A multi-access link connected to an interface is commonly referred to as the directly connected network or local network for that interface. This usage comes about because a network id 1 is used to recognise whether an IP address belongs to a system connected to the same multi-access link. If the destination host for a packet is not connected to the same local network as the sender, the packet must be sent to a router connected to the local network, commonly called the first-hop router. The first-hop router will forward the packet towards the destination using a link connected to some other interface of the gateway. The packet will be forwarded by intermediate routers until it eventually reaches the last-hop router, which has an interface connected to the same multi-access link as the destination. We ve described the forwarding mechanism used in the Internet: Every router and host has a forwarding table (also called a routing table), with entries that specify an address prefix, a mask (to isolate the prefix in an IP destination address), an interface to transmit frames, and (if necessary) a first-hop router to forward the packet towards its destination. To determine how to send a packet, a router or host uses the IP forwarding algorithm. The destination address D is extracted from the IP packet. 1 We can correctly say network id here because, for directly connected systems, the forwarding prefix really is the network portion of the IP address, for both IPv4 and IPv6. 1 July, 2014

2 For each entry in the forwarding table, we form the logical AND of the entry s mask with D and test whether the result matches the address prefix contained in the entry. We use the forwarding table entry associated with the longest such match. The packet will be sent using the interface specified in this entry. The link-layer (MAC) address will be the link-layer address of the destination, if the destination is directly connected to the local network, or the link-layer address of the first-hop router. To forward the packet, the packet is wrapped in a frame (an Ethernet frame, for example) with the link-layer destination address set as specified in the previous step. The frame is transmitted from the interface selected in the previous step. How do entries get into the forwarding table? The answer depends on whether the system is a router or a host. Typically, hosts do not participate in routing protocols. The initial entries in a host s forwarding table are placed there during configuration of the interface. What might we see? An entry for link-local addresses. In IPv6, this entry will specify the linklocal address prefix fe80::/10. In IPv4, this entry will specify the address prefix /16, reserved for dynamic configuration. A default entry, to be used when no other entry matches. For IPv6, this entry will specify the prefix ::/0. For IPv4, this entry will specify the prefix /0. Typically, this entry contains the IP address of a router used to forward IP packets to destinations off the local network. If the systems connected to the local network have routable IP addresses 2 in addition to link-local addresses, there must be an entry with a prefix and mask matching the IP addresses of systems directly connected to the interface. In IPv4, this information is obtained from a DHCP server or from information in configuration files 3 added by a human. In IPv6, information about on-link prefixes can also be obtained from Router Advertisements. 2 Either globally routable, or selected from the IPv6 unique-local block fc00:/7 or the IPv4 private-use IP blocks /8, /12, and /16 that are routable within an organisation. 3 The details of the configuration file structure will vary from system to system. For linux systems, /etc/sysctl.conf controls global properties like forwarding and acceptance of redirects. Configuration of individual interfaces may be in a single file (e.g., /etc/network/interfaces on an Ubuntu system) or in a collection of files in a 2 July, 2014

3 In environments with multiple routers attached to the local network, it may be useful to have explicit entries for address prefixes that specify off-link destinations so that hosts can choose the correct router to forward a packet. In IPv4, this information can be obtained from a DHCP server or specified in configuration files added by a human 4. In IPv6, information about off-link prefixes can also be obtained from Router Advertisements. Multicast addresses may be subsumed by the default entry, or there may be explicit entries. IPv4 multicast addresses have a prefix of /4. For IPv6, the multicast prefix is ff00::/8. Subsequently, routers may use ICMP redirect messages to add information to a host s forwarding table 5. System administrators can also manipulate the forwarding tables using the command line tools and configuration GUIs provided by the system. In the common case, there will be one IP network mapped onto a link, and the address prefix and mask in the forwarding table entry match the network id portion of an IP address. It s possible, though uncommon, to map multiple IP networks onto a single physical link. There may be a single forwarding table entry with an address prefix that covers all of the network ids, or there may be multiple entries with distinct prefixes. Static routes are well and good, but as the number of connected networks within an organization grows and the intranet becomes complicated and dynamic 6 it s better to automate the process of determining routes. With dynamic directory (e.g., /etc/sysconfig/network-scripts/ifcfg-dev on a Fedora system). These files are processed by the scripts or programs that initialise interfaces and the network protocol stack. 4 Specifying forwarding table entries with information in configuration files is often referred to as static routing. 5 Implementations may maintain a cache of forwarding information, with each entry in the cache labelled with a full IP address. This avoids working through the full IP forwarding algorithm for frequently used destinations. Depending on the implementation, an ICMP redirect message may result in a new entry in the forwarding table or it may result in an entry in the forwarding cache only. 6 It s useful to recall how an internet becomes dynamic as it grows. One source is planned change corresponding to organisational change. Networks come and go to match changes in the organisation s structure. Another source is unplanned change due to equipment failure. Size matters. Individual pieces (networks and components) may be stable over periods of years, but if there are 10 s of thousands of pieces, change will occur somewhere every few hours. 3 July, 2014

4 routing, routers exchange routing information using routing protocols and use this information to continuously recalculate the best routes and update their forwarding tables. Before proceeding further into routing protocols, we need to define the concept of an autonomous system and use it to distinguish two broad groups of routing protocols. An autonomous system (AS) is a group of networks (more specifically, a group of routers) under the control of a single administrative authority. It is assumed that this will result in all routers in the autonomous system using a coordinated set of routing policies. To route packets within an AS, routers will communicate information using an interior gateway protocol (IGP), which generally determines the best routes based on some measurable routing metric (most commonly hop count, but often incorporating notions of transmission time). To route packets between ASs, routers will communicate information using an exterior gateway protocol (EGP), which has provisions for defining and ranking routes based on fairly arbitrary policy issues. The underlying assumption is that within a single region of administrative control (a single AS) the only consideration is to move packets from source to destination as efificiently as possible. Once a packet begins to move between autonomous systems, political and administrative considerations become dominant, and nothing moves without explicit negotiated agreements. Company A may not want its packets to pass through a network controlled by rival Company B, or it might prefer to use ISP C because it offers a cheaper rate than ISP D. To communicate routing information, routers use routing protocols. These can be divided into three classes, based on the type of routing algorithm that is used. Distance-vector routing exchanges information in the form of {destination, metric} pairs. The metric is a property of the entire route to the destination. When a router receives news of a better route, it replaces its entry. When it receives news that a route no longer exists, it deletes the entry. No one router has any notion of the full network topology, and each believes what its neighbour says about the destinations the neighbour can reach. Link-state routing exchanges information in the form of a list of direct connections to neighbours. Each router publishes a list of {neighbour, metric} pairs which are flooded to all other routers. The metric is a property of the direct link to the immediate neighbour. Each router builds a directed 4 July, 2014

5 graph model of the full network based on this information, and then runs a shortest path calculation to determine how to reach other destinations. This procedure avoids a number of pitfalls inherent in distance-vector routing. Path-vector routing exchanges information in the form of path attributes, which provide information about characteristics of the path that a packet will traverse as it travels from the source host to the destination host. This is not the same as specifying a route. Path attributes convey qualitative information, as opposed to detailed directions. Distance-vector and link-state routing algorithms are used for interior routing protocols. Path-vector routing is used for exterior routing protocols. Distance-vector routing is disappearing. It has persisted in use in spite of its limitations, because it came first, and because it performs adequately on smallto medium-sized systems which are reasonably stable. 5 July, 2014

6 Routing Information Protocol The Routing Information Protocol () was originally defined in RFC 1058 in 1988 but was in wide use prior to publication of the standard. The de facto standard was the implementation of routed distributed as part of Berkely Unix. We re going to go directly to -2, documented in RFC 2453, Version supports only IPv4. It s essentially -1 with support for CIDR (i.e., it includes a prefix and mask as part of the information for a route). Because -2 is an incremental improvement in capability, -1 and -2 are mostly compatible if care is taken to conform to the classful addressing scheme. While we re citing RFCs, it s important to mention RFC 1812, Requirements for IP Version 4 Routers, which collects in one document a wealth of information about the implementation of an Internet router. Recall that the basic operation in a distance-vector protocol goes like this: When a route update arrives, check it against the current routing database 7. If the update came from the router that s listed as the first-hop router in the current entry for the route, use the update, even if the new metric is worse than the old one. Otherwise, if the metric included in the update is better than the metric for the existing entry for the route, replace the existing entry with the contents of the update. This will change the first-hop router for the route. If there s no existing entry for the route, add the new route. Seems simple enough. What can go wrong? Lots of things, unfortunately, unless we take some care in the implementation. Recall the count to infinity problem from Cmpt 371. The classic configuration is shown to the right. Initially, R1 can reach N in one hop, and R2 can reach N through R1 in two hops. Assume the link {R1,N} fails. R1 updates its routing table to indicate that the route to N is unusable by setting the metric to infinity. 7 Any routing algorithm will maintain data structures appropriate for the information exchanged by the algorithm and the calculations it performs on that information. Eventually, the final result of the algorithm will be used to update the forwarding table. Rather than write this out in detail for each algorithm, the notes may simply refer to the routing database. R2 R1 N 6 July, 2014

7 Then, just in time to save the day, an update arrives from R2 claiming that it can reach N in two hops. R1 happily installs the new route to N through R2, giving it a metric of three hops. When R1 sends out its next update, it claims it can reach N in three hops. R2 notices, and since its route to N is through R1, bumps its metric for the route to four hops. And sends this information to R1... This cycle will not end until R1 and R2 have counted to infinity. To guarantee finite termination, is declared to be some suitably small integer. In the case of, = 16. To avoid this count to infinity scenario between a pair of routers, the protocol requires the use of the split horizon rule when sending routing updates. The rule is don t advertise a route to the first-hop router for the route. In the more general context of a multi-access link (such as Ethernet) with multiple routers advertising on the link, the rule becomes don t advertise a route out the interface that s used by the route (i.e., the interface where the routing update arrived). A stronger technique is called split horizon with poison reverse. If router R1 uses router R2 as the first hop for a route to net N, router R1 should advertise to R2 a route to net N with a cost of. (I.e., R1 should not simply omit any mention of net N in updates to R2. It should explicitly advertise to R2 that it cannot reach net N.) The rationale for poison reverse is that if router R2 should somehow come to the mistaken belief that it can reach net N through R1, poison reverse will cause the route to be immediately discarded. Note that in an environment with many individual routes, this can result in a dramatic increase in the size of routing update messages. The explanation of poison reverse in the text is incorrect. See 3.4.3, 3.4.4, and 3.8 of RFC 2453, Version 2. For recommendations on how to implement poison reverse, see RFC 1812, F.2.2. The explanation of poison reverse is most often given in terms of a pair of routers connected by a point-to-point link. It works just as well on a multiaccess link like Ethernet, where several routers may be listening. Any router that has a viable alternative route will be advertising a reasonable metric, and that route will be adopted by all other routers. 7 July, 2014

8 Unfortunately, split horizon is not sufificient to avoid count-toinfinity if more than two routers are involved. The example from RFC 2453 is shown in the figure to the right. Suppose the network has been stable for a while, and R1 and R3 have entries in their routing table specifying a route to N using R2 as the first-hop router. (R2 will then use the link between R2 and R4 to forward packets to N, but this is not known by any router other than R2. Remember that in no router has a complete picture of the network.) R1 1 R2 1 1 R R4 1 N Suppose link {R2,R4} fails. What we d like to see happen is a quick changeover to use link {R3,R4}, previously unattractive because of its high cost. R2 will notice immediately that the link has gone down, and will change its own routing table to reflect this. But R1 and R3 will continue to advertise routes to N to each other. Since they got these routes from R2, split horizon is no help. And neither R1 or R3 are aware that R2 is in the other s route. Table 1 shows the sequence of routing updates. The first line shows the situation before link {R2, R4} fails. The second line shows the situation immediately after the failure of the link. Assume that R2 sends out updates to each neighbour at a regular interval, and that the time for an update message to R1 arrives. The third line shows the situation after R1 processes this update. The trouble really starts between the third and fourth lines. Assume that the time comes for R3 to send an update to R1, and it sends the update before it receives an update from R2. The fourth line shows the situation after R1 has processed the update from R3. A count-to-infinity cycle is inevitable at this point, even if R2 gets off an update to R3 as shown in the fifth line. The remainder of the lines follow the count-to-infinity cycle as updates flow between the routers. (For simplicity, the remaining lines assume an order where R1 updates R2, R2 updates R3, R3 updates R1,...) All through the above, router R4 has been advertising to R3 a route to N with cost 11. The cycle ends when the cost of the route through R2 exceeds the cost of the route through R4. R3 adopts the route through R4. Subsequent updates from R3 will be accepted by R1 and R2, resulting in the situation shown on the last line of the table. 8 July, 2014

9 R1 R2 R3 Dest Gate Hops Dest Gate Hops Dest Gate Hops N R2 3 N R4 2 N R2 3 initial stable state N R2 3 N R4 N R2 3 {R2,R4} fails N R2 N R4 N R2 3 R2 updates R1 N R3 4 N R4 N R2 3 R3 updates R1 N R3 4 N R4 N R2 R2 updates R3 N R3 4 N R1 5 N R2 R1 updates R2 N R3 4 N R1 5 N R2 6 R2 updates R3 N R3 7 N R1 5 N R2 6 R3 updates R1 N R3 7 N R1 8 N R2 6 R1 updates R2 N R3 7 N R1 8 N R2 9 R2 updates R3 N R3 10 N R1 8 N R2 9 R3 updates R1 N R3 10 N R1 11 N R2 9 R1 updates R2 N R3 10 N R1 11 N R4 11 R3 prefers route through R4 N R3 12 N R3 12 N R4 11 R1 and R2 now route through R3 Table 1: Routing updates for count-to-infinity example from RFC 2453 To minimise the possibility of a count-to-infinity cycle, uses a technique called triggered update. Triggered update counts on the rule that says a router must use an update from the router listed as the first hop for the route. The aim is to get the bad news to neighbours as soon as possible. Normally, routers using broadcast routing update messages every 30 seconds, plus/minus a small random delay to avoid synchronisation. The count-to-infinity problem arises when a router propagates stale information about a route. To combat the problem, triggered update requires that whenever a router changes the metric on a route, it must send out an update immediately. In the previous example, if R2 had managed to get updates to R1 and R3 before one of them updated the other, the count-to-infinity loop would have been avoided. In essence, the bad news propagates out as a tree from the router connected 9 July, 2014

10 to the failed link. Propagation ends when a router is encountered which has a route that comes from somewhere else, or when the update reaches a router where the route is absent or already has a metric of. The hope is that propagating up-to-date information immediately will minimise the number of count-to-infinity cycles that develop from propagating second-hand outdated information. Note: minimise, not eliminate. With bad timing, count-to-infinity cycles can still occur. To further reduce the chance of using an untimely update, we can apply holddown. For a fixed amount of time (on the order of 60 seconds) after receiving an update that says a route has disappeared, routers should ignore updates which offer alternative routes. This gives still more time for correct routing updates to propagate. Legitimate alternate routes will survive, because at some point they will originate from a different source. Note that neither RFC 2453 or RFC 1812 mention holddown for the protocol. It is an extension used in some implementations. All of the above problems make fairly inefificient. There can be lots of trafific once a routing change starts to propagate, and we can still have convergence problems in spite of all the effort put into minimising the time window where a count-to-infinity cycle can start. On the plus side, is simple. If an intranet is simple, fairly static, and the routers don t have to interact with routers running other routing protocols, may be adequate. That covers the basic techniques let s look at the details. -2 runs over UDP, using the well-known UDP port 520. Routers running -2 belong to two multicast groups related to routing: is all routers running -2, and is all routers on this subnet (synonymous with all routers on the local network). Each message consists of a one-word header followed by up to 25 route descriptions (called entries in the RFCs). The format of the header is command (8) version (8) must be 0 (16) The command can be one of request, reply, or several other specialpurpose commands used for router control and debugging. The version can be either 1 or 2. An explicit message length field is not necessary the length can be calculated from the size field in the UDP header. 10 July, 2014

11 The format of a entry is address family identifier (16) route tag (16) IP address (32) subnet mask (32) next hop (32) metric (32) The address family identifier specifies the protocol family of this routing entry. -1 was designed to be capable of supporting protocol families other than IP, but this has been compromised in entries included only an address and a metric, which allowed the address to occupy up to 12 bytes. IP addresses require only 4 bytes, and -2 uses the extra space for the address prefix mask ( subnet mask ) and next hop address. The route tag was intended to allow routers to distinguish between routes inside an autonomous system and routes outside the autonomous system, or more generally routes circulating within the group of routers exchanging messages vs. routes imported from outside the group. The original standard left room for various uses. The IP address and matching subnet mask are just what you d expect. The next hop field allows one router to report routes on behalf of other routers. This is intended for use in a network where distinct groups of routers exchange routing information amongst themselves, but contact between groups is limited to a set of designated routers. (For example, consider an Ethernet backbone with routers connecting to many subnetworks. A technique to reduce the amount of network trafific consumed by routing updates is to separate the routers into groups, with designated routers exchanging information between the groups. The designated router can specify that packets be sent to another router in its group, since all are on the same link.) The metric is the cost associated with the route. Traditionally, this is a hop count, but the protocol does not require this. The only restriction it imposes is that the metric be a value between 1 and = 16. In normal operation, we can identify five situations that trigger action: initialisation, request received for full routing table, update received, transmit regular update, and transmit triggered update. 11 July, 2014

12 A final situation, a request for a specific routing table entry, is intended for debugging and management. When the process initialises, it transmits a request over each active interface asking for any routers to send their complete routing tables. This request is multicast if possible using the -2 routers multicast address, By definition, a request containing a single entry with the address family field set to 0 and the metric set to 16 is a request for a router s entire routing table. Routers receiving this message should respond by sending their entire routing table. Split horizon processing is applied the requesting router could be recovering from a crash and the responding router may have routes which it obtained from the requesting router before the crash. When an update is received, the receiving router updates its tables according to the rules described previously: Use the new route information if it s an update from the first-hop router for the existing route. Use the new route if it s better than the previous known route, or if it s an entirely new route. Otherwise, ignore it. The protocol specification does suggest that if the receiving router has suspicions about the current route (i.e., the expiry timer is well along, indicating that the router that supplied the route is overdue to send an update) it might want to take preemptive action and switch to a new route. One possible result of an update message is that the metric for a route will be set to, triggering the route deletion process: When the metric is changed to, a garbage collection timer is set (typically 120 seconds, four times the 30 second update interval). The route is no longer used but is still included in update messages until the garbage collection timer expires, at which point it is purged from the routing table. 12 July, 2014

13 Every 30 seconds, routers are supposed to multicast a regular update message which includes the entire routing table, subject to the rules of split horizon processing. This is an important aspect of the protocol, because it works with a timeout mechanism to provide a way of purging dead routes. If a router does not receive an update for a route within 180 seconds, the route is marked for deletion and the route deletion process just described is initiated. A triggered update is sent as required, in response to a change in the metric for a route. Like a regular update, a triggered update is multicast if possible. As mentioned, the primary intent here is to immediately propagate correct information when a route goes down or the metric becomes worse. But appearance of a new route or a change for the better in the route metric can also trigger an update. RFC 1812 states that a triggered update is mandatory for bad news, and highly recommended for good news. In contrast to a regular update, only changed routes need to be included in a triggered update message. This implies that the protocol implementation should associate a change flag with each routing table entry, which is set when the entry is updated and cleared once all necessary triggered update messages have been sent. When a router receives a request for specific routing table entries, it responds by constructing a reply with the route information for the requested prefix, if present, setting the metric to 16 if it has no route. A request for a specific routing table entry will have the address family field set to the code for IPv4 and the address field set to the desired address. The responding router does not apply split horizon rules in response to a request for a specific route because it is assumed that this type of query is used for debugging and management. We don t want to be hiding information. Some loose ends to close out the discussion: -2 has provision for authentication; when it s used, the first entry is overloaded. The address family field is set to 0xffff and the route tag field is used to specify the type of authentication. The remaining 16 bytes 13 July, 2014

14 of the entry contain an authentication cookie. The standard defines only plain-text password authentication. More recent implementations provide encrypted authentication of various sorts. -2 applies random variations to its time delays to avoid router synchronisation. For example, when a route changes, you don t want the network flooded with triggered update messages. When a triggered update is sent, a random delay of 1 5 seconds is enforced before the router is allowed to send another update. The 30 second time delay between regularly scheduled updates is also adjusted with a random value between -5 and +5 seconds to prevent synchronization. An extension of for IPv6, ng, is described in RFC There are some changes that attempt to minimise the number of IPv6 addresses contained in a routing update. Otherwise, the algorithms and operation are unchanged. 14 July, 2014