CA2521501C - Technique for notifying eigrp neighbors when destroying adjacencies in a computer network - Google Patents
Technique for notifying eigrp neighbors when destroying adjacencies in a computer network Download PDFInfo
- Publication number
- CA2521501C CA2521501C CA002521501A CA2521501A CA2521501C CA 2521501 C CA2521501 C CA 2521501C CA 002521501 A CA002521501 A CA 002521501A CA 2521501 A CA2521501 A CA 2521501A CA 2521501 C CA2521501 C CA 2521501C
- Authority
- CA
- Canada
- Prior art keywords
- goodbye
- neighbor
- router
- neighbors
- attribute
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/026—Details of "hello" or keep-alive messages
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/033—Topology update or discovery by updating distance vector protocols
Abstract
A technique efficiently notifies EIGRP neighbors when destroying adjacencies in a computer network. A goodbye notification packet is provided that enables an EIGRP router to inform one or more of its neighbors of its intention to destroy their existing adjacencies. The goodbye notification packet comprises an EIGRP packet header with variable-length fields embodied as an appended goodbye attribute. The appended goodbye attribute is illustratively tagged according to a TLV encoding format that defines a new type (T) field called "a goodbye" having a predetermined type that distinguishes it from a conventional EIGRP Hello packet. A value (V) field of infor~mation conveyed within the goodbye attribute contains a list of neighbor (peer) identi~fiers (IDs). The peer IDs on this list instruct those neighbor routers to "go away" so that their adjacencies can be destroyed.
Description
2 PCT/US2004/004615 TECHNIQUE FOR NOTIFYING EIGRP NEIGHBORS WHEN DESTROYING
ADJACENCIES IN A COMPUTER NETWORK
FIELD OF THE INVENTION
This invention relates generally to computer networks, and more particularly, to destruction of adjacencies between neighboring routers of a computer network.
BACKGROUND OF THE INVENTION
A computer network is a geographically distributed collection of interconnected communication links and sub-networks (subnets) for transporting data between nodes, such as computers. Many types of computer networks are available, with the types io ranging from local area networks (L,ANs) to wide area networks (WANs). A
LAN is an example of a subnet that provides relatively short distance communication among the interconnected nodes, whereas a WAN enables long distance communication over links provided by public or private telecommunications facilities. The nodes typically communicate by exchanging discrete .frames or packets of data according to predefined is protocols. In this context, a protocol consists of a. set of rules defining how the nodes interact with each other.
Computer networks may be further interconnected by an intermediate node, called a router, to extend the effective '6sme" of each network. since management of a large system of interconnect computer networks can prove burdensome, smaller groups zo of computer networks may be maintained as routing domains or autonomous systems.
The networks within an autonomous system are typically coupled together by conven-tional intradomain routers. These routers manage communication among local net-works within their domains and communicate with each other using an intradomain routing (or an interior gateway) protocol. An example of such a protocol is the En-zs hanced Interior Gateway Routing Protocol (EIGRP) described in Cisco TCPlIP
Routizzg PYOfessiozzal Reference, 2zzd Additiofz, Chapter 4, pgs. 104-108 (1999) and Enhanced Ihtej"ZOY GatewayRoutingP~otocol, httt~://www.cisco.com/warp/nublic/103/eigrp-toc.html (1992-2003).
The EIGRP protocol is a hybrid of distance vector and link state routing proto-col technologies. A distance vector protocol computes a best path to a destination us-ing distance ("cost" or hop count) and vector (the next hop) information. For EIGRP, the distance information is represented as a composite of available bandwidth, delay, .
load utilization and link reliability information that allows "fine tuning" of link charac-teristics to achieve optimal (or best) paths. Unlike most link state protocols that main-tain information or "state" of the entire network topology, an EIGRP roister only main-twins state pertaining to reachable neighboring roisters. As used herein, neighboring roisters (or "neighbors") are two roisters that have interfaces to a common network, to wherein an interface is a connection between a roister and one of its attached networks.
The state of each neighbor is stored in a neighbor data structure of the EIGRF
roister.
An adjacency is a relationship formed between selected neighbors for the pur-pose of exchanging routing information and abstracting the network topology.
One or more roister adjacencies may be established over an interface. Adjacencies are gener-is ally established, maintained and destroyed through the use of a conventional Hello protocol. Broadly stated, the Hello protocol ensures that communication between neighbors is bi-directional by periodically sending Hello packets out all roister inter-faces. Two roisters become neighbors when they see each other's Hello packets over the common network.
ao The EIGRP protocol includes a Neighbor Discovery process that roisters use to dynamically learn of other roisters on their directly attached networks.
Roisters also use this process to discover when their neighbors 'become unreachable or inoperative. The Neighbor Discovery process is achieved with low overhead by periodically sending small Hello packets at a rate called the "HelloInterval". The "HoldTime" is the amount as of time, i.e., a multiple of the HelloInterval, that an EIGRP roister will consider a neighbor alive without receiving a Hello packet. As long as the Hello packets are re-ceived from a neighbor within the HoldTime, the EIGRF roister determines that the neighbor is alive and functioning; this, in turn, allows both neighbors to exchange (and update) routing information to thereby reach routing convergence. However, if the so Hello packets are not received within the HoldTime, the roister assumes that the neigh bor no longer exists and "tears down" (destroys) the adjacency with the neighbor.
ADJACENCIES IN A COMPUTER NETWORK
FIELD OF THE INVENTION
This invention relates generally to computer networks, and more particularly, to destruction of adjacencies between neighboring routers of a computer network.
BACKGROUND OF THE INVENTION
A computer network is a geographically distributed collection of interconnected communication links and sub-networks (subnets) for transporting data between nodes, such as computers. Many types of computer networks are available, with the types io ranging from local area networks (L,ANs) to wide area networks (WANs). A
LAN is an example of a subnet that provides relatively short distance communication among the interconnected nodes, whereas a WAN enables long distance communication over links provided by public or private telecommunications facilities. The nodes typically communicate by exchanging discrete .frames or packets of data according to predefined is protocols. In this context, a protocol consists of a. set of rules defining how the nodes interact with each other.
Computer networks may be further interconnected by an intermediate node, called a router, to extend the effective '6sme" of each network. since management of a large system of interconnect computer networks can prove burdensome, smaller groups zo of computer networks may be maintained as routing domains or autonomous systems.
The networks within an autonomous system are typically coupled together by conven-tional intradomain routers. These routers manage communication among local net-works within their domains and communicate with each other using an intradomain routing (or an interior gateway) protocol. An example of such a protocol is the En-zs hanced Interior Gateway Routing Protocol (EIGRP) described in Cisco TCPlIP
Routizzg PYOfessiozzal Reference, 2zzd Additiofz, Chapter 4, pgs. 104-108 (1999) and Enhanced Ihtej"ZOY GatewayRoutingP~otocol, httt~://www.cisco.com/warp/nublic/103/eigrp-toc.html (1992-2003).
The EIGRP protocol is a hybrid of distance vector and link state routing proto-col technologies. A distance vector protocol computes a best path to a destination us-ing distance ("cost" or hop count) and vector (the next hop) information. For EIGRP, the distance information is represented as a composite of available bandwidth, delay, .
load utilization and link reliability information that allows "fine tuning" of link charac-teristics to achieve optimal (or best) paths. Unlike most link state protocols that main-tain information or "state" of the entire network topology, an EIGRP roister only main-twins state pertaining to reachable neighboring roisters. As used herein, neighboring roisters (or "neighbors") are two roisters that have interfaces to a common network, to wherein an interface is a connection between a roister and one of its attached networks.
The state of each neighbor is stored in a neighbor data structure of the EIGRF
roister.
An adjacency is a relationship formed between selected neighbors for the pur-pose of exchanging routing information and abstracting the network topology.
One or more roister adjacencies may be established over an interface. Adjacencies are gener-is ally established, maintained and destroyed through the use of a conventional Hello protocol. Broadly stated, the Hello protocol ensures that communication between neighbors is bi-directional by periodically sending Hello packets out all roister inter-faces. Two roisters become neighbors when they see each other's Hello packets over the common network.
ao The EIGRP protocol includes a Neighbor Discovery process that roisters use to dynamically learn of other roisters on their directly attached networks.
Roisters also use this process to discover when their neighbors 'become unreachable or inoperative. The Neighbor Discovery process is achieved with low overhead by periodically sending small Hello packets at a rate called the "HelloInterval". The "HoldTime" is the amount as of time, i.e., a multiple of the HelloInterval, that an EIGRP roister will consider a neighbor alive without receiving a Hello packet. As long as the Hello packets are re-ceived from a neighbor within the HoldTime, the EIGRF roister determines that the neighbor is alive and functioning; this, in turn, allows both neighbors to exchange (and update) routing information to thereby reach routing convergence. However, if the so Hello packets are not received within the HoldTime, the roister assumes that the neigh bor no longer exists and "tears down" (destroys) the adjacency with the neighbor.
-3-Often, it is desirable for a router to unilaterally decide to destroy an adjacency with its neighbor. In the case of a routing protocol that can maintain adjacencies over point-to-point interface connections, there may be electrical characteristics of the physical connection that disappear when the router "goes away" so that the neighbor can quickly detect that the router is gone. However, there are some point-to-point con-nection networks that do not provide electrical notification when a neighboring router disappears.
For a routing protocol that maintains adjacencies over mufti-access interfaces, such as an Ethernet subnet interface, there are typically no electrical characteristics to io inform the neighbors sharing that subnet that their neighboring router has disappeared.
One way the router can inform the neighbors of its impending disappearance is to send an unreliable, "terminate" message over the mufti-access interface indicating that the muter is going away. Routing protocols that have unreliable (e.g., broadcast) capabili-ties can use this type of terminate mechanism to destroy adjacencies. Yet it is often is undesirable to destroy all neighbor adjacencies using such an unreliable mechanism because there may be only a subset of adjacencies that needs terminating.
As noted, another conventional method of detecting neighbor (also referred to as "peer") loss and, subsequently, destroying an adjacency is "time-based"
through the absence of communication with the neighbor for a predetermined period of time.
As ao with the case of the EIGRP protocol, it can be assumed that the neighbor no longer ex-ists after expiration of that time period. However, it is also undesirable to assume the delay/latency associated with waiting the entire predetermined period of time, such as the HoldTime, to detect peer loss in order to destroy an existing adjacency.
Rather, it is desirable to promptly notify neighbors of an intention to destroy adjacencies so that the zs adjacencies can be quickly removed, thereby "speeding-up" routing convergence and improving network stability.
SUMMARY ~F THE INVENTION
The present invention overcomes the disadvantages of the prior art by providing a technique for efficiently notifying EIGRP neighbors when destroying adjacencies in a so computer network. According to the inventive technique, a novel goodbye notification
For a routing protocol that maintains adjacencies over mufti-access interfaces, such as an Ethernet subnet interface, there are typically no electrical characteristics to io inform the neighbors sharing that subnet that their neighboring router has disappeared.
One way the router can inform the neighbors of its impending disappearance is to send an unreliable, "terminate" message over the mufti-access interface indicating that the muter is going away. Routing protocols that have unreliable (e.g., broadcast) capabili-ties can use this type of terminate mechanism to destroy adjacencies. Yet it is often is undesirable to destroy all neighbor adjacencies using such an unreliable mechanism because there may be only a subset of adjacencies that needs terminating.
As noted, another conventional method of detecting neighbor (also referred to as "peer") loss and, subsequently, destroying an adjacency is "time-based"
through the absence of communication with the neighbor for a predetermined period of time.
As ao with the case of the EIGRP protocol, it can be assumed that the neighbor no longer ex-ists after expiration of that time period. However, it is also undesirable to assume the delay/latency associated with waiting the entire predetermined period of time, such as the HoldTime, to detect peer loss in order to destroy an existing adjacency.
Rather, it is desirable to promptly notify neighbors of an intention to destroy adjacencies so that the zs adjacencies can be quickly removed, thereby "speeding-up" routing convergence and improving network stability.
SUMMARY ~F THE INVENTION
The present invention overcomes the disadvantages of the prior art by providing a technique for efficiently notifying EIGRP neighbors when destroying adjacencies in a so computer network. According to the inventive technique, a novel goodbye notification
-4-packet is provided that enables an EI(~RP router to inform one or more of its neighbors of its intention to destroy their existing adjacencies. The goodbye notification packet comprises an EIGRF packet header with variable-length fields embodied as an ap-pended goodbye attribute. The appended goodbye attribute is illustratively tagged ac-cording to a TLV encoding format that defines a new type (T) field called "a goodbye"
having a predetermined type that distinguishes it from a conventional EIGRI' Hello packet. A value (V) field of information conveyed within the goodbye attribute con-tains a list of neighbor (or peer) identifiers (mss). The peer IDs on this list instruct those neighboring routers to "go away" so that their adjacencies can be destroyed.
io ~perationally, a router issues the goodbye notification packet to one or more neighbors. Upon receiving the goodbye notification packet, each neighbor examines the TLV encoded contents of the appended goodbye attribute. Specifically, the neigh-bor examines the type field of the novel attribute and, if it is configured to understand that type of information, identifies the packet as a goodbye notification packet. The is neighbor then examines the value field of the attribute, searching for its peer ~ within the list of peer mss. Upon discovering its peer ~, the neighbor is instructed to destroy the adjacency with the router, i.e., the source of the goodbye notification packet.
An advantage of the invention is the ability of the go~dbye notification packet to operate in both a reliable and an unreliable environment. That is, the goodbye notifi-2o cation packet may function as a reliable message when notifying a neighbor on a point-to-point connection (in a reliable environment) to go away. In addition, the goodbye notification packet may function as an unreliable message in an unreliable environment (shared network media) that notifies a subset of neighbors (through the list of peer 117s) to go away. This aspect of the invention enables scaling of goodbye notification as packet, as a single packet can include a list of peer mss, wherein the list can include one to as many as a maximum number of peer IDs. ~nly those routers identified by peer IDs proceed to destroy their adjacencies with the source of the goodbye packet. The goodbye packet can further function as a reliable message in an unreliable environment by identifying a single peer ID in the value field of the appended attribute, as well as an 3o unreliable message across an entire shared media subnet.
having a predetermined type that distinguishes it from a conventional EIGRI' Hello packet. A value (V) field of information conveyed within the goodbye attribute con-tains a list of neighbor (or peer) identifiers (mss). The peer IDs on this list instruct those neighboring routers to "go away" so that their adjacencies can be destroyed.
io ~perationally, a router issues the goodbye notification packet to one or more neighbors. Upon receiving the goodbye notification packet, each neighbor examines the TLV encoded contents of the appended goodbye attribute. Specifically, the neigh-bor examines the type field of the novel attribute and, if it is configured to understand that type of information, identifies the packet as a goodbye notification packet. The is neighbor then examines the value field of the attribute, searching for its peer ~ within the list of peer mss. Upon discovering its peer ~, the neighbor is instructed to destroy the adjacency with the router, i.e., the source of the goodbye notification packet.
An advantage of the invention is the ability of the go~dbye notification packet to operate in both a reliable and an unreliable environment. That is, the goodbye notifi-2o cation packet may function as a reliable message when notifying a neighbor on a point-to-point connection (in a reliable environment) to go away. In addition, the goodbye notification packet may function as an unreliable message in an unreliable environment (shared network media) that notifies a subset of neighbors (through the list of peer 117s) to go away. This aspect of the invention enables scaling of goodbye notification as packet, as a single packet can include a list of peer mss, wherein the list can include one to as many as a maximum number of peer IDs. ~nly those routers identified by peer IDs proceed to destroy their adjacencies with the source of the goodbye packet. The goodbye packet can further function as a reliable message in an unreliable environment by identifying a single peer ID in the value field of the appended attribute, as well as an 3o unreliable message across an entire shared media subnet.
-5-BRIEF DESCRIPTION OF THE DRAWINGS
The above and further advantages of the invention may be better understood by referring to the following description in conjunction with the accompanying drawings in which like reference numbers indicate identical or functionally similar elements:
Fig. 1 is a schematic block diagram of a computer network comprising a plural-ity of autonomous systems including intermediate nodes, such as intradomain routers;
Fig. 2 is a schematic block diagram of a router that may be advantageously used with the present invention;
Fig. 3 is a schematic block diagram of a conventional protocol stack, such as the io Internet communications protocol stack;
Fig. 4 is a schematic block diagram depicting the format of a Hello packet;
Fig. 5 is a schematic block diagram of an EIGRP router having adjacencies with its neighbors;
Fig. 6 is a schematic block diagram of an EIGRP routing protocol process that is may be advantageously used with the present invention;
Fig. 7 is a schematic block diagram of a goodbye notification packet according to the present invention; and Fig. ~ is a flowchart illustrating a sequence of steps when using the goodbye notification packet according to the present invention.
zo DETAILED DESC TI~l~'~T ~F AI~T II~I~ITSTRATI~E EI~B~IIII~ENT
Fig. 1 is a schematic block diagram of a computer network 100 comprising a plurality of routing domains or autonomous systems interconnected by intermediate nodes, such as conventional interdomain routers 120 and intradomain routers 200. The interdomain routers 120 interconnect various autonomous systems (AS1_4), whereas the 2s intradomain routers 200 manage communication media and nodes within their respec-tive AS domains. The communication media include shared medium networks 104, such as local area network (LAIC subnetworks, point-to-point links 102 and non-broadcast mufti-access (NBMA) clouds such as frame relay or asynchronous transfer node networks. Communication among the routers is typically effected by exchanging 3o discrete protocol data units (PI~U 150) or packets in accordance with predefined proto-cols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP). It will be
The above and further advantages of the invention may be better understood by referring to the following description in conjunction with the accompanying drawings in which like reference numbers indicate identical or functionally similar elements:
Fig. 1 is a schematic block diagram of a computer network comprising a plural-ity of autonomous systems including intermediate nodes, such as intradomain routers;
Fig. 2 is a schematic block diagram of a router that may be advantageously used with the present invention;
Fig. 3 is a schematic block diagram of a conventional protocol stack, such as the io Internet communications protocol stack;
Fig. 4 is a schematic block diagram depicting the format of a Hello packet;
Fig. 5 is a schematic block diagram of an EIGRP router having adjacencies with its neighbors;
Fig. 6 is a schematic block diagram of an EIGRP routing protocol process that is may be advantageously used with the present invention;
Fig. 7 is a schematic block diagram of a goodbye notification packet according to the present invention; and Fig. ~ is a flowchart illustrating a sequence of steps when using the goodbye notification packet according to the present invention.
zo DETAILED DESC TI~l~'~T ~F AI~T II~I~ITSTRATI~E EI~B~IIII~ENT
Fig. 1 is a schematic block diagram of a computer network 100 comprising a plurality of routing domains or autonomous systems interconnected by intermediate nodes, such as conventional interdomain routers 120 and intradomain routers 200. The interdomain routers 120 interconnect various autonomous systems (AS1_4), whereas the 2s intradomain routers 200 manage communication media and nodes within their respec-tive AS domains. The communication media include shared medium networks 104, such as local area network (LAIC subnetworks, point-to-point links 102 and non-broadcast mufti-access (NBMA) clouds such as frame relay or asynchronous transfer node networks. Communication among the routers is typically effected by exchanging 3o discrete protocol data units (PI~U 150) or packets in accordance with predefined proto-cols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP). It will be
-6-understood to those skilled in the art that other protocols, such as the Internet packet exchange (IPA protocol, the Datagram Delivery Protocol (DDP) as well as other link state routing protocols, may be advantageously used with the present invention.
Fig. 2 is a schematic block diagram of an intradomain router 200. An example of the router 200 that may be illustratively used with the present invention is the 7200 series router available from Cisco Systems, Inc. The router 200 implements a modular and scalable architecture that facilitates use of the router as an edge device for enter-prises and service providers. To that end, the router comprises a network processing engine 210 coupled to a plurality of port adapters 220. Each port adapter 220 supports io most WAN and LAN technologies and, to that end, comprises circuitry that connects the muter to communication media of the network 100.
The network processing engine 210 is a processor-based system comprising functionality incorporated within a typical router. That is, the engine comprises a proc-essor 212 (and cache 21 S) coupled to a system memory 214 via a system controller is 216. The memory 214 may comprise dynamic random access memory (DRAIN) and/or synchronous DRAT~I (SD storage locations addressable by the processor 212 for storing software programs and data structures, such as tables, packets, etc. A
network operating system 250, portions of which are typically resident in memory and executed by the processor, functionally organizes the muter by, iazte~ eelic~, invoking network op-ao erations in support of software processes executing on the muter. It will be apparent to those skilled in the art that other memory means, including various computer readable media, may be used for storing and executing program instructions pertaining to the operation of the router.
A key function of the router is determining the next node to which a packet is as sent; in order to accomplish such "routing" the routers cooperate to determine optimal ("best") paths through the computer network 100. The routing function is preferably performed by a network (internetwork) layer of a protocol stack that, in the illustrative embodiment, is associated with the network operating system 250 of each router. Fig.
3 is a schematic block diagram of a conventional protocol stack, such as the Internet 3o communications protocol stack 300. The architecture of the Internet protocol stack 300 is represented by four layers termed, in ascending interfacing order, the network inter-face layer 308, the internetwork layer 306, the transport layer 304 and the application layer 302.
The lower network interface layer 308 is generally standardized and imple-mented in hardware and firmware, whereas the higher layers are typically implemented s in the form of software. The primary internetwork layer protocol of the Internet archi-tecture is the Internet protocol (If). IP is primarily a connectionless protocol that pro-vides internetwork routing, fragmentation and assembly of exchanged packets -gener-ally referred to as "datagrams" in an Internet environment - and which relies on trans-port protocols for end-to-end reliability. An example of such a transport protocol is the io Transmission Control Protocol (TCP) that is implemented by the transport layer 304 and provides connection-oriented services to the upper layer protocols of the Internet architecture. The term TC'PlIP is commonly used to denote the Internet architecture.
In particular, the internetwork layer 306 concerns the protocol and algorithms that the routers 200 utilize so that they can cooperate to calculate paths through the is computer network 100. An intradomain protocol may be used to perform intradomain routing (for the Internetwork layer) within each AS of the computer network 100. An example of a protocol used to distribute routing information between neighboring routers belonging to a single AS is the Enhanced Interior Gateway Routing Protocol (EIGRP). The EIGRP routing protocol is well known and described in detail in the ao aforementioned Cise~ TCPI~P 1Z~uting~ Pr~~essior~czl lZeferet~ee, 2a~d ~ldditi~ti and En-l~araced Inter~i~~ Gateway 1~~uti~cg Pr~t~col materials.
The EIGRP protocol is a platform independent protocol comprising a hybrid of distance vector and link state routing protocol technologies. A router configured to run the EIGRP protocol computes a best path to a destination using distance ("cost" or hop zs count) information represented as a composite of available bandwidth, delay, load utili-zation and link reliability information that allows "fine tuning" of link characteristics to achieve optimal (or best) paths. The EIGRP muter also maintains state pertaining to reachable neighboring routers (or "neighbors") in a neighbor data structure.
The reach-able neighbors (e.g., other intradomain routers 200 within AS2,4 ofFig. 1) are associ-3o ated with the EIGRP router through an adjacency relationship that enables the exchange _g_ of routing information between the neighbors. This adjacency relationship is estab-lished and maintained using Hello packets defined by the EIGRP routing protocol.
Fig. 4 is a schematic block diagram depicting the format of a Hello packet 400 comprising an EIGRP packet header 410 and Hello-specific variable-length fields 450.
EIGRP packets may be encapsulated within various network layer protocols, such as IPX (Novell networks) and DIP (AppleTalk networks); however, in the illustrative embodiment described herein, the EIGRP packets are encapsulated as IP packets (TCP/IP networks). Each EIGI~P packet, such as a Hello packet, has a fixed 20-byte EIGRP header 410. The header contains information needed to determine whether the io packet should be accepted for further processing. The Hello packet is an EIGRP type 5 packet that is periodically sent over interfaces of the router to establish and maintain neighbor adjacencies. All routers connected to a common network must agree on cer-twin parameters, such as the HoldTime, included in the Hello packet.
The EIGRP packet header 410 includes a version field 412 containing the is EIGI~P version number, an opcode field 414 containing the type of EIGIZP
packet and a checksum field 416 that contains a checksum (e.g., standard one's complement of the one's complement sum) for the entire contents of the packet. The header 410 also in-cludes a flags field 41~ having a content that defines special handling of the packet and a sequence number field 420 that contains a unique sequence number with respect to a ao sending router. An ack number field 422 contains an acknowledgement number with respect to a receiver of the packet and an AS number field 424 contains an autonomous system number of the sending system.
Each EIGRP packet may contain a variable number of fields, each of which is tagged in accordance with a type (T), length (L) and value (V) encoding format. These zs tagged fields allow for newer versions of software to add capabilities and coexist with old versions of software in the same configuration. Fields that are tagged, but that are not recognizable by certain routers can be skipped. This encoding scheme also allows multiple network layer protocols to carry independent information. The Hello-specific variable fields 450 of the EIGRP Hello packet are tagged according to the TLV
encod-so ing format.
The Hello-specific variable-length fields 450 include a type field 460 that is structured as a protocol identifier (ll~) sub-field 462 containing ID
assignments for various supported network layer protocols and a type code sub-field 464. The type code for the Hello packet 400 is illustratively a parameter type (e.g., 0x0001) TLV used s to convey EIGRP metric K-values as well as the HoldTime value. The content of length field 470 illustratively specifies the length (in bytes) of the type, length and value fields, while the value field 480 contains the K-values 482 and the HoldTime value 484. Note that the HoldTime is the amount of time (in seconds) that a receiving roister should consider the sending neighbor valid. A valid neighbor is a roister that is io able to forward packets and participate in the EIGRP protocol. Zlpon considering a neighbor valid, the roister stores all routing information advertised by the neighbor.
Fig. 5 is a schematic block diagram of an EIGRP roister S00 having adjacencies 502a,b with its neighbors 540a,b over a multi-access interface 512a and a point-to-point interface 512b of the roister. The mufti-access interface 512a comprises the electrical, is mechanical and signaling circuitry that connects the roister to shared media, such as an Ethernet network, whereas the point-to-point interface S 12b comprises the circuitry that connects the roister to a point-to-point network connection. The roister 500 is illustra-tively an embodiment of roister 200 (Fig. 2) and is configured to execute an EIGI~
routing protocol process 600 that uses the encapsulation services of its respective sup-zo porting network layer 520, e.g., the I7DP network layer 522, the IP network layer 524 and/or the IfX network layer 526. The EIGRP process 600 is a component of the net-work operating system 250, such as the I~S~ software available from Cisco Systems, Inc.
Fig. 6 is a schematic block diagram of the EIGRP routing protocol process 600 zs that may be advantageously used with the present invention. The EIGRP
process is illustratively embodied as an EIGRP protocol engine 650 that is responsible for pro-viding general functions for various protocol dependent modules, along with providing reliable transport service, route computations and, notably, neighbor discovery and failure detection. For a mufti-protocol implementation, there is a protocol dependent so "client" module 610 for each supported network layer 520. For example, an IP-EIGRP
client module 610a executes and advertises TCP/IP related routing information for the If network layer 524. The protocol dependent modules 610 provide network layer spe-cific functions and are responsible for understanding protocol specific packet formats, as well as interfacing with their respective routing tables 620.
The EIGRP protocol engine 650 comprises a number of components, including s a Reliable Transport 612, a Route Server Processor 614, a Diffusing Update Algorithm (DUAL) Finite State Machine (FSM) 615, a client Interface 616 and a Neighbor Dis-covery process 61 ~. The Reliable Transport 612 is responsible for guaranteed, ordered delivery of EIGRl' packets to all neighbors. The DUAL FSM 615 embodies a decision process for all route computations through execution of a DUAL algorithm used to ob-io tain loop-freedom throughout the route computations. The DUAL FSM is responsible for maintaining topology tables 640 that are populated by the protocol dependent mod-ules 610. Each protocol dependent module 610 has a topology table 640 that stores routing information for destinations. The contents of the table 640 are used to deter-mine information that is advertised and inserted into the protocol-specific routing tables is 620.
The Neighbor Discovery process 61 ~ is the process used by the EIGRP router 500 to dynamically learn of other routers (neighbors 540) on its directly attached net-works. The router 500 also uses process 618 to discover when its neighbors become unreachable or inoperative. The information or state of each adjacent neighbor 540 is ao stored in a neighbor table 630 maintained by each protocol dependent module 610.
When newly discovered neighbors 540 are learned, the address and interface of the neighbor is recorded in the neighbor table 630.
The Neighbor Discovery process 61 ~ is achieved with low overhead by periodi-cally creating and sending small Hello packets 400 at a rate called the "HelloInterval".
zs When EIGRP router 500 is initialized, it starts sending the Hello packets, preferably multicast addressed. Each Hello packet 400 includes the EIGRP metric K-values and a HoldTime value 484. Once the router 500 detects a new neighbor 540 from re-ceipt of the Hello packet, it sends a reliable (INIT) EIGRP Update packet to the neigh-bor to initiate topology table exchanges with the new neighbor 540. Upon receiving the so 11\TIT update packet, the neighbor 540 detects its peer and proceeds with establishing the adjacency 502 with the EIGRP router 500.
The "HoldTime" is the amount of time that an EIGRP roister will consider a neighbor alive without receiving a Hello packet 400. In the illustrative embodiment, the HelloInterval is preferably 5 seconds and the HoldTime is 15 seconds. As long as the Hello packets are received from a neighbor within the HoldTime, the EIGRP
roister determines that the neighbor is alive and functioning; this, in turn, allows both neigh-bors to exchange (and update) routing information to thereby reach routing conver-gence. However, if the Hello packets are not received within the HoldTime, the roister assumes that the neighbor no longer exists and "tears down" (destroys) the adjacency with the neighbor.
io ~ften, it is desirable for the EICrRF roister 500 to unilaterally decide to destroy the adjacency 502 with its neighbor 540. ~ne method of detecting neighbor (peer) loss and, subsequently, destroying an adjacency is "time-based" through the absence of communication with the neighbor for a predetermined period of time. For example if Hello packets are not received from the neighbor 540 within the HoldTime, the EIC~~
is roister 500 assumes that the neighbor no longer exists and "tears down"
(destroys) the adjacency 502 with the neighbor. However, it is also undesirable to assume the de-lay/latency associated with waiting the entire predetermined time period, such as the HoldTime, to detect peer loss in order to destroy an existing adjacency.
Rather, it is desirable to promptly notify neighbors of an intention to destroy adjacencies so that the ao adjacencies can be quickly removed, thereby "speeding-up" routing convergence and improving network stability.
The present invention relates to a technique for efficiently notifying EIGRP
neighbors when destroying adjacencies in a computer network. According to the in-ventive technique, a novel goodbye notification packet is provided that enables an as EIGRP roister, such as roister 500, to inform one or more of its neighbors 540 of its in-tention to destroy their existing adjacencies 502. Fig. 7 is a schematic block diagram of the goodbye notification packet 700 comprising an EIGRP packet header 710 with variable-length fields embodied as an appended goodbye attribute 750. The goodbye attribute 750 is illustratively tagged according to a type (T), length (L) and value (V) so encoding format.
The TLV encoding format is a generic way to communicate information be-tween two systems or nodes, such as roisters, where the information may not be entirely known to one roister. The TLV is used to identify a type (T) of information being con-veyed, a length (L) of information to be conveyed and a value (V) of the actual infor-s mation conveyed. An advantage of a TLV-based communication system is that a roister can skip over any type of information that it is not configured to "understand".
That is, using the length (L) parameter, the roister can skip an attribute (TLV) it doesn't understand, until it finds a TLV for which it is configured. The length (L,) parameter is implementation-specific and can denote the length from the beginning of the first field io of the attribute to the end. However, the length generally denotes the length of the value (V) field and not the type field or length field.
The EIGRP packet header 710 is similar to the EIGRI' packet header 410 (Fig.
4) and, thus, includes a version field 712 containing the EIGRP version number, an op-code field 714 containing the type of EIGI~ packet and a checksum field 716 that is contains a checksum (e.g., standard one's complement of the one's complement sum) for the entire contents of the packet. A flags field 718 has a content that defines special handling of the packet and a sequence number field 720 contains a unique sequence number with respect to a sending roister. An ack number field 722 contains an ac-knowledgement number with respect to a receiver of the packet and an AS number field ao 724 contains an autonomous system number of the sending system. In addition, the goodbye attribute 750 defines a new type (T) field 752 called "a goodbye"
having a predetermined type (e.g., 0x0007) that distinguishes it from a conventional EIGI~P
Hello packet. A value (V) field 756 contains a list of neighbor (peer) mss, wherein each peer ID is a conventional identifier, such as an address, of a roister. A
neighbor whose as peer ~ appears on the peer ID list is instructed to initiate a "peer down"
action to de-stroy its adjacency with the EIGRf roister 500.
The peer ~s of neighbors that will have their adjacencies destroyed are stored on, e.g., a queue of interface 512 in roister 500. When scheduled to run, the Neighbor Discovery process 618 examines the queue and constructs goodbye notification packets so 700 using the peer mss. The list of peer IDs contained in each goodbye notification packet 700 can include one to as many as a maximum number of peer IDs.
Multiple goodbye notification packets 700 may be used if there are more peer IDs than can be carried in field 756 of a single packet 700.
Destruction of an adjacency can be on an interface basis, such that EIGRP
router 500 may destroy all neighbor adjacencies 502 on one interface, but none ofthe s adjacencies on the other interfaces. However, it is possible to destroy only one adja-cency on an interface, e.g., mufti-access interface 512a, such as when changing a pa-rameter between the router 500 and a neighbor 540a. For example, the router might change authentication or some type of security information between a neighbor and it-self. Here, the router wants to restart only that neighbor's relationship over with the io new security information, while continuing to run different security information for the other neighbors.
Fig. 8 is a flowchart illustrating a sequence of steps when using the goodbye notification packet according to the present invention. The sequence starts at Step 800 and proceeds to Step 802 where a router, such as EIC~ItF muter 500, sends the goodbye is notification packet 700 to one or more neighbors 540. Upon receiving the goodbye no-tification packet, each neighbor 540 examines the TLV encoded contents of the ap-pended goodbye attribute 750 in Step 804. Specifically, the neighbor examines the type field of the novel attribute to determine if it is configured to understand that type of information (Step 806). If not, the neighbor skips over the attribute in Step 808 and ao the sequence ends at Step 820. However, if the neighbor is configured to understand the type of information, it identifies the packet type as a goodbye notification packet in Step 810. The neighbor then examines the value field of the attribute, searching for its peer ~ within the list of peer ~s in Step 812. If the neighbor does not discover its peer ~ (Step 814), the sequence ends at Step 820. ~therwise if it does discover its as peer ID, the neighbor destroys the adjacency with the source of the goodbye notifica-tion packet (router 500) in Step 816 and the sequence ends at Step 820.
An advantage of the invention is the ability of the goodbye notification packet to operate in both a reliable and an unreliable environment. That is, the goodbye notifi-cation packet may function as a reliable message when notifying a neighbor on a point-so to-point connection (in a reliable environment) to "go away", i.e., destroy its adjacency with the source of the packet (an EIC'rRf router). In addition, the goodbye notification packet may function as an unreliable message in an unreliable environment (shared network media) that notifies a subset of neighbors (through the list of peer 117s) to de-stroy their adjacencies with the EIGRP router. This aspect of the invention enables scaling of goodbye notification packet, as a single packet can include a list of peer mss, wherein the list can include one to as many as a maximum number of peer mss.
~nly those routers identified by peer ~s proceed to destroy their adjacencies with the source of the goodbye packet. The goodbye packet can further function as a reliable message in an unreliable environment by identifying a single peer ~ in the value field of the appended attribute, as well as an unreliable message across an entire shared media sub-io net.
There are various network situations that will benefit from the novel goodbye notification technique such as, for example, when there is a one-way failure on a link between two neighbors. Here, one router detects the failure and removes the adjacency, while the other muter still receives packets and maintains the adjacency. In the absence is of the goodbye notification technique, the adjacency is eventually destroyed in both routers, but only because of retransmission timeouts or a stuck-in-active condition.
Another network situation involves failure of unreliable delivery service, leav-ing only reliable delivery as an option. ~Jhen unreliable delivery fails, the adjacency between tw~ routers is typically destroyed due to expiration of the HoldT°ime. How-zo ever, in the absence of the goodbye technique, EIGIZP reliable traffic effectively resets the HoldTime that, in turn, maintains the adjacency. In addition, when a user reloads router 500 or removes the EIGRP routing protocol process 600, the goodbye notifica-tion packets) enable notification of all of the router's neighbors 540 so that they can quickly destroy their adjacencies with the router and discover alternate routes. Simi-an lady, when an EIGRP configured interface is "shutdown", use of the goodbye tech-nique enables fast and efficient notification to all neighbors.
While there has been shown and described an illustrative embodiment for effi-ciently notifying EIGRP neighbors when destroying adjacencies in a computer net-work, it is to be understood that various other adaptations and modifications may be so made within the spirit and scope of the present invention. For example, in an alternate embodiment, an EIGRf router 500 may employ the Hello packet 400 as a "wildcard goodbye packet" to destroy the adjacencies of all neighbors 540 coupled to an interface, such as multi-access interface 512a. Here, all K-values 482 contained in value field 480 of the Hello-specific variable-length fields 450 are set to invalid constants (e.g., 255). . In addition, a new goodbye flag (e.g., goodbye all_peers) is provided for the s flags field 418 of EI(~RP header 410. When the goodbye flag is set, the Neighbor Dis-covery process 618 stops sending goodbye notification packets 700 to individual neighbors (if any) and sends only one wildcard goodbye packet on the interface. This embodiment of the invention provides backward compatibility and simplicity in proc-essing. If a neighbor 540a running an older version of the EIGI~P protocol receives the io wildcard goodbye packet with the invalid K-values, it immediately tears down the adja-cency with the router 500. Moreover, the wildcard goodbye packet is understood at the protocol dependent modules 610 rather than relying on protocol specific code to deci-pher a protocol specific wildcard address.
The foregoing description has been directed to specific embodiments of this in-is vention. It will be apparent, however, that other variations and modifications may be made to the described embodiments, with the attainment of some or all of their advan-tages. For instance, it is expressly contemplated that the teachings of this invention, including the various modules described herein, can be implemented as software, in-cluding a computer-readable medium having program instructions executing on a com-2o puter, hardware, firmware, or a combination thereof. In addition, it is understood that the data structures described herein can include additional information while remaining within the scope of the present invention. Furthermore, the inventive goodbye notifi-cation technique may apply to any protocol that maintains peering information (state), including non-routing protocols, such as wireless protocols running on wireless devices as that have wireless connections between them. Accordingly this description is to be taken only by way of example and not to otherwise limit the scope of the invention.
Therefore, it is the object of the appended claims to cover all such variations and modi-fications as come within the true spirit and scope of the invention.
What is claimed is:
Fig. 2 is a schematic block diagram of an intradomain router 200. An example of the router 200 that may be illustratively used with the present invention is the 7200 series router available from Cisco Systems, Inc. The router 200 implements a modular and scalable architecture that facilitates use of the router as an edge device for enter-prises and service providers. To that end, the router comprises a network processing engine 210 coupled to a plurality of port adapters 220. Each port adapter 220 supports io most WAN and LAN technologies and, to that end, comprises circuitry that connects the muter to communication media of the network 100.
The network processing engine 210 is a processor-based system comprising functionality incorporated within a typical router. That is, the engine comprises a proc-essor 212 (and cache 21 S) coupled to a system memory 214 via a system controller is 216. The memory 214 may comprise dynamic random access memory (DRAIN) and/or synchronous DRAT~I (SD storage locations addressable by the processor 212 for storing software programs and data structures, such as tables, packets, etc. A
network operating system 250, portions of which are typically resident in memory and executed by the processor, functionally organizes the muter by, iazte~ eelic~, invoking network op-ao erations in support of software processes executing on the muter. It will be apparent to those skilled in the art that other memory means, including various computer readable media, may be used for storing and executing program instructions pertaining to the operation of the router.
A key function of the router is determining the next node to which a packet is as sent; in order to accomplish such "routing" the routers cooperate to determine optimal ("best") paths through the computer network 100. The routing function is preferably performed by a network (internetwork) layer of a protocol stack that, in the illustrative embodiment, is associated with the network operating system 250 of each router. Fig.
3 is a schematic block diagram of a conventional protocol stack, such as the Internet 3o communications protocol stack 300. The architecture of the Internet protocol stack 300 is represented by four layers termed, in ascending interfacing order, the network inter-face layer 308, the internetwork layer 306, the transport layer 304 and the application layer 302.
The lower network interface layer 308 is generally standardized and imple-mented in hardware and firmware, whereas the higher layers are typically implemented s in the form of software. The primary internetwork layer protocol of the Internet archi-tecture is the Internet protocol (If). IP is primarily a connectionless protocol that pro-vides internetwork routing, fragmentation and assembly of exchanged packets -gener-ally referred to as "datagrams" in an Internet environment - and which relies on trans-port protocols for end-to-end reliability. An example of such a transport protocol is the io Transmission Control Protocol (TCP) that is implemented by the transport layer 304 and provides connection-oriented services to the upper layer protocols of the Internet architecture. The term TC'PlIP is commonly used to denote the Internet architecture.
In particular, the internetwork layer 306 concerns the protocol and algorithms that the routers 200 utilize so that they can cooperate to calculate paths through the is computer network 100. An intradomain protocol may be used to perform intradomain routing (for the Internetwork layer) within each AS of the computer network 100. An example of a protocol used to distribute routing information between neighboring routers belonging to a single AS is the Enhanced Interior Gateway Routing Protocol (EIGRP). The EIGRP routing protocol is well known and described in detail in the ao aforementioned Cise~ TCPI~P 1Z~uting~ Pr~~essior~czl lZeferet~ee, 2a~d ~ldditi~ti and En-l~araced Inter~i~~ Gateway 1~~uti~cg Pr~t~col materials.
The EIGRP protocol is a platform independent protocol comprising a hybrid of distance vector and link state routing protocol technologies. A router configured to run the EIGRP protocol computes a best path to a destination using distance ("cost" or hop zs count) information represented as a composite of available bandwidth, delay, load utili-zation and link reliability information that allows "fine tuning" of link characteristics to achieve optimal (or best) paths. The EIGRP muter also maintains state pertaining to reachable neighboring routers (or "neighbors") in a neighbor data structure.
The reach-able neighbors (e.g., other intradomain routers 200 within AS2,4 ofFig. 1) are associ-3o ated with the EIGRP router through an adjacency relationship that enables the exchange _g_ of routing information between the neighbors. This adjacency relationship is estab-lished and maintained using Hello packets defined by the EIGRP routing protocol.
Fig. 4 is a schematic block diagram depicting the format of a Hello packet 400 comprising an EIGRP packet header 410 and Hello-specific variable-length fields 450.
EIGRP packets may be encapsulated within various network layer protocols, such as IPX (Novell networks) and DIP (AppleTalk networks); however, in the illustrative embodiment described herein, the EIGRP packets are encapsulated as IP packets (TCP/IP networks). Each EIGI~P packet, such as a Hello packet, has a fixed 20-byte EIGRP header 410. The header contains information needed to determine whether the io packet should be accepted for further processing. The Hello packet is an EIGRP type 5 packet that is periodically sent over interfaces of the router to establish and maintain neighbor adjacencies. All routers connected to a common network must agree on cer-twin parameters, such as the HoldTime, included in the Hello packet.
The EIGRP packet header 410 includes a version field 412 containing the is EIGI~P version number, an opcode field 414 containing the type of EIGIZP
packet and a checksum field 416 that contains a checksum (e.g., standard one's complement of the one's complement sum) for the entire contents of the packet. The header 410 also in-cludes a flags field 41~ having a content that defines special handling of the packet and a sequence number field 420 that contains a unique sequence number with respect to a ao sending router. An ack number field 422 contains an acknowledgement number with respect to a receiver of the packet and an AS number field 424 contains an autonomous system number of the sending system.
Each EIGRP packet may contain a variable number of fields, each of which is tagged in accordance with a type (T), length (L) and value (V) encoding format. These zs tagged fields allow for newer versions of software to add capabilities and coexist with old versions of software in the same configuration. Fields that are tagged, but that are not recognizable by certain routers can be skipped. This encoding scheme also allows multiple network layer protocols to carry independent information. The Hello-specific variable fields 450 of the EIGRP Hello packet are tagged according to the TLV
encod-so ing format.
The Hello-specific variable-length fields 450 include a type field 460 that is structured as a protocol identifier (ll~) sub-field 462 containing ID
assignments for various supported network layer protocols and a type code sub-field 464. The type code for the Hello packet 400 is illustratively a parameter type (e.g., 0x0001) TLV used s to convey EIGRP metric K-values as well as the HoldTime value. The content of length field 470 illustratively specifies the length (in bytes) of the type, length and value fields, while the value field 480 contains the K-values 482 and the HoldTime value 484. Note that the HoldTime is the amount of time (in seconds) that a receiving roister should consider the sending neighbor valid. A valid neighbor is a roister that is io able to forward packets and participate in the EIGRP protocol. Zlpon considering a neighbor valid, the roister stores all routing information advertised by the neighbor.
Fig. 5 is a schematic block diagram of an EIGRP roister S00 having adjacencies 502a,b with its neighbors 540a,b over a multi-access interface 512a and a point-to-point interface 512b of the roister. The mufti-access interface 512a comprises the electrical, is mechanical and signaling circuitry that connects the roister to shared media, such as an Ethernet network, whereas the point-to-point interface S 12b comprises the circuitry that connects the roister to a point-to-point network connection. The roister 500 is illustra-tively an embodiment of roister 200 (Fig. 2) and is configured to execute an EIGI~
routing protocol process 600 that uses the encapsulation services of its respective sup-zo porting network layer 520, e.g., the I7DP network layer 522, the IP network layer 524 and/or the IfX network layer 526. The EIGRP process 600 is a component of the net-work operating system 250, such as the I~S~ software available from Cisco Systems, Inc.
Fig. 6 is a schematic block diagram of the EIGRP routing protocol process 600 zs that may be advantageously used with the present invention. The EIGRP
process is illustratively embodied as an EIGRP protocol engine 650 that is responsible for pro-viding general functions for various protocol dependent modules, along with providing reliable transport service, route computations and, notably, neighbor discovery and failure detection. For a mufti-protocol implementation, there is a protocol dependent so "client" module 610 for each supported network layer 520. For example, an IP-EIGRP
client module 610a executes and advertises TCP/IP related routing information for the If network layer 524. The protocol dependent modules 610 provide network layer spe-cific functions and are responsible for understanding protocol specific packet formats, as well as interfacing with their respective routing tables 620.
The EIGRP protocol engine 650 comprises a number of components, including s a Reliable Transport 612, a Route Server Processor 614, a Diffusing Update Algorithm (DUAL) Finite State Machine (FSM) 615, a client Interface 616 and a Neighbor Dis-covery process 61 ~. The Reliable Transport 612 is responsible for guaranteed, ordered delivery of EIGRl' packets to all neighbors. The DUAL FSM 615 embodies a decision process for all route computations through execution of a DUAL algorithm used to ob-io tain loop-freedom throughout the route computations. The DUAL FSM is responsible for maintaining topology tables 640 that are populated by the protocol dependent mod-ules 610. Each protocol dependent module 610 has a topology table 640 that stores routing information for destinations. The contents of the table 640 are used to deter-mine information that is advertised and inserted into the protocol-specific routing tables is 620.
The Neighbor Discovery process 61 ~ is the process used by the EIGRP router 500 to dynamically learn of other routers (neighbors 540) on its directly attached net-works. The router 500 also uses process 618 to discover when its neighbors become unreachable or inoperative. The information or state of each adjacent neighbor 540 is ao stored in a neighbor table 630 maintained by each protocol dependent module 610.
When newly discovered neighbors 540 are learned, the address and interface of the neighbor is recorded in the neighbor table 630.
The Neighbor Discovery process 61 ~ is achieved with low overhead by periodi-cally creating and sending small Hello packets 400 at a rate called the "HelloInterval".
zs When EIGRP router 500 is initialized, it starts sending the Hello packets, preferably multicast addressed. Each Hello packet 400 includes the EIGRP metric K-values and a HoldTime value 484. Once the router 500 detects a new neighbor 540 from re-ceipt of the Hello packet, it sends a reliable (INIT) EIGRP Update packet to the neigh-bor to initiate topology table exchanges with the new neighbor 540. Upon receiving the so 11\TIT update packet, the neighbor 540 detects its peer and proceeds with establishing the adjacency 502 with the EIGRP router 500.
The "HoldTime" is the amount of time that an EIGRP roister will consider a neighbor alive without receiving a Hello packet 400. In the illustrative embodiment, the HelloInterval is preferably 5 seconds and the HoldTime is 15 seconds. As long as the Hello packets are received from a neighbor within the HoldTime, the EIGRP
roister determines that the neighbor is alive and functioning; this, in turn, allows both neigh-bors to exchange (and update) routing information to thereby reach routing conver-gence. However, if the Hello packets are not received within the HoldTime, the roister assumes that the neighbor no longer exists and "tears down" (destroys) the adjacency with the neighbor.
io ~ften, it is desirable for the EICrRF roister 500 to unilaterally decide to destroy the adjacency 502 with its neighbor 540. ~ne method of detecting neighbor (peer) loss and, subsequently, destroying an adjacency is "time-based" through the absence of communication with the neighbor for a predetermined period of time. For example if Hello packets are not received from the neighbor 540 within the HoldTime, the EIC~~
is roister 500 assumes that the neighbor no longer exists and "tears down"
(destroys) the adjacency 502 with the neighbor. However, it is also undesirable to assume the de-lay/latency associated with waiting the entire predetermined time period, such as the HoldTime, to detect peer loss in order to destroy an existing adjacency.
Rather, it is desirable to promptly notify neighbors of an intention to destroy adjacencies so that the ao adjacencies can be quickly removed, thereby "speeding-up" routing convergence and improving network stability.
The present invention relates to a technique for efficiently notifying EIGRP
neighbors when destroying adjacencies in a computer network. According to the in-ventive technique, a novel goodbye notification packet is provided that enables an as EIGRP roister, such as roister 500, to inform one or more of its neighbors 540 of its in-tention to destroy their existing adjacencies 502. Fig. 7 is a schematic block diagram of the goodbye notification packet 700 comprising an EIGRP packet header 710 with variable-length fields embodied as an appended goodbye attribute 750. The goodbye attribute 750 is illustratively tagged according to a type (T), length (L) and value (V) so encoding format.
The TLV encoding format is a generic way to communicate information be-tween two systems or nodes, such as roisters, where the information may not be entirely known to one roister. The TLV is used to identify a type (T) of information being con-veyed, a length (L) of information to be conveyed and a value (V) of the actual infor-s mation conveyed. An advantage of a TLV-based communication system is that a roister can skip over any type of information that it is not configured to "understand".
That is, using the length (L) parameter, the roister can skip an attribute (TLV) it doesn't understand, until it finds a TLV for which it is configured. The length (L,) parameter is implementation-specific and can denote the length from the beginning of the first field io of the attribute to the end. However, the length generally denotes the length of the value (V) field and not the type field or length field.
The EIGRP packet header 710 is similar to the EIGRI' packet header 410 (Fig.
4) and, thus, includes a version field 712 containing the EIGRP version number, an op-code field 714 containing the type of EIGI~ packet and a checksum field 716 that is contains a checksum (e.g., standard one's complement of the one's complement sum) for the entire contents of the packet. A flags field 718 has a content that defines special handling of the packet and a sequence number field 720 contains a unique sequence number with respect to a sending roister. An ack number field 722 contains an ac-knowledgement number with respect to a receiver of the packet and an AS number field ao 724 contains an autonomous system number of the sending system. In addition, the goodbye attribute 750 defines a new type (T) field 752 called "a goodbye"
having a predetermined type (e.g., 0x0007) that distinguishes it from a conventional EIGI~P
Hello packet. A value (V) field 756 contains a list of neighbor (peer) mss, wherein each peer ID is a conventional identifier, such as an address, of a roister. A
neighbor whose as peer ~ appears on the peer ID list is instructed to initiate a "peer down"
action to de-stroy its adjacency with the EIGRf roister 500.
The peer ~s of neighbors that will have their adjacencies destroyed are stored on, e.g., a queue of interface 512 in roister 500. When scheduled to run, the Neighbor Discovery process 618 examines the queue and constructs goodbye notification packets so 700 using the peer mss. The list of peer IDs contained in each goodbye notification packet 700 can include one to as many as a maximum number of peer IDs.
Multiple goodbye notification packets 700 may be used if there are more peer IDs than can be carried in field 756 of a single packet 700.
Destruction of an adjacency can be on an interface basis, such that EIGRP
router 500 may destroy all neighbor adjacencies 502 on one interface, but none ofthe s adjacencies on the other interfaces. However, it is possible to destroy only one adja-cency on an interface, e.g., mufti-access interface 512a, such as when changing a pa-rameter between the router 500 and a neighbor 540a. For example, the router might change authentication or some type of security information between a neighbor and it-self. Here, the router wants to restart only that neighbor's relationship over with the io new security information, while continuing to run different security information for the other neighbors.
Fig. 8 is a flowchart illustrating a sequence of steps when using the goodbye notification packet according to the present invention. The sequence starts at Step 800 and proceeds to Step 802 where a router, such as EIC~ItF muter 500, sends the goodbye is notification packet 700 to one or more neighbors 540. Upon receiving the goodbye no-tification packet, each neighbor 540 examines the TLV encoded contents of the ap-pended goodbye attribute 750 in Step 804. Specifically, the neighbor examines the type field of the novel attribute to determine if it is configured to understand that type of information (Step 806). If not, the neighbor skips over the attribute in Step 808 and ao the sequence ends at Step 820. However, if the neighbor is configured to understand the type of information, it identifies the packet type as a goodbye notification packet in Step 810. The neighbor then examines the value field of the attribute, searching for its peer ~ within the list of peer ~s in Step 812. If the neighbor does not discover its peer ~ (Step 814), the sequence ends at Step 820. ~therwise if it does discover its as peer ID, the neighbor destroys the adjacency with the source of the goodbye notifica-tion packet (router 500) in Step 816 and the sequence ends at Step 820.
An advantage of the invention is the ability of the goodbye notification packet to operate in both a reliable and an unreliable environment. That is, the goodbye notifi-cation packet may function as a reliable message when notifying a neighbor on a point-so to-point connection (in a reliable environment) to "go away", i.e., destroy its adjacency with the source of the packet (an EIC'rRf router). In addition, the goodbye notification packet may function as an unreliable message in an unreliable environment (shared network media) that notifies a subset of neighbors (through the list of peer 117s) to de-stroy their adjacencies with the EIGRP router. This aspect of the invention enables scaling of goodbye notification packet, as a single packet can include a list of peer mss, wherein the list can include one to as many as a maximum number of peer mss.
~nly those routers identified by peer ~s proceed to destroy their adjacencies with the source of the goodbye packet. The goodbye packet can further function as a reliable message in an unreliable environment by identifying a single peer ~ in the value field of the appended attribute, as well as an unreliable message across an entire shared media sub-io net.
There are various network situations that will benefit from the novel goodbye notification technique such as, for example, when there is a one-way failure on a link between two neighbors. Here, one router detects the failure and removes the adjacency, while the other muter still receives packets and maintains the adjacency. In the absence is of the goodbye notification technique, the adjacency is eventually destroyed in both routers, but only because of retransmission timeouts or a stuck-in-active condition.
Another network situation involves failure of unreliable delivery service, leav-ing only reliable delivery as an option. ~Jhen unreliable delivery fails, the adjacency between tw~ routers is typically destroyed due to expiration of the HoldT°ime. How-zo ever, in the absence of the goodbye technique, EIGIZP reliable traffic effectively resets the HoldTime that, in turn, maintains the adjacency. In addition, when a user reloads router 500 or removes the EIGRP routing protocol process 600, the goodbye notifica-tion packets) enable notification of all of the router's neighbors 540 so that they can quickly destroy their adjacencies with the router and discover alternate routes. Simi-an lady, when an EIGRP configured interface is "shutdown", use of the goodbye tech-nique enables fast and efficient notification to all neighbors.
While there has been shown and described an illustrative embodiment for effi-ciently notifying EIGRP neighbors when destroying adjacencies in a computer net-work, it is to be understood that various other adaptations and modifications may be so made within the spirit and scope of the present invention. For example, in an alternate embodiment, an EIGRf router 500 may employ the Hello packet 400 as a "wildcard goodbye packet" to destroy the adjacencies of all neighbors 540 coupled to an interface, such as multi-access interface 512a. Here, all K-values 482 contained in value field 480 of the Hello-specific variable-length fields 450 are set to invalid constants (e.g., 255). . In addition, a new goodbye flag (e.g., goodbye all_peers) is provided for the s flags field 418 of EI(~RP header 410. When the goodbye flag is set, the Neighbor Dis-covery process 618 stops sending goodbye notification packets 700 to individual neighbors (if any) and sends only one wildcard goodbye packet on the interface. This embodiment of the invention provides backward compatibility and simplicity in proc-essing. If a neighbor 540a running an older version of the EIGI~P protocol receives the io wildcard goodbye packet with the invalid K-values, it immediately tears down the adja-cency with the router 500. Moreover, the wildcard goodbye packet is understood at the protocol dependent modules 610 rather than relying on protocol specific code to deci-pher a protocol specific wildcard address.
The foregoing description has been directed to specific embodiments of this in-is vention. It will be apparent, however, that other variations and modifications may be made to the described embodiments, with the attainment of some or all of their advan-tages. For instance, it is expressly contemplated that the teachings of this invention, including the various modules described herein, can be implemented as software, in-cluding a computer-readable medium having program instructions executing on a com-2o puter, hardware, firmware, or a combination thereof. In addition, it is understood that the data structures described herein can include additional information while remaining within the scope of the present invention. Furthermore, the inventive goodbye notifi-cation technique may apply to any protocol that maintains peering information (state), including non-routing protocols, such as wireless protocols running on wireless devices as that have wireless connections between them. Accordingly this description is to be taken only by way of example and not to otherwise limit the scope of the invention.
Therefore, it is the object of the appended claims to cover all such variations and modi-fications as come within the true spirit and scope of the invention.
What is claimed is:
Claims (20)
1. A system configured to notify neighbors when destroying adjacencies in a computer network, the system comprising:
a router adapted to generate a goodbye notification packet to inform one or more of the neighbors to destroy the adjacencies, the goodbye notification packet hav-ing a packet header with an appended goodbye attribute tagged according to an encod-ing format.
a router adapted to generate a goodbye notification packet to inform one or more of the neighbors to destroy the adjacencies, the goodbye notification packet hav-ing a packet header with an appended goodbye attribute tagged according to an encod-ing format.
2. The system of Claim 1 wherein the goodbye attribute comprises:
a goodbye type; and a list of neighbor (peer) identifiers (IDs), wherein each neighbor identified by a peer ID on the list destroys its adjacency with the router.
a goodbye type; and a list of neighbor (peer) identifiers (IDs), wherein each neighbor identified by a peer ID on the list destroys its adjacency with the router.
3. The system of Claim 2 wherein the muter is an enhanced interior gateway routing protocol (EIGRP) router configured to run an EIGRP routing protocol process.
4. The system of Claim 3 wherein the EIGRP routing protocol process comprises a neighbor discovery process configured to construct the goodbye notification packet.
5. The system of Claim 2 wherein the router comprises:
a multi-access interface with circuitry that connects the router to a shared media computer network; and a point-to-point interface with circuitry that connects the router to a point-to-point computer network connection.
a multi-access interface with circuitry that connects the router to a shared media computer network; and a point-to-point interface with circuitry that connects the router to a point-to-point computer network connection.
6. The system of Claim 5 wherein the multi-access interface enables use of the good-bye notification packet as an unreliable message in an unreliable environment to notify a subset of neighbors to destroy their adjacencies with the router.
7. The system of Claim 6 wherein the subset of neighbors is notified through the list of peer IDs.
8. The system of Claim 5 wherein the point-to-point interface enables use of the good-bye notification packet as a reliable message in a reliable environment to notify a single neighbor to destroy its adjacency with the router.
9. The system of Claim 8 wherein the single neighbor is notified through the list of peer IDs.
10. A method for notifying neighbors when destroying adjacencies in a computer net-work, the method comprising the steps of:
sending a goodbye notification packet from a router to one or more of the neighbors to inform the neighbors to destroy the adjacencies, the goodbye notification packet having a packet header with an appended goodbye attribute;
examining the appended goodbye attribute at each neighbor;
if the neighbor is configured to understand the goodbye attribute, searching a list of peer identifiers (IDs) contained in the goodbye attribute to determine if the peer ID of the neighbor is on the list; and if the peer ID of the neighbor is on the list, destroying the adjacency with the router.
sending a goodbye notification packet from a router to one or more of the neighbors to inform the neighbors to destroy the adjacencies, the goodbye notification packet having a packet header with an appended goodbye attribute;
examining the appended goodbye attribute at each neighbor;
if the neighbor is configured to understand the goodbye attribute, searching a list of peer identifiers (IDs) contained in the goodbye attribute to determine if the peer ID of the neighbor is on the list; and if the peer ID of the neighbor is on the list, destroying the adjacency with the router.
11. The method of Claim 10 wherein the step of examining comprises the step of ex-amining a type of the goodbye attribute to determine if the neighbor is configured to understand that type of information.
12. The method of Claim 11 further comprising the step of, if the neighbor is not con-figured to understand the goodbye attribute, skipping over a value field of the goodbye attribute.
13. The method of Claim 12 wherein the neighbors are routers configured to run an Enhanced Interior Gateway Routing Protocol (EIGRP).
14. A system configured to notify neighbors when destroying adjacencies in a com-puter network, the system comprising:
a router configured to run an enhanced interior gateway routing protocol (EIGRP) to generate a goodbye notification packet to inform one or more of the neigh-bors to destroy the adjacencies, the goodbye notification packet having a packet header with an appended goodbye attribute having a predetermined goodbye type and a list of neighbor (peer) identifiers (IDs), wherein each neighbor identified by a peer ID on the list destroys its adjacency with the router.
a router configured to run an enhanced interior gateway routing protocol (EIGRP) to generate a goodbye notification packet to inform one or more of the neigh-bors to destroy the adjacencies, the goodbye notification packet having a packet header with an appended goodbye attribute having a predetermined goodbye type and a list of neighbor (peer) identifiers (IDs), wherein each neighbor identified by a peer ID on the list destroys its adjacency with the router.
15. Apparatus adapted to notify neighbors when destroying adjacencies in a computer network, the apparatus comprising:
means for sending a goodbye notification packet from a router to one or more of the neighbors to inform the neighbors to destroy the adjacencies, the goodbye notifica-tion packet having a packet header with an appended goodbye attribute;
means for examining the appended goodbye attribute at each neighbor;
if the neighbor is configured to understand the goodbye attribute, means for searching a list of peer identifiers (IDs) contained in the goodbye attribute to determine if the peer ID of the neighbor is on the list; and if the peer ID of the neighbor is on the list, means for destroying the adjacency with the router.
means for sending a goodbye notification packet from a router to one or more of the neighbors to inform the neighbors to destroy the adjacencies, the goodbye notifica-tion packet having a packet header with an appended goodbye attribute;
means for examining the appended goodbye attribute at each neighbor;
if the neighbor is configured to understand the goodbye attribute, means for searching a list of peer identifiers (IDs) contained in the goodbye attribute to determine if the peer ID of the neighbor is on the list; and if the peer ID of the neighbor is on the list, means for destroying the adjacency with the router.
16. The apparatus of Claim 15 wherein the means for examining comprises means for examining a type of the goodbye attribute to determine if the neighbor is configured to understand that type of information.
17. The apparatus of Claim 16 further comprising, if the neighbor is not configured to understand the goodbye attribute, means for skipping over a value field of the goodbye attribute.
18. A computer readable medium containing executable program instructions for noti-fying neighbors when destroying adjacencies in a computer network, the executable program instructions comprising program instructions for:
sending a goodbye notification packet from a router to one or more of the neighbors to inform the neighbors to destroy the adjacencies, the goodbye notification packet having a packet header with an appended goodbye attribute;
examining the appended goodbye attribute at each neighbor;
if the neighbor is configured to understand the goodbye attribute, searching a list of peer identifiers (IDs) contained in the goodbye attribute to determine if the peer ID of the neighbor is on the list; and if the peer ID of the neighbor is on the list, destroying the adjacency with the router.
sending a goodbye notification packet from a router to one or more of the neighbors to inform the neighbors to destroy the adjacencies, the goodbye notification packet having a packet header with an appended goodbye attribute;
examining the appended goodbye attribute at each neighbor;
if the neighbor is configured to understand the goodbye attribute, searching a list of peer identifiers (IDs) contained in the goodbye attribute to determine if the peer ID of the neighbor is on the list; and if the peer ID of the neighbor is on the list, destroying the adjacency with the router.
19. The computer readable medium of Claim 18 wherein the program instruction for examining comprises one or more program instructions for examining a type of the goodbye attribute to determine if the neighbor is configured to understand that type of information.
20. The computer readable medium method of Claim 19 further comprising one or more program instructions for, if the neighbor is not configured to understand the goodbye attribute, skipping over a value field of the goodbye attribute.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/465,129 US7388862B2 (en) | 2003-06-19 | 2003-06-19 | Technique for notifying EIGRP neighbors when destroying adjacencies in a computer network |
| US10/465,129 | 2003-06-19 | ||
| PCT/US2004/004615 WO2005006682A2 (en) | 2003-06-19 | 2004-02-17 | Technique for notifying eigrp neighbors when destroying adjacencies in a computer network |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2521501A1 CA2521501A1 (en) | 2005-01-20 |
| CA2521501C true CA2521501C (en) | 2009-12-15 |
Family
ID=33517440
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002521501A Expired - Fee Related CA2521501C (en) | 2003-06-19 | 2004-02-17 | Technique for notifying eigrp neighbors when destroying adjacencies in a computer network |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US7388862B2 (en) |
| EP (1) | EP1634411B1 (en) |
| CN (1) | CN100484088C (en) |
| AU (1) | AU2004300837B2 (en) |
| CA (1) | CA2521501C (en) |
| WO (1) | WO2005006682A2 (en) |
Families Citing this family (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9137033B2 (en) | 2003-03-18 | 2015-09-15 | Dynamic Network Services, Inc. | Methods and systems for monitoring network routing |
| US7626948B1 (en) * | 2003-09-12 | 2009-12-01 | Cisco Technology, Inc. | System and method for verifying the validity of a path in a network environment |
| US7720054B2 (en) * | 2004-03-02 | 2010-05-18 | Cisco Technology, Inc. | Router configured for outputting update messages specifying a detected attribute change of a connected active path according to a prescribed routing protocol |
| US7924726B2 (en) * | 2004-07-12 | 2011-04-12 | Cisco Technology, Inc. | Arrangement for preventing count-to-infinity in flooding distance vector routing protocols |
| US7733868B2 (en) * | 2005-01-26 | 2010-06-08 | Internet Broadcasting Corp. | Layered multicast and fair bandwidth allocation and packet prioritization |
| US7792045B1 (en) * | 2005-08-25 | 2010-09-07 | Emc Corporation | Method and apparatus for configuration and analysis of internal network routing protocols |
| US7583672B2 (en) | 2006-04-05 | 2009-09-01 | Cisco Technology, Inc. | Techniques to support asymmetrical static/dynamic adjacency in routers |
| US7512106B2 (en) * | 2006-08-01 | 2009-03-31 | Cisco Technology, Inc. | Techniques for distributing routing information using multicasts |
| WO2008033424A2 (en) * | 2006-09-12 | 2008-03-20 | Foleeo, Inc. | Hive-based peer-to-peer network |
| US20080080750A1 (en) * | 2006-10-02 | 2008-04-03 | Wison Technology Corp. | Interactive wireless fingerprint recognition system |
| US20080175449A1 (en) * | 2007-01-19 | 2008-07-24 | Wison Technology Corp. | Fingerprint-based network authentication method and system thereof |
| US7821970B2 (en) * | 2007-09-26 | 2010-10-26 | Cisco Technology, Inc. | Protection of transit links in a network |
| US9319277B2 (en) * | 2007-11-14 | 2016-04-19 | At&T Intellectual Property I, L.P. | Network router employing enhanced prefix limiting |
| CN101179444B (en) * | 2007-12-11 | 2010-12-08 | 华为技术有限公司 | Configuration take-effective method, configuration system and configuration gateway |
| US8644186B1 (en) | 2008-10-03 | 2014-02-04 | Cisco Technology, Inc. | System and method for detecting loops for routing in a network environment |
| US8699368B2 (en) | 2011-07-26 | 2014-04-15 | Cisco Technology, Inc. | Link reliability metrics in communication networks |
| US8831019B2 (en) * | 2012-05-18 | 2014-09-09 | Renesys | Path reconstruction and interconnection modeling (PRIM) |
| US10439880B2 (en) * | 2014-11-05 | 2019-10-08 | Cisco Technology, Inc. | Loop-free convergence in communication networks |
| CN104598626B (en) * | 2015-02-04 | 2018-02-02 | 中国人民解放军总后勤部军事交通运输研究所 | Data modularization storage method in automatic tag identification |
| CN111310893B (en) * | 2016-08-05 | 2023-11-21 | 中科寒武纪科技股份有限公司 | Device and method for executing neural network operation |
| CN109067781B (en) * | 2018-09-18 | 2021-04-16 | 重庆金美通信有限责任公司 | Method for improving EIGRP protocol message information capacity |
| US11516320B2 (en) * | 2020-12-23 | 2022-11-29 | Itron, Inc. | Frame compatibility across network protocol versions |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2092134C (en) * | 1992-03-24 | 1998-07-21 | Anthony J. Mazzola | Distributed routing network element |
| US6038212A (en) * | 1996-12-13 | 2000-03-14 | International Business Machines Corporation | Method and system for optimizing the connection set up time in high speed communication networks for recovering from network failure |
| US5964841A (en) * | 1997-03-03 | 1999-10-12 | Cisco Technology, Inc. | Technique for handling forwarding transients with link state routing protocol |
| US6339595B1 (en) * | 1997-12-23 | 2002-01-15 | Cisco Technology, Inc. | Peer-model support for virtual private networks with potentially overlapping addresses |
| US6202114B1 (en) * | 1997-12-31 | 2001-03-13 | Cisco Technology, Inc. | Spanning tree with fast link-failure convergence |
| US6314105B1 (en) | 1998-05-19 | 2001-11-06 | Cisco Technology, Inc. | Method and apparatus for creating and dismantling a transit path in a subnetwork |
| US6512768B1 (en) * | 1999-02-26 | 2003-01-28 | Cisco Technology, Inc. | Discovery and tag space identifiers in a tag distribution protocol (TDP) |
| US6392997B1 (en) | 1999-03-16 | 2002-05-21 | Cisco Technology, Inc. | Technique for group-based routing update with limited per neighbor/adjacency customization |
| US6553423B1 (en) | 1999-05-27 | 2003-04-22 | Cisco Technology, Inc. | Method and apparatus for dynamic exchange of capabilities between adjacent/neighboring networks nodes |
| US6779042B1 (en) | 1999-09-10 | 2004-08-17 | Ianywhere Solutions, Inc. | System, method, and computer program product for enabling on-device servers, offline forms, and dynamic ad tracking on mobile devices |
| JP3654158B2 (en) * | 2000-08-09 | 2005-06-02 | 日本電気株式会社 | Packet transfer path control apparatus and packet transfer path control method used therefor |
| US7035202B2 (en) * | 2001-03-16 | 2006-04-25 | Juniper Networks, Inc. | Network routing using link failure information |
| US7126921B2 (en) * | 2001-05-14 | 2006-10-24 | Tropic Networks Inc. | Packet network providing fast distribution of node related information and a method therefor |
| US6590868B2 (en) | 2001-06-02 | 2003-07-08 | Redback Networks Inc. | Method and apparatus for restart communication between network elements |
| US6931441B1 (en) * | 2001-06-29 | 2005-08-16 | Cisco Technology, Inc. | Method and apparatus for managing a network using link state information |
| FR2831743B1 (en) * | 2001-10-25 | 2004-01-30 | Cit Alcatel | IS-IS FAULT TOLERANT ROUTING SYSTEM AND CORRESPONDING METHOD |
-
2003
- 2003-06-19 US US10/465,129 patent/US7388862B2/en active Active
-
2004
- 2004-02-17 EP EP04711860.9A patent/EP1634411B1/en not_active Expired - Lifetime
- 2004-02-17 CN CNB2004800113057A patent/CN100484088C/en not_active Expired - Fee Related
- 2004-02-17 WO PCT/US2004/004615 patent/WO2005006682A2/en active Application Filing
- 2004-02-17 AU AU2004300837A patent/AU2004300837B2/en not_active Expired - Fee Related
- 2004-02-17 CA CA002521501A patent/CA2521501C/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CA2521501A1 (en) | 2005-01-20 |
| WO2005006682A3 (en) | 2005-04-07 |
| EP1634411B1 (en) | 2013-05-01 |
| US20040258002A1 (en) | 2004-12-23 |
| WO2005006682A2 (en) | 2005-01-20 |
| EP1634411A2 (en) | 2006-03-15 |
| CN100484088C (en) | 2009-04-29 |
| AU2004300837B2 (en) | 2009-12-03 |
| AU2004300837A1 (en) | 2005-01-20 |
| CN1792064A (en) | 2006-06-21 |
| US7388862B2 (en) | 2008-06-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2521501C (en) | Technique for notifying eigrp neighbors when destroying adjacencies in a computer network | |
| US7065059B1 (en) | Technique for restoring adjacencies in OSPF in a non-stop forwarding intermediate node of a computer network | |
| CA2536497C (en) | Distributed software architecture for implementing the border gateway protocol (bgp) | |
| US9300563B2 (en) | Technique for efficiently and dynamically maintaining bidirectional forwarding detection on a bundle of links | |
| US8953432B2 (en) | Softrouter dynamic binding protocol | |
| EP1698089B1 (en) | System and method for distributing route selection in an implementation of a routing protocol | |
| EP1723542B1 (en) | Technique for graceful shutdown of a routing protocol in a network | |
| US20150312132A1 (en) | METHOD TO CHECK HEALTH OF AUTOMATICALLY DISCOVERED CONTROLLERS IN SOFTWARE DEFINED NETWORKS (SDNs) | |
| US6950427B1 (en) | Technique for resynchronizing LSDB in OSPF after a software reload in a non-stop forwarding intermediate node of a computer network | |
| US7248579B1 (en) | System and method for providing a link state database (LSDB) snapshot for neighbor synchronization | |
| US20040260834A1 (en) | Scalable router-based network node | |
| US7639680B1 (en) | Out of band data base synchronization for OSPF | |
| US7633874B1 (en) | Soft notification messaging for a routing protocol | |
| CN114448859A (en) | Supporting multiple transport options for border gateway protocol | |
| Cisco | Configuring Novell IPX | |
| Cisco | Configuring Novell IPX | |
| Cisco | Configuring Novell IPX | |
| Cisco | Configuring Novell IPX | |
| Cisco | Configuring Novell IPX | |
| Cisco | Configuring Novell IPX | |
| Cisco | Configuring Novell IPX | |
| Cisco | Configuring Novell IPX | |
| Cisco | Configuring Novell IPX | |
| Cisco | Configuring Novell IPX | |
| Jeker | Design and Implementation of |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |
Effective date: 20180219 |