Hubbry Logo
Routing protocolRouting protocolMain
Open search
Routing protocol
Community hub
Routing protocol
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Routing protocol
Routing protocol
Routing protocol
View on Wikipedia
from Wikipedia
Classification of routing protocols for computer networks

A routing protocol specifies how routers communicate with each other to distribute information that enables them to select paths between nodes on a computer network. Routers perform the traffic directing functions on the Internet; data packets are forwarded through the networks of the internet from router to router until they reach their destination computer. Routing algorithms determine the specific choice of route. Each router has a prior knowledge only of networks attached to it directly. A routing protocol shares this information first among immediate neighbors, and then throughout the network. This way, routers gain knowledge of the topology of the network. The ability of routing protocols to dynamically adjust to changing conditions such as disabled connections and components and route data around obstructions is what gives the Internet its fault tolerance and high availability.

The specific characteristics of routing protocols include the manner in which they avoid routing loops, the manner in which they select preferred routes, using information about hop costs, the time they require to reach routing convergence, their scalability, and other factors such as relay multiplexing and cloud access framework parameters. Certain additional characteristics such as multilayer interfacing may also be employed as a means of distributing uncompromised networking gateways to authorized ports.[1] This has the added benefit of preventing issues with routing protocol loops.[2]

Many routing protocols are defined in technical standards documents called RFCs.[3][4][5][6]

Types

[edit]

Although there are many types of routing protocols, three major classes are in widespread use on IP networks:

OSI layer designation

[edit]

Routing protocols, according to the OSI routing framework, are layer management protocols for the network layer, regardless of their transport mechanism:

Interior gateway protocols

[edit]

Interior gateway protocols (IGPs) exchange routing information within a single routing domain. Examples of IGPs include:

Exterior gateway protocols

[edit]

Exterior gateway protocols exchange routing information between autonomous systems. Examples include:

Routing software

[edit]

Many software implementations exist for most of the common routing protocols. Examples of open-source applications are Bird Internet routing daemon, Quagga, GNU Zebra, OpenBGPD, OpenOSPFD, and XORP.

Routed protocols

[edit]

Some network certification courses distinguish between routing protocols and routed protocols. A routed protocol is used to deliver application traffic. It provides appropriate addressing information in its internet layer or network layer to allow a packet to be forwarded from one network to another. Examples of routed protocols are the Internet Protocol (IP) and Internetwork Packet Exchange (IPX).

See also

[edit]

Notes

[edit]

References

[edit]

Further reading

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Routing protocol

View on Grokipedia
from Grokipedia
A routing protocol is a standardized set of rules and procedures that enables routers in a to dynamically exchange information about , destinations, and paths, allowing them to select and maintain optimal routes for forwarding data packets between nodes. These protocols operate at the network layer (Layer 3 of the ) and are essential for scalable , as they automate path discovery and adaptation to changes such as link failures, congestion, or topology updates, without requiring manual reconfiguration of every router. Unlike , which relies on fixed, administrator-defined routes suitable only for small or stable networks, protocols support by periodically sharing routing tables or updates among routers to build and refine a shared view of the network. Routing protocols are broadly classified into categories based on their scope and mechanism. Interior Gateway Protocols (IGPs) manage routing within a single autonomous system (AS), such as an enterprise network, and include distance-vector protocols like the Routing Information Protocol (RIP), which uses hop count as a metric to measure path distance and exchanges full routing tables periodically. Link-state IGPs, such as Open Shortest Path First (OSPF), flood link-state advertisements to all routers in the AS, enabling each to compute shortest paths independently using algorithms like Dijkstra's. In contrast, Exterior Gateway Protocols (EGPs) handle inter-AS routing across the broader internet; the dominant example is Border Gateway Protocol version 4 (BGP-4), a path-vector protocol that propagates AS-level path attributes to make policy-based decisions, ensuring scalability for the global Internet. Other variants, like hybrid protocols such as Enhanced Interior Gateway Routing Protocol (EIGRP), combine distance-vector and link-state elements for faster convergence and efficient bandwidth use in Cisco environments. Key aspects of routing protocols include convergence time—the speed at which the network stabilizes after a change—scalability to handle large topologies, and security features to mitigate threats like route hijacking or spoofing, as outlined in IETF guidelines. Metrics such as bandwidth, delay, load, and reliability guide path selection, with protocols prioritizing loop prevention. These protocols underpin modern networks, from local area networks (LANs) to the , while evolving to address emerging needs like and low-power IoT environments.

Overview

Definition and Purpose

A routing protocol is a standardized set of rules that enables routers to dynamically exchange information about the network topology and select optimal paths for data packets in a . These protocols operate at the network layer, facilitating communication between routers to build and maintain a map of the network's structure. The primary purpose of routing protocols is to automate route discovery and adaptation in packet-switched networks, such as the , ensuring efficient data transmission despite changes like link failures or congestion. They support load balancing across multiple paths to optimize resource use and provide by rerouting traffic around disruptions, thereby maintaining end-to-end connectivity. Core functions of routing protocols include neighbor discovery to identify directly connected routers, route advertisement to propagate topology updates, and path computation to evaluate and choose the best routes based on predefined metrics. Following network changes, protocols achieve convergence, the process by which all routers agree on a consistent set of routes, stabilizing the network. For instance, in IP networks, these protocols populate routing tables that guide to destination addresses. Importantly, routing protocols focus on building these tables in the , distinct from the data plane's role in actual packet transmission using the established routes.

Historical Development

