Patent application number | Description | Published |
20090296579 | EFFICIENT CONVERGENCE OF GROUPED VPN PREFIXES - In one embodiment, one or more virtual private network (VPN) prefixes may be grouped at a network node into sets having shared network border node next-hop options, where each border node has a defined index value associated therewith. Also, a list of VPN labels associated with each VPN prefix may be maintained by the network node, where each VPN label is associated with a border node of a particular set by a corresponding index value. Further, the network node may determine a particular border node for traffic to be forwarded, along with the defined index value. The network node may then apply the index value to select an associated VPN label, and may affix the selected VPN label to the traffic for forwarding. | 12-03-2009 |
20100080131 | Validation of Routes Advertised by Border Gateway Protocol - Disclosed are, inter alia, methods, apparatus, computer-storage media, mechanisms, and means associated with validation of routes advertised by Border Gateway Protocol. One embodiment validates or invalidates a route received in a Border Gateway Protocol (BGP) update message. A route is validated in response to determining that the originating autonomous system specified in the AS_Path attribute for the route in a received BGP update message has authority to advertise the route and/or whether or not multiple autonomous systems identified in the AS_Path attribute of the update message is authorized to advertise the route, possibly in a particular order. | 04-01-2010 |
20100215047 | SUBSETS OF THE FORWARD INFORMATION BASE (FIB) DISTRIBUTED AMONG LINE CARDS IN A SWITCHING DEVICE - Disclosed are, inter alia, methods, apparatus, computer-storage media, mechanisms, and means associated with subsets of the Forward Information Base (FIB) distributed among line cards in a switching device; especially wherein one or more of the line cards does not contain the complete FIB, and this line card forwards packets, for which it does not have the forwarding information, to another line card which has the forwarding information for the packet. | 08-26-2010 |
20100220736 | Advertising alternate paths at border gateway protocol route reflectors - In one embodiment, a method includes receiving routing information at an alternate route reflector in a network, identifying at the alternate route reflector, an alternate path different from a primary path selected and advertised at a primary route reflector in the network, and advertising at the alternate route reflector, the alternate path. The primary and alternate paths define paths for a destination and the alternate path is the only path advertised by the alternate route reflector for the destination. | 09-02-2010 |
20110080911 | Forwarding of Packets to a Same Location Having a Same Internet Protocol (IP) Address Embedded in a Different Advertised Route - Routes advertised in a network may include an Internet Protocol (IP) address and one or more values to distinguish the route from other route(s) including the same IP address. Routes in a same context (e.g., within a same Virtual Private Network or for an entire network) with a same IP address are considered to refer to a same destination. When these routes are associated with different paths through a network, these different paths can be used to forward traffic for packets associated with routes including a same IP address (in a same context), particularly in response to a network problem. | 04-07-2011 |
20120002673 | Distributing Packets to Line Cards of a Packet Switching Device Based on Bridge Indication Values Received Therewith - A packet switching device maintains mappings of bridge identification values to line cards for each of multiple virtual bridges. When a packet is received that includes a bridge identification value, corresponding line card(s) are identified, with each being forwarded the packet. Each of these identified line cards, in response to receipt of the packet from the line card, determines whether to forward or drop the packet based on its maintained bridge table. In this manner, the original receiving line card does not need to maintain forwarding information based on destination addresses of received packets (e.g., does not need to maintain a bridge table for each virtual bridge), but rather forwards a packet to other line cards associated with the virtual bridge corresponding to the bridge identification value received in a packet. | 01-05-2012 |
20120063314 | UNIVERSAL LOAD-BALANCING TUNNEL ENCAPSULATION - In one embodiment, packets received at head-end nodes in a computer network may have a payload and protocol ID of an original protocol of the packet. To allow load balancing across the network, the head-end node may convert the protocol ID to indicate a UDP packet, and may insert a UDP shim header into the packet having a load balance ID, at least one port ID of a destination tail-end node of the packet, and an indication of the original protocol ID. The head-end node may transmit the converted UDP packet toward the tail-end node as part of a load-balanced UDP flow based on the load balance ID. Tail-end nodes may receive UDP packets, and determine whether they are converted UDP packets. If so, the original protocol of the packet may be determined, the UDP header may be removed, and the packet may be processed according to the original protocol. | 03-15-2012 |
20120099420 | EFFICIENT CONVERGENCE OF GROUPED VPN PREFIXES - In one embodiment, a list of border node next hop options is maintained in a memory. The list of border node next hop options includes one or more of border nodes that may be utilized to reach one or more prefixes. An index value is associated with each border node of the list of border node next hop options. A list of labels is also maintained in the memory. The index value of each border node is associated with a corresponding label for a path to reach that border node. When a change to the one or more border nodes is detected, the list of border node next hop options is updated to remove a border node. However, a label for the path to reach the border node is maintained in the list of labels for at least a period of time. | 04-26-2012 |
20120170486 | HIDING A SERVICE NODE IN A NETWORK FROM A NETWORK ROUTING TOPOLOGY - Hiding a service node in a network from a network topology is provided. In one embodiment, for example, an apparatus for hiding a service node in a network from a network topology, the apparatus comprising: a network interface; a processor; and one or more stored sequences of instructions which, when executed by the processor, cause the processor to perform: discovering a service node in a data network in accordance with a link-state protocol wherein the service node provides a network topology dependent service other than packet forwarding; establishing a link-state adjacency with the service node and one or more packet forwarding nodes in accordance with the link-state protocol; receiving a link-state advertisement; in response to identifying the link-state advertisement as an originating link-state advertisement sent from the service node, suppressing flooding of the received link-state advertisement to the one or more packet forwarding nodes. | 07-05-2012 |
20120198064 | USING CONTEXT LABELS TO SCALE MAC TABLES ON COMPUTER NETWORK EDGE DEVICES - In one embodiment, an access component of a local network edge device receives traffic, and generates a frame for the traffic that includes a remote context label that identifies an access component of the remote network edge device to which the traffic is to be forwarded upon arrival at the remote network edge device, and a virtual circuit label corresponding to a particular virtual service of the traffic. The local network edge device forwards the frame towards the remote network edge device. In another embodiment, the frame may be received at a core component of the remote network edge device, an in response to the remote context label identifying an access component of the remote network edge device, forwarded to the access component, which determines the particular virtual service, and forwards the traffic from the frame out the access component towards an endpoint for the traffic. | 08-02-2012 |
20120213225 | Packet Switching Label Assignment Across Multiple Packet Switching Forwarding Groups - In one embodiment, a packet switching device assigns a same particular packet switching label to each particular route of a plurality of particular routes having the same one or more best paths, wherein the plurality of particular routes includes routes from at least two different forwarding groups. A forwarding group is defined as a specific route, one or more routes associated with a same customer edge router, or one or more routes associated with a single virtual routing and forwarding domain (VRF). The packet switching device advertises to other packet switching device(s) to add this same particular label to packets having one of the plurality of particular routes, which they do. The packet switching device then packet switches packets based on the particular label received in a label field in a header of these packets. | 08-23-2012 |
20120230335 | TRAFFIC DISTRIBUTION ACROSS A PLURALITY OF ATTACHMENT CIRCUITS OF A MULTIHOMED SITE - In one embodiment, an edge device of a core network may receive a plurality of packets from a peripheral network having a plurality of active connections to the core network, where each packet has a destination address and a source address. The edge device may compute a hash on the destination address or the source address of each packet, and determine whether the computed hash corresponds to the edge device. In response to the computed hash not corresponding to the edge device, the edge device may drop the packet, and in response to the computed hash corresponding to the edge device, the edge device may process the packet to forward the packet, where the dropping and processing load balances the plurality of packets over the active connections and prevents formation of loops in the core network. | 09-13-2012 |
20130114613 | Virtual Machines in a Packet Switching Device - In one embodiment, a packet switching device creates multiple virtual packet switching devices within the same physical packet switching device using virtual machines and sharing particular physical resources of the packet switching device. One embodiment uses this functionality to change the operating version (e.g., upgrade or downgrade) of the packet switching device by originally operating according to a first operating version, operating according to both a first and second operating version, and then ceasing operating according to the first operating version. Using such a technique, a packet switching device can be upgraded or downgraded while fully operating (e.g., without having to reboot line cards and route processing engines). | 05-09-2013 |
20130176845 | Determining Backup Forwarding Paths Based on Route Distinguisher Correlation Values - In one embodiment, a packet switching device determines backup forwarding paths based on route distinguisher correlation values. A route distinguisher correlation value is some value associated with multiple routes, which allows a packet switching device to consider routes associated with a same route distinguisher correlation value, but having different route distinguishers and a same prefix to be considered as going to a same destination. Examples of route distinguisher correlation value used in one embodiment include, but are not limited to: scalar values, a route distinguisher of a different route, a virtual private network associated with a different route; a route target associated with the a different route; or a Border Gateway Protocol (BGP) Next-hop address associated with a different route. | 07-11-2013 |
20130191340 | In Service Version Modification of a High-Availability System - In one embodiment, an operating system kernel and/or one or more processes of a high-availability system are modified while the system is operating and providing high-availability service. In accomplishing this, one embodiment uses a second virtual machine to operate a second operating system kernel including a second set of processes in the standby mode, which receive state information from corresponding process(es) in the active mode. Individually, the operating system kernel and processes within the second set of processes may be a same or different version of their counterpart in a first virtual machine and its processes which are being replaced. When the second set of processes have acquired sufficient state information to perform the standby role, the operation of the first virtual machine is typically ceased as the version modified second virtual machine is performing the version modified functionality of the first virtual machine. | 07-25-2013 |
20130223228 | Resilient Forwarding of Packets with a Per-Customer Edge (per-CE) Label - In one embodiment, a packet switching device is configured to perform a lookup operation, based on a particular per-CE label (per-Customer Edge label) included in a particular packet, in a forwarding data structure for identifying forwarding information for the particular packet. When a corresponding outbound path is unavailable, a per-VRF (per-Virtual Routing and Forwarding) lookup operation in a VRF data structure, identified based on the particular per-CE label, based on a destination address of a packet encapsulated within the received packet. A corresponding packet is forwarded based on the results of the VRF lookup operation. In one embodiment, a set of more than one egress line card is identified based on this lookup operation, and packets of different routes are load balanced among egress line cards in this identified set of egress line cards. | 08-29-2013 |
20140192630 | GRACEFUL HANDLING OF CRITICAL TRAFFIC BLACKHOLING FAULTS - In one embodiment, a network device may detect a data plane critical fault condition, while a corresponding control plane is not experiencing a critical fault condition. In response to a network device based critical fault condition, the network device may activate and advertise an increased and expensive usable metric for each network interface of the network device. On the other hand, in response to an interface based critical fault condition, the network device may activate and advertise an increased and expensive usable metric for one or more particular network interfaces of the interface based critical fault, and signals, over the control plane to a corresponding network device at an opposing end of each particular network interface of the interface based critical fault, a request to activate and advertise an increased and expensive usable metric at the opposing end of each particular network interface. | 07-10-2014 |
20140376402 | METHODS AND SYSTEMS FOR AUTOMATIC GENERATION OF ROUTING CONFIGURATION FILES - Described herein are methods and systems for automatically generating routing configuration files based on a network topology and a collection of routing configuration templates. Such automatically generated routing configuration files may be suitable for a network running one or more of the RIP, EIGRP, OSPF, IS-IS and BGP routing protocols. The network topology may be specified in a graph description language, such as DOT, and/or a graph modeling language, such as GraphML. The routing configuration templates include certain routing protocol commands or sequence of commands that are frequently repeated in the configuration of a network device. Based on the network topology, the routing configuration templates are instantiated in a certain fashion, and any placeholders therein are replaced with information specific to the network topology. | 12-25-2014 |