Systems and methods provide for provisioning a dynamic intent-based firewall. A network controller can generate a master route table for network segments reachable from edge network devices managed by the controller. The controller can receive zone definition information mapping the network segments into zones and Zone-based Firewall (ZFW) policies to apply to traffic between a source and destination zone specified by each ZFW policy. The controller can evaluate a ZFW policy to determine first edge network devices that can reach first network segments mapped to the source zone specified by the ZFW policy, second edge network devices that can reach second network segments mapped to the destination zone specified by the ZFW policy, and routing information (from the route table) between the first network segments, the first and second edge network devices, and the second network segments. The controller can transmit the routing information to the edge network devices.

A node operable in a mesh communication network and a method performed thereby for routing a received packet towards a destination are provided. The method includes receiving a packet addressed to a destination node in the mesh network, the packet including information related to address of source node, last hop address, address of destination node, and a hop counter. The method further includes determining whether the destination address is included in a routing table of the node in the mesh communication network. When the destination address is included in a routing table, the received packet is forwarded according to the routing table; or when the destination address is not included in a routing table, the received packet is flooded by broadcasting it in the mesh communication network.

In a method, a controller sends a first route update packet including a first route to a first forwarding device, so that the first forwarding device sends a third route update packet including a third route to at least one target forwarding device; a second forwarding device receives the third route update packet, determines a target link from the first forwarding device to the second forwarding device, and sends, based on a monitored state of the target link, a second route update packet including a second route and a target field to the controller; and the controller determines the state of the target link based on the target field in the second route update packet.

A data center failure management system and method in a Software Defined Networking (SDN) deployment. In one embodiment, an SDN controller associated with the data center is configured to learn new flows entering the data center and determine which flows require flow stickiness. Responsive to the determination, the SDN controller generates commands to one or more switching nodes and/or one or more border gateway nodes to redirect the sticky flows arriving at the switching nodes via ECMP routes from the gateway nodes or avoid the ECMP routes by the gateway nodes in order to overcome certain failure conditions encountered in the data center, an external network, or both.

A first route reflector client manager determines identifies that a distributed lock has been released, wherein the first route reflector client manager corresponds to a first route reflector client. In response to the determining that the distributed lock has been released, the first route reflector client manager retrieves the distributed lock. In response to retrieving the distributed lock the first route reflector client manager provisions the first route reflector client into a first route reflector. The first route reflector client manager advertises information corresponding to the provisioning of the first route reflector client into the first route reflector, wherein the advertising causes at least a second route reflector client to identify the first route reflector client as the first route reflector.

Techniques are presented for distributing host route information of virtual machines to routing bridges (RBridges). A first RBridge receives a routing message that is associated with a virtual machine and is sent by a second RBridge. The routing message comprises of mobility attribute information associated with a mobility characteristic of the virtual machine obtained from an egress RBridge that distributes the routing message. The first RBridge adds a forwarding table attribute to the routing message that indicates whether or not the first RBridge has host route information associated with the virtual machine in a forwarding table of the first RBridge. The first RBridge also distributes the routing message including the mobility attribute information and the forwarding table attribute, to one or more RBridges in the network.

The present disclosure generally relates to the support of optical connection setup. More specifically, the present disclosure relates to a technique of supporting provision of a connection via a data communication network of an optical network between packet network islands. A method embodiment comprises establishing a Border Gateway Protocol-Link State, BGP-LS, connection via the DCN between a first edge node of the first packet network island and a BGP-LS node in the optical network.

A system and method for software defined network (SDN) management. Route information is received from a customer edge (CE) device. The route information is parsed to identify at least one virtual routing and forwarding (VRF) instance for which the route information is intended. The route information is imported into the VRF instance.

A method and system for a VPN setup in which one of the peers' outgoing traffic is dynamically rerouted to exit VPN servers based on infrastructure or user requirements without losing the initial connection state or leaking unencrypted network traffic is described. One exemplary embodiment describes a method for a client to change their routing to multiple server locations. Another exemplary embodiment describes a method for the entry VPN servers to reroute traffic based on strategic traffic analysis.

A tunnel between interior border gateway protocol neighbor includes: receiving an announcement from an Interior Border Gateway Protocol (IBGP) neighbor, wherein the announcement from the IBGP neighbor includes an address used by the IBGP neighbor in creating the neighborhood with the border device; setting up a tunnel with an address used by the border device in creating the neighborhood with the IBGP neighbor being a local address, and the address used by the IBGP neighbor in creating the neighborhood with the border device being a remote address; and determining the IBGP neighbor as the next hop of a BGP route issued by the IBGP neighbor and a local interface of the tunnel as the outgoing interface of the BGP route.