Cloud VNEs and Unmanaged Segments
These topics describe how Cisco ANA manages virtual (VNE) clouds that are used to represent unmanaged network segments, the technologies that support Cloud VNEs, how to model multiple access networks with Cloud VNEs, and how Cisco ANA performs correlation decisions over unmanaged segments:
•Using Cloud VNEs over Unmanaged Segments
•Supported Networking Technologies for Cloud VNEs
•Modeling Multiple Access Networks with Cloud VNEs
Using Cloud VNEs over Unmanaged Segments
In some scenarios, Cisco ANA must manage more than one network segment that interconnects with others over a network segment which is not managed. In such a setup, faults on one device might be correlated to faults on another device which is located on the other side of the unmanaged segment of the network, or to unknown problems in the unmanaged segment itself.
Note Unmanaged segments must be pure switches; no routing can be involved with the segment.
Cisco ANA uses Cloud VNEs to represent unmanaged network segments. A Cloud VNE represents the unmanaged segment of a network as a single device to which two or more managed segments of the network can be connected. The Cloud VNE builds a model with port type and technology that is identical to its adjacent VNEs and virtual forwarding components. This model allows the VNEs to pass flows of simulated packets in order to calculate correlations and affected subscribers.
Each VNE can be configured to connect to a Cloud VNE. When loading, the VNE gathers whatever data is relevant to the Cloud VNE, and sends the data to it. Upon receiving this information, the Cloud VNE builds the corresponding model to allow the topology to connect the two VNEs.
Note Each physical port in a VNE can connect to only one Cloud VNE.
A Cloud VNE can also represent multiple unmanaged segments and multiple technologies, as long as each technology is in a different network segment. In addition, multiple Cloud VNEs can also be created, each one representing a portion of an unmanaged network. For more information, see Modeling Multiple Access Networks with Cloud VNEs.
Three types of technologies are supported when a Cloud VNE simulates an unmanaged segment of a network: Frame Relay, ATM, and Ethernet. For more information about the supported technologies for Cloud VNEs, see Supported Networking Technologies for Cloud VNEs.
Figure 4-1 shows network elements (routers) that are connected to an unmanaged network, and their corresponding VNEs. The unmanaged segment represented by the Cloud VNE can be an ATM, Frame Relay, or Ethernet type network (Layer 2 only).
Figure 4-1 Cloud VNE Example
Supported Networking Technologies for Cloud VNEs
Three types of networking technologies are supported for Cloud VNEs—Frame Relay, ATM, and Ethernet—as described in the following topics:
•Cloud VNEs with ATM and Frame Relay Technologies
•Cloud VNEs with Ethernet Technology
Cloud VNEs with ATM and Frame Relay Technologies
The Cloud VNE can simulate an ATM or Frame Relay switching network, in which the endpoints are routers with ATM or Frame Relay interfaces that terminate the switching network.
The functionality of the Cloud VNE is similar to that of a virtual switch that connects endpoints that are part of the managed network. The Cloud VNE has an ATM (or Frame Relay) port for each VNE port connected to it. The cloud also contains forwarding information in a cross-connect table (with ATM VC encapsulation, or Frame Relay VC encapsulation with DLCI), that represents how traffic passes the unmanaged switching network.
The logic that builds the cross-connects in the Cloud VNE is based on one of the following:
•IP layer information that includes the ATM/Frame Relay interfaces' IP addresses and the next hop addresses, extracted from the routing table.
•CDP, if the devices are CDP-enabled Cisco routers, and the devices in the unmanaged segment are not CDP enabled.
Note Duplicate IP addresses on ATM or Frame Relay interfaces are supported only if the physical ATM or Frame Relay edge ports can be grouped in such a way that there is no communication between them. Each group can include only interfaces with unique IP addresses, and no virtual connection may exist between these interfaces.
Cloud VNEs with Ethernet Technology
The Cloud VNE can simulate an Ethernet network with (optionally) multiple VLANs configured, in which the endpoints are either routers with Ethernet interfaces, or LAN switches.
The functionality of the Cloud VNE is similar to that of a virtual LAN switch that connects endpoints that are part of the managed network. The Cloud VNE contains an Ethernet port with all VLAN encapsulations for each VNE port connected to it. It also contains forwarding information in a per-VLAN bridging table that represents how traffic passes through the unmanaged network.
The logic that builds the bridging tables in the Cloud VNE is based on Ethernet layer information, as follows:
•For tagged ports:
–MAC addresses and VLAN IDs configured on the Ethernet interfaces connected to the cloud.
–Learned MAC addresses on the port that can be extracted from the Address Resolution Protocol (ARP) table (in the case of a router), or bridging table (in the case of a LAN switch).
•Access ports (untagged ports) connected to the correct VLAN, based on local and learned MAC addresses.
Modeling Multiple Access Networks with Cloud VNEs
In most scenarios, unmanaged network segments are access networks that are used by customers to access the service provider network. Legacy access networks are based on circuit switching such as ATM and Frame Relay, while new access networks are mainly Ethernet based.
In multiple separated access networks, it is common practice to create multiple Cloud VNEs, one per access network.
This type of configuration has the following advantages:
•In most Ethernet based access networks, multiple VLANs with the same ID cannot be used in the same access network, as this would create a risk of connecting multiple VLANs to one broadcast domain. The use of multiple Cloud VNEs avoids this risk by allowing multiple VLAN IDs with the same ID to exist in the network.
•Using multiple Cloud VNEs reduces the chance of duplicate IP addresses configured on the ATM or Frame Relay interfaces connecting to the same Cloud VNE.
•Using multiple Cloud VNEs enables network elements in a GUI map to be organized according to their geographical location.