Abstract: A plurality of switches may be arranged according to a spine and leaf topology in which each spine switch is connected to all leaf switches. A leaf switch includes a memory configured to store a plurality of policies, each of the plurality of policies being associated with a respective source identifier value and a respective destination address; a network interface communicatively coupled to one of the spine switches; and a processor implemented in circuitry and configured to: receive a packet from the spine switch via the network interface, the packet being encapsulated with a Virtual Extensible Local Area Network (VXLAN) header; extract a source identifier value from the VXLAN header; determine a destination address for the packet; determine a policy of the plurality of policies to apply to the packet according to the source identifier value and the destination address; and apply the policy to the packet.

Abstract: A plurality of switches may be arranged according to a spine and leaf topology in which each spine switch is connected to all leaf switches. A leaf switch includes a memory configured to store a plurality of policies, each of the plurality of policies being associated with a respective source identifier value and a respective destination address; a network interface communicatively coupled to one of the spine switches; and a processor implemented in circuitry and configured to: receive a packet from the spine switch via the network interface, the packet being encapsulated with a Virtual Extensible Local Area Network (VXLAN) header; extract a source identifier value from the VXLAN header; determine a destination address for the packet; determine a policy of the plurality of policies to apply to the packet according to the source identifier value and the destination address; and apply the policy to the packet.

Abstract: A plurality of switches may be arranged according to a spine and leaf topology in which each spine switch is connected to all leaf switches. A leaf switch includes a memory configured to store a plurality of policies, each of the plurality of policies being associated with a respective source identifier value and a respective destination address; a network interface communicatively coupled to one of the spine switches; and a processor implemented in circuitry and configured to: receive a packet from the spine switch via the network interface, the packet being encapsulated with a Virtual Extensible Local Area Network (VXLAN) header; extract a source identifier value from the VXLAN header; determine a destination address for the packet; determine a policy of the plurality of policies to apply to the packet according to the source identifier value and the destination address; and apply the policy to the packet.

Abstract: A Software-defined Networking (SDN) controller of data center with application-aware firewall policy enforcement is disclosed. In one example, the SDN controller receives a request to initialize an instance of an application. in response to receiving the request, the SDN controller transmits, to a firewall component positioned between an SDN gateway device of the data center and a network external to the data center, a message. In some examples, the messing includes an application signature corresponding to the instance of the application and an application firewall policy corresponding to the application signature. The message instructs the firewall component to install the application firewall policy for application to network traffic for the instance of the application.

Abstract: A Software-defined Networking (SDN) controller of data center with application-aware firewall policy enforcement is disclosed. In one example, the SDN controller receives a request to initialize an instance of an application. in response to receiving the request, the SDN controller transmits, to a firewall component positioned between an SDN gateway device of the data center and a network external to the data center, a message. In some examples, the messing includes an application signature corresponding to the instance of the application and an application firewall policy corresponding to the application signature. The message instructs the firewall component to install the application firewall policy for application to network traffic for the instance of the application.

Abstract: Techniques are described for routing inter-AS LSPs with a centralized controller taking inter-AS TE metric values for inter-AS links into account. The inter-AS TE metric values, e.g., local preference values, MED values, or EROS, indicate route preferences for routes between ASes. The disclosed techniques enable network devices within either or both of a first AS and a second AS to store inter-AS TE metric values for inter-AS links in TEDs of the network devices. The network devices then send the contents of their TEDs, including the inter-AS TE metric values, to a centralized controller of the first AS and the second AS. The centralized controller computes an inter-AS LSP across the first AS and the second AS based at least in part on the inter-AS TE metric values such that the inter-AS LSP includes a preferred one of the inter-AS links as indicated by the inter-AS TE metric values.

Abstract: Techniques are described for reporting, by non-ingress routers for traffic engineering label switched paths (TE LSPs) and to a path computation element, actual paths taken by the TE LSPs through the network. A first network device: receives, from a second network device, an LSP path signaling message that includes a route object having a first indication of at least a sub-path of a path for TE LSP through a network, wherein the first network device is not an ingress label edge router for the TE LSP; generates, in response to the LSP path signaling message and based at least in part on the route object, an LSP path report message that includes a second indication of the at least the sub-path of the path for the TE LSP; and sends, to a path computation element, the LSP path report message to notify the PCE.

Abstract: Techniques are described for routing inter-AS LSPs with a centralized controller taking inter-AS TE metric values for inter-AS links into account. The inter-AS TE metric values, e.g., local preference values, MED values, or EROS, indicate route preferences for routes between ASes. The disclosed techniques enable network devices within either or both of a first AS and a second AS to store inter-AS TE metric values for inter-AS links in TEDs of the network devices. The network devices then send the contents of their TEDs, including the inter-AS TE metric values, to a centralized controller of the first AS and the second AS. The centralized controller computes an inter-AS LSP across the first AS and the second AS based at least in part on the inter-AS TE metric values such that the inter-AS LSP includes a preferred one of the inter-AS links as indicated by the inter-AS TE metric values.

Abstract: Techniques are described for reporting, by non-ingress routers for traffic engineering label switched paths (TE LSPs) and to a path computation element, actual paths taken by the TE LSPs through the network. A first network device: receives, from a second network device, an LSP path signaling message that includes a route object having a first indication of at least a sub-path of a path for TE LSP through a network, wherein the first network device is not an ingress label edge router for the TE LSP; generates, in response to the LSP path signaling message and based at least in part on the route object, an LSP path report message that includes a second indication of the at least the sub-path of the path for the TE LSP; and sends, to a path computation element, the LSP path report message to notify the PCE.