The development of routing protocols began in the 1970s with the , the precursor to the modern , where initial packet-switching networks relied on basic mechanisms for forwarding data across interconnected systems. Early efforts included protocols for public data networks, such as X.25 standardized by the in 1976, which provided connection-oriented packet delivery but lacked dynamic routing capabilities suited for wide-area networks. This evolved with the introduction of the (IP) in RFC 791 in 1981, which established the foundation for datagram routing in interconnected packet-switched networks, emphasizing without built-in routing specifics. In the 1980s, as the ARPANET transitioned to TCP/IP and the early emerged, dedicated routing protocols were formalized to handle inter-network communication. The (EGP), specified in RFC 904 in 1984, became the first standard for exchanging reachability information between autonomous systems on the nascent , functioning primarily as a reachability protocol rather than a full solution. Shortly after, the (RIP), documented in RFC 1058 in 1988, emerged as the first widely adopted (IGP) for within local networks, using a simple distance-vector approach based on hop count to propagate updates. The 1990s marked a period of standardization and scalability improvements amid rapid Internet growth. (OSPF) was introduced in RFC 1131 in 1989 as a link-state IGP alternative to RIP, with significant updates in RFC 2328 in 1998 to enhance authentication, load balancing, and convergence. For inter-domain routing, the (BGP) debuted in RFC 1105 in 1989, evolving to BGP-4 in RFC 1771 in 1995, which introduced support for classless addressing to manage the expanding global . A pivotal shift occurred with the adoption of (CIDR) in RFC 1519 in 1993, transitioning from rigid classful addressing to flexible prefix-based aggregation, which conserved space and reduced sizes. Additionally, RFC 1812 in 1995 outlined comprehensive requirements for IPv4 routers, including forwarding behaviors and protocol support, standardizing implementation practices. Entering the 2000s, protocols saw enhancements for emerging needs like . (IS-IS), originally for OSI networks and adapted for IP in RFC 1195 in 1990, received extensions through Type-Length-Value (TLV) additions in the early 2000s, enabling multi-protocol support without major redesign. Meanwhile, Cisco's (EIGRP), developed as a proprietary hybrid protocol in the to improve upon RIP and IGRP, was opened to other vendors in 2013 via an IETF informational draft. These advancements addressed convergence challenges from expansion, with link-state protocols like OSPF and offering faster updates compared to early distance-vector methods.

Fundamental Concepts

Static vs. Dynamic Routing

Static routing involves the manual configuration of routes by network administrators, where specific paths are explicitly defined in the without any automatic adaptation to network changes. These routes remain fixed until manually updated, making them suitable for small, stable networks where alterations are infrequent. For instance, static routes are often used to direct to a or to reach non-connected networks that do not require ongoing monitoring. In contrast, dynamic routing employs protocols that enable routers to automatically discover, share, and update routing information with neighboring devices, allowing the network to adapt in real-time to events such as link failures or congestion. This approach relies on periodic exchanges of routing updates or event-triggered notifications to maintain an optimal path selection based on current network conditions. is essential for larger or more volatile environments, as it supports and resilience without constant human intervention. The primary differences between static and dynamic routing lie in their configuration, resource utilization, and adaptability. Static routing is simpler to implement, consumes minimal bandwidth and CPU resources since no update protocols are involved, and offers higher security by avoiding exposure to routing protocol vulnerabilities. However, it lacks scalability and fault tolerance, requiring manual reconfiguration for any changes, which can lead to downtime in dynamic environments. Dynamic routing, while more resource-intensive due to the overhead of protocol exchanges, provides automatic recovery from failures and better load balancing, though it introduces complexity and potential security risks from protocol interactions. Static routing is typically preferred in edge cases, such as defining default routes or in stub networks with predictable traffic patterns, whereas dynamic routing is ideal for core infrastructures experiencing frequent topology shifts. Many modern networks adopt a hybrid model, leveraging dynamic protocols for primary route learning while incorporating static routes as overrides or backups to ensure reliability and control in specific scenarios.

Key Routing Metrics and Algorithms

Routing protocols rely on metrics to assess and compare potential paths, enabling routers to select the most efficient route for based on predefined criteria. The hop count serves as the simplest metric, quantifying the number of intermediate routers () a packet must pass through to reach its destination; paths exceeding a certain hop limit, such as 15 in some implementations, are deemed unreachable. Bandwidth is a critical metric that prioritizes paths with greater data-carrying capacity to reduce potential bottlenecks and improve throughput. Delay encompasses the total latency along a path, including time, transmission delays, and queuing effects, favoring lower-latency routes for time-sensitive traffic. often represents a composite metric integrating multiple factors, such as bandwidth and delay, to balance speed and capacity in path selection. Reliability measures link stability by considering factors like error rates and uptime, while load evaluates current traffic utilization to avoid overburdened paths. Path selection in routing protocols is driven by algorithms that compute the "shortest" path according to the chosen metric, treating the network as a weighted graph where links represent edges and routers represent nodes. Link-state protocols utilize to construct a from a source router to all destinations, leveraging global topology knowledge; the algorithm iteratively selects the unvisited node with the minimum from the source and relaxes the distances to its neighbors using a for efficiency. This approach ensures optimal paths in stable networks but requires significant computational resources for large topologies. In contrast, distance-vector protocols implement the Bellman-Ford algorithm in a distributed manner, where each router periodically exchanges estimates with neighbors and updates its table via iterative relaxation. The Bellman-Ford equation forms the basis of these updates: dx(y)=min⁡v∈Nx{c(x,v)+dv(y)}d_x(y) = \min_{v \in N_x} \left\{ c(x,v) + d_v(y) \right\} where dx(y)d_x(y) denotes the shortest-path distance from router xx to destination yy, NxN_x is the set of xx's neighbors, c(x,v)c(x,v) is the between xx and neighbor vv, and the minimization occurs over all neighbors vv. In practice, a distance-vector update for the path to destination DD via neighbor NN computes the new distance as the sum of NN's reported metric to DD and the direct to NN, retaining the minimum across all neighbors. Convergence is the process by which routers synchronize their tables to a stable state following changes, such as link failures or additions; rapid convergence minimizes disruptions, but slow convergence in distance-vector protocols can propagate outdated information, leading to temporary inconsistencies. A notable issue during convergence is the count-to- problem, where routers incrementally increase distance metrics in a loop until reaching an threshold (e.g., 16 ), exacerbating delays and potential packet loss. To mitigate routing loops, loop-prevention mechanisms are integrated into protocols. Split horizon prevents a router from advertising a route back out the same interface on which it was learned, reducing the risk of reciprocal updates that could form loops between adjacent routers. Poison reverse extends split horizon by actively advertising such routes with an infinite metric (e.g., 16), explicitly signaling unreachability and accelerating loop detection and resolution. These techniques enhance stability in dynamic environments without requiring global knowledge.

Classification

By Network Scope

