U.S. patent application number 10/742132 was filed with the patent office on 2004-10-21 for dynamic routing on networks.
This patent application is currently assigned to Nokia Inc.. Invention is credited to Sharma, Atul.
Application Number | 20040210892 10/742132 |
Document ID | / |
Family ID | 29778857 |
Filed Date | 2004-10-21 |
United States Patent
Application |
20040210892 |
Kind Code |
A1 |
Sharma, Atul |
October 21, 2004 |
Dynamic routing on networks
Abstract
Systems and methods are provided for routing packets on a
network based on information of a routing gateway or a neighboring
gateway. One embodiment includes updating a routing table using
interface information shared by a neighboring router. Another
embodiment includes making routing decisions based on interface
information from a neighboring router. Another embodiment includes
making routing decisions based on priorities determined from
interface information. Another embodiment updating a routing table
on a first gateway by receiving data disclosing interface
information on a neighboring second gateway and updating a routing
table based on the interface information. Another embodiment
includes maintaining a routing table on the first gateway that
includes, for each route, information on the gateway that is two
physical hops away from the first gateway. For each route, if the
gateway that is two physical hops away from the first gateway is
the first gateway, the route is made inactive.
Inventors: |
Sharma, Atul; (Westford,
MA) |
Correspondence
Address: |
DARBY & DARBY P.C.
P.O. BOX 5257
NEW YORK
NY
10150-6257
US
|
Assignee: |
Nokia Inc.
Irving
TX
75039
|
Family ID: |
29778857 |
Appl. No.: |
10/742132 |
Filed: |
December 18, 2003 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10742132 |
Dec 18, 2003 |
|
|
|
10180081 |
Jun 27, 2002 |
|
|
|
6744774 |
|
|
|
|
Current U.S.
Class: |
717/168 ;
717/171 |
Current CPC
Class: |
H04L 45/302 20130101;
H04L 63/0272 20130101; H04L 45/02 20130101; H04L 45/48 20130101;
H04L 63/164 20130101; H04L 45/12 20130101 |
Class at
Publication: |
717/168 ;
717/171 |
International
Class: |
G06F 009/44 |
Claims
I claim:
1. A gateway for routing over a network, comprising: a transceiver
that is configured to receive a signal, wherein the signal includes
information that is associated a second gateway that is two
physical hops away from the gateway; and a processor that is
configured to perform actions, the actions comprising: maintaining
a routing table that identifies a third gateway that is two
physical hops away from the gateway; and updating the routing table
in response to the signal.
2. The gateway of claim 1, wherein the signal includes at least one
of a distance vector response message and a link state
advertisement message.
3. The gateway of claim 1, wherein the signal is sent from a fourth
gateway, the signal includes an entry that indicates an address of
the second gateway, and wherein the second gateway is one physical
hop away from the fourth gateway.
4. The gateway of claim 1, wherein the signal is sent from a fourth
gateway, the signal includes a first indicator that indicates a
link type of a link that is associated with the fourth gateway, the
second gateway is the third gateway, and wherein if the link type
corresponds to a virtual link type, the signal further includes a
second indicator that identifies the third gateway.
5. The gateway of claim 1, wherein the gateway is further
configured to route packets based on the routing table.
6. The gateway of claim 1, wherein the gateway is further
configured to dynamically route packets based on the routing table,
and wherein the gateway is part of a one-legged virtual private
network.
7. The gateway of claim 1, wherein the routing table includes a
plurality of route entries, and wherein the processor is configured
to maintain the routing table by including a next_nexthop indicator
for each of the plurality of route entries.
8. The gateway of claim 7, wherein the processor is configured to
perform further actions, comprising: determining, for each of the
route entries, if the next_nexthop indicator identifies the
gateway; and if the next_nexthop indictor identifies the gateway,
making the route entry inactive.
9. A gateway for routing over a network, comprising: a transceiver
that is configured to process packets; and a processor that is
configured to perform actions, the actions comprising: maintaining
a routing table that includes a plurality of route entries, wherein
each of the route entries is associated with a route, each of the
route entries includes a next_nexthop indicator, and wherein each
next_nexthop indicator identifies another gateway that is two
physical hops from the gateway on the associated route; and for
each route of the plurality of route entries: determining if the
next_nexthop indicator of the route entry identifies the gateway;
and if the next_nexthop indicator of the route entry identifies the
gateway, making the route inactive.
10. The gateway of claim 9, wherein the processor is configured to
perform further actions, comprising receiving a routing message;
and updating the routing table in response to the routing
message.
11. The gateway of claim 10, wherein the routing message is related
to one of the next_nexthop indicators, and wherein the processor is
configured to update the routing table such that the one of the
next_nexthop indicators is updated.
12. The gateway of claim 10, wherein the processor is configured to
update the routing table such that a new next_nexthop indicator is
added to the routing table.
13. A method for routing over a network, comprising: maintaining a
routing table that is associated with a gateway, wherein the
routing table identifies another gateway that is two physical hops
away from the gateway, wherein at least one of the two physical
hops is associated with a virtual interface; and routing a packet
based upon the routing table.
14. The method of claim 13, wherein the routing table includes a
plurality of route entries, each of the route entries includes a
next_nexthop indicator, and wherein each next_nexthop indicator
identifies an indicated gateway that is two physical hops from the
gateway on a route that is associated with the route entry.
15. The method of claim 14, further comprising: for each route of
the plurality of routes: determining if the next_nexthop indicator
identifies the gateway, wherein the routing table is maintained in
the gateway; and if the next_nexthop indicator identifies the
gateway, making the route inactive.
16. The method of claim 13, further comprising: receiving a signal,
wherein the signal includes information that is associated with a
second gateway that is two physical hops away the gateway; and
updating the routing table in response to the signal.
17. The gateway of claim 16, wherein the signal is sent from a
third gateway, and wherein the signal includes an entry that
indicates an address of the second gateway.
18. A computer-readable medium encoded with a data structure for
routing a packet over a network, the data structure comprising: a
plurality of route entries, wherein each route entry is associated
with a route over the network, wherein the plurality of route
entries is associated with a gateway, and wherein each route entry
comprises an indicator that identifies an indicated gateway that is
two physical hops away from the gateway.
19. The computer-readable medium of claim 18, wherein, for at least
one of the route entries, the indicated gateway is the gateway.
20. A gateway for routing over a network, comprising: means for
maintaining a routing table that identifies at least one gateway
that is two physical hops away from the gateway, wherein at least
one of the two physical hops is associated with a virtual
interface; and means for routing a packet based upon the routing
table.
Description
RELATED APPLICATIONS
[0001] This application is a continuation-in-part of the
application having the application Ser. No. 10/180,181, filed on
Jun. 27, 2002, of which the benefit of the earlier filing date is
hereby claimed under 35 U.S.C. .sctn. 120, and of which is hereby
incorporated by reference.
FIELD OF THE INVENTION
[0002] This invention relates generally to telecommunications
networks. More particularly, the invention concerns systems and
methods for dynamically routing packets on a network.
BACKGROUND OF THE INVENTION
[0003] Dynamic Routing is used on the Internet backbone (core and
edge) routers. With the coming of Virtual Private Networks and
overlay secure networks using VPN, semantics of dynamic routing
shall be affected. Current methods for dynamic routing will lead to
various issues and difficulties as virtual private networks become
more common. Issues related to running dynamic routing on virtual
private networks need to be addressed.
[0004] IPsec is the Internet Engineering Task Force (IETF)
standards protocol for providing security over the Internet at the
network (IP) level. It provides authentication and encryption with
the help of manual or automatic key exchange via IKE protocol.
IPsec can be implemented via transport or tunnel mode. For the
application of virtual private networks and secure overlay
networks, tunnel mode of IPsec is typically used. Many
implementations implement IPsec tunnels as logical virtual
interfaces overlaying the physical interfaces. These logical
virtual interfaces can be used as with other interfaces to run
dynamic protocols on top of them. In such a setup, the tunnel
endpoints will be considered as neighbors and the tunnel will be
considered as a point-to-point link.
[0005] Running a dynamic protocol, such as Open Shortest Path First
(OSPF), Routing Information Protocol (RIP), or Border Gateway
Protocol (BGP) on a tunnel interface would mean that routing
information like adjacency, distance vector, and link state of the
nodes behind one tunnel end point are shipped to the remote tunnel
endpoint. As such, the routes at one end (local and private) are
learned by the remote tunnel endpoint.
[0006] For example, FIG. 1 shows a tunnel link between endpoints A
and B via the Internet.
[0007] After enabling a dynamic protocol on the tunnel link
interfaces on A and B, the routes to hosts in protected network A
shall be visible to B as well as to hosts in protected network B.
Similarly, the routes in protected network B shall be visible to A
as well as to hosts in protected network A. The routing information
conveyed in the dynamic routing protocol shall go out encrypted
from A to B and B to A.
[0008] After the new routes are learned, for traffic from A or
hosts in protected network A destined to B, or for hosts in
protected network B, the tunnel interface can be chosen. As such,
packets will go through IPsec processing, thereby coming out of the
tunnel encrypted for destinations in B. Difficulties may arise,
however, such as difficulties related to conflicts in routing
between the virtual nature of the link between A and B and the
physical links on which it is overlaid. Other difficulties may also
arise, such as related to routing decisions between virtual paths
and physical paths, between more than one virtual path, or between
IPsec processing and routing procedures.
SUMMARY OF THE INVENTION
[0009] The present invention overcomes many routing difficulties
that may arise in relation to dynamic routing and virtual paths. As
such, the present invention provides methods for updating a routing
table and routing packets on a network having virtual links
overlaying physical links. One embodiment of the invention includes
updating a routing table using interface information shared by a
neighboring router. Other embodiments include making routing
decisions based on interface information from a neighboring router.
Further embodiments include making routing decisions based on
priorities established according to interface information. Yet
other embodiments include making routing decisions based on local
interface information.
[0010] In one embodiment of the invention, a method of updating a
routing table on a first gateway includes the steps of receiving
data disclosing interface information on a neighboring second
gateway, and updating a routing table based on the interface
information. The interface information for the neighboring second
gateway includes identification of communication interfaces on the
second gateway, a neighbor for each one of the interfaces, an
interface type for each one of the interfaces, and a physical type
interface on which each virtual type interface is overlaid.
[0011] In another embodiment of the invention, a gateway is
provided that routes packets based on data provided in an interface
message from neighboring gateways. The steps involved in routing a
packet at the gateway includes receiving the data packet, choosing
a first route based on a routing protocol, determining an interface
on the second gateway corresponding to a second next hop in the
route, identifying a third gateway based on the interface, and if
the third gateway matches the first gateway, choosing another
route.
[0012] In other embodiments of the invention, computer-executable
instructions for implementing the disclosed methods are stored on
computer-readable media. Other features and advantages of the
invention will become apparent with reference to the following
detailed description and figures.
BRIEF DESCRIPTION OF THE DRAWINGS
[0013] The invention will be described in detail in the following
description of preferred embodiments with reference to the
following figures wherein:
[0014] FIG. 1 shows an architecture that supports virtual
connections between gateways in accordance with prior art;
[0015] FIG. 2 shows an architecture that supports apparatus and
methods in accordance with embodiments of the invention;
[0016] FIG. 3 shows a RIP Response Message and an Interface
Message/Interface Table in accordance with one embodiment of the
present invention according to the architecture of FIG. 2;
[0017] FIG. 4 shows a Link State Advertisement Message, an
Interface Table, and entries from a Global Routing Table in
accordance with another embodiment of the present invention
according to the architecture of FIG. 2;
[0018] FIG. 5 shows a router according to a further embodiment of
the present invention;
[0019] FIG. 6 shows a Radix Prefix Tree based on a Global Routing
Table according to another embodiment of the present invention
based on the architecture of FIG. 2;
[0020] FIG. 7 shows another architecture that supports apparatus
and methods in accordance with embodiments of the invention;
[0021] FIG. 8 shows a Radix Prefix Tree based on a Global Routing
Table according to another embodiment of the present invention
based on the architecture of FIG. 7;
[0022] FIG. 9 shows a Radix Prefix Tree based on a Global Routing
Table according to a further embodiment of the present invention
based on the architecture of FIG. 7;
[0023] FIG. 10 shows steps of a method in accordance with
embodiments of the invention;
[0024] FIG. 11 shows a distance vector response message in
accordance with another embodiment of the present invention;
[0025] FIG. 12 shows a Link State Advertisement message in
accordance with another embodiment of the present invention;
[0026] FIG. 13 shows a routing entry in accordance with another
embodiment of the invention;
[0027] FIG. 14 shows a flow chart of a method in accordance with
embodiments of the invention;
[0028] FIG. 15 shows a Prefix Tree based on a Global Routing Table
according to another embodiment of the present invention; and
[0029] FIG. 16 shows a block diagram of a one-legged virtual
private network in accordance with embodiments of the present
invention.
DETAILED DESCRIPTION OF THE INVENTION
[0030] Throughout the specification and claims, the following terms
take at least the meanings explicitly associated herein, unless the
context clearly dictates otherwise. The meanings identified below
are not intended to limit the terms, but merely provide
illustrative examples for the terms. The phrase "in one
embodiment," as used herein does not necessarily refer to the same
embodiment, although it may. The meaning of "a," "an," and "the"
includes plural reference, and the meaning of "in" includes "in"
and "on."
[0031] The invention may be embodied in various forms. Referring
now to FIG. 2, a network architecture 10 is shown that supports
systems and methods in accordance with embodiments of the
invention. The architecture generally includes gateways A, B, C, D,
E, and F labeled 12, 14, 16, 18, 20, and 22 respectively. A gateway
as used herein refers to any device capable of forwarding data
packets, such as a personal computer or a router. That is, the term
gateway refers to any node in a network that can forward data
packets, and can also refer to an entire network through which data
packets are forwarded. Architecture 10 is a simple example that
does not differentiate between hosts and routers, packet switches
and terminals, subnets and links, etc. Each gateway is identified
by its address, which is simply represented here as A, B, C, D, E
and F. Assume for simplicity sake that the links are symmetric.
[0032] As shown, gateway A is connected to neighbors C, E, and F
via links 24 (L1), 26 and 28 respectively. Likewise, gateway D is
connected to neighbors C and B via links 30 (L2) and 32 (L3)
respectively. The links may be point-to-point links or broadcast
links. A tunnel 34 acts as a virtual link between gateways A and B,
which have a security association therebetween. As such, gateways A
and B treat each other as neighbors, even though in reality tunnel
34 is overlaid on physical links L1, L2 and L3. From the
perspective of gateway A, gateway E is in the network net2, gateway
B is the network net5, gateway C is in the network net0, gateway D
is in the network net4, and gateway F is in the network net1.
[0033] An example gateway according to one embodiment of the
invention is shown in FIG. 5, which includes a router 100. The
router 100 generally includes a processor 102 connected to a memory
104 and a plurality of real interfaces 106, 108, and 110. The real
interfaces 106, 108, 110 according to one embodiment include
ethernet interfaces identified as eth0, eth1 and eth2, which
correspond to real (physical) interfaces 110, 106 and 108
respectively. As an example, suppose that router 100 represents
gateway A. Accordingly, as represented in FIG. 2, interface eth0 is
connected to network net0 with gateway C as a next hop within that
network. In addition, eth1 is connected to network net1 with
gateway F as a next hop within that network, and eth2 is connected
to network net2 with gateway E as a next hop within that network.
Further, based on a security association with another gateway,
virtual interface 120 (e.g. tun0 for gateway C) may be established
and stored in memory 104 for forwarding packets via an associated
tunnel, such as tunnel 34. Tun0 therefore is a virtual interface on
gateway A that is connected to network net3 with gateway B as a
neighbor (a virtual next hop) within that network.
[0034] Tun0, however, is overlaid on eth0, which is connected to
net0 with gateway C as a neighbor.
[0035] Stored in the memory 104 of router 100 are forwarding
software 112 and a global routing table 116. As discussed later, a
routing daemon 114 may also be stored in the memory 104, as well as
an interface table 118 for a neighboring router. Routing daemon 114
and forwarding software 112 are programs written in a language such
as the language known as C. In one embodiment router 100 operates
on a UNIX.RTM. operating system, such as systems known as Berkeley
System Distribution Unix (BSD) or Free BSD.
[0036] Referring back to FIG. 2, suppose that from the perspectives
of A and C, based on a metric such as a throughput metric or a
delay metric, that tunnel 34 has a cost equal to 5. Suppose also
that L1 has a cost of 1, L2 has a cost of 1, and L3 has a cost of
10. This creates an inconsistency of costs for tunnel 34 versus the
aggregate cost of physical links L1, L2 and L3 on which tunnel 34
is overlaid. This inconsistency may be due to various reasons, such
as the use of multiple metrics, inconsistent updates from gateways,
flaws in computing metrics, or for other reasons.
[0037] Suppose now that a data packet (not shown) arrives at
gateway A and that the data packet has a destination, for example a
gateway (not shown) beyond gateway B. As such, gateway A may route
the packet to gateway B through at least two routes. Assume that
one route through tunnel 34 is a viable option and that another
route through links L1, L2 and L3 (i.e. unencrypted) is another
option. Assume based on the lower cost of tunnel 34, gateway A
selects the route with tunnel 34 and therefore performs IPSec
processing and forwards the packet on tunnel 34 to gateway B.
Because tunnel 34 overlays L1, the packet is forwarded to C with a
destination address for B. Based on an aggregate cost of 6 to
forward the packet via L1 and tunnel 34 versus an aggregate cost of
11 to forward the packet via L2 and L3, gateway C forwards the
packet to A. Gateway A repeats its evaluation and forwards the
packet back to gateway C. Accordingly, the packet is continuously
looped until its time to live expires, thereby never reaching
gateway B. The continuous loop between A and C may be avoided by
exchanging interface information between neighboring gateways A and
C and updating their routing tables accordingly.
[0038] Referring now to FIGS. 2, 3, 5 and 10, a method for updating
a routing table according to interface information for a neighbor
gateway in accordance with one embodiment of the invention is
shown. Inclusion of interface information of neighboring gateways
in routing decisions avoids the loop problem discussed above. It
further avoids other potential problems and provides advantages,
such as greater flexibility and improved accuracy in routing
decisions. Such routing decisions generally include the use of
dynamic routing protocols.
[0039] As an example, suppose that a dynamic routing protocol in
operation on gateway A and C includes a distance vector protocol
such as Routing Information Protocol (RIP) version 1 (see IETF RFC
1058) or RIP version 2 (see IETF RFC 1388). In accordance with such
protocols, gateways typically send routing messages to their
neighbors that include routing information known by the sending
gateway. Suppose that gateways A and C use RIP and that gateway A
sends 80 to gateway C a routing message 34, which in this example
is a RIP response message.
[0040] As shown in FIG. 3, the RIP response message 34 according to
one embodiment of the invention includes an identification 36 of
each network connected to A (e.g. net0, net1, net2 and net3), the
number of hops 38 to each network identified, and a nexthop_link
indicator 40 for each network. The nexthop_link indicator 40 in one
embodiment includes information that discloses an interface.sub.'id
42 for one of the interfaces 106, 108, 110, 120 on A for the
network represented by identification 36. In other words,
nexthop_link discloses the interface on A that a packet will take
in being forwarded on A to the network with which the nexthop_link
is associated.
[0041] According to such an embodiment, gateway A also sends 82 an
interface message 44 to gateway C. The interface message 44 may be
sent along with the RIP response message 34 or it may be sent
independently. The interface message 44 according to one embodiment
includes an interface list 46 that discloses an interface_id 42 for
each interface on gateway A. For each interface_id 42, interface
message 44 discloses an interface type 48 for the corresponding
interface on A, a neighbor 50 (a gateway for a point to point
network or a network for a broadcast network) to which the
corresponding interface is connected, and if the interface type 48
is virtual, the physical type interface 52 on which the virtual
type interface is overlaid.
[0042] Upon reception of the interface message 44, gateway C either
creates 84 an interface table 54 for gateway A and stores it in
memory 104, or updates an existing interface table 54 in memory
104, according to instructions stored in memory 104. The interface
table 54 according to one embodiment includes interface list 46
from interface message 44. Upon reception of RIP Response message
34, gateway C updates 86 entries 35 of a global routing table (not
shown) to include the nexthop_link indicator 42 for each associated
route that includes gateway A as the nexthop in the route. The
nexthop_link indicator 42 identifies the interface_id for the
nexthop from gateway A in the associated route. The nexthop_link
indicator 42 further includes a pointer 56 pointing to an entry in
interface table 54 corresponding to the interface_id for the next
hop. An example of global routing table entries that include
nexthop_link indicators is shown in FIG. 6 and is discussed along
with another embodiment of the invention.
[0043] Referring now to FIGS. 2, 4, 5 and 10, another embodiment of
a method for updating a routing table according to the present
invention is shown. This embodiment coincides with the use of a
link state protocol, such as Open Shortest Path First (OSPF), on
gateways A and C. As such, this embodiment is generally the same as
the previous RIP embodiment, except that only a link state
advertisement message 60 is sent 80 from A to C, rather than an
interface message 44. A conventional OSPF link state advertisement
message includes an indication of link type 62 for each link
connected to the gateway, as well as a link_id 64 for a neighbor
gateway connected to that link. It also typically includes link
data 66 identifying real interfaces on the gateway for each real
link. It may include an interface_id 68 for each interface on the
gateway, but generally does not provide overlay information 70. In
such an embodiment according to the present invention, the link
state advertisement message 60 is expanded to include overlay
information 70 for at least virtual link types.
[0044] As an example, link state advertisement message 60 includes
link type information 62 for each interface on gateway A. The
link_id 64 discloses each of A's neighbors based on the link. For
example, the virtual link from A to B is represented accurately as
a virtual type link with the link_id equaling "B," the neighbor
through that link. It further includes link_data 66, which
identifies a physical interface for each link, or for each virtual
link, identifies a gateway (e.g. gateway A) as a host of the
virtual link. It may further include interface_id 68, which
identifies an interface for each physical or virtual link.
Accordingly, the interface_id for the virtual link on gateway A
identifies tun0 as the interface for the virtual link to B. Overlay
information 70 identifies physical interface "eth0" as being the
real interface for the virtual link 34 to gateway B.
[0045] Upon reception 80 of the link state advertisement message
60, in accordance with a further embodiment the present invention,
an interface table 54 is created (or updated) 84 based on the
information in the advertisement message 60. Further, entries 35 in
the global routing table (not shown) for gateway C may also be
updated 86 to include a nexthop_link indicator 42. The nexthop_link
indicator 42 may be created by information inferred from the
advertisement message 60. For example, routing daemon 114 may
evaluate advertisement message 60 and determine that the
nexthop_link for the virtual link on gateway A is "tun0." Routing
daemon 114 may further create a pointer to an entry in the
interface table 54 that corresponds to the nexthop_link for the
virtual link. Based on the updated global routing table (not shown)
and the interface table 54, methods for routing packets disclosed
in accordance with the RIP embodiment are also applicable in this
embodiment.
[0046] In a further embodiment of the present invention shown in
FIGS. 2, 5 and 10, a method of routing a data packet includes the
steps of receiving 88 a data packet (not shown) and choosing 90 a
potential route based on a routing protocol. Suppose that the
routing is a part of forwarding software 122 stored on gateway C.
Suppose further that gateway C receives a packet (not shown)
destined for gateway B and that the routing protocol selects the
route of L1 to A and A to B (network 3) via tunnel 34 as the
potential route. After selecting such a route, forwarding software
122 (or alternatively routing daemon 114) reviews the entry 35 for
the selected route in the global routing table (not shown), which
includes a nexthop_link indicator 42. Upon finding the nexthop_link
indicator 42, forwarding software 122 is able to determine 92 the
interface that will be taken on gateway A to forward the packet to
gateway B. As indicated by nexthop_link indicator 42, and as shown
in the example architecture 10 and RIP response message 34, gateway
A will forward the packet along such a route using interface
tun0.
[0047] Because nexthop_link indicator 42 further includes a pointer
56 to an entry in interface table 54, forwarding software 112 is
able to determine 92 that the interface having interface_id "tun0"
is a virtual link to neighbor B that is overlaid on the outgoing
physical interface represented by interface_id "eth0." Based on the
entry in interface table 54 for interface_id "eth0," forwarding
software 112 is able to determine that the packet will be forwarded
on "eth0" to neighbor "C." Once forwarding software 112 recognizes
itself (gateway C) as the neighbor for the nexthop_link on A, it
will choose 94 another route that excludes gateway A. As such, the
forwarding software 122 will return another route to B as a
potential route, such as a route through D. A route is chosen 99
based on priority, and the forwarding software forwards 96 the data
packet along the selected route.
[0048] Referring now to FIGS. 2, 5, 6 and 10, another embodiment of
the present invention is shown, which includes a further method for
forwarding a data packet (not shown) based on interface
information. This method may take advantage of previous methods
discussed for updating a routing table. However, in accordance with
this method, a routing daemon 114 stored in memory 104 of a router
100 updates 97 route entries 35 of global routing table (not shown)
to include priorities 70 based on interface information. For
example, assume gateway C has established an interface table 54 for
gateway A and has updated routing entries 35 associated with routes
to gateway B to include nexthop_link indicators 42. Based on
instructions included in daemon 114, daemon 114 evaluates the
nexthop_link 42 for each route to B (e.g. via D or via A), and
assigns a priority based on a potential conflict with the route via
A. Daemon 114 determines the potential conflict by following the
pointer 56 of nexthop_link indicator 42 and by determining that
packets via tun0 on gateway A will be routed to itself, gateway
C.
[0049] As part of the method for routing the packet (not shown),
forwarding software 112 consults global routing table entries 35
for routes to B. This may occur by following logic such as
represented by, for example, a Radix Prefix Tree 72. Upon
evaluating the priorities of entries 35, forwarding software 112
selects 99 the route via D based on its assigned priority being
higher than the priority for the route via A. As such, even though
the route via A has a lower cost as determined by metrics, the
route via D is selected and the data packet is forwarded 96 along
that route.
[0050] Referring now to FIG. 7, a network architecture 210 is shown
that supports systems and methods in accordance with further
embodiments of the invention. The architecture 210 generally
includes gateways A, B, C, D, E, and F labeled 212, 214, 216, 218,
220, and 222 respectively. Architecture 210 is similar to
architecture 10 of FIG. 2, except that gateway F is shown connected
to gateway B. Further, the cost for routing a packet (not shown)
between A and B via gateway F as determined by metrics is 2, versus
a cost of 5 via tunnel 234. Accordingly, for a packet received at
gateway A for forwarding to gateway B, a routing decision based on
metrics would favor the route via gateway F. Such a decision,
however, may be contrary to the intent of sending the packet (not
shown) to gateway A. For example, it may be desirable for the
packet to be routed to gateway B in an encrypted state via tunnel
234, rather than in an unencrypted state via gateway F. A routing
decision based on metrics, therefore, would frustrate this
intent.
[0051] A method of routing a data packet according to one
embodiment of the invention is illustrated with reference to FIGS.
7, 8 and 10. Suppose that a data packet (not shown) is received at
gateway A that has a destination of gateway B. According to
instructions stored in the memory 104 of gateway A, such as part of
a routing daemon 114, entries 235 corresponding to routes to
gateway B in a routing table (not shown) are evaluated and updated
98 to include priorities 270. The priorities are determined by
routing daemon 114 based on the interface type for a local
interface corresponding to each route. As such, routing daemon 114
considers the local interface associated with each route and
determines the interface type for each interface. Daemon 114
thereby determines that the route to gateway B via gateway F is
connected to local interface eth1, which is a physical type
interface. Daemon 114 also determines that the route via tunnel 234
is connected to local interface tun0 and is a virtual type
interface. Because tun0 is a virtual interface and eth1 is a
physical interface, daemon 114 assigns a higher priority 270 to the
route via tunnel 234.
[0052] Based on the priorities, forwarding software 112 selects the
route via tunnel 234 even though the route via gateway F has a
lower cost. Accordingly, the packets received at gateway A will be
encrypted in transmission to gateway B via tunnel 234, despite
other choices suggested by metrics.
[0053] In another embodiment of the invention, forwarding software
112 performs the steps performed by routing daemon 114 except for
assigning priorities. As such, forwarding software 112 determines
that the route via tunnel 234 is connected to local interface tun0
and is a virtual type interface. Because tun0 is a virtual
interface and eth1 is a physical interface, forwarding software 112
selects the route via tunnel 234 according to its programming
despite the costs determined by metrics.
[0054] Referring now to FIGS. 7 and 9, a method of routing a data
packet according to a further embodiment of the invention is shown.
Suppose that an encrypted data packet (not shown) is received at
gateway D from gateway C that has a destination address of gateway
B, as part of routing on tunnel 234. Based on metrics, it is
possible that gateway D will forward the data packet to gateway C
on a route to gateway B that includes gateways C, A, and F. This
may cause a loop as the packet is routed back and forth between
gateways C and D or gateways A, C and D.
[0055] According to a further embodiment of the present invention,
a method for routing a packet is shown in FIG. 9. As such,
instructions stored in the memory 104 of gateway D, such as daemon
114, evaluates potential routes for forwarding the packet to
gateway B by looking at entries 235 of a global routing table. Upon
recognizing that the direct route to gateway B includes one hop
(e.g. nexthop=B), daemon 114 assigns a higher priority to this
route than to other routes that includes multiple hops.
Accordingly, forwarding software 112 selects the direct route to
gateway B over other routes suggested by metrics.
[0056] Embodiments of the invention described with reference to
FIGS. 1-10 above are directed at overcoming the routing
difficulties such as previously described. Embodiments of the
invention described with reference to FIGS. 11-16 below are
directed at overcoming the routing difficulties such as previously
described. Moreover, embodiments of the invention described with
reference to FIGS. 11-16 below are further directed at solving
additional routing difficulties. For example, a one-legged virtual
private network (VPN) may present additional routing difficulties,
as described in greater detail with reference to FIG. 16, below.
Embodiments of the invention described with reference to FIGS.
11-16 may be employed to overcome the routing difficulties
previously described, as well as overcoming routing difficulties
presented by one-legged VPNs and the like.
[0057] FIG. 11 shows an embodiment of distance vector response
message 1134. Distance vector response message 1134 may include a
modified RIP response message, and the like. In one embodiment,
distance vector response message 1134 is sent from gateway A 12 to
gateway C 16 (referring to FIG. 2). Also, distance vector response
message 1134 may include an identification 1136 of each network
connected to gateway A 12 (e.g. net0, net1, net2 and net3,
referring to FIG. 2), the number of hops 1138 to each network
identified, and next_physical_hop indicator 1190 for each network.
Next_physical_hop indicator 1190 may identify the gateway that is
one physical hop away from gateway A 12 for the network
identified.
[0058] FIG. 12 shows Link State Advertisement message 1260. Link
State Advertisement message 1260 may include a modified OSPF Link
State Advertisement message, and the like. In one embodiment, Link
State Advertisement message 1260 is sent from gateway A 12 to
gateway C 16 (referring to FIG. 2).
[0059] Link State Advertisement message 1260 may include link type
indicator 1262 for each link connected to gateway A 12, as well as
link_id 1264 for a neighbor (gateway C 16) connected to that link.
Link type indicator 1262 may indicate whether the link is a
point-to-point link, a virtual link, and the like. Link_id 1264 may
identify each of gateway A 12's neighbors based on the link. In one
embodiment, the virtual link from gateway A 12 to gateway B 14
(referring to FIG. 2) may be represented as a virtual type link
with the link_id identifying gateway B 14, the neighbor through
that link.
[0060] Additionally, Link State Advertisement message 1260 may
include link_data 1266. Link_data 1266 may identify a physical
interface for each physical link. Also, for each virtual link,
Link_data 1266 may identify a gateway (e.g. gateway A 12) as a host
of the virtual link.
[0061] Link State Advertisement message 1260 may further include
interface_id 1268, which may identify an interface for each
physical or virtual link. Accordingly, the interface_id for the
virtual link on gateway A 12 may identify tun0 (referring to FIG.
2) as the interface for the virtual link to gateway B 14. Also,
Link State Advertisement message 1260 may include next_physical_hop
indicator 1280. If the link type for the network identifier is
virtual, next_physical_hop indicator 1280 may identify the gateway
that is one physical hop away from the gateway A 12 for the network
identified.
[0062] According to one embodiment, for link T1 (referring to FIG.
2), link_id 1264 identifies gateway B14, and next_physical_hop
indicator 1280 identifies gateway C 1216, since gateway C 1216 is
the next physical hop from gateway A 12 to gateway B 14 on link
T1.
[0063] According to one embodiment, the gateway that is one
physical hop away from the gateway A 12 for the network is not
identified if the link type for the network is point-to-point, as
illustrated in FIG. 12. Although not shown in FIG. 12, according to
another embodiment, the next_physical_hop indicator may also
identify the gateway that is one physical hop away from the gateway
A 12 for the network identified if the link type for the network
identifier is point-to-point.
[0064] FIG. 13 shows an embodiment of routing entry 1335. Gateway C
16 (referring to FIG. 2) may have a global routing table (not
shown) that may include routing entries 1335 after gateway C 16 has
been updated in response to routing messages. Additionally, each
routing entry 1335 may include Nexthop indicator 1391, local
interface indicator 1392, next_nexthop indicator 1394, priority
indicator 1396, and next route indicator 1398.
[0065] An embodiment of routing entry 1335 that may be included in
the global routing table of gateway C 16 is discussed herein.
However, it is understood that other embodiments of routing entry
1335 may be included in the global routing table of other
gateways.
[0066] Each routing entry 1335 may be associated with a particular
route. In one embodiment, Nexthop indicator 1391 may identify the
gateway that is one physical hop away from this gateway along the
associated route. For this embodiment, "this gateway" refers to
gateway C 16. As used herein, identifying a gateway may refer to
indicating an address of the gateway, and the like. FIG. 13
illustrates an embodiment of routing entry 1335 that is associated
with a route from gateway C 16 to gateway B 14 with gateway A 12
(referring to FIG. 2) as the first physical hop taken. Accordingly,
in this embodiment, Nexthop indicator 1391 identifies gateway A
12.
[0067] Local interface indicator 1392 may identify the first local
interface that a packet would take along the associated route. The
local interface may be virtual or physical. In the embodiment of
routing entry 1335 shown in FIG. 13, local interface indicator 1392
may identify interface Eth0 (referring to FIG. 2), since that is
the first local interface along the associated route.
[0068] Next_nexthop indicator 1394 may identify the gateway that is
two physical hops away from this gateway (i.e. gateway C 16) along
the associated route. FIG. 13 illustrates an embodiment of routing
entry 1335 that is associated with a route from gateway C 16 to
gateway B 14 with gateway A 12 as the first physical hop taken.
Accordingly, in this embodiment, gateway A 12 is the first physical
hop on the route from gateway C 16 to gateway A 12. At gateway A
12, in this embodiment, a packet would use link T1 to reach gateway
B 14. In this embodiment, the first physical hop that a packet
would take on link T1 (when going from gateway A 12 to gateway B
14) is gateway C 16. So in this embodiment, the first physical hop
on the associated route is from gateway C 16 to gateway A 12, and
the second physical hop on the associated route is from gateway A
12 to gateway C 16. Accordingly, for this embodiment, next_nexthop
indicator 1394 may identify gateway C 16.
[0069] Gateway C 16 may be configured to evaluate whether
next_nexthop indicator 1394 identifies itself (i.e. gateway C 16).
If next_nexthop indicator 1394 identifies itself, gateway C 16 may
make the associated route inactive. Making the associated route
inactive may be accomplished in a number of ways, including
discarding the associated route, reducing the priority of the
associated route, making the route unusable in some other manner,
and the like.
[0070] Priority indicator 1396 may indicate the priority of the
associated route. Gateway C 16 may be configured to use the
priority to determine which route should be selected for a packet.
The priority of the associated route may be determined, in part, by
one or more metrics, protocols, and the like. Examples of such
protocols may include distance vector protocols, link state
protocols, and the like. However, the metrics may not be the sole
factor in determining priority. In one embodiment, the priority of
the route may be lowered if next_nexthop indicator 1394 identifies
this gateway (i.e. gateway C 16), as discussed in the previous
paragraph.
[0071] In one embodiment, routing entries 1335 in the global
routing table having associated routes that each lead to the same
gateway may be ordered in a list, group, and the like. In this
embodiment, routing entry 1335 may include next route indicator
1398. Next route indicator 1398 may identify the next routing entry
1335 in the list, if there is a subsequent entry in the list.
[0072] FIG. 14 shows an embodiment of a flow chart of process 1400.
After a start block, the process proceeds to block 1402, where a
signal is received. The signal may be a routing message, and the
like. The routing message may be Distance Vector Response Message
1134 (referring to FIG. 11), Link State Advertisement Message 1236
(referring to FIG. 12), and the like. The routing message may be
received by a gateway that maintains a global routing table. The
routing message may include information that is related to
identifying at least one gateway that is two physical hops away
from this gateway. At least one of the two physical hops may be
associated with a virtual interface, such as tun0 (referring to
FIG. 2), and the like.
[0073] The process then moves from block 1402 to block 1404,
wherein appropriate routing entries (e.g. routing entry 1335,
referring to FIG. 13) for the global routing table are updated.
This may include adding or updating a next_nexthop indicator for
appropriate route entries.
[0074] The process then steps from block 1404 to decision block
1406, where a determination is made as to whether the next nexthop
indicator for any of the route entries in the global routing table
identifies this gateway. "This gateway" refers to the gateway in
which the global routing table is held. In one embodiment, the
determination at block 1406 is made using logic that can be
represented in a prefix tree, as described in greater detail with
reference to FIG. 15 below. If none of the routing entries in the
global routing table identify this gateway, the process advances to
a return block, where the process returns to performing other
actions.
[0075] At decision block 1406, if it is determined that a route
entry identifies this gateway, the process proceeds to block 1408.
At block 1408, the route entry that includes the next_nexthop
indicator that identifies this gateway is made inactive. The
process then moves from block 1408 to the return block, where the
process returns to performing other actions.
[0076] FIG. 15 shows an embodiment of prefix tree 1573 based on a
global routing table (not shown). In one embodiment, a routing
daemon (e.g. 114, referring to FIG. 5) stored in a memory (e.g.
104, referring to FIG. 5) of a gateway (e.g. 100, referring to FIG.
5) updates route entries 1535 of the global routing table to
include priorities 1596. In one embodiment, gateway C 16 updates
routing entries 1535 associated with routes to gateway B 14
(referring to FIG. 2) to include next_nexthop indicators 1594.
Based on instructions that may be included in the daemon, the
daemon may evaluate the next_nexthop indicator 1594 for each route
to gateway B 14 (e.g. via gateway D 18 or via gateway A 12), and
may assign priority 1596 based on a potential conflict with the
route via gateway A 12 (referring to FIG. 2). The daemon may make
the route to gateway C 16 via gateway A 12 inactive, since
next_nexthop indicator 1594 for that route identifies gateway C
16.
[0077] In one embodiment, forwarding software (e.g. 112, referring
to FIG. 5) in gateway C 16 may consult routing entries 1535 for
routes to gateway B 14. This may occur by employing logic such as
represented by, for example, radix prefix tree 1573. Additionally,
the forwarding software may be configured to evaluate priorities
1596 of entries 1535.
[0078] Further, the forwarding software may be configured to then
select the route via gateway D 18 since priority 1596 for the route
via gateway D 18 is higher than the priority for the route via
gateway A 12. Even though the route via gateway A 12 may have a
lower cost as determined by metrics, the route via gateway D 18 may
be selected and a data packet is forwarded along that route. In one
embodiment, a lower number may be used to indicate a higher
priority. In another embodiment, a higher number may be used to
indicate a higher priority. In the embodiment shown in FIG. 15, the
highest priority identified with the number 1, the second highest
priority is identified with the number 2, and so forth.
[0079] FIG. 16 shows a block diagram of an embodiment of one-legged
VPN 1610. One-legged VPN 1610 may include gateways such as gateway
A 1612, gateway B 1614, gateway C 1616, gateway D 1618, gateway E
1660, gateway F 1622, and gateway G 1680. Another embodiment may
include another arrangement for a one-legged VPN.
[0080] Gateway A 1612 may be configured for routing packets. For a
packet that is sent from gateway A 1612 to gateway B 1614 via
virtual link T1, gateway A may encrypt the packet before sending
it. In contrast, for a packet that is sent from gateway A via one
of the physical links L1, L4, or L5, the packet may be sent as
clear text (i.e. unencrypted).
[0081] Gateway G 1680 is part of the one-legged VPN. In one
embodiment, it is desirable for packets sent from gateway G 1680 to
gateway B 1614 to be encrypted. Accordingly, in this embodiment, it
is desirable that a packet sent from gateway G 1680 be forwarded to
gateway A 1612, so that gateway A 1612 can encrypt the packet
before the packet is sent to gateway B 1614. However, in this
embodiment, it is desirable for packets sent from gateway C 1616
that are destined for gateway B 1614 to be forwarded to gateway D
1618 rather than gateway A 1612. If a packet sent from gateway C
1616 that is destined for gateway B 1614 is forwarded to gateway A
1612, a loop may result.
[0082] The desirable forwarding discussed in the previous paragraph
can be accomplished by employing process 1400 (referring to FIG.
14). Employing method 1400, packets sent from gateway G 1680 to
gateway B 1614 (or another gateway that may be reached via gateway
B 1614) may be forwarded to gateway A 1612. In the global routing
table of gateway G 1680, the route entry with an associated route
to gateway B 1614 via gateway A 1612 may have a next_nexthop
indicator that identifies gateway C 1616. If the next_nexthop
indicator does not identify itself (gateway G 1680), the associated
route may be accepted.
[0083] Employing process 1400, packets sent from gateway C to
gateway B 1614 (or another gateway that may be reached via gateway
B) may be forwarded to gateway D 1618 rather than gateway A 1612.
In the global routing table of gateway C 1616, the route entry with
an associated route to gateway B 1614 via gateway A 1612 may have a
next_nexthop indicator that identifies gateway C 1616. Since the
next_nexthop indicator identifies itself (gateway C 1616), the
associated route may be made inactive.
[0084] While the present invention has been described in connection
with the illustrated embodiments, it will be appreciated and
understood that modifications may be made without departing from
the true spirit and scope of the invention. In particular, the
invention applies to almost any type of network and a variety of
different routing protocols, such as path vector protocols. Since
many embodiments of the invention can be made without departing
from the spirit and scope of the invention, the invention also
resides in the claims hereinafter appended.
* * * * *