Patent application number | Description | Published |
20100150020 | BACKUP ROUTE GENERATION IN BORDER GATEWAY PROTOCOL - A method is provided for generating a backup route. Here, a route and a route distinguisher type associated with the route are received and a backup route is generated based on attributes of the route. A particular backup route distinguisher type that is associated with the route distinguisher type is assigned to the backup route. The backup route with the backup route distinguisher type are then advertised. Another method is provided that identifies the backup route. When the route and its route distinguisher type are received from the advertisement, an identification is made as to whether the route distinguisher type is assigned to a backup route. The route may then be designated as a backup route based on the identification. | 06-17-2010 |
20100329270 | DYNAMIC DISCOVERY MECHANISMS VIA INTER-DOMAIN ROUTING PROTOCOL - In an embodiment, a method is provided at which it is used in a device. In this method, a logical identifier assigned to the device is identified and additionally, a mesh group identifier identifying a mesh group is identified. The logical identifier and the mesh group identifier are encoded in a routing message, which is used in an inter-domain routing protocol, and this routing message is transmitted to a reflector device in communication with the device. The reflector device is configured to transmit the routing message to a remote device included in the computer network. | 12-30-2010 |
20110149980 | EFFICIENT GENERATION OF VPN-BASED BGP UPDATES - In one embodiment, a router may store a “neighbor table” for storing the router's Border Gateway Protocol (BGP) neighbors. Each neighbor corresponds to a virtual routing and forwarding (VRF) instance and associated VRF identifier (ID), and the neighbor table indexes the BGP neighbors according to their respective VRF ID. In response to initiating a BGP update generation for a BGP table having BGP network entries, each entry having an associated VRF ID that indicates to which VRF instance the BGP entry is to be advertised, a single lookup operation for each BGP entry is performed into the neighbor table based on the corresponding VRF ID of each BGP entry to determine a corresponding VRF update group of indexed BGP neighbors to which each BGP entry is to be advertised. Accordingly, a shared BGP update may be generated for each VRF update group for the initiated BGP update generation. | 06-23-2011 |
20120134368 | DYNAMIC DISCOVERY MECHANISMS VIA INTER-DOMAIN ROUTING PROTOCOL - In an embodiment, a method is provided at which it is used in a device. In this method, a logical identifier assigned to the device is identified and additionally, a mesh group identifier identifying a mesh group is identified. The logical identifier and the mesh group identifier are encoded in a routing message, which is used in an inter-domain routing protocol, and this routing message is transmitted to a reflector device in communication with the device. The reflector device is configured to transmit the routing message to a remote device included in the computer network. | 05-31-2012 |
20120263049 | BGP SLOW PEER DETECTION - In one embodiment, a router selects a particular peer from an original update group used with an Exterior Gateway Protocol (EGP) such as Border Gateway Protocol (BGP). The original update group includes a plurality of peers of the router that share a same outbound policy and that receive common update messages, from the router, of routing table information. The router determines that the particular peer is a potential slow peer based on a first type of indicia, wherein a slow peer is a peer that cannot keep up with a rate at which the router generates update messages over a prolonged period of time. The router confirms that one or more second types of indicia are consistent with the particular peer being a slow peer. In response to the confirmation, the router determines that the particular peer is a slow peer. | 10-18-2012 |
20140082216 | PERFORMING OFFLINE BGP PREFIX ORIGIN AND PATH VALIDATION AT ROUTE REFLECTORS - In one embodiment, an edge router receives an update message from a neighboring EBGP edge router, creates a modified origin validation state extended community, prepares a modified update message by attaching the modified origin validation state extended community to the update message, and sends the modified update message to a route reflector. The route reflector receives the modified update message, performs a prefix origin validation and a path validation based on the information contained in the modified update message, prepares a validation message based on the prefix origin validation and path validation, and sends the validation message to the edge router and to all other neighboring IBGP edge routers. The edge routers receive the validation message from the route reflector, parse the validation message, and inherit a validation state parsed from the validation message. | 03-20-2014 |
20140211651 | BGP SLOW PEER DETECTION - In one embodiment, a router selects a particular peer from an original update group used with an Exterior Gateway Protocol (EGP) such as Border Gateway Protocol (BGP). The original update group includes a plurality of peers of the router that share a same outbound policy and that receive common update messages, from the router, of routing table information. The router determines that the particular peer is a potential slow peer based on a first type of indicia, wherein a slow peer is a peer that cannot keep up with a rate at which the router generates update messages over a prolonged period of time. The router confirms that one or more second types of indicia are consistent with the particular peer being a slow peer. In response to the confirmation, the router determines that the particular peer is a slow peer. | 07-31-2014 |
20150207728 | VERIFYING DATA PLANE PATHS BASED ON A VALIDATED SECURE CONTROL PLANE - In one embodiment, a plurality of packets is sent from an origin device along a communication path toward a destination device. Each packet includes a lifespan indicator which is incrementally increased for each subsequently sent packet. A plurality of response messages are received at the origin device from a plurality of intermediate devices, respectively. A plurality of secure path objects included in the plurality of response messages, respectively, is determined. Additionally, the plurality of secure path objects are validated based on validation information accessible by the origin device. Validation results of the plurality of secure path objects are checked to determine whether a packet that is sent from the origin device and received by the destination device travels along a particular communication path as dictated by control plane information. | 07-23-2015 |
20150207729 | TYING DATA PLANE PATHS TO A SECURE CONTROL PLANE - In one embodiment, a router located at an exit edge of an autonomous system (AS) receives a data packet in a data plane, and determines a destination of the data packet and an associated AS-path information to the destination. The router may then insert the AS-path information into the data packet, and forwards the data packet with the AS-path information toward the destination, such that a receiving device in a destination AS can validate whether the data packet was routed through a path that was secure from a control plane perspective based on a collection of one or more insertions of AS-path information. | 07-23-2015 |
20150207818 | OVERCOMING CIRCULAR DEPENDENCIES WHEN BOOTSTRAPPING AN RPKI SITE - In one embodiment, a validation server in a computer network determines that an edge router of the computer network has blocked access to a desired server address based on the edge router not having authentication information for the desired server address. In response, the server creates a white-listing policy to temporarily allow access to the desired server address at the edge router, and sends the white-listing policy to the edge router. The validation server may then proceed with performing server fetching operations to the desired server address from the validation server while the white-listing policy is in effect, and instructs the edge device to remove the white-listing policy once the server fetching operations are completed. | 07-23-2015 |