SESSION-BASED FORWARDING
The present disclosure discloses a method and network device for session based forwarding. Specifically, the disclosed system receives a first packet in a session, and performs a route lookup to determine a route for the first packet. Then, the system caches a reference to the route and a neighbor in the session, and also caches a reference to the session in a tunnel within which packets in the session are to be forwarded. Based on a comparison between the route version number cached in the session and the route version number in a route table corresponding to the route referenced by a route index in the session, the system determines whether the route is stale. If so, the system performs another route lookup to update the route. Moreover, the system uses cached reference to the session in the tunnel for forwarding subsequent packets in the session.
1 . A method comprising:
receiving, by a network device, a first packet in a session;
performing, by the network device, a route lookup based on a header of the first packet to determine a route for the first packet; and
caching, by the network device, a reference to the route and a neighbor in the session such that subsequent packets in the session are routed based on the cached reference in lieu of subsequent route lookups.
2 . The method of claim 1 , wherein the reference to the route comprises one or more of: a route index, a route version number, a neighbor index, and a neighbor index number.
3 . The method of claim 1 , further comprising:
comparing, by the network device, a first route version number cached in the session and a second route version number in a route table corresponding to the route referenced by a route index in the session; and
determining, by the network device, that the route is stale in response to the first route version number being different from the second route version number.
4 . The method of claim 3 , further comprising:
comparing, by the network device, a first neighbor index and version number cached in the session with a second neighbor index and version number in a neighbor table corresponding to the route referenced by the route index in the session; and
determining, by the network device, that the route is stale in response to the first neighbor index or version number being different from the second neighbor index or version number.
5 . The method of claim 4 , further comprising:
in response to determining that the route is stale, performing another route lookup to update the route with one or more of an updated route index, an updated route version number, an updated neighbor index, and an updated neighbor version number.
6 . The method of claim 4 , further comprising:
in response to determining that the route is stale and the session is inactive, delaying route lookup until at least one packet is received in the session.
7 . The method of claim 3 , wherein at least two paths with identical cost corresponding to the route are stored in the route table, each path being identified by a unique Equal Cost Multiple Path (ECMP) index.
8 . The method of claim 7 , wherein, when a new ECMP index is added to the route table, a subsequent session uses the path associated with the new ECMP index and an existing session continues to use an existing path associated with an existing ECMP index.
9 . The method of claim 4 , wherein, when at least two next hop nodes use Virtual Router Redundancy Protocol (VRRP), the route is determined to be stale based on difference between the first neighbor version number cached in the session and the second neighbor version number corresponding to the route in the neighbor table.
10 . The method of claim 3 , further comprising:
in response to the route determined to be stale, performing another route lookup to update the session with an updated route index and an updated route version number;
in response to the updated route index and the updated route version corresponding to a shorter alternative route than the route, forwarding subsequent packets in the session using the shorter alternative route.
11 . The method of claim 10 , wherein the shorter alternative route is stored in a patricia trie as a child node of a parent node, wherein the parent node corresponds to the route, and wherein a route version number of the route corresponding to the parent node is increased in response to the child node being inserted in the patricia trie.
12 . The method of claim 1 , further comprising:
caching, by the network device, a reference to the session in a tunnel within which packets in the session are to be forwarded, thereby allowing direct access to the route from the tunnel.
13 . The method of claim 1 , further comprising:
encapsulating, by the network device, the first packet based on information returned from a bridge lookup prior to encrypting the first packet;
identifying, by the network device, a network interface that the first packet is to be transmitted on;
sending the first packet to a security engine of the network device to encrypt the first packet; and
instructing the security engine to forward encrypted first packet to the identified network interface in lieu of returning the encrypted first packet to a processor within the network device.
14 . A network device having a symmetric multiprocessing architecture, the network device comprising:
a plurality of CPU cores;
a network interface to receive one or more data packets; and
a memory whose access is shared by the dedicated CPU core and the plurality of CPU cores;
wherein the plurality of CPU cores are to:
receive a first packet in a session;
perform a route lookup based on a header of the first packet to determine a route for the first packet; and
cache a reference to the route and a neighbor in the session such that subsequent packets in the session are routed based on the cached reference in lieu of subsequent route lookups.
15 . The network device of claim 14 , wherein the reference to the route comprises one or more of: a route index, a route version number, a neighbor index, and a neighbor index number.
16 . The network device of claim 14 , wherein the plurality of CPU cores are further to:
compare a first route version number cached in the session and a second route version number in a route table corresponding to the route referenced by a route index in the session; and
determine that the route is stale in response to the first route version number being different from the second route version number.
17 . The method of claim 16 , wherein the plurality of CPU cores are further to:
compare a first neighbor index and version number cached in the session with a second neighbor index and version number in a neighbor table corresponding to the route referenced by the route index in the session; and
determine that the route is stale in response to the first neighbor index or version number being different from the second neighbor index or version number.
18 . The network device of claim 17 , wherein the plurality of CPU cores are further to:
perform another route lookup to update the route with one or more of an updated route index, an updated route version number, an updated neighbor index, and an updated neighbor version number in response to determining that the route is stale.
19 . The network device of claim 17 , wherein the plurality of CPU cores are further to:
delay route lookup until at least one packet is received in the session in response to determining that the route is stale and the session is inactive.
20 . The network device of claim 16 , wherein at least two paths with identical costs corresponding to the route are stored in the route table, each path being identified by a unique Equal Cost Multiple Path (ECMP) index.
21 . The network device of claim 20 , wherein, when a new ECMP index is added to the route table, a subsequent session uses the path associated with the new ECMP index and an existing session continues to use an existing path associated with an existing ECMP index.
22 . The network device of claim 17 , wherein, when at least two next hop nodes use Virtual Router Redundancy Protocol (VRRP), the route is determined to be stale based on difference between the first neighbor version number cached in the session and the second neighbor version number corresponding to the route in the neighbor table.
23 . The network device of claim 16 , wherein the plurality of CPU cores further to:
perform another route lookup to update the session with an updated route index and an updated route version number in response to the route determined to be stale;
forward subsequent packets in the session using the shorter alternative route in response to the updated route index and the updated route version corresponding to a shorter alternative route than the route.
24 . The network device of claim 23 , wherein the shorter alternative route is stored in a patricia trie as a child node of a parent node, wherein the parent node corresponds to the route, and wherein a route version number of the route corresponding to the parent node is increased in response to the child node being inserted in the patricia trie.
25 . The network device of claim 14 , wherein the plurality of CPU cores are further to:
cache a reference to the session in a tunnel within which packets in the session are to be forwarded, thereby allowing direct access to the route from the tunnel.
26 . The network device of claim 14 , wherein the plurality of the CPU cores are further to:
encapsulate the first packet based on information returned from a bridge lookup prior to encrypting the first packet;
identify a network interface that the first packet is to be transmitted on;
send the first packet to a security engine of the network device to encrypt the first packet; and
instruct the security engine to forward encrypted first packet to the identified network interface in lieu of returning the encrypted first packet to a processor within the network device.
27 . A non-transitory computer-readable storage medium storing embedded instructions for a plurality of operations that are executed by one or more mechanisms implemented within a network device having a symmetric multiprocessing architecture, the plurality of operations comprising:
receiving a first packet in a session;
performing a route lookup to determine a route for the first packet;
caching a reference to the route in the session;
caching a reference to the session and a neighbor in a tunnel within which packets in the session are forwarded;
comparing a first route version number cached in the session with a second route version number in a route table corresponding to the route referenced by a route index in the session;
determining whether the route is stale based on the first and second route version numbers;
performing another route lookup to update the route in response to determining that the route is stale; and
using cached reference to the session in the tunnel for forwarding subsequent packets in the session.