2.12. Marco legal
2.12.2. Código de la Niñez y Adolescencia, la responsabilidad de los
◆ IP Availability Manager completes a discovery cycle: an initial discovery, a full
discovery, a pending discovery, or a single-device discovery.
By subscribing to DiscoveredLastAt attribute updates on IP Availability Manager, the MPLS Topology Server becomes aware of discovery cycle completions in IP Availability Manager.
◆ The MPLS Topology Server is restarted or communication is lost and then
reestablished between the MPLS Topology Server and IP Availability Manager.
◆ The MPLS Topology Server receives a manual discovery (Discover All) request, as
How discovery is conducted
The MPLS Topology Server imports its initial topology from IP Availability Manager in accordance to the BASEDIR/smarts/conf/mpls-t/dxa-am.conf file. Thereafter, it synchronize its topology with IP Availability Manager in accordance to the dxa-am.conf file. The dxa-am.conf file is described in the EMC Ionix MPLS Manager Configuration Guide.
Initial discovery
During its initial discovery, the MPLS Topology Server imports from IP Availability Manager an MPLS topology collection set named MPLS-System. MPLS-System contains
MPLS-enabled router and switch devices as well as CE and other non-MPLS-enabled devices that connect directly to the MPLS-enabled devices. The MPLS-enabled devices are not differentiated from the non-MPLS-enabled devices.
The MPLS Topology Server conducts a full-scope discovery on all devices in MPLS-System and learns the identity of each device during the discovery:
◆ PE ◆ P
◆ Multi-VRF CE ◆ CE
A full-scope discovery uses SNMP and/or CLI to discover all supported features, such as TE tunnels, LSPs, VRFs, Layer 2 VPNs, and Layer 3 VPNs, to name a few.
Subsequent discovery
During a subsequent discovery, the MPLS Topology Server conducts a full-scope discovery on PE and P devices, but does not conduct a full-scope discovery on Multi-VRF CE or CE devices. Instead, the MPLS Topology Server conducts an SNMP discovery of just VRFs on Multi-VRF CE and CE devices.
If the MPLS-BGP cross-domain correlation feature is enabled, the MPLS Topology Server also conducts an SNMP discovery of exterior BGP (eBGP) sessions on Multi-VRF CE and CE devices.
Of course, as in previous releases, the MPLS Topology Server performs a subsequent discovery in accordance to the following algorithm:
◆ Performs a topology synchronization with IP Availability Manager and compares the
current IP Availability Manager topology with the previously imported topology.
◆ Conducts discovery only on new devices, or on known devices that have a newer
discovery timestamp.
How discovery is conducted 41
Use cases for discovery
Here are a few use cases that describe the discovery behavior for the MPLS Topology Server. The MPLS Topology Server becomes aware of topology changes in IP Availability Manager by subscribing to DiscoveredLastAt attribute updates on IP Availability Manager.
◆ A new MPLS-enabled or CE device is added to IP Availability Manager
The MPLS Topology Server performs a topology synchronization with IP Availability Manager and detects the new device. The MPLS Topology Server conducts a discovery on just the newly added device.
◆ An existing MPLS-enabled or CE device is deleted from IP Availability Manager
The MPLS Topology Server performs a topology synchronization with IP Availability Manager and removes the device and its associated objects from the MPLS topology.
◆ An existing MPLS-enabled or CE device is updated in IP Availability Manager
The MPLS Topology Server performs a topology synchronization with IP Availability Manager and conducts a discovery on just the newly updated device.
MPLS VPN Overlapping IP Discovery 43
MPLS VPN Overlapping IP Discovery
This chapter introduces the MPLS VPN-Tagging Server and describes how the server solves the overlapping IP discovery problem. It consists of the following sections:
◆ Introducing the MPLS VPN-Tagging Server ... 44 ◆ Functional overview ... 46 ◆ Discovery in the Cisco environment ... 47 ◆ Discovery in the Alcatel-Lucent environment ... 49 ◆ Discovery assumptions and criteria... 52 ◆ Overlapping IP naming format ... 52 ◆ Configuring the MPLS VPN-Tagging Server ... 53 ◆ Starting the MPLS VPN-Tagging Server... 53
Introducing the MPLS VPN-Tagging Server
Due to the limited number of available IPv4 addresses, private IP addresses are frequently used in MPLS L3VPN networks. In Figure 18 on page 44, for example:
◆ Router PE1 uses IP address 10.1.0.2 on its interface that is facing router CE1, which is
part of customer 2’s VPN.
◆ Router PE2 uses IP address 10.1.0.2 on its interface that is facing router CE5, which is
in Customer 1’s VPN.
Moreover, router PE2 has two interfaces with the same IP address, 10.5.0.2. One interface is facing router CE3, and the other is facing router CE4.
Figure 18 Example of overlapping IPs in MPLS-enabled VPNs
When a network device has two or more interfaces that share the same private IP address, known as overlapping IP addresses, IP Availability Manager cannot automatically create the related IP objects for those interfaces, and cannot correctly identify the related network connections for those interfaces.
PE1 CE1 Customer 1 West Site Customer 2 West Site Customer 2 East Site MPLS network Customer 1 East Site CE3 CE4 CE2 P1 CE5 PE2 .1 Overlapping IP address Overlapping IP address 10.5.0.0/30
PE = Provider Edge router P = Provider router .2
Introducing the MPLS VPN-Tagging Server 45
MPLS VPN-Tagging Server purpose
The MPLS VPN-Tagging Server, an optional server in the MPLS Management Suite of products, differs from other Domain Managers in the sense that it creates no system or network instances. Its sole purpose is to solve the overlapping IP address problem for IP Availability Manager by performing MPLS VPN overlapping IP discovery.
MPLS VPN-Tagging Server assistance
By interoperating with the MPLS VPN-Tagging Server, IP Availability Manager is able to correctly represent in its repository the overlapping IP configurations that are shown in
Figure 19 on page 45, Figure 20 on page 45, and Figure 21 on page 46.
Figure 19 IP overlapping configuration 1: separate PE-CE pairs
Figure 20 IP overlapping configuration 2: common PE, separate CEs
10.1.0.1 PE 10.1.0.2 CE PE 10.1.0.2 CE 10.1.0.1 PE CE CE
Figure 21 IP overlapping configuration 3: common PE and CE, separate VRFs
Note that the CE device in configuration 3 is a multi-VRF CE. A multi-VRF CE maintains VPN routing and forwarding (VRF) tables for the purpose of extending the privacy and security of an MPLS L3VPN from the PE to the branch office. The multi-VRF CE maintains a VRF table for each interface or subinterface, to provide each client organization with its own IP address space.
Functional overview
The MPLS VPN-Tagging Server discovers VRF-based network connections and sends the connection information to IP Availability Manager. IP Availability Manager uses the connection information to distinguish the overlapping IPs in certain VRF overlapping IP configurations.
The MPLS VPN-Tagging Server writes the discovered VRF-related information to a single instance of “IP_External” on IP Availability Manager. IP_External is a class that stores the VRF-related information as four tables, one of which is the Network Connection table. Using the IP tag and network connection information from the Network Connection table, IP Availability Manager is able to build the correct network connections for all three overlapping IP configurations in Figure 19 on page 45, Figure 20 on page 45, and
Figure 21 on page 46. For configuration 3, IP Availability Manager is limited to building only system-level network connections.
The MPLS VPN-Tagging Server performs overlapping-IP and corresponding network-connection discovery in two vendor-specific environments:
◆ Cisco
◆ Alcatel-Lucent
The MPLS VPN-Tagging Server can perform discovery in both environments at the same time. Blue VPN Red VPN 10.9.0.1 10.9.0.2 PE Black VPN CE
Discovery in the Cisco environment 47
Discovery in the Cisco environment
Figure 22 on page 47 shows the design architecture of MPLS VPN overlapping IP discovery in the Cisco environment.
Figure 22 MPLS VPN-Tagging Server discovery in the Cisco environment
The MPLS VPN-Tagging Server performs SNMP discovery on Cisco routers or switches to discover VRF-based network connections for the devices. When the MPLS VPN-Tagging Server discovers these connections, it sends the connection information to IP Availability Manager so that IP Availability Manager is able to distinguish overlapping IPs on the same device.
The flowchart in Figure 23 on page 48 shows how MPLS VPN overlapping IP discovery works in the Cisco environment.
Attribute: IsDiscoveryInProgress MPLS network SNMP polling SNMP & CLI discovery SNMP discovery (Get VRF topology) Topology & CLI device access objects Status updates MPLS VPN-Tagging Server MPLS Monitoring Server MPLS Topology Server MPLS Analysis Server IP tag & connection information MPLS Manager (same host machine)
Cisco SNMPAgents
SNMP discovery, polling, & traps
IP Availability Manager
Figure 23 MPLS VPN overlapping IP discovery flow in the Cisco environment
Overlapping IP discovery of a Cisco device is triggered by IP Availability Manager when it sets a device’s IsDiscoveryInProgress attribute to True during the course of discovering the device. The MPLS VPN-Tagging Server subscribes to IsDiscoveryInProgress attributes. When the MPLS VPN-Tagging Server receives an IsDiscoveryInProgress attribute = True for either a Cisco router or switch, it retrieves the address of the device’s SNMP agent from IP Availability Manager and places the address in its discovery queue. It then initiates SNMP discovery on the SNMP agent, obtains the IP route-distinguisher tag and other related network connection information by querying the agent’s VRF-related MIB, and writes that information to IP Availability Manager’s Network Connection table.
Monitor IsDiscoveryInProgress
attributes of devices
IP RD tag and connection information
SNMPAgent Network Connection table IP Availability Manager VPN-Tagging Server Discovery postprocess: Read table, build connections,
and tag IPs
No
Yes
Read VRF-related MIB and discover IP RD tags and network connections Do nothing VPN-Tagging Server discovery queue Vendor = Cisco ? Is IsDiscovery- InProgress = True for
Router or Switch ?
Device 1 Device 2
Discovery in the Alcatel-Lucent environment 49
Discovery in the Alcatel-Lucent environment
Figure 24 on page 49 shows the design architecture of MPLS VPN overlapping IP discovery in the Alcatel-Lucent environment.
Figure 24 MPLS VPN-Tagging Server discovery in the Alcatel-Lucent environment
The MPLS VPN-Tagging Server sends CLI discovery requests to the EMC Ionix Adapter for Alcatel-Lucent 5620 SAM EMS (the Adapter) in an attempt to discover VRF-based network connections for Lucent-Alcatel routers or switches. When the MPLS VPN-Tagging Server discovers these connections, it sends the connection information to IP Availability Manager so that IP Availability Manager is able to distinguish overlapping IPs on the same device. MPLS network SNMP polling SNMP & CLI discovery SNMP discovery,
polling, & traps Topology & alarms Status updates Topology Topology & CLI device access objects Status updates IP Availability Manager MPLS VPN-Tagging Server Attribute: RouteChangedLastAt Adapter for 5620 SAM EMS Topology & status updates
MPLS Monitoring Server MPLS Topology Server MPLS Analysis Server Alcatel-Lucent device topology IP tag & connection information MPLS Manager (same host machine)
CLI discovery request (Get VRF topology)
Topology & alarms
5620 SAM EMS
CLI_
pass- through
Overlapping IP discovery of Alcatel-Lucent devices is triggered in any of the following ways:
◆ When the MPLS VPN-Tagging Server starts up.
At startup, the MPLS VPN-Tagging Server imports a list of Alcatel-Lucent devices from its source IP Availability Manager and performs a full discovery. The devices are identified in the Global_TopologyCollection objects that the Adapter creates in IP Availability Manager.
◆ When the MPLS VPN-Tagging Server receives, from IP Availability Manager, a
DiscoveredLastAt attribute update for a Global_TopologyCollection object. The Adapter changes the date of a global object’s DiscoveredLastAt attribute whenever the Adapter:
• Connects to IP Availability Manager and creates the global object. • Adds new devices to the global object.
The MPLS VPN-Tagging Server subscribes to DiscoveredLastAt attribute updates.
◆ When the MPLS VPN-Tagging Server receives, from the Adapter, a RouteChangedLastAt
attribute update for an Alcatel-Lucent device.
The Adapter sets a device’s RouteChangedLastAt attribute to a new date whenever the Adapter learns of a new or changed route for the device. The MPLS VPN-Tagging Server subscribes to RouteChangedLastAt attribute updates.
When the MPLS VPN-Tagging Server receives a RouteChangedLastAt attribute update for a device, it places the device in its discovery queue. During the next scheduled
full-discovery interval, as defined in the
BASEDIR/smarts/conf/vpn-tagging/vpn-tagging.conf file, the MPLS VPN-Tagging Server discovers the device.
When initiating a discovery of an Alcatel-Lucent device, the MPLS VPN-Tagging Server sends to the Adapter a CLI request that includes the device’s name. The Adapter executes the request and returns the output to the MPLS VPN-Tagging Server.
A CLI request contains the following CLI command:
show router <VRF name> route-table
The execution of the CLI command yields the IP route-distinguisher tag and other related network connection information for the target device. The MPLS VPN-Tagging Server writes that information to IP Availability Manager’s Network Connection table.
Discovery in the Alcatel-Lucent environment 51
On-demand discovery
In addition to periodic discovery, on-demand discovery of Alcatel-Lucent devices is supported. To enable the discovery of Alcatel-Lucent devices, you must add the following parameter and value to the vpn-tagging.conf file:
Enable5620SAMDiscovery = TRUE
“Configuring the MPLS VPN-Tagging Server” on page 53 refers to the vpn-tagging.conf file and provides information about configuring the MPLS VPN-Tagging Server.
An on-demand discovery can be initiated in any of the following ways:
◆ To initiate a discovery of all the devices in the MPLS VPN-Tagging Server’s discovery
queue, go to the BASEDIR/smarts/bin directory in the MPLS Management Suite installation area and enter either of the following commands:
dmctl -s <MPLS VPN-Tagging Server name> invoke
VPNTagging_Manager::VPNTagging-Manager::invoke5620SAMDiscovery dmctl -s <MPLS VPN-Tagging Server name> put
VPNTagging_Manager::VPNTagging-Manager::Force5620SAMDiscovery TRUE
◆ To initiate a discovery of all the devices in the Global_TopologyCollection objects, go
to the BASEDIR/smarts/bin directory in the MPLS Management Suite installation area and enter the following command:
dmctl -s <MPLS VPN-Tagging Server name> put
VPNTagging_Manager::VPNTagging-Manager::invokeDomainDiscovery <domain name>
Where <domain name> may be an IP Availability Manager’s name or an Adapter’s name.
Adapter Configuration
The EMC Ionix Adapter for Alcatel-Lucent 5620 SAM EMS User Guide describes the Adapter in detail and presents configuration procedures for the Adapter.
Configuring the connection from the Adapter to a Domain Manager, such as IP Availability Manager or the MPLS Topology Server, is achieved by setting a particular parameter in the Adapter’s emsConfig.import file. For example, setting the AMServerName parameter value to the name of an IP Availability Manager will cause the Adapter to forward to that IP Availability Manager the topology data that is expected by an IP Availability Manager. As an aside, the Adapter will set the ServiceName attribute of each object that it forwards to a Domain Manager to the name of the Adapter, to identify the Adapter as the object’s source. By doing so, any other Domain Manager that imports or is assigned these objects will be able to use the ServiceName value to subscribe to the Adapter for status updates. By this means, for example, the MPLS VPN-Tagging Server is able to subscribe to the Adapter for RouteChangedLastAt attribute updates.
Discovery assumptions and criteria
MPLS VPN overlapping IP discovery is based on the following assumptions and criteria:
◆ The loopback IP address of each CE device is unique and known.
◆ The loopback IP address of each CE device must be used to advertise the route in the
VRF; that is, the CE device can be identified by its loopback IP address.
◆ The Loopback IP address is not tagged by any IP tag filter that a user has created by
using the IP tagging feature in IP Availability Manager.
◆ Each VRF has a route distinguisher.
IP objects of interfaces that are associated with a single VRF have the same 8-byte route distinguisher value. The purpose of the route distinguisher is to allow the creation of distinct routes to separate instances of the same (overlapping) IPv4 address.
◆ VRF name is unique on each single device.
◆ IP address is unique on each CE device. This assumption is not applicable to the
overlapping IP configuration that is shown in Figure 21 on page 46. For this reason, the overlapping IP discovery feature cannot be used to build interface-level network connections between the PE and CE for the configuration in Figure 21.
Overlapping IP naming format
EMC Ionix applications require unique instance name in their repositories. The
conventional IP instance naming method, which is adding a prefix "IP-" to the IP address to create the name of the instance (for example, "IP-10.0.1.14"), is not applicable for overlapping IP addresses.
The Name of an overlapping IP instance will be in the following format:
IP-<IP address>/<route distinguisher>
The DisplayName attribute will be in the following format:
<route distinguisher>:<IP address> [host system name]
For example, router R1 has a VRF named “red.” Interface 15, which is associated with this VRF, has a duplicated IP address 10.0.1.14 and is part of the subnet 10.0.1.12/30. The route distinguisher of VRF “red” is “4445:401.” The name of this IP instance will be:
IP-10.0.1.14/4445:401
And its DisplayName will be:
4445:401:10.0.1.14 [R1]
Configuring the MPLS VPN-Tagging Server 53
Configuring the MPLS VPN-Tagging Server
By default, the MPLS VPN-Tagging Server is configured to connect to an IP Availability Manager named INCHARGE-AM. You can edit the MPLS VPN-Tagging Server’s configuration file named vpn-tagging.conf and change this name or add one or more additional IP Availability Managers as connections to the MPLS VPN-Tagging Server.
The EMC Ionix MPLS Manager Configuration Guide describes the parameters in the vpn-tagging.conf file and provides instructions for modifying the parameters. The “Configuring IP Availability Manager” chapter of the configuration guide also describes these parameters and provides instructions for:
◆ Enabling IP Availability Manager to discover overlapping IP addresses.
◆ Enabling IP Availability Manager to interoperate with the MPLS VPN-Tagging Server.
Starting the MPLS VPN-Tagging Server
As a prerequisite, the MPLS VPN-Tagging Server must be started before IP Availability