Routing protocols are classified by network scope into interior gateway protocols (IGPs) and exterior gateway protocols (EGPs), based on whether they operate within or across autonomous systems (ASes). An autonomous system is a collection of IP networks and routers under the control of one or more network operators that presents a common policy to the . ASes are assigned unique identifiers, known as autonomous system numbers (ASNs), by the (IANA), which allocates them to regional Internet registries. Originally, BGP-4 used 16-bit ASNs as defined in RFC 4271, but this was extended to 32-bit ASNs to accommodate growth, per RFC 6793. Interior gateway protocols (IGPs) are designed for within a single AS, focusing on intra-domain efficiency to enable fast convergence and optimal path selection based on network metrics like bandwidth or delay. They exchange information among routers under unified administrative control, prioritizing rapid adaptation to internal changes without considering external policies. Common IGPs include OSPF and , which support scalable intra-AS through mechanisms like hierarchical areas or levels. Exterior gateway protocols (EGPs), in contrast, facilitate inter-domain routing between multiple ASes, emphasizing scalability for the global Internet and policy-based decisions such as peering agreements or traffic engineering preferences over simple metrics. The original EGP specified in RFC 827 has been largely superseded by BGP, which handles route advertisement and selection across AS boundaries while preventing loops through path attributes. EGPs must manage vast scale, with BGP supporting millions of routes through aggregation and filtering, but they converge more slowly than IGPs due to policy validations. This scope distinction influences protocol design: IGPs optimize for low-latency internal operations, while EGPs incorporate administrative policies to enforce business or security rules across diverse domains. In practice, the core employs a hybrid approach, using BGP as the primary EGP for inter-AS connectivity and OSPF or as IGPs within backbone providers' ASes to distribute internal routes efficiently.

By OSI Layer

Routing protocols predominantly operate at Layer 3 of the , known as the Network Layer, where they perform path determination and packet forwarding based on logical addressing, such as IP addresses, abstracted from the specifics of the physical transmission medium. This layer's functions, as outlined in the , include relaying and routing data units across multiple interconnected networks to reach the destination . For instance, the (IP) exemplifies this by using hierarchical addressing to enable end-to-end delivery independent of underlying Layer 2 technologies like Ethernet or . Although primarily Layer 3 entities, routing protocols frequently interface with Layer 2, the , for essential operations such as adjacent router discovery and link status monitoring. A representative case is the use of Hello packets in protocols like OSPF, which are encapsulated in IP but rely on Layer 2 mechanisms, such as Ethernet framing and addressing, to exchange information between directly connected neighbors. These interactions ensure that Layer 3 routing decisions are informed by real-time Layer 2 topology changes without embedding physical details into the routing logic itself. Layer 4, the , plays a supporting role in many routing protocols by providing reliable message delivery, though it does not influence the routing computations. For example, BGP leverages TCP on port 179 to establish persistent sessions and ensure ordered, error-checked exchange of routing updates between peers, distinguishing it from connectionless alternatives that might use UDP. This transport mechanism enhances protocol robustness but remains ancillary to the core Layer 3 functions. The historical standardization of , particularly for IP networks, firmly anchors it at Layer 3, consistent with the OSI model's delineation in ISO/IEC 7498-1, which separates from lower-layer concerns. Notable exceptions include (ATM) networks, where routing and connection management blend Layer 2 switching with partial Layer 3 addressing, often described as operating at an intermediate "Layer 2.5." Overall, this Layer 3 orientation promotes interoperability, allowing routing protocols to function uniformly across varied Layer 2 media, from traditional wired links to modern wireless infrastructures, thereby supporting scalable, multi-vendor network deployments. Routed protocols like IP exemplify this layered independence.

By Algorithm Type

Routing protocols can be classified by their underlying algorithms, which determine how routers exchange and compute paths to destinations. The primary categories include distance-vector, link-state, path-vector, and hybrid algorithms, each balancing , convergence speed, and resource usage differently. In distance-vector algorithms, routers maintain a table of distances to all destinations and periodically share their entire with directly connected neighbors. Each router updates its table by selecting the minimum offered by neighbors, plus the link to that neighbor, using an iterative process based on the Bellman-Ford method. This approach relies on hop-by-hop updates, where routers propagate indirectly through . However, it is susceptible to routing loops without mechanisms like split horizon or poison reverse, which prevent advertising routes back to the next-hop neighbor or advertise infinite distances for such routes. Link-state algorithms enable each router to build a complete of the network by flooding link-state advertisements—summaries of a router's direct connections and their costs—to all other routers. Once the is constructed, each router independently computes the shortest paths to all destinations using a shortest-path-first , such as Dijkstra's. This flooding ensures a consistent view of the network across all nodes, allowing for rapid detection and response to changes like link failures. Sequence numbers in advertisements help manage updates and discard obsolete information. Path-vector algorithms extend distance-vector methods for larger, policy-driven environments by including not just distances but the full sequence of nodes (or autonomous systems) in the path to a destination. Routers exchange these path vectors with neighbors, rejecting any that include their own identifier to prevent loops without needing additional safeguards like split horizon. This inclusion of path attributes supports policy enforcement, such as preferring certain paths based on administrative rules, making it suitable for interdomain routing. Hybrid algorithms combine elements of distance-vector and link-state approaches to mitigate the limitations of each, such as using partial knowledge from link-state flooding within a limited scope while relying on distance-vector updates for broader propagation. This partial sharing reduces the overhead of full topology dissemination while improving convergence over pure distance-vector methods. Key features include incremental updates and load balancing, allowing routers to maintain efficiency in medium-sized networks. The choice among these algorithms involves trade-offs in and . Distance-vector algorithms require low CPU and , as they only track neighbor distances, but consume more bandwidth due to frequent full-table exchanges and converge slowly, exacerbating loop risks in dynamic networks. In contrast, link-state algorithms demand higher CPU for path computations and for the full but use bandwidth more efficiently after initial flooding and converge faster with fewer loops. Path-vector adds flexibility at the of larger sizes, while hybrids balance these by optimizing for in specific scopes.
AspectDistance-VectorLink-StatePath-VectorHybrid
CPU UsageLow (simple updates)High (full path calculations)Moderate (path checks + distances)Moderate (partial computations)
Memory UsageLow (neighbor tables only)High (complete topology)Moderate (paths + attributes)Moderate (selective topology)
BandwidthHigh (periodic full tables)Low after convergence (flooding initial)Moderate (path vectors)Low (incremental + partial)
ConvergenceSlow (reactive propagation)Fast (proactive flooding)Variable (policy-dependent)Fast (combined mechanisms)
Loop RiskHigh (needs safeguards)Low (global view)Low (self-detection in paths)Low (hybrid safeguards)
ScalabilityPoor for large networksGood for large networksGood for interdomainGood for medium networks
These trade-offs highlight how distance-vector suits simple, small networks with low overhead, while link-state excels in complex environments requiring quick adaptation.

Interior Gateway Protocols

Distance-Vector Protocols

Distance-vector protocols are a class of interior gateway protocols (IGPs) where routers maintain routing tables that list the distance (typically measured in or a metric) to all known destinations and periodically share these tables with neighboring routers. These protocols operate on the principle of distributed , where each router independently calculates its best paths based on information received from peers, without maintaining a complete map. The core mechanics rely on the Bellman-Ford algorithm for route computation. Routers broadcast their entire to directly connected neighbors at fixed intervals, such as every 30 seconds, using UDP port 520. Upon receiving an update, a router relaxes its distance estimates using the Bellman-Ford equation: Dx(y)=min⁡v{C(x,v)+Dv(y), Dx(y)}D_x(y) = \min_v \left\{ C(x,v) + D_v(y), \, D_x(y) \right\} where Dx(y)D_x(y) is the estimated distance from router xx to destination yy, C(x,v)C(x,v) is the cost of the link from xx to neighbor vv, and Dv(y)D_v(y) is the distance reported by vv to yy. This relaxation step ensures that routes are updated only if a shorter path is found, promoting convergence toward optimal distances over multiple iterations. A primary example is the (RIP), first specified in RFC 1058 as RIPv1 in 1988. RIPv1 is a classful protocol that assumes fixed network boundaries without subnet mask information, making it incompatible with modern variable-length subnet masking (VLSM). It enforces a maximum hop count of 15, with 16 denoting infinity (unreachable destinations), to prevent routing loops and limit network diameter. Although foundational to distance-vector routing, RIPv1 has become obsolete by 2025 due to its limitations in handling subnetted networks and lack of security features. RIPv2, defined in RFC 2453 (1998), addresses these shortcomings while retaining the core distance-vector mechanics. It supports VLSM through inclusion of subnet masks in route advertisements, enabling (CIDR). is provided via a simple MD5-based mechanism to verify update integrity, and updates are sent as multicasts to 224.0.0.9 rather than broadcasts for efficiency. The 15-hop limit and UDP port 520 remain unchanged. Distance-vector protocols offer advantages in simplicity and low , requiring minimal computational overhead as routers only need to store and exchange vectors rather than full data. This makes them suitable for small to medium-sized, stable networks with limited router capabilities. However, they suffer from slow convergence times, particularly after changes, as updates propagate hop-by-hop. The count-to-infinity problem exacerbates this, where a link causes routers to incrementally increase metrics in a loop until reaching infinity (16), potentially taking up to 15 iterations. loops can form temporarily during convergence, leading to or blackholing. Mitigations include split horizon (omitting routes learned from a neighbor in updates to that neighbor), poisoned reverse (advertising such routes with metric 16), and hold-down timers (temporarily ignoring updates for routes in flux for 180 seconds). The 15-hop limit also inherently curbs infinite counting but restricts to small networks. Link-state protocols are a class of interior gateway protocols (IGPs) used in IP networks to dynamically discover and maintain routing tables by exchanging detailed information among routers. Unlike distance-vector approaches, which rely on partial neighbor reports and can suffer from slow convergence and routing loops due to count-to-infinity problems, link-state protocols enable each router to independently compute optimal paths based on a complete network map. The core mechanics of link-state protocols involve the generation and flooding of Link-State Advertisements (LSAs), which describe a router's local links, including neighbors, costs, and states. These LSAs are reliably flooded across the network using a reliable flooding algorithm, ensuring every router receives identical copies. Each router then constructs a Link-State Database (LSDB) from the collected LSAs, representing the entire as a weighted graph. To derive forwarding tables, routers execute the Shortest Path First (SPF) algorithm, specifically , which computes the minimum-cost paths from the local router to all destinations. uses a to iteratively select the node with the lowest tentative , updating paths to neighbors with relaxation steps; its is O((V+E)log⁡V)O((V + E) \log V), where VV is the number of vertices (routers) and EE is the number of edges (links), making it efficient for moderate-sized networks with binary heaps. A prominent example is , standardized for IPv4 networks in RFC 2328 (1998). OSPFv2 organizes the network into areas to enhance , with Area 0 serving as the backbone for inter-area routing; LSAs are categorized into types such as Router LSAs (Type 1) for intra-area and Summary LSAs (Type 3) for inter-area routes. Adjacencies form via Hello packets sent to addresses 224.0.0.5 (all OSPF routers) and 224.0.0.6 (designated routers), enabling bidirectional neighbor detection and database synchronization through Database Description and Link-State Request exchanges. OSPFv2 supports fast convergence, typically within seconds, by triggering LSAs on changes and recomputing SPF trees. Another key protocol is , originally defined in ISO 10589 (1992) for Connectionless Network Service (CLNS) and adapted for via RFC 1195 (1990). IS-IS uses Link-State Protocol Data Units (PDUs)—analogous to LSAs—flooded within levels (Level 1 for intra-area, Level 2 for inter-area), with the network divided into areas for . It employs a type-length-value (TLV) encoding for flexibility, allowing extensions like support without protocol redesign, and uses addresses like 224.0.0.18 for Hellos. IS-IS is favored in large ISP backbones for its faster convergence (often sub-second with modern implementations) and lower overhead in stable topologies, as it avoids IP-specific assumptions inherent in OSPF. Link-state protocols offer several advantages, including rapid convergence after failures (typically 1-5 seconds), inherent loop prevention due to synchronized views, and support for equal-cost multipath (ECMP) to balance loads across equivalent paths. However, they demand significant CPU and memory resources for LSDB maintenance and SPF computations in large networks (e.g., thousands of routers), often necessitating area partitioning to limit flood scope and reduce overhead. issues can arise without careful configuration, as full-mesh flooding scales poorly beyond regional sizes.

Hybrid Protocols

Hybrid protocols, such as the (EIGRP), combine elements of distance-vector and link-state routing to achieve efficient, loop-free path computation within an autonomous system. Developed by Cisco Systems in the early 1990s as an enhancement to the (IGRP), EIGRP was initially proprietary but became an with the publication of RFC 7868 in 2016. Unlike pure distance-vector protocols that rely solely on periodic updates and can suffer from slow convergence and loops, or link-state protocols that flood complete topology information, hybrid approaches like EIGRP use partial topology knowledge to balance and speed. At the core of EIGRP's mechanics is the Diffusing Update Algorithm (DUAL), which ensures loop-free routing by diffusing computations across the network only when necessary. DUAL maintains a table that tracks routes advertised by neighbors, including the reported (RD) from each neighbor to a destination and the feasible (FD), which is the best-known from the local router. Loop prevention is achieved through the feasibility condition: a successor route is selected only if a neighbor's RD is less than the local FD, guaranteeing no loops without requiring global . This partial topology awareness allows EIGRP to propagate updates selectively, reducing overhead compared to full link-state flooding. The Reliable Transport Protocol (RTP) supports DUAL by providing reliable, ordered delivery of EIGRP packets via sequence numbers, acknowledgments, and retransmissions, using for efficiency in stable topologies and for queries. EIGRP employs a composite metric to evaluate path quality, incorporating bandwidth (K1), delay (K3), load (), and reliability (K5), with MTU (K4) and other factors optionally included; default values emphasize bandwidth and delay for a balanced assessment. The metric scales these components to produce a 32-bit value, enabling fine-grained path selection. EIGRP supports both IPv4 and , using protocol number 88 and addresses like 224.0.0.10 for IPv4 and FF02:0:0:0:0:0:0:A for IPv6. Route updates occur via hello packets for neighbor discovery and maintenance, with triggered updates for changes. Key advantages of EIGRP include rapid convergence through its query-and-response mechanism, where a router in active state queries neighbors for alternative paths and awaits replies before installing a new route, often sub-second in small networks. is enhanced by feasible successors—backup routes precomputed and stored in the topology that meet the feasibility condition—allowing instant without recomputation. This hybrid design minimizes bandwidth usage with partial updates while providing link-state-like loop prevention and fast recovery. However, EIGRP has limitations, including historical vendor specificity that restricted interoperability until RFC 7868, making it less open than standards like OSPF or . Potential issues like "stuck-in-active" states can arise if query replies timeout (default 180 seconds), leading to route recomputation delays, though mitigated by active timers and SIA queries. The DUAL (FSM) governs route states per destination, operating independently to ensure consistency. Routes are either passive (stable and usable, with a successor and optional feasible successors) or active (unusable during recomputation, triggered by topology changes like link failures). Transitions occur via events such as updates, queries, or replies: for instance, a passive route may become active upon successor loss, diffusing a query until sufficient replies confirm a loop-free path, after which it returns to passive. This state management avoids loops by only advertising distances from confirmed successors.

Exterior Gateway Protocols

Path-Vector Protocols

Path-vector protocols are a class of routing algorithms primarily used in exterior gateway protocols (EGPs) for inter-domain across autonomous systems (ASes) in large-scale networks like the . Unlike interior gateway protocols (IGPs) such as distance-vector methods, which focus on hop counts or metrics within a single domain, path-vector protocols maintain and advertise complete path sequences of ASes to destinations, enabling explicit path selection and policy enforcement. In terms of mechanics, path-vector protocols extend the distance-vector approach by including the full of ASes in route advertisements, rather than just a distance metric; routers append their own AS number to the path before propagating updates and select the best path based on local policies applied to these sequences. This allows for loop detection: if a router receives a path containing its own AS number, it discards the advertisement to prevent loops. Policies can then prioritize or reject paths based on attributes like AS sequence length or specific AS preferences, supporting complex inter-domain decisions. Key advantages include scalability for handling millions of routes across the global , as the path information abstracts internal domain details and reduces the need for full knowledge. Additionally, the protocol's policy-based nature enables autonomous systems to enforce business agreements, such as preferring shorter AS paths or avoiding certain transit providers, which is essential for commercial . However, path-vector protocols exhibit limitations, including slower convergence times compared to IGPs, often due to conflicts that cause prolonged route oscillations during network changes. —repeated advertisement and withdrawal of the same route—can also occur, exacerbating instability and increasing overhead in dynamic environments. Historically, path-vector protocols evolved from the original (EGP), specified in 1984 as a simple reachability exchange mechanism for early core gateways but limited to tree-like topologies and now obsolete. This led to the development of more robust path-vector designs, with the (BGP) emerging as the primary implementation for modern inter-domain routing.

Border Gateway Protocol (BGP)

The (BGP) serves as the primary for exchanging routing information between autonomous systems (ASes) on the , operating as a path-vector protocol that prevents routing loops by tracking AS paths. It enables decisions, allowing network operators to influence traffic flow based on business, performance, or security considerations, and has become the for interdomain routing since its widespread adoption in the 1990s. BGP version 4 (BGP-4), specified in RFC 4271 and published in 2006, forms the core of modern implementations and supports both IPv4 and addressing through multiprotocol extensions defined in RFC 4760. BGP establishes reliable sessions using TCP port 179, ensuring ordered and error-checked delivery of routing updates between peers. Key BGP attributes include well-known mandatory ones like AS_PATH, which records the sequence of ASes traversed to detect loops, and NEXT_HOP, which specifies the of the next router along the path. Optional attributes encompass LOCAL_PREF for prioritizing routes within an AS based on internal policies and MED (Multi-Exit Discriminator) for suggesting preferred entry points to external ASes. BGP operates in two main modes: external BGP (eBGP) for direct peering between adjacent ASes, typically over single-hop links, and internal BGP (iBGP) for disseminating routes within an AS, which traditionally requires a full of sessions or scalable alternatives like route reflectors to avoid N-squared connectivity overhead. Peers maintain sessions with periodic messages sent every 60 seconds by default to detect connectivity failures, while update messages propagate reachability information and withdraws remove invalid routes. Route selection follows a deterministic best-path that evaluates attributes in a fixed order: preferring the highest LOCAL_PREF, then the shortest AS_PATH length, followed by the lowest MED value among paths from the same neighboring AS, and additional tie-breakers such as the lowest IGP metric to the NEXT_HOP or the lowest router ID. To manage the Internet's scale, BGP handles a global IPv4 routing table exceeding 1 million prefixes as of November 2025, reflecting the growth in Internet-connected networks and address allocations. Mechanisms like route dampening, introduced in RFC 2439, suppress unstable routes that flap repeatedly—penalizing them with exponentially increasing suppression periods based on instability history—to prevent unnecessary propagation of transient failures across the network.

Modern Developments

IPv6-Specific Routing

Routing protocols for IPv6 have been developed through extensions to existing IPv4 protocols and the introduction of IPv6-native mechanisms to accommodate the protocol's expanded address space and features, such as mandatory support for IPsec and stateless address autoconfiguration. OSPFv3, defined in RFC 5340 (2008), adapts the Open Shortest Path First (OSPF) protocol for IPv6 by separating the control plane from the data plane, allowing OSPFv3 to operate independently of IPv4 while supporting multiple address families through link-local signaling and area flooding of link-local addresses (LLAs). This enables OSPFv3 routers to advertise IPv6 prefixes using opaque link-local addresses for neighbor discovery, ensuring compatibility with IPv6's neighbor discovery protocol (NDP). Similarly, RIPng (RIPv6), specified in RFC 2080 (1997), extends the distance-vector Routing Information Protocol for IPv6 by using UDP port 521 and IPv6 multicast addresses for updates, while introducing prefix lengths in route advertisements to handle IPv6's hierarchical addressing. For exterior routing, BGP's multiprotocol extensions in RFC 4760 (2007) enable the exchange of reachability information via the Address Family Identifier (AFI) and Subsequent Address Family Identifier (SAFI) mechanisms, allowing a single BGP session to carry both IPv4 and routes without requiring separate peering sessions. This (MP-BGP) uses the AFI value 2 for unicast (SAFI 1) and supports additional SAFIs for and VPNs, facilitating seamless integration in inter-domain environments. Intermediate System to Intermediate System () was extended for in RFC 5308 (2008), which introduces native Type-Length-Value (TLV) encodings to advertise prefixes directly in IS-IS link-state packets, leveraging the protocol's existing flooding mechanisms without altering its core adjacency formation. While no entirely new unicast routing protocols have achieved dominance for , Protocol Independent Multicast (PIM) in RFC 4601 (2003) provides robust support for routing through sparse-mode operations, using addresses (ff02::x) for protocol messages and embedded-RP mechanisms to simplify rendezvous point discovery in larger networks. These adaptations address -specific requirements, such as address handling in OSPFv3 and via route types that distinguish from prefixes, and routing challenges in PIM, where group address scoping prevents unintended flooding across sites. The larger 128-bit space poses challenges for protocols, primarily by increasing the potential size of forwarding information bases (FIBs) and requiring more efficient prefix aggregation to mitigate route table bloat, as evidenced by the model observed in BGP tables. and specifics further complicate deployment, as protocols like OSPFv3 must explicitly filter routes to avoid suboptimal paths, while PIM's implementation demands careful management of listener discovery (MLD) integration to handle source-specific trees efficiently. In practice, dual-stack operation—running IPv4 and protocols concurrently on the same routers—remains the predominant deployment model for IPv6 routing as of 2025, enabling gradual transition without disrupting existing IPv4 infrastructure. Full IPv6 routing tables in BGP have grown to approximately 238,000 entries by November 2025, reflecting increased adoption but still significantly smaller than IPv4 tables due to better aggregation practices.

Security Considerations

Routing protocols are susceptible to various security threats that can compromise network integrity, availability, and confidentiality. Key vulnerabilities include route spoofing and hijacking, where attackers falsely advertise routes to redirect traffic, often exploiting the trust-based nature of protocols like BGP through prefix announcements or leaks. Denial-of-service (DoS) attacks can overwhelm routers by flooding them with excessive updates or management messages, consuming CPU resources and disrupting routing convergence. Man-in-the-middle (MITM) attacks on peering sessions, such as those in BGP, allow or alteration of routing information since protocols like BGP lack inherent peer entity . In interior gateway protocols (IGPs), authentication mechanisms like are commonly used to protect against unauthorized updates; for instance, employs as specified in RFC 2082, while OSPF integrates it into its cryptographic framework per RFC 2328. However, IGPs remain vulnerable to sequence number attacks, where an attacker floods link-state advertisements (LSAs) with incremented sequence numbers in protocols like OSPF, causing routers to repeatedly recalculate the and leading to instability. For exterior gateway protocols (EGPs), particularly BGP, advanced mitigations address these issues. BGPsec, defined in RFC 8205, introduces cryptographic path validation using digital signatures to verify the authenticity and integrity of the AS path, preventing hijacking by ensuring each AS in the path has authorized the advertisement. Complementing this, the (RPKI) per RFC 6480 enables certificate-based origin validation through Route Origin Authorizations (ROAs), allowing routers to confirm that a prefix advertisement originates from the legitimate holder. General mitigation strategies across protocols include TTL security checks, such as the Generalized TTL Security Mechanism (GTSM) in RFC 5082, which discards packets with TTL values below an expected threshold (e.g., 254 for directly connected peers) to limit spoofing from off-path attackers by enforcing a hop count limit. or TLS-based encryption provides integrity for protocol messages, while on update reception helps counter DoS by capping the volume of incoming announcements. As of , BGPsec has seen no production deployment and remains largely experimental, with adoption limited due to implementation complexity and lack of widespread router support. Incidents underscore ongoing risks; for example, the stemmed from a BGP configuration error that inadvertently withdrew critical prefixes, severing global connectivity for hours and highlighting the fragility of even non-malicious misconfigurations. More recently, a incident involving the prefix 203.127.225.0/24 occurred in April , demonstrating persistent vulnerabilities despite mitigation efforts.

Integration with Software-Defined Networking

(SDN) fundamentally alters traditional routing by decoupling the from the data plane, enabling a centralized controller to manage network behavior through protocols like , which communicates with switches to install flow rules and compute routes, thereby replacing the distributed decision-making of protocols such as OSPF or BGP in core networks. In this architecture, traditional routing protocols are often retained at network edges for discovery and connectivity to legacy systems, while the SDN controller handles internal path optimization and traffic engineering. This shift allows for programmable routing policies that adapt dynamically to application needs, contrasting with the static convergence of conventional protocols. Key integrations between routing protocols and SDN include BGP FlowSpec, defined in RFC 5575, which extends BGP to distribute dynamic traffic filtering rules as Network Layer Reachability Information (NLRI), enabling SDN controllers to propagate policies for without altering core forwarding tables. Similarly, OSPF serves as an underlay protocol in SDN environments, providing link-state routing for the physical IP fabric that supports overlay networks; for instance, in , OSPF ensures robust connectivity across compute nodes and gateways, allowing the SDN overlay to focus on virtual tenant isolation. Within SDN, advanced protocols enhance routing programmability, such as P4, a that allows developers to define custom packet processing behaviors on switches, enabling flexible routing decisions like load balancing or in-network computing without relying on vendor-specific ASICs. Another example is (EVPN), outlined in RFC 7432, which leverages BGP as a to advertise MAC/IP reachability over VXLAN overlays, facilitating scalable multi-tenancy in SDN data centers by integrating with centralized controllers for endpoint discovery and mobility. The integration offers advantages like centralized policy enforcement, where a single controller applies consistent rules across the network, simplifying management compared to per-device configurations in traditional . It also improves scaling by offloading complex computations to the controller, reducing convergence times in large topologies, and supports hybrid models that combine SDN cores with traditional protocol edges for gradual adoption in enterprise environments. As of 2025, trends highlight SDN's role in networks, where BGP integrates with SDN controllers to enable network slicing, partitioning resources for low-latency services like autonomous vehicles via dynamic policy orchestration. In data centers, solutions like ACI exemplify widespread adoption, using SDN to automate BGP/EVPN overlays for intent-based networking and multi-cloud scaling.

Implementation and Tools

Routing Software

Routing software encompasses the implementations that execute routing protocols on network devices, enabling dynamic route computation and exchange. These implementations range from open-source daemons suitable for diverse environments to proprietary operating systems optimized for vendor-specific hardware. Open-source options provide flexibility and community-driven enhancements, while proprietary solutions offer integrated features tailored to enterprise-scale deployments. FRRouting (FRR), the successor to , is a prominent open-source routing protocol suite for and Unix systems, supporting key protocols such as BGP, OSPF, and . It facilitates routing, peering, and integration with containerized networks. BIRD serves as a lightweight, full-featured routing daemon, with a strong emphasis on BGP for use in Internet Exchange Points and high-performance environments. ExaBGP, a Python-based tool, functions as a versatile BGP implementation primarily for testing, route injection, and network attack mitigation scenarios. Proprietary routing software includes , which provides a comprehensive suite of routing protocols integrated into Cisco's for robust enterprise networking. Juniper Junos OS emphasizes modularity and supports protocols like , enabling consistent operation across Juniper hardware with features for large-scale routing. Arista EOS, a Linux-based , delivers extensible routing capabilities, including BGP and OSPF, with a focus on programmability for cloud data centers. A common architectural feature in routing software is the use of daemon-based designs for modularity and efficiency. In FRR, the zebra daemon acts as a central IP routing manager, handling kernel table updates, interface lookups, and route redistribution across protocols to ensure seamless integration with the host's networking stack. Many implementations, including FRR, incorporate Virtual Routing and Forwarding (VRF) support to enable MPLS-based segmentation, allowing multiple isolated routing instances on a single device for enhanced traffic isolation in service provider networks. Deployments of routing software extend to Linux-based routers like , an open-source platform that leverages FRR for protocol support in virtual and cloud environments. In cloud infrastructures, AWS Transit Gateway utilizes BGP for dynamic routing across virtual private clouds and on-premises connections, providing scalable hub-and-spoke topologies. Additionally, FRR supports containerization, with Docker images and deployments like frr-k8s enabling BGP route advertisement in cluster-based networks.

Routed Protocols

Routed protocols are protocols that carry user data across networks, such as IP packets, and can be forwarded by routers from source to destination based on addressing information. These protocols operate independently of protocols but depend on them to determine forwarding paths, as protocols exchange topology information to populate routing tables used for packet delivery. Prominent examples include Internet Protocol version 4 (IPv4) and version 6 (), which dominate modern by providing logical addressing and fragmentation for end-to-end data transmission. Legacy routed protocols, such as /Sequenced Packet Exchange (IPX/SPX) developed by for networks and for early Macintosh systems, were widely used in the 1980s and 1990s but have become obsolete with the shift to IP-based infrastructures. Routing protocols construct and maintain forwarding tables that enable routers to direct traffic for routed protocols; for instance, in IP networks, the (TOS) field in the IPv4 header (now evolved into Differentiated Services Code Point or DSCP in and updated IPv4) allows routing decisions to prioritize packets for (QoS). Operating at OSI Layer 3, routed protocols are encapsulated within Layer 2 frames, such as Ethernet, for transmission over , ensuring compatibility across diverse link-layer technologies. In contemporary networks, technologies like (MPLS) introduce pseudo-routed mechanisms by using labels to forward packets in lieu of traditional IP lookups, enhancing efficiency in service provider environments while still supporting IP as the underlying routed protocol. Similarly, Segment Routing (SR), as defined in RFC 8402, integrates source-based routing instructions directly into IP or MPLS headers, allowing explicit path control without intermediate state maintenance in routers.

References

  1. https://aws.amazon.com/what-is/routing/
  2. https://datatracker.ietf.org/doc/html/rfc1058
  3. https://datatracker.ietf.org/doc/html/rfc4271
  4. https://www.cisco.com/c/en/us/td/docs/security/firepower/70/fdm/fptd-fdm-config-guide-700/fptd-fdm-eigrp.html
  5. https://www.ietf.org/rfc/rfc4593.txt
  6. https://datatracker.ietf.org/doc/html/rfc6550
  7. https://do-server1.sfs.uwm.edu/key/21C86L6122/text/17C90L8/ospf__a-network__routing-protocol.pdf
  8. https://www.cisco.com/c/en/us/tech/ip/ip-routing/index.html
  9. https://community.cisco.com/t5/networking-knowledge-base/dynamic-routing-protocols-ospf-eigrp-ripv2-is-is-bgp/ta-p/4511577
  10. https://www.cisco.com/c/en/us/td/docs/security/asa/asa922/configuration/general/asa-922-general-config/route-overview.pdf
  11. https://learningnetwork.cisco.com/s/article/Routing-Protocols-an-Overview
  12. https://visor.mit.edu/6.02/_static/f2021/book/Chapter18.pdf
  13. https://www.cisco.com/site/us/en/learn/topics/networking/what-is-routing.html
  14. https://www.cs.utexas.edu/~mhan/courses/cs356r/sp23/lecture_notes/CS356R-07-01-Network-Intro-Forwarding-and-Routing.pdf
  15. https://www.internetsociety.org/internet/history-internet/brief-history-internet-related-networks/
  16. https://www.itu.int/en/ITU-T/studygroups/com17/Pages/history.aspx
  17. https://datatracker.ietf.org/doc/html/rfc791
  18. https://datatracker.ietf.org/doc/html/rfc904
  19. https://datatracker.ietf.org/doc/html/rfc2328
  20. https://datatracker.ietf.org/doc/rfc1105/
  21. https://datatracker.ietf.org/doc/html/rfc1519
  22. https://datatracker.ietf.org/doc/html/rfc1812
  23. https://datatracker.ietf.org/doc/html/rfc1195
  24. https://datatracker.ietf.org/doc/html/rfc5308
  25. https://datatracker.ietf.org/doc/html/rfc7868
  26. https://datatracker.ietf.org/doc/html/rfc5302
  27. https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/6-x/unicast/configuration/guide/l3_cli_nxos/l3_route.pdf
  28. https://www.rfc-editor.org/rfc/rfc1058.html
  29. https://www.cisco.com/c/en/us/support/docs/ip/interior-gateway-routing-protocol-igrp/13678-3.html
  30. https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/16406-eigrp-toc.html
  31. https://www.cs.yale.edu/homes/lans/readings/routing/dijkstra-routing-1959.pdf
  32. https://people.cs.rutgers.edu/~sn624/352-S19/lectures/12-nw.pdf
  33. https://www.iana.org/assignments/as-numbers
  34. https://datatracker.ietf.org/doc/html/rfc6793
  35. https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-xr-software/IOS-XR-Best-Practices/IOSXR-Deployment-BestPractices.html
  36. https://datatracker.ietf.org/doc/html/rfc827
  37. https://datatracker.ietf.org/doc/html/rfc2791
  38. https://datatracker.ietf.org/doc/html/rfc1930
  39. https://www.ecma-international.org/wp-content/uploads/s020269e.pdf
  40. https://www.geeksforgeeks.org/computer-networks/classification-of-routing-algorithms/
  41. https://cseweb.ucsd.edu/classes/fa11/cse123-a/123f11_Lec9.pdf
  42. https://eng.libretexts.org/Bookshelves/Computer_Science/Networks/An_Introduction_to_Computer_Networks_(Dordal)/09%3A_Routing-Update_Algorithms/9.06%3A_Link-State_Routing-Update_Algorithm
  43. https://www.sciencedirect.com/topics/computer-science/path-vector-protocol
  44. https://www.cbtnuggets.com/blog/technology/networking/link-state-distance-vector-vs-hybrid-routing-protocols
  45. https://orhanergun.net/link-state-vs-distance-vector
  46. https://www.firewall.cx/networking/routing-protocols/hybrid-routing.html
  47. https://datatracker.ietf.org/doc/html/rfc1058#section-2
  48. https://datatracker.ietf.org/doc/html/rfc1058#section-3.3
  49. https://datatracker.ietf.org/doc/html/rfc1058#section-2.2
  50. https://datatracker.ietf.org/doc/html/rfc1058#section-5.1
  51. https://datatracker.ietf.org/doc/html/rfc1058#section-3.5
  52. https://www.ietf.org/archive/id/draft-ietf-grow-routing-ops-terms-01.html
  53. https://datatracker.ietf.org/doc/html/rfc2453#section-4.3
  54. https://datatracker.ietf.org/doc/html/rfc2453#section-4.1
  55. https://datatracker.ietf.org/doc/html/rfc2453#section-3.5
  56. https://datatracker.ietf.org/doc/html/rfc1058#section-1.1
  57. https://datatracker.ietf.org/doc/html/rfc1058#section-1
  58. https://www.ciscopress.com/articles/article.asp?p=3188199
  59. https://escholarship.org/content/qt0j73185m/qt0j73185m.pdf
  60. https://datatracker.ietf.org/doc/html/rfc7868#section-5.6
  61. https://conferences.sigcomm.org/sigcomm/2003/papers/p49-sobrinho.pdf
  62. https://www.rfc-editor.org/rfc/rfc1105.html
  63. https://www2.cs.arizona.edu/~bzhang/paper/convergence.pdf
  64. https://www.manageengine.com/network-monitoring/tech-topics/route-flapping.html
  65. https://bgp.potaroo.net/as2.0/bgp-active.html
  66. https://bgp.potaroo.net/v6/as2.0/index.html
  67. https://blogs.cisco.com/industries/ipv6-in-2025-where-are-we
  68. https://www.cidr-report.org/v6/
  69. https://www.cloudflare.com/learning/security/glossary/bgp-hijacking/
  70. https://datatracker.ietf.org/doc/html/rfc2082
  71. https://datatracker.ietf.org/doc/html/rfc6863
  72. https://datatracker.ietf.org/doc/html/rfc8205
  73. https://datatracker.ietf.org/doc/html/rfc6480
  74. https://datatracker.ietf.org/doc/html/rfc5082
  75. https://blog.apnic.net/2025/05/23/bgpsec-could-you-run-it-if-you-wanted-to/
  76. https://blog.cloudflare.com/october-2021-facebook-outage/
  77. https://blog.apnic.net/2025/10/16/understanding-stealthy-bgp-hijacking-risk-in-the-rov-era/
  78. https://www.vmware.com/topics/software-defined-networking
  79. https://textbook.cs168.io/datacenter/sdn.html
  80. https://www.ibm.com/think/topics/sdn
  81. https://www.rfc-editor.org/rfc/rfc5575.html
  82. https://networklessons.com/vxlan/vxlan-underlay-ospf
  83. https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html
  84. https://www.sciencedirect.com/science/article/pii/S1389128621001109
  85. https://www.linkedin.com/pulse/ai-cloud-5g-emerging-tech-trends-driving-software-defined-nitin-k-4apec
  86. https://newsroom.cisco.com/c/dam/r/newsroom/pdfs/Cisco-2025-Networking-Research.pdf
  87. https://frrouting.org/
  88. https://bird.network.cz/
  89. https://github.com/Exa-Networks/exabgp
  90. https://www.juniper.net/us/en/products/operating-system.html
  91. https://www.arista.com/en/products/eos
  92. https://docs.frrouting.org/en/latest/zebra.html
  93. https://github.com/FRRouting/frr/issues/353
  94. https://docs.vyos.io/en/latest/
  95. https://github.com/metallb/frr-k8s
  96. https://learningnetwork.cisco.com/s/question/0D53i00000Kt0ygCAB/routing-and-routed-protocol
  97. https://networkengineering.stackexchange.com/questions/30955/what-is-the-difference-between-routing-protocols-and-routed-protcols
  98. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/configuration/15-s/iri-15-s-book/iri-iprouting.html
  99. https://www.certificationkits.com/cisco-routing-protocols/
  100. https://earthsci.stanford.edu/computing/resources/network/architecture/commonprotocols.php
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.