Fully Dynamic VSD Integration Model
This chapter provides information about fully dynamic virtualized service directory (VSD) integration model.
Topics in this chapter include:
Applicability
Software requirements for this feature are SR OS Release 13.0.R4 or later and Nuage Virtualized Services Platform (VSP) release 3.2.R1 or later. This configuration was tested on SR OS Release 13.0.R4 and Nuage VSP release 3.2.R3.
Fully dynamic extensible messaging and presence protocol (XMPP) provisioning is not supported along with the dynamic business services feature in Release 13.0. Both features are mutually exclusive.
Provisioning of filter entries from Virtualized Services Directory (VSD) is not supported in SR OS 13.0.
Nuage VSP conceptual knowledge and Nuage VSD operational knowledge are prerequisites. See the Nuage VSP user documentation for more information.
Overview
The Nuage VSP is a Software-Defined Networking (SDN) solution that provides data center (DC) network virtualization and automatically establishes connectivity between compute resources upon their creation. Leveraging programmable business logic and a powerful policy engine, the Nuage VSP provides an open and highly responsive solution that scales to meet the stringent needs of massive multi-tenant DCs. The Nuage VSP can be deployed over an existing DC IP network fabric, and has three main components:
Virtualized Services Directory (VSD), Virtualized Services Controller (VSC), and Virtual Routing and Switching (VRS), as displayed in Nuage VSP overview
Virtualized Services Directory (VSD)
The Nuage VSD is a programmable policy and analytics engine. It provides a flexible and hierarchical network policy framework that enables IT administrators to define and enforce resource policies in a user-friendly manner.
The VSD contains a multi-tenant service directory, which supports role-based administration of users, computing, and network resources. The VSD also manages network resource assignments such as IP addresses and ACLs.
For the purpose of service assurance, the VSD allows the definition of sophisticated statistics rules, such as collection frequencies, rolling averages, and samples, as well as Threshold Crossing Alerts (TCA). When a TCA occurs, it will trigger an event that can be exported to external systems through a generic messaging bus. Statistics are aggregated over hours, days, and months, and stored in a Hadoop® analytics cluster to facilitate data mining and performance reporting.
The VSD runs as a number of processes in a virtual machine (VM) environment.
Virtualized Services Controller (VSC)
The Nuage VSC is an SDN controller. It functions as the robust network control plane for DCs, maintaining a full view of per-tenant network and service topologies. Through the VSC, virtual routing and switching constructs are established to program the network forwarding plane, the Nuage VRS, using the OpenFlow protocol.
The VSC communicates with the VSD policy engine using Extensible Messaging and Presence Protocol (XMPP). An ejabberd XMPP server/cluster is used to distribute messages between the VSD and VSC entities. Multiple VSC instances can be interconnected within and across DCs by leveraging Multi-Protocol Border Gateway Protocol (MP-BGP).
The VSC is based on the Service Router Operating System (SR OS) and runs in a virtual machine environment.
Virtual Routing and Switching (VRS)
The Nuage VRS component is an enhanced Open vSwitch (OVS) implementation that constitutes the network forwarding plane. It encapsulates and de-encapsulates user traffic, enforcing L2 to L4 traffic policies as defined by the VSD. The VRS tracks Virtual Machine (VM) creation, migration, and deletion events in order to dynamically adjust network connectivity.
DC Gateway automated service provisioning
The first phase of VSD-SR OS integration was introduced in SR OS 12.0.R4. This phase included the development of an XMPP interface on the SR OS and the integration in the Nuage XMPP architecture. This so-called Static + Dynamic (S-D) provisioning model allows the auto-provisioning of VPLS and VPRN route targets, as well as VPLS VNI (VXLAN Network Identifiers) on the SR OS through the XMPP interface and the VSD interaction. The prerequisite in this model is the pre-configuration of the VPLS and VPRN services on the SR OS through CLI or SNMP. This model is intended to be used in DC Gateways where the WAN and the DC are managed by different administrative entities. The DC administrator will use VSD to ‟attach” the already configured VPLS or VPRN service to the L2 or L3 domain in the DC.
The second phase of VSD-SR OS integration was introduced in SR OS 13.0.R4. This phase supports the Fully Dynamic (F-D) provisioning model. The goal of this model is to avoid the prerequisite of pre-configuring the services on the SR OS existing in the S-D provisioning model, since this model assumes that the service is completely owned by the DC administrator. The entire service will be auto-generated on the SR OS as a result of the interaction with the VSD. DC Gateway fully dynamic provisioning workflow shows the workflow of the F-D provisioning model.
As soon as the XMPP server is configured on the SR OS DC Gateway, it is auto-discovered by the VSD.
The Cloud Service Provider (CSP) root user creates WAN services and assigns these resources to Enterprise administrators; for example, to the Ent-1 admin.
The Ent-1 admin sees the WAN service in the infrastructure resources and assigns permissions to certain user groups in Ent-1, who can consume these WAN resources by connecting to an L2/L3 domain.
As soon as the WAN service is added to an L2/L3 domain, the VSD pushes a list of parameters to the SR OS DC Gateway, which uses a python script to construct the configuration of the WAN service. The list of parameters sent to the 7750 routers can include:
service-name (Service ID field in the WAN Service GUI) - used as VSD domain in the CLI
config-type (Config Type field in the WAN Service GUI) - DYNAMIC for F-D XMPP provisioning
service-type (based on combination of the Service Type field and IRB check box in the WAN Service GUI) - possible values: L2DOMAIN, L2DOMAIN-IRB, VRF-GRE, or VRF-VXLAN
name (name of the L2 domain in the VSD to which the WAN service is assigned, or BackHaulSubnet in the case of service-type VRF-VXLAN)
service-policy (service Policy in the WAN Service GUI field) - should match the python policy configured on the SR OS DC Gateway
vn-id (VNI used for the Nuage overlay service) - dynamically supplied for VXLAN WAN services
RT-I (internal Route Target used for the Nuage overlay service)
RT-E (ext. Route Target in the WAN Service GUI field)
metadata (list of opaque parameters supplied in the Metadata section of the WAN Service GUI)
The dynamic provisioning of parameters is provided for the following VSD domain types (configured in the SR OS DC Gateway):
l2-domain |
To attach a service at the gateway to an L2 (Ethernet) domain in the data center with no routing at the gateway, a VPLS service must be associated with a vsd-domain of type l2-domain. |
l2-domain-irb |
To attach a service at the gateway to an L2 (Ethernet) domain in the data center with routing at the gateway, an R-VPLS service should be associated with a vsd-domain of type l2-domain-irb. |
vrf-gre |
To attach a service at the gateway to an L3 domain (with GRE transport) in the data center, a VPRN service should be associated with a vsd-domain of type vrf-gre. |
vrf-vxlan |
To attach a service at the gateway to an L3 domain (with VXLAN transport) in the data center, an R-VPLS service (with ip-route-advertisement enabled and linked to an EVPN-tunnel) should be associated with a vsd-domain of type vrf-vxlan. |
This chapter will show examples of l2-domain, l2-domain-irb, and vrf-vxlan service type F-D provisioning, and focuses mostly on the SR OS DC Gateway configuration. For a more detailed F-D provisioning workflow on the VSD UI, refer to the VSP User Guide.
Python script
The XMPP parameters supplied by the VSD are parsed by a python script on the SR OS DC Gateway that dynamically provisions the VPLS and/or VPRN services provided for the Nuage overlay services.
The python script generates an executable CLI script based on the information received in the XMPP attributes. Three dynamic data service functions can be specified: setup, modify, or teardown. A fourth action, revert, is automatically invoked when the modify action fails:
setup function: output = CLI to create a new dynamic data service.
teardown function: output = CLI to delete an existing dynamic data service.
modify function: output = CLI to change the parameters of an existing dynamic data service
revert function: output = CLI to rollback the dynamic data service modify function actions in case of a modify failure
The python script uses the alc.dyn python module that contains a number of functions required to set up dynamic data services. To use the alc.dyn module, it must be imported into the python script:
from alc import dyn
The alc.dyn module contains a number of functions. Relevant alc.dyn functions for F-D XMPP provisioning are listed here:
dyn.action(dictionary)
dyn.add_cli(string)
dyn.select_free-id(service-id)
The next sections provide a basic description of these functions. The alc.dyn module contains other functions that are not relevant for this feature. For a full list of the alc.dyn functions together with an extensive explanation of each function, refer to the RADIUS-Triggered Dynamic Data Service Provisioning chapter.
The trigger in the python script to execute a specific function is by calling the internal function dyn.action(d), where "d" is a python dictionary:
d = { key : value, key : value, key : value, … , key : value }
For F-D XMPP provisioning, only 1 key:value pair is used and the key string must be set to "script".
The value is a tuple with the following comma separated values:
(setup-function, modify-function, revert-function, teardown-function)
Setup and teardown functions are mandatory. Modify and revert functions are optional. If a modify function is defined, the revert function must also be defined. If no modify/revert function is required, the keyword None should be used instead.
The following two combinations are supported for F-D Dynamic XMPP provisioning:
without modify function:
d = {"script" : (setup_script, None, None, teardown_script)} dyn.action(d)with modify function (allows for changes in the WAN service on the VSD while the service is assigned to a domain):
d = {"script" : (setup_script, modify_script, revert_script, teardown_script)} dyn.action(d)
When the configuration for a new service-name is received from the VSD, the vsd parameters and the opaque parameters string are concatenated into a single dictionary. The setup_script() is called and the dictionary is passed to the function. In this chapter, the dictionary will be named "vsdParams", but any other name would do. Within the python script:
The VSD UI parameters are referenced as vsdParams['rt'], vsdParams['vni'], vsdParams['servicetype'], and so on.
The metadata parameters are defined in an opaque string. For example, when the metadata string "rd=1:1,sap=1/1/1:1000" is supplied to the VSD WAN Service GUI, the format in the dictionary will be in the following format: "'metadata': 'rd=1:1,sap=1/1/1:1000 '".
To reference the metadata, the format is changed (trailing space is removed and parameters split up):
metadata = vsdParams['metadata']
metadata = metadata.rstrip()
metadata = dict(e.split('=') for e in metadata.split(','))
The individual metadata parameters can then be referenced in a similar way as the vsd parameters; for example, metadata['rd'], metadata['sap'], and so on.
When the startup script is executed, the config>service>vsd>domain is created outside the script context before running the actual script. The teardown script will remove the vsd domain. The domain-name is taken from the service-name supplied by the VSD ("Service ID" field in the WAN Service GUI - used as VSD domain in the CLI). When testing the script with the tools perform python-script command, the domain-name is taken from the domain-name command parameter (see Testing the python script section).
When subsequent configuration messages are received from the VSD, the new parameter list is again generated from the VSD message and compared to the last parameter list that was successfully executed.
If the two strings are identical, no action is taken.
If there is a difference between the strings, the modify_script() function is called. For example, the modify_script() function is set up to handle a change in the service-mtu.
If a configuration message is received from the VSD for an existing service-name with no VSD parameters, the teardown_script() is called.
If a setup_script() fails, the teardown_script() is called.
To generate CLI output in the python script, an internal function, dyn.add_cli(output-string), is available. It adds the specified output-string to the CLI script. Python enables the use of triple quotes to specify strings that span multiple lines. For example:
from alc import dyn
dyn.add_cli("""
configure
service
ies %(svc_id)s customer 1 create
service-name "%(inst)s"
description "%(inst)s"
no shutdown
exit
exit
exit
""" % d)
An internal function, dyn.select_free_id("service-id"), is available to select a free (unused) service identifier in the service-range specified in the dynamic-services context (see the Configuration section). If no service-range is configured, the python script fails when dyn.select_free_id("service-id") is called. The service-id is made available again after a successful teardown (removal) of the service.
XMPP
The Extensible Messaging and Presence Protocol (XMPP) is an open technology for real-time communication, using XML (Extensible Markup Language) as the base format for exchanging information. XMPP provides a way to send small pieces of XML from one entity to another in near real time. Although initially intended for Instant Messaging applications, it can be easily extended to be used in a DC environment.
In the Nuage solution, each XMPP client, including the SR OS, is referred to with a JID(JabberID) in the following format: username@xmppserver.domain. The xmppserver.domainpoints to the XMPP server.
The Nuage VSP/SR OS DC Gateway solution uses the XMPP PubSub (Publish Subscribe) extension. This extension allows a user to subscribe to a node so that it can be notified whenever there is new or updated information available. The mechanism is used in this feature to auto-discover the username of the VSD JID. Additionally, the SR OS will subscribe to a separate PubSub for each DC Gateway, to discover updates on specific domains. Subscriptions are confirmed periodically (every 15 min).
The SR OS DC Gateway will periodically audit the VSD and request a DIFF list of F-D VSD domains. The VSD keeps a DIFF list of domains, which contains the F-D domain names for which the VSD has not received an info/query (IQ) request from the SR OS for a long time. The DC Gateway periodically checks the info for each of its deployed dynamic services with an IQ request (every 16-24 min). A DIFF or FULL domain list audit can also be triggered with the tools perform service vsd fd-domain-sync <full> | <diff> command.
Configuration
This section describes the configuration that is required on the SR OS DC Gateway for F-D XMPP provisioning.
The following figure shows the basic setup used and also illustrates the XMPP architecture in the data center. Although the VSD and XMPP servers are represented by a single server, a cluster of VSD servers (using the same database) and/or XMPP servers will be a very common configuration in a data center.
It is assumed that underlying IP connectivity and an IGP has already been configured in this setup.
XMPP configuration
To receive configuration parameters from the VSD, the SR OS DC Gateway has to establish an XMPP client session with the XMPP server. Only one XMPP server can be configured.
When the XMPP server is properly configured, with no shutdown, the 7750 will try to establish a TCP session with the XMPP server through the management interface first. If it fails to establish communication, the 7750 will use in-band communication and will use its system IP as the source IP address.
To resolve the XMPP server fully qualified domain name (FQDN), provide a DNS server in the boot option file (bof) configuration and configure a dns-domain:
*A:pe-9>config>system# show bof
===============================================================================
BOF (Memory)
===============================================================================
---snip---
primary-dns 138.203.39.47
dns-domain nuage.net
---snip---
===============================================================================
Then, configure the system-id of the DC Gateway that will be communicated to the VSD:
*A:pe-9>config>system# info
----------------------------------------------
#--------------------------------------------------
echo "vsd Configuration"
#--------------------------------------------------
vsd
system-id "pe9"
exit
The next step is to configure the VSD server. The domain-name is the domain portion of the JID. The username is the username portion of the JID acting as an XMPP client. Ensure that the username uses all letters in lowercase (see SR OS 13.0 release notes). If no username is provided, an in-band registration will be provided, using the chassis MAC as username. The use of a password is optional:
*A:pe-9>config>system# info
#--------------------------------------------------
echo "Xmpp Configuration"
#--------------------------------------------------
xmpp
server vsd domain-name vsd1.nuage.net create username pe9
no shutdown
exit
exit
----------------------------------------------
When the XMPP server has been configured, the state should move to "Functional":
*A:pe-9# show system xmpp server
===============================================================================
XMPP Server Table
===============================================================================
Name User Name State
XMPP FQDN Last State chgd Admin State
-------------------------------------------------------------------------------
vsd pe9 Functional
vsd1.nuage.net 0d 00:37:01 inService
-------------------------------------------------------------------------------
No. of XMPP server's: 1
===============================================================================
XMPP Tx/Rx counters and other details can be obtained with the following command:
*A:pe-9# show system xmpp server "vsd"
===============================================================================
XMPP Server Table
===============================================================================
XMPP FQDN : vsd1.nuage.net
XMPP Admin User : pe9
XMPP Oper User : pe9
State Lst Chg Since: 0d 00:07:43 State : Functional
Admin State : Up Connection Mode : outOfBand
Auth Type : md5
IQ Tx. : 10 IQ Rx. : 10
IQ Error : 0 IQ Timed Out : 0
IQ Min. Rtt : 20 ms IQ Max. Rtt : 80 ms
IQ Ack Rcvd. : 10
Push Updates Rcvd : 1 VSD list Upd Rcvd : 1
Msg Tx. : 3 Msg Rx. : 3
Msg Ack. Rx. : 3 Msg Error : 0
Msg Min. Rtt : 0 ms Msg Max. Rtt : 80 ms
Sub Tx. : 1 UnSub Tx. : 0
Msg Timed Out : 0
F-D XMPP provisioning uses the PubSub XMPP extension that allows each user to subscribe to a node, to be notified whenever that node gets new pieces of information or updated information.
The DC Gateway PubSub subscription state and subscriber name can be shown:
*A:pe-9# show system vsd
===============================================================================
VSD Information
===============================================================================
System Id : pe9
GW Last Audit Tx Time : 10/13/2015 13:56:34
Gateway Publish-Subscribe Information
-------------------------------------------------------------------------------
Subscribed : True
Subscriber Name : nuage_gateway_id_pe9
Last Subscription Time : 10/13/2015 13:56:34
===============================================================================
At the same time, the SR OS DC Gateway will be announced as a pending gateway in the VSD:
The gateway will be promoted to the available gateways group by clicking on the arrow below the pending gateway icon:
BGP configuration
In the Nuage VSP solution, MP-BGP is used in the control plane to distribute MAC/IP information about the VMs. This information is distributed between the different VSCs, VSGs, and SR OS DC Gateways. Configure MP-BGP on the SR OS DC Gateway and the VSC/VSG (in this case, a VSG was used, but VSC is similar):
*A:pe-9>config>router# info
----------------------------------------------
#--------------------------------------------------
echo "IP Configuration"
#--------------------------------------------------
interface "system"
address 10.0.0.9/32
no shutdown
exit
---snip---
autonomous-system 65000
---snip---
#--------------------------------------------------
echo "BGP Configuration"
#--------------------------------------------------
min-route-advertisement 5
rapid-withdrawal
rapid-update evpn
group "Nuage"
family route-target evpn
type internal
neighbor 39.0.0.94
exit
exit
no shutdown
*A:vsc1.nuage.net>config>router# info
----------------------------------------------
#--------------------------------------------------
echo "IP Configuration"
#--------------------------------------------------
---snip---
interface "system"
address 39.0.0.94/32
no shutdown
exit
autonomous-system 65000
---snip---
#--------------------------------------------------
echo "BGP Configuration"
#--------------------------------------------------
bgp
family route-target evpn
min-route-advertisement 5
rapid-withdrawal
rapid-update evpn
group "internal"
type internal
neighbor 10.0.0.9
family evpn
exit
exit
no shutdown
exit
----------------------------------------------
In this setup, the family type "evpn" and "route-target" is used. The former is used to learn the EVPN route updates while the latter is restricting the SR OS to only learn those MB-BGP routes for which it has a route target configured.
To use vrf-gre domains, configure BGP family "vpn-ipv4" as well. Similarly, to use BGP-MH (for example, in case of redundant SR OS DC Gateways with L2-domains), the use of BGP family "l2vpn" is required.
Verify that BGP peering is in the operational state:
*A:pe-9# show router bgp summary
===============================================================================
BGP Router ID:10.0.0.9 AS:65000 Local AS:65000
===============================================================================
BGP Admin State : Up BGP Oper State : Up
---snip---
AS PktRcvd InQ Up/Down State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
-------------------------------------------------------------------------------
39.0.0.94
65000 76287 0 00h04m14s 0/0/0 (RouteTarget)
2634 0 0/0/0 (Evpn)
-------------------------------------------------------------------------------
Dynamic VSD Services range
F-D XMPP provisioning requires a reserved range of Service-IDs that can be used for dynamic data services. This configured range is no longer available for regular services configured via CLI/SNMP:
*A:pe-9>config>service# info
----------------------------------------------
vsd
service-range 64000 to 64999
exit
*A:pe-9# show service vsd summary
===============================================================================
VSD Information
===============================================================================
Service Range
Start : 64000 End : 64999
===============================================================================
No domain entries found
Python script
The python script that will build the dynamic services based on the VSD parameters obtained via XMPP can be stored locally on the CF or on a remote FTP server:
*A:pe-9>config>python# info
----------------------------------------------
python-script "l2domain_services" create
primary-url "ftp://*:*@138.203.15.48/./l2domain_service.py"
no shutdown
exit
The script is loaded into memory as soon as a no shutdown is performed and is reloaded with each shutdown/no shutdown action. Alternatively, a tools command can be used to reload the script:
*A:pe-9# tools perform python-script reload "l2domain_services"
In case incorrect python syntax is used in the script, an error message is displayed after a no shutdown of the script (or a reload with the tools command), with an indication of the line where the error is located.
The details of the python script can be inspected:
*A:pe-9# show python python-script "l2domain_services"
===============================================================================
Python script "l2domain_services"
===============================================================================
Description : (Not Specified)
Admin state : inService
Oper state : inService
Action on fail: drop
Protection : none
Primary URL : ftp://*:*@138.203.15.48/./l2domain_service.py
Secondary URL : (Not Specified)
Tertiary URL : (Not Specified)
Active URL : primary
Last changed : 10/13/2015 09:54:26
===============================================================================
The contents of the python script can also be viewed. The contents of the script are shown in the "Test the python script" section:
*A:pe-9# show python python-script "l2domain_services" source-in-use
===============================================================================
Python script "l2domain_services"
===============================================================================
Admin state : inService
Oper state : inService
Primary URL : ftp://*:*@138.203.15.48/./l2domain_service.py
Secondary URL : (Not Specified)
Tertiary URL : (Not Specified)
Active URL : primary
-------------------------------------------------------------------------------
Source (dumped from memory)
-------------------------------------------------------------------------------
1 from alc import dyn
2
3 # example of metadata to be added in VSD WAN Service: "rd=1:1,sap=1/1/1:1000"
4
---snip---
8 def setup_script(vsdParams):
---snip---
70 def modify_script(vsdParams,setup_result):
---snip---
106 def revert_script(vsdParams,setup_result):
---snip---
129 def teardown_script(setupParams):
---snip---
164 d = {"script" : (setup_script, modify_script, revert_script, teardown_script)}
165
166 dyn.action(d)
===============================================================================
A list of CLI command nodes that can be used with python script function dyn.add_cli is provided with the tools dump service vsd-services command-list command. In general, all the ‛leaf’ commands under the nodes shown in the tools dump command, can be used with the python script.
Further restriction of CLI commands is possible by creating a separate CLI user for the XMPP interface and associate that user with a profile where the commands are limited.
The CLI user for the XMPP interface is configurable:
config>system>security>cli-script>authorization>
vsd
[no] cli-user <username>
Python policy
Python scripts are called by a python policy that will be referred to in the VSD WAN services GUI in the Service Policy field.
Create a python policy (that will be referred to in the VSD GUI) and link the python policy to the python script:
*A:pe-9>config>python# info
----------------------------------------------
python-policy "py-l2" create
description "Python script to create L2 domains"
vsd script "l2domain_services"
exit
*A:pe-9# show python python-script "l2domain_services" association
===============================================================================
Python Script Association
===============================================================================
Policy Type Dir
-------------------------------------------------------------------------------
py-l2 vsdAccessRequest ingress
-------------------------------------------------------------------------------
*A:pe-9# show python python-policy "py-l2"
===============================================================================
Python policy "py-l2"
===============================================================================
Description : Python script to create L2 domains
-------------------------------------------------------------------------------
Messages
-------------------------------------------------------------------------------
Type Dir Script
-------------------------------------------------------------------------------
vsdAccessRequest ingress l2domain_services
-------------------------------------------------------------------------------
Test the python script
The python script can be tested separately on the SR OS DC Gateway; even before connecting it to the Nuage setup.
Some notes about the python script and creating dynamic services:
The VSD (and tools evaluate-script command) will provide some compulsory parameters like:
domain-name
domain type (l2-domain|vrf-gre|vrf-vxlan|l2-domain-irb)
action (setup or teardown)
vni
RT (internal and external route-targets are provided)
The VSD (and tools evaluate-script command) can provide extra metadata that is supplied in a text string and comma separated. For example, metadata "rd=1:1,sap=1/1/1:1000".
The RT format supplied by the VSD though XMPP (that is, "x:x") differs from the RT format that can be used with the tools evaluate-script command (for example, "target:x:x"). For that reason, it can be useful to add the following check in the script:
if not rt.startswith ('target'): rt = "target:"+rtThe VSD metadata string includes an empty space at the end. This can be removed with the following python command:
metadata = metadata.rstrip()If a configuration message is received from the VSD for an existing service-name with no VSD parameters, or if a setup_script() fails, the teardown_script() is called.
At any point in the script, you can add print commands to check the status/content of various parameters.
The python policy and script can then be tested with the tools evaluate-script command. Example syntax has been added into the scripts for convenience.
Before testing the script, it will be useful to enable the following debugging:
debug
python
python-script "l2domain_services"
script-all-info
exit
exit
vsd
scripts
event
cli
errors
executed-cmd
warnings
state-change
exit
exit
exit
exit
In this section, a python example script for an l2-domain is used. The contents of the script are shown in the following text format. Examples for l2-domain-irb and vrf-vxlan type domains are shown in dedicated sections:
from alc import dyn
# example of metadata to be added in VSD WAN Service: "rd=1:1,sap=1/1/1:1000"
# example of tools cli to test this script: tools perform service vsd evaluate-script domain-name "l2dom1" type l2-domain action setup policy "py-l2" vni 1234 rt-i target:1:1 rt-e target:1:1 metadata "rd=1:1,sap=1/1/1:1000"
# teardown example cli: tools perform service vsd evaluate-script domain-name "l2dom1" type l2-domain action teardown policy "py-l2" vni 1234 rt-i target:1:1 rt-e target:1:1
def setup_script(vsdParams):
print ("These are the VSD params: " + str(vsdParams))
servicetype = vsdParams['servicetype']
vni = vsdParams['vni']
rt = vsdParams['rt']
# add "target:" if provisioned by VSD (VSD uses x:x format whereas tools command uses target:x:x format)
if not rt.startswith ('target'):
rt = "target:"+rt
metadata = vsdParams['metadata']
# remove trailing space at the end of the metadata
metadata = metadata.rstrip()
print ("VSD metadata" + str(metadata))
metadata = dict(e.split('=') for e in metadata.split(','))
print ("Modified metadata" + str(metadata))
vplsSvc_id = dyn.select_free_id("service-id")
print ("this is the free svc id picked up by the system: " + vplsSvc_id)
if servicetype == "L2DOMAIN":
rd = metadata['rd']
sap_id = metadata['sap']
print ('servicetype, VPLS id, rt, vni, rd, sap:', servicetype, vplsSvc_id, rt, vni, rd, sap_id)
dyn.add_cli("""
configure service
vpls %(vplsSvc_id)s customer 1 create
description vpls%(vplsSvc_id)s
proxy-arp
dynamic-arp-populate
no shutdown
exit
bgp
route-distinguisher %(rd)s
route-target %(rt)s
exit
vxlan vni %(vni)s create
exit
bgp-evpn
evi %(vplsSvc_id)s
vxlan
no shutdown
exit
exit
service-name evi%(vplsSvc_id)s
sap %(sap_id)s create
exit
no shutdown
exit
exit
exit
""" % {'vplsSvc_id' : vplsSvc_id, 'vni' : vsdParams['vni'], 'rt' : rt, 'rd' : metadata['rd'], 'sap_id' : sap_id})
# L2DOMAIN returns setupParams: vplsSvc_id, servicetype, vni, sap
return {'vplsSvc_id' : vplsSvc_id, 'servicetype' : servicetype, 'vni' : vni, 'sap_id' : sap_id}
#------------------------------------------------------------------------------------------------
def modify_script(vsdParams,setup_result):
print ("These are the setup_result params for modify_script: " + str(setup_result))
print ("These are the VSD params for modify_script: " + str(vsdParams))
# remove trailing space at the end of the metadata
metadata = vsdParams['metadata'].rstrip()
print ("VSD metadata" + str(metadata))
metadata = dict(e.split('=') for e in metadata.split(','))
print ("Modified metadata" + str(metadata))
# updating the setup_result dict
setup_result.update(metadata)
params = setup_result
print ("The updated params from metadata and return from the setup result: " + str(params))
svc_mtu = params['svc-mtu']
dyn.add_cli("""
configure service
vpls %(vplsSvc_id)s
service-mtu %(svc-mtu)s
exit
exit
exit
""" %params )
# Result is passed to teardown_script
return params
#------------------------------------------------------------------------------------------------
def revert_script(vsdParams,setup_result):
print ("These are the setup_result params for revert_script: " + str(setup_result))
print ("These are the VSD params for revert_script: " + str(vsdParams))
# When modify fails, the revert is called and then the teardown is called.
# It is recommended to revert to same value as used in setup for the attributes modified in modify_script.
params = setup_result
dyn.add_cli("""
configure service
vpls %(vplsSvc_id)s
service-mtu 2000
exit
exit
exit
""" %params )
# Result is passed to teardown_script
return params
#------------------------------------------------------------------------------------------------
def teardown_script(setupParams):
print ("These are the teardown_script setupParams: " + str(setupParams))
servicetype = setupParams['servicetype']
if servicetype == "L2DOMAIN":
dyn.add_cli("""
configure service
vpls %(vplsSvc_id)s
no description
proxy-arp shut
no proxy-arp
bgp-evpn
vxlan
shut
exit
no evi
exit
no vxlan vni %(vni)s
bgp
no route-distinguisher
no route-target
exit
no bgp
no bgp-evpn
sap %(sap_id)s
shutdown
exit
no sap %(sap_id)s
shutdown
exit
no vpls %(vplsSvc_id)s
exit
exit
""" % {'vplsSvc_id' : setupParams['vplsSvc_id'], 'vni' : setupParams['vni'], 'sap_id' : setupParams['sap_id']})
return setupParams
d = {"script" : (setup_script, modify_script, revert_script, teardown_script)}
dyn.action(d)
The script can be tested with the following command:
*A:pe-9# tools perform service vsd evaluate-script domain-name "l2dom1" type l2-domain action setup policy "py-l2" vni 1234 rt-i target:1:1 rt-e target:1:1 metadata "rd=1:1,sap=1/1/1:1000"
1 2015/10/15 09:51:16.08 UTC MINOR: DEBUG #2001 Base dyn-script req=setup
"dyn-script req=setup: l2dom1
state=init->waiting-for-setup
"
2 2015/10/15 09:51:16.08 UTC MINOR: DEBUG #2001 Base dyn-script req=setup
"dyn-script req=setup: l2dom1
state=waiting-for-setup->generating-setup
"
3 2015/10/15 09:51:16.08 UTC MINOR: DEBUG #2001 Base Python Output
"Python Output: l2domain_services
These are the VSD params: {'rt': 'target:1:1', 'rte': 'target:1:1', 'domain': ''
, 'servicetype': 'L2DOMAIN', 'vni': '1234', 'metadata': 'rd=1:1,sap=1/1/1:1000 '
}
VSD metadatard=1:1,sap=1/1/1:1000
Modified metadata{'rd': '1:1', 'sap': '1/1/1:1000'}
this is the free svc id picked up by the system: 64000
('servicetype, VPLS id, rt, vni, rd, sap:', 'L2DOMAIN', '64000', 'target:1:1', '
1234', '1:1', '1/1/1:1000')
"
4 2015/10/15 09:51:16.08 UTC MINOR: DEBUG #2001 Base Python Result
"Python Result: l2domain_services
"
5 2015/10/15 09:51:16.08 UTC MINOR: DEBUG #2001 Base dyn-script req=setup
"dyn-script req=setup: l2dom1
state=generating-setup->executing-setup
"
6 2015/10/15 09:51:16.08 UTC MINOR: DEBUG #2001 Base dyn-script cli 1/1
"dyn-script cli 1/1: script:l2dom1(cli 705 dict 0->123)
configure service
vpls 64000 customer 1 create
description vpls64000
proxy-arp
dynamic-arp-populate
no shut
exit
bgp
route-distinguisher 1:1
route-target target:1:1
exit
vxlan vni 1234 create
exit
bgp-evpn
evi 64000
vxlan
no shut
exit
exit
service-name evi64000
sap 1/1/1:1000 create
exit
no shutdown
exit
exit
exit
"
7 2015/10/15 09:51:16.08 UTC MINOR: DEBUG #2001 Base dyn-script setup
"dyn-script setup: l2dom1 script:l2dom1 line 2
configure service"
Success
---snip---
24 2015/10/15 09:51:16.08 UTC MINOR: DEBUG #2001 Base dyn-script req=setup
"dyn-script req=setup: l2dom1
state=executing-setup->established
"
At this moment a new VSD domain has been created as well as a new service:
*A:pe-9# show service vsd domain
===============================================================================
VSD Domain Table
===============================================================================
Name Type Origin Admin
-------------------------------------------------------------------------------
l2dom1 l2Domain vsd inService
-------------------------------------------------------------------------------
*A:pe-9# show service vsd domain "l2dom1" association
============================================================
Service VSD Domain
============================================================
Svc Id Svc Type Domain Type Domain Admin Origin
------------------------------------------------------------
64000 vpls l2Domain inService vsd
------------------------------------------------------------
*A:pe-9# show service vsd domain "l2dom1"
===============================================================================
VSD Information
===============================================================================
Name : l2dom1
Description : l2dom1
Type : l2Domain Admin State : inService
Last Error To Vsd : (Not Specified)
Last Error From Vsd: (Not Specified)
Statistics
-------------------------------------------------------------------------------
Last Cfg Chg Evt : 10/14/2015 16:02:54 Cfg Chg Evts : 1
Last Cfg Update : 10/14/2015 16:02:54 Cfg Upd Rcvd : 1
Last Cfg Done : 10/14/2015 16:02:54Cfg Success : 1 Cfg Failed : 0
Last Recd Params : script = {'domain' : '', 'vn
: i' : '1234', 'rt' : 'target:
: 1:1', 'rte' : 'target:1:1',
: 'servicetype' : 'L2DOMAIN',
: 'metadata' : 'rd=1:1,sap=1/1
: /1:1000 '}
Last Exec Params : script = {'domain' : '', 'vn
: i' : '1234', 'rt' : 'target:
: 1:1', 'rte' : 'target:1:1',
: 'servicetype' : 'L2DOMAIN',
: 'metadata' : 'rd=1:1,sap=1/1
: /1:1000 '}
===============================================================================
*A:pe-9# show service service-using
===============================================================================
Services
===============================================================================
ServiceId Type Adm Opr CustomerId Service Name
-------------------------------------------------------------------------------
64000 VPLS Up Up 1 evi64000
2147483648 IES Up Down 1 _tmnx_InternalIesService
2147483649 intVpls Up Down 1 _tmnx_InternalVplsService
-------------------------------------------------------------------------------
Service ID 2147483648 and 2147483649 are internal services that are always present on the SR OS. They are not relevant for this feature and will be truncated in other output examples in this document.
*A:pe-9# show service id 64000 all
===============================================================================
Service Detailed Information
===============================================================================
Service Id : 64000 Vpn Id : 0
Service Type : VPLS
Name : evi64000
Description : vpls64000
Customer Id : 1 Creation Origin : vsd
Last Status Change: 10/14/2015 16:02:54
Last Mgmt Change : 10/14/2015 16:02:54
Etree Mode : Disabled
Admin State : Up Oper State : Up
MTU : 1514 Def. Mesh VC Id : 64000
SAP Count : 1 SDP Bind Count : 0
---snip---
VSD Domain : l2dom1
---snip---
-------------------------------------------------------------------------------
BGP Information
-------------------------------------------------------------------------------
Vsi-Import : None
Vsi-Export : None
Route Dist : 1:1
Oper Route Dist : 1:1
Oper RD Type : configured
Rte-Target Import : 1:1 Rte-Target Export : 1:1
Oper RT Imp Origin: configured Oper RT Import : 1:1
Oper RT Exp Origin: configured Oper RT Export : 1:1
PW-Template Id : None
-------------------------------------------------------------------------------
---snip---
-------------------------------------------------------------------------------
SAP 1/1/1:1000
-------------------------------------------------------------------------------
Service Id : 64000
SAP : 1/1/1:1000 Encap : q-tag
Description : (Not Specified)
Admin State : Up Oper State : Up
---snip---
You cannot see the dynamic VSD services in the configuration nor can you edit their configuration under normal circumstances (this is discussed further in the next section).
*A:pe-9>config>service# info
----------------------------------------------
customer 1 create
description "Default customer"
exit
vsd
service-range 64000 to 64999
exit
----------------------------------------------
*A:pe-9# configure service vpls 64000
MINOR: CLI Modification of services created by a dynamic script is not allowed.
The service can be modified by adding/changing a service-mtu to the metadata. This will trigger the modify-script function in the python script. The following basic script is only an example of how a modify-script function operates. The script could be extended to modify other parameters as well; however this is out of the scope of this chapter:
*A:pe-9# tools perform service vsd evaluate-script domain-name "l2dom1" type l2-domain action modify policy "py-l2" vni 1234 rt-i target:1:1 rt-e target:1:1 metadata "rd=1:1,sap=1/1/1:1000,svc-mtu=2222"
25 2015/10/15 09:51:22.44 UTC MINOR: DEBUG #2001 Base dyn-script req=modify
"dyn-script req=modify: l2dom1
state=established->waiting-for-modify
"
26 2015/10/15 09:51:22.44 UTC MINOR: DEBUG #2001 Base dyn-script req=modify
"dyn-script req=modify: l2dom1
state=waiting-for-modify->generating-modify
"
27 2015/10/15 09:51:22.44 UTC MINOR: DEBUG #2001 Base Python Output
"Python Output: l2domain_services
These are the setup_result params for modify_script: {'servicetype': 'L2DOMAIN',
'vplsSvc_id': '64000', 'vni': '1234', 'sap_id': '1/1/1:1000'}
These are the VSD params for modify_script: {'rt': 'target:1:1', 'rte': 'target:
1:1', 'domain': '', 'servicetype': 'L2DOMAIN', 'vni': '1234', 'metadata': 'rd=1:
1,sap=1/1/1:1000,svc-mtu=2222 '}
VSD metadatard=1:1,sap=1/1/1:1000,svc-mtu=2222
Modified metadata{'rd': '1:1', 'sap': '1/1/1:1000', 'svc-mtu': '2222'}
The updated params from metadata and return from the setup result: {'rd': '1:1',
'servicetype': 'L2DOMAIN', 'svc-mtu': '2222', 'sap_id': '1/1/1:1000', 'sap': '1
/1/1:1000', 'vplsSvc_id': '64000', 'vni': '1234'}
"
Success
28 2015/10/15 09:51:22.44 UTC MINOR: DEBUG #2001 Base Python Result
"Python Result: l2domain_services
"
29 2015/10/15 09:51:22.44 UTC MINOR: DEBUG #2001 Base dyn-script req=modify
"dyn-script req=modify: l2dom1
state=generating-modify->executing-modify
"
*A:pe-9#
30 2015/10/15 09:51:22.44 UTC MINOR: DEBUG #2001 Base dyn-script cli 1/1
"dyn-script cli 1/1: script:l2dom1(cli 123 dict 123->203)
configure service
vpls 64000
service-mtu 2222
exit
exit
exit
"
31 2015/10/15 09:51:22.44 UTC MINOR: DEBUG #2001 Base dyn-script modify
"dyn-script modify: l2dom1 script:l2dom1 line 2
configure service"
---snip---
36 2015/10/15 09:51:22.44 UTC MINOR: DEBUG #2001 Base dyn-script req=commit
"dyn-script req=commit: l2dom1
state=waiting-for-commit->established
"
The service-mtu has now been changed to 2222:
show service id 64000 all | match MTU
MTU : 2222 Def. Mesh VC Id : 64000
Admin MTU : 9212 Oper MTU : 9212
The service can be removed with the teardown script:
*A:pe-9# tools perform service vsd evaluate-script domain-name "l2dom1" type l2-domain action teardown policy "py-l2" vni 1234 rt-i target:1:1 rt-e target:1:1
37 2015/10/15 09:51:29.80 UTC MINOR: DEBUG #2001 Base dyn-script req=teardown
"dyn-script req=teardown: l2dom1
state=established->waiting-for-teardown
"
38 2015/10/15 09:51:29.80 UTC MINOR: DEBUG #2001 Base dyn-script req=teardown
"dyn-script req=teardown: l2dom1
state=waiting-for-teardown->generating-teardown
"
39 2015/10/15 09:51:29.80 UTC MINOR: DEBUG #2001 Base Python Output
"Python Output: l2domain_services
These are the teardown_script setupParams: {'servicetype': 'L2DOMAIN', 'svc-mtu'
: '2222', 'sap_id': '1/1/1:1000', 'vplsSvc_id': '64000', 'vni': '1234', 'rd': '1
:1', 'sap': '1/1/1:1000'}
"
40 2015/10/15 09:51:29.80 UTC MINOR: DEBUG #2001 Base Python Result
"Python Result: l2domain_services
"
41 2015/10/15 09:51:29.80 UTC MINOR: DEBUG #2001 Base dyn-script req=teardown
"dyn-script req=teardown: l2dom1
state=generating-teardown->executing-teardown
"
42 2015/10/15 09:51:29.80 UTC MINOR: DEBUG #2001 Base dyn-script cli 1/1
"dyn-script cli 1/1: script:l2dom1(cli 709 dict 203->0)
configure service
vpls 64000
no description
proxy-arp shut
no proxy-arp
bgp-evpn
vxlan
shut
exit
no evi
exit
no vxlan vni 1234
bgp
no route-distinguisher
no route-target
exit
no bgp
no bgp-evpn
sap 1/1/1:1000
shutdown
exit
no sap 1/1/1:1000
shutdown
exit
no vpls 64000
exit
exit
"
43 2015/10/15 09:51:29.80 UTC MINOR: DEBUG #2001 Base dyn-script teardown
"dyn-script teardown: l2dom1 script:l2dom1 line 2
configure service"
---snip---
63 2015/10/15 09:51:29.81 UTC MINOR: DEBUG #2001 Base dyn-script req=teardown
"dyn-script req=teardown: l2dom1
state=executing-teardown->stopped
"
After the dynamic service has been torn down, the dynamic service and the VSD domain should not be present on the SR OS DC Gateway:
*A:pe-9# show service service-using
===============================================================================
Services
===============================================================================
ServiceId Type Adm Opr CustomerId Service Name
-------------------------------------------------------------------------------
2147483648 IES Up Down 1 _tmnx_InternalIesService
2147483649 intVpls Up Down 1 _tmnx_InternalVplsService
-------------------------------------------------------------------------------
Matching Services : 2
-------------------------------------------------------------------------------
===============================================================================
*A:pe-9# show service vsd domain
No domain entries found
Editing dynamic VSD services
As indicated in the previous section, the dynamic VSD services CLI configuration cannot be shown or edited normally. However, under certain circumstances, it might be necessary to inspect/change/remove the configuration of a dynamic VSD service; for example, when the python VSD script was not using the correct syntax and the creation/deletion of the dynamic VSD service failed.
It is possible to edit the dynamic VSD services configuration by entering the enable-vsd-config mode. First, create a password, which is required to enter this mode:
*A:pe-9# configure system security password
*A:pe-9>config>system>security>password# vsd-password *****
Then, enter the enable-vsd-config mode. You will be asked for the previously configured password:
*A:pe-9# enable-vsd-config
Password:
Now you can edit the dynamic VSD services configuration and change/add/remove configuration:
*A:pe-9# configure service
*A:pe-9>config>service# info
----------------------------------------------
customer 1 create
description "Default customer"
exit
vsd
domain l2dom1 type l2-domain create
description "l2dom1"
no shutdown
exit
service-range 64000 to 64999
exit
vpls 64000 customer 1 create
description "vpls64000"
vxlan vni 1234 create
exit
bgp
route-distinguisher 1:1
exit
bgp-evpn
evi 64000
vxlan
no shutdown
exit
mpls
shutdown
exit
exit
proxy-arp
dynamic-arp-populate
no shutdown
exit
stp
shutdown
exit
service-name "evi64000"
sap 1/1/1:1000 create
exit
vsd-domain "l2dom1"
no shutdown
exit
----------------------------------------------
In the enable-vsd-config mode, only dynamic VSD services can be edited, not regular CLI-based services:
*A:pe-9# configure service vpls 100 customer 1 create
MINOR: SVCMGR #1201 Invalid service-id - not reserved
After inspecting/editing the dynamic VSD services configuration, you should exit this mode again:
*A:pe-9# no enable-vsd-config
L2 VXLAN
An example python script for F-D XMPP provisioning of an L2 VXLAN type service (l2-domain) was provided in the "Testing the python script" section. In this section, the same script is used for provisioning via the VSD.
To dynamically provision this type of service, a few things must be configured on the VSD: (screenshots of this workflow are available in the VSP User Guide)
Create an L2 WAN service in the VSD:
under Platform Config/Infrastructure, select the DC Gateway to add a WAN service
select Service Type "layer 2" (no IRB)
select "Dynamic" configuration type to allow Fully Dynamic provisioning
under Service Policy, provide the python policy configured on the DC Gateway
provide a Name and Service-ID (the Service-ID will be the name of the dynamically created service domain on the DC Gateway)
Add the metadata to the WAN service:
right-click the WAN service and select "inspect"
a dialog box appears, select the "Metadata" tag and add the metadata info "rd=1:1,sap=1/1/1:1000"
Add permissions to Enterprise1. The WAN service should now be visible in Enterprise1. Add permissions for a group of users to use this WAN service. Instantiate the L2 domain and attach the WAN service.
As soon as the WAN service is attached to the L2 domain, the VSD will send a notification via XMPP to the DC Gateway about the new Service-ID. The VSD will send an XMPP IQ request to the VSD to obtain the VSD service parameters.
There is an 8 to 12 s delay. The command tools perform service vsd domain refresh-config can be used to expedite the request.
As soon as the DC Gateway receives this information, the python policy mentioned in the VSD service parameters is triggered and the VSD parameters are passed to the associated python script. The python script will then construct and execute the same configuration CLI and trigger similar debug information as is shown in the section "Testing the python script".
After the python script has completed successfully, the service can be inspected in a similar way as before.
show service service-using
show service id <service-id> all
enter enable-vsd-config mode if required and inspect the service config
MAC addresses can now be learned in the Nuage VSC/VSG and sent via MP-BGP to the DC Gateway:
*A:pe-9# show service id 64000 fdb detail
===============================================================================
Forwarding Database, Service 64000
===============================================================================
ServId MAC Source-Identifier Type Last Change
Age
-------------------------------------------------------------------------------
64000 1e:50:01:01:00:01 vxlan: Evpn 10/14/15 16:10:44
39.0.0.94:1006636
-------------------------------------------------------------------------------
In case HyperVisors (HVs) with VRS are deployed or a Host vPORT has been connected to a VSG, the EVPN MAC/Route (type 2) will also include the IP address of the VM/Host, in which case the DC Gateway can perform a proxy-arp function. For more information about EVPN-VXLAN features, refer to the chapters EVPN for VXLAN Tunnels (Layer 2) and EVPN for VXLAN Tunnels (Layer 3).
*A:pe-9# show service id 64000 proxy-arp detail
-------------------------------------------------------------------------------
Proxy Arp
-------------------------------------------------------------------------------
Admin State : enabled
Dyn Populate : enabled
Age Time : disabled Send Refresh : disabled
Table Size : 250 Total : 1
Static Count : 0 EVPN Count : 1
Dynamic Count : 0 Duplicate Count : 0
Dup Detect
-------------------------------------------------------------------------------
Detect Window : 3 mins Num Moves : 5
Hold down : 9 mins
Anti Spoof MAC : None
EVPN
-------------------------------------------------------------------------------
Garp Flood : enabled Req Flood : enabled
-------------------------------------------------------------------------------
===============================================================================
VPLS Proxy Arp Entries
===============================================================================
IP Address Mac Address Type Status Last Update
-------------------------------------------------------------------------------
10.32.78.100 1e:50:01:01:00:01 evpn active 07/22/2015 10:05:25
-------------------------------------------------------------------------------
Number of entries : 1
===============================================================================
The svc-ID belonging to the Service-ID configured on the VSD can be easily obtained:
*A:pe-9# show service vsd domain "L2-service-1" association
============================================================
Service VSD Domain
============================================================
Svc Id Svc Type Domain Type Domain Admin Origin
------------------------------------------------------------
64000 vpls l2Domain inService vsd
------------------------------------------------------------
Number of entries: 1
The associated RT/RD/VNI information can then be displayed with the show service id <service-id> all command, as shown previously.
An overview of the VTEPs that the DC Gateway shares this service with, and the corresponding VNIs is available:
*A:pe-9# show service id 64000 vxlan
===============================================================================
VPLS VXLAN, Ingress VXLAN Network Id: 1006636
===============================================================================
Egress VTEP, VNI
===============================================================================
VTEP Address Egress VNI Num. MACs Mcast Oper State L2 PBR
-------------------------------------------------------------------------------
39.0.0.94 1006636 0 Yes Up No
-------------------------------------------------------------------------------
An overview of all the Service-IDs and associated VNIs that the DC Gateway has in common with a VSC or VSG can be shown with the following command:
*A:pe-9# show service vxlan 39.0.0.94
===============================================================================
VXLAN Tunnel Endpoint: 39.0.0.94
===============================================================================
Egress VNI Service Id Oper State
-------------------------------------------------------------------------------
1006636 64000 Up
-------------------------------------------------------------------------------
===============================================================================
Relevant MAC/IP/VNI/RT/NH information is also in the EVPN BGP RIB:
*A:pe-9# show router bgp routes evpn mac
===============================================================================
BGP Router ID:10.0.0.9 AS:65000 Local AS:65000
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP EVPN MAC Routes
===============================================================================
Flag Route Dist. MacAddr ESI
Tag Mac Mobility Ip Address
NextHop
Label1
-------------------------------------------------------------------------------
u*>i 65534:39790 1e:50:01:01:00:01 ESI-0
1006636 Static 10.32.78.100
39.0.0.94
VNI 1006636
-------------------------------------------------------------------------------
The WAN service can be detached from the L2 domain in the VSD GUI, if required.
This triggers similar debug information on the DC Gateway as the tools perform service vsd evaluate teardown command shown in the "Testing the python script" section.
After deleting the WAN service in the VSD GUI, the VPLS service and the service domain is removed from the DC Gateway.
L2 VXLAN IRB
An example python script for F-D XMPP provisioning of an L2 VXLAN IRB type service (l2-domain-irb) is as follows:
from alc import dyn
# example of metadata to be added in VSD WAN Service: "rd=2:2,sap=1/1/1:1000,vprnAS=65000,vprnRD=65000:1,vprnRT=target:65000:1,vprnLo=1.1.1.1,irbGW=10.32.78.1/24"
# example of tools cli to test this script: tools perform service vsd evaluate-script domain-name "l2domIRB1" type l2-domain-irb action setup policy "py-l2-irb" vni 1234 rt-i target:2:2 rt-e target:2:2 metadata "rd=2:2,sap=1/1/1:1000,vprnAS=65000,vprnRD=65000:1,vprnRT=target:65000:1,vprnLo=1.1.1.1,irbGW=10.32.78.1/24"
# teardown example cli: tools perform service vsd evaluate-script domain-name "l2domIRB1" type l2-domain-irb action teardown policy "py-l2-irb" vni 1234 rt-i target:2:2 rt-e target:2:2
def setup_script(vsdParams):
print ("These are the VSD params: " + str(vsdParams))
servicetype = vsdParams['servicetype']
vni = vsdParams['vni']
rt = vsdParams['rt']
# add "target:" if provisioned by VSD (VSD uses x:x format whereas tools command uses target:x:x format)
if not rt.startswith ('target'):
rt = "target:"+rt
metadata = vsdParams['metadata']
# remove trailing space at the end of the metadata
metadata = metadata.rstrip()
print ("VSD metadata" + str(metadata))
metadata = dict(e.split('=') for e in metadata.split(','))
print ("Modified metadata" + str(metadata))
vplsSvc_id = dyn.select_free_id("service-id")
vprnSvc_id = dyn.select_free_id("service-id")
print ("this are the free svc ids picked up by the system: VPLS:" + vplsSvc_id + " + VPRN:" + vprnSvc_id)
if servicetype == "L2DOMAIN-IRB":
rd = metadata['rd']
sap_id = metadata['sap']
vprn_AS = metadata ['vprnAS']
vprn_RD = metadata ['vprnRD']
vprn_RT = metadata ['vprnRT']
vprn_Lo = metadata ['vprnLo']
irb_GW = metadata ['irbGW']
print ('servicetype, VPLS id, rt, vni, rd, sap, VPRN id, vprn_AS, vprn_RD, vprn_RT, vprn_Lo, irb_GW:', servicetype, vplsSvc_id, rt, vni, rd, sap_id, vprnSvc_id, vprn_AS, vprn_RD, vprn_RT, vprn_Lo, irb_GW)
dyn.add_cli("""
configure service
vpls %(vplsSvc_id)s customer 1 create
allow-ip-int-bind
exit
description vpls%(vplsSvc_id)s
bgp
route-distinguisher %(rd)s
route-target %(rt)s
exit
vxlan vni %(vni)s create
exit
bgp-evpn
evi %(vplsSvc_id)s
vxlan
no shut
exit
exit
service-name vpls%(vplsSvc_id)s
sap %(sap_id)s create
exit
no shutdown
exit
exit
exit
configure service
vprn %(vprnSvc_id)s customer 1 create
autonomous-system %(vprn_AS)s
route-distinguisher %(vprn_RD)s
vrf-target %(vprn_RT)s
interface "irbvpls-%(vplsSvc_id)s" create
address %(irb_GW)s
vpls "vpls%(vplsSvc_id)s"
exit
exit
interface "lo1" create
address %(vprn_Lo)s/32
loopback
exit
no shutdown
exit
exit
""" % {'vplsSvc_id' : vplsSvc_id, 'vprnSvc_id' : vprnSvc_id, 'vni' : vsdParams['vni'], 'rt' : rt, 'rd' : metadata['rd'], 'sap_id' : sap_id, 'vprn_AS' : vprn_AS, 'vprn_RD' : vprn_RD, 'vprn_RT' : vprn_RT, 'vprn_Lo' : vprn_Lo, 'irb_GW' : irb_GW})
# L2DOMAIN-IRB returns setupParams: vplsSvc_id, vprnSvc_id, servicetype, vni, sap, vprn_AS, vprn_RD, vprn_RT, vprn_Lo
return {'vplsSvc_id' : vplsSvc_id, 'vprnSvc_id' : vprnSvc_id, 'servicetype' : servicetype, 'vni' : vni, 'sap_id' : sap_id, 'vprn_AS' : vprn_AS, 'vprn_RD' : vprn_RD, 'vprn_RT' : vprn_RT, 'vprn_Lo' : vprn_Lo, 'irb_GW': irb_GW}
#------------------------------------------------------------------------------------------------
def teardown_script(setupParams):
print ("These are the teardown_script setupParams: " + str(setupParams))
servicetype = setupParams['servicetype']
if servicetype == "L2DOMAIN-IRB":
dyn.add_cli("""
configure service
vpls %(vplsSvc_id)s
no description
bgp-evpn
vxlan
shut
exit
no evi
exit
no vxlan vni %(vni)s
bgp
no route-distinguisher
no route-target
exit
no bgp
no bgp-evpn
sap %(sap_id)s
shutdown
exit
no sap %(sap_id)s
shutdown
exit
no vpls %(vplsSvc_id)s
vprn %(vprnSvc_id)s
interface lo1 shutdown
no interface lo1
interface "irbvpls-%(vplsSvc_id)s"
no vpls
shutdown
exit
no interface "irbvpls-%(vplsSvc_id)s"
shutdown
exit
no vprn %(vprnSvc_id)s
exit
""" % {'vplsSvc_id' : setupParams['vplsSvc_id'], 'vprnSvc_id' : setupParams['vprnSvc_id'], 'vni' : setupParams['vni'], 'sap_id' : setupParams['sap_id']})
return setupParams
d = {"script" : (setup_script, None, None, teardown_script)}
dyn.action(d)
The python script and policy are configured in a similar way as the previous example:
*A:pe-9# configure python
*A:pe-9>config>python# info
----------------------------------------------
python-script "l2domain-irb_services" create
primary-url "ftp://*:*@138.203.15.48/./l2domainIRB_service.py"
no shutdown
exit
python-policy "py-l2-irb" create
description "Python script to create L2-IRB domains"
vsd script "l2domain-irb_services"
exit
----------------------------------------------
It is also possible to create a python script that covers different domain types. The relevant part of the script is then addressed by using the following if-statement in the script:
servicetype = vsdParams.get('servicetype')
if servicetype == "L2DOMAIN-IRB":
---snip---
On the VSD, the following has to be provided:
(screenshots of this workflow are available in the VSP User Guide)
Create an L2 WAN service in the VSD:
under Platform Config/Infrastructure, select the DC Gateway to add a WAN service
select Service Type "layer 2" and select "IRB"
select "Dynamic" configuration type to allow Fully Dynamic provisioning
under Service Policy, provide the python policy configured on the DC Gateway
provide a Name and Service-ID (the Service-ID will be the name of the dynamically created service domain on the DC Gateway)
Add the metadata to the WAN service:
right-click the WAN service and select "inspect"
a pop-up dialog box appears; select the "Metadata" tag and add the metadata info; for example,
"rd=2:2,sap=1/1/1:1000,vprnAS=65000,vprnRD=65000:1,vprnRT=target:65000:1,vprnLo=1.1.1.1, irbGW=10.32.78.1/24"
Add permissions to Enterprise1. The WAN service should now be visible in Enterprise1.
Add permissions for a group of users to use this WAN service. Instantiate an L2 domain and attach the WAN service.
After the script has completed, there should be two new services created:
*A:pe-9# show service service-using
===============================================================================
Services
===============================================================================
ServiceId Type Adm Opr CustomerId Service Name
-------------------------------------------------------------------------------
64000 VPLS Up Up 1 vpls64000
64001 VPRN Up Up 1
*A:pe-9# show service id 64000 all
===============================================================================
Service Detailed Information
===============================================================================
Service Id : 64000 Vpn Id : 0
Service Type : VPLS
Name : vpls64000
Description : vpls64000
Customer Id : 1 Creation Origin : vsd
Last Status Change: 07/22/2015 11:15:36
Last Mgmt Change : 07/22/2015 11:15:36
Etree Mode : Disabled
Admin State : Up Oper State : Up
MTU : 1514 Def. Mesh VC Id : 64000
SAP Count : 1 SDP Bind Count : 0
---snip---
VSD Domain : L2-IRB-Service-1
---snip---
-------------------------------------------------------------------------------
BGP Information
-------------------------------------------------------------------------------
Vsi-Import : None
Vsi-Export : None
Route Dist : 2:2
Oper Route Dist : 2:2
Oper RD Type : configured
Rte-Target Import : 65534:6985 Rte-Target Export : 65534:6985
Oper RT Imp Origin: configured Oper RT Import : 65534:6985
Oper RT Exp Origin: configured Oper RT Export : 65534:6985
PW-Template Id : None
-------------------------------------------------------------------------------
---snip---
-------------------------------------------------------------------------------
SAP 1/1/1:1000
-------------------------------------------------------------------------------
Service Id : 64000
SAP : 1/1/1:1000 Encap : q-tag
Description : (Not Specified)
Admin State : Up Oper State : Up
---snip---
===============================================================================
VPLS VXLAN, Ingress VXLAN Network Id: 1006636
===============================================================================
Egress VTEP, VNI
===============================================================================
VTEP Address Egress VNI Num. MACs Mcast Oper State L2 PBR
-------------------------------------------------------------------------------
39.0.0.94 1006636 0 Yes Up No
-------------------------------------------------------------------------------
---snip---
*A:pe-9# show service id 64001 all
===============================================================================
Service Detailed Information
===============================================================================
Service Id : 64001 Vpn Id : 0
Service Type : VPRN
Name : (Not Specified)
Description : (Not Specified)
Customer Id : 1 Creation Origin : vsd
Last Status Change: 07/22/2015 11:15:36
Last Mgmt Change : 07/22/2015 11:15:36
Admin State : Up Oper State : Up
Route Dist. : 65000:1 VPRN Type : regular
Oper Route Dist : 65000:1
Oper RD Type : configured
AS Number : 65000 Router Id : 10.0.0.9
ECMP : Enabled ECMP Max Routes : 1
---snip---
-------------------------------------------------------------------------------
Interface
-------------------------------------------------------------------------------
If Name : irbvpls-64000
Admin State : Up Oper (v4/v6) : Up/Down
Protocols : None
IP Addr/mask : 10.32.78.1/24 Address Type : Primary
---snip---
Routed VPLS Details
VPLS Name : vpls64000
Binding Status : Up
---snip---
-------------------------------------------------------------------------------
Interface
-------------------------------------------------------------------------------
If Name : lo1
Admin State : Up Oper (v4/v6) : Up/Down
Protocols : None
IP Addr/mask : 1.1.1.1/32 Address Type : Primary
The dynamically created configuration can be inspected in enable-vsd-config mode (only enter the enable-vsd-config mode when absolutely required):
*A:pe-9>config>service# info
----------------------------------------------
customer 1 create
description "Default customer"
exit
vsd
domain L2-IRB-Service-1 type l2-domain-irb create
description "L2-IRB-Service-1"
no shutdown
exit
service-range 64000 to 64999
exit
vpls 64000 customer 1 create
description "vpls64000"
allow-ip-int-bind
exit
vxlan vni 1006636 create
exit
bgp
route-distinguisher 2:2
exit
bgp-evpn
evi 64000
vxlan
no shutdown
exit
mpls
shutdown
exit
exit
stp
shutdown
exit
service-name "vpls64000"
sap 1/1/1:1000 create
exit
vsd-domain "L2-IRB-Service-1"
no shutdown
exit
vprn 64001 customer 1 create
autonomous-system 65000
route-distinguisher 65000:1
auto-bind-tunnel
resolution any
exit
vrf-target target:65000:1
interface "irbvpls-64000" create
address 10.32.78.1/24
vpls "vpls64000"
exit
exit
interface "lo1" create
address 1.1.1.1/32
loopback
exit
vsd-domain "L2-IRB-Service-1"
no shutdown
exit
----------------------------------------------
MAC addresses can now be learned in the Nuage VSP/VSG and sent via MP-BGP to the DC Gateway:
*A:pe-9# show service id 64000 fdb detail
===============================================================================
Forwarding Database, Service 64000
===============================================================================
ServId MAC Source-Identifier Type Last Change
Age
-------------------------------------------------------------------------------
64000 1e:50:01:01:00:01 vxlan: Evpn 07/22/15 11:26:15
39.0.0.94:1006636
64000 1e:e2:ff:00:f9:3d cpm Intf 07/22/15 11:15:36
-------------------------------------------------------------------------------
The second MAC address is the GW-MAC that the VM or VSG-connected host will use to reach the interface on the VPRN:
*A:pe-9# show router 64001 route-table
===============================================================================
Route Table (Service: 64001)
===============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
-------------------------------------------------------------------------------
1.1.1.1/32 Local Local 00h17m10s 0
lo1 0
10.32.78.0/24 Local Local 00h17m10s 0
irbvpls-64000 0
*A:pe-9# show router 64001 arp
===============================================================================
ARP Table (Service: 64001)
===============================================================================
IP Address MAC Address Expiry Type Interface
-------------------------------------------------------------------------------
10.32.78.1 1e:e2:ff:00:f9:3d 00h00m00s Oth[I] irbvpls-64000
10.32.78.100 1e:50:01:01:00:01 03h53m22s Dyn[I] irbvpls-64000
1.1.1.1 1e:e2:ff:00:00:00 00h00m00s Oth lo1
Similar commands as shown in the previous section are available to obtain relevant information:
show service vsd domain "L2-IRB-Service-1" association to obtain svc-IDs
show service id <id> all to obtain RT/RD/VNI values
show service id <id> vxlan to obtain VTEPs in the VPLS service
show service vxlan <vtep-ip> to obtain svc-ID and VNI information
show router bgp routes evpn mac to obtain MAC/IP/VNI/RT/NH information
The VM or VSG-connected Host should be able to ping the loopback interface of the VPRN service:
*A:ce1# ping 1.1.1.1 source 10.32.78.100
PING 1.1.1.1 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=1.67ms.
64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=1.83ms.
L3 VXLAN
An example python script for F-D XMPP provisioning of an L3 VXLAN type service (vrf-vxlan) is:
from alc import dyn
# example of metadata to be added in VSD WAN Service: "rd=3:3,vprnAS=65000,vprnRD=65000:1,vprnRT=target:65000:1,vprnLo=1.1.1.1"
# example of tools cli to test this script: tools perform service vsd evaluate-script domain-name "l3dom1" type vrf-vxlan action setup policy "py-vrf-vxlan" vni 1234 rt-i target:3:3 rt-e target:3:3 metadata "rd=3:3,vprnAS=65000,vprnRD=65000:1,vprnRT=target:65000:1,vprnLo=1.1.1.1"
# teardown example cli: tools perform service vsd evaluate-script domain-name "l3dom1" type vrf-vxlan action teardown policy "py-vrf-vxlan" vni 1234 rt-i target:3:3 rt-e target:3:3
def setup_script(vsdParams):
print ("These are the VSD params: " + str(vsdParams))
servicetype = vsdParams['servicetype']
vni = vsdParams['vni']
rt = vsdParams['rt']
# add "target:" if provisioned by VSD (VSD uses x:x format whereas tools command uses target:x:x format)
if not rt.startswith ('target'):
rt = "target:"+rt
metadata = vsdParams['metadata']
# remove trailing space at the end of the metadata
metadata = metadata.rstrip()
print ("VSD metadata" + str(metadata))
metadata = dict(e.split('=') for e in metadata.split(','))
print ("Modified metadata" + str(metadata))
vplsSvc_id = dyn.select_free_id("service-id")
vprnSvc_id = dyn.select_free_id("service-id")
print ("this are the free svc ids picked up by the system: VPLS:" + vplsSvc_id + " + VPRN:" + vprnSvc_id)
if servicetype == "VRF-VXLAN":
rd = metadata['rd']
vprn_AS = metadata ['vprnAS']
vprn_RD = metadata ['vprnRD']
vprn_RT = metadata ['vprnRT']
vprn_Lo = metadata ['vprnLo']
print ('servicetype, VPLS id, rt, vni, rd, VPRN id, vprn_AS, vprn_RD, vprn_RT, vprn_Lo:', servicetype, vplsSvc_id, rt, vni, rd, vprnSvc_id, vprn_AS, vprn_RD, vprn_RT, vprn_Lo)
dyn.add_cli("""
configure router policy-options
begin
community _VSD_%(vplsSvc_id)s members %(rt)s
policy-statement vsi_import_%(vplsSvc_id)s
entry 10
from
family evpn
community _VSD_%(vplsSvc_id)s
exit
action accept
exit
exit
exit
policy-statement vsi_export_%(vplsSvc_id)s
entry 10
from
family evpn
exit
action accept
community add _VSD_%(vplsSvc_id)s
exit
exit
exit
commit
exit
configure service
vpls %(vplsSvc_id)s customer 1 create
allow-ip-int-bind
exit
description vpls%(vplsSvc_id)s
bgp
route-distinguisher %(rd)s
vsi-import vsi_import_%(vplsSvc_id)s
vsi-export vsi_export_%(vplsSvc_id)s
exit
vxlan vni %(vni)s create
exit
bgp-evpn
ip-route-advertisement
vxlan
no shut
exit
exit
service-name vpls%(vplsSvc_id)s
no shutdown
exit
exit
exit
configure service
vprn %(vprnSvc_id)s customer 1 create
autonomous-system %(vprn_AS)s
route-distinguisher %(vprn_RD)s
vrf-target %(vprn_RT)s
interface "vpls-%(vplsSvc_id)s" create
vpls "vpls%(vplsSvc_id)s" evpn-tunnel
exit
interface "lo1" create
address %(vprn_Lo)s/32
loopback
exit
no shutdown
exit
exit
""" % {'vplsSvc_id' : vplsSvc_id, 'vprnSvc_id' : vprnSvc_id, 'vni' : vsdParams['vni'], 'rt' : rt, 'rd' : metadata['rd'], 'vprn_AS' : vprn_AS, 'vprn_RD' : vprn_RD, 'vprn_RT' : vprn_RT, 'vprn_Lo' : vprn_Lo})
# VRF-VXLAN returns setupParams: vplsSvc_id, vprnSvc_id, servicetype, vni, vprn_AS, vprn_RD, vprn_RT, vprn_Lo
return {'vplsSvc_id' : vplsSvc_id, 'vprnSvc_id' : vprnSvc_id, 'servicetype' : servicetype, 'vni' : vni, 'vprn_AS' : vprn_AS, 'vprn_RD' : vprn_RD, 'vprn_RT' : vprn_RT, 'vprn_Lo' : vprn_Lo}
#------------------------------------------------------------------------------------------------
def teardown_script(setupParams):
print ("These are the teardown_script setupParams: " + str(setupParams))
servicetype = setupParams['servicetype']
if servicetype == "VRF-VXLAN":
dyn.add_cli("""
configure service
vpls %(vplsSvc_id)s
no description
bgp-evpn
vxlan
shut
exit
no evi
exit
no vxlan vni %(vni)s
bgp
no route-distinguisher
no route-target
exit
no bgp
no bgp-evpn
shutdown
exit
no vpls %(vplsSvc_id)s
vprn %(vprnSvc_id)s
interface lo1 shutdown
no interface lo1
interface "vpls-%(vplsSvc_id)s"
vpls "vpls%(vplsSvc_id)s"
no evpn-tunnel
exit
no vpls
shutdown
exit
no interface "vpls-%(vplsSvc_id)s"
shutdown
exit
no vprn %(vprnSvc_id)s
exit
configure router policy-options
begin
no community _VSD_%(vplsSvc_id)s
no policy-statement vsi_import_%(vplsSvc_id)s
no policy-statement vsi_export_%(vplsSvc_id)s
commit
exit
""" % {'vplsSvc_id' : setupParams['vplsSvc_id'], 'vprnSvc_id' : setupParams['vprnSvc_id'], 'vni' : setupParams['vni']})
return setupParams
d = {"script" : (setup_script, None, None, teardown_script)}
dyn.action(d)
The python script and policy are configured in a similar way as the previous example:
*A:pe-9# configure python
*A:pe-9>config>python# info
----------------------------------------------
python-script "vrf-vxlan_services" create
primary-url "ftp://*:*@138.203.15.48/./vrf-vxlan_service.py"
no shutdown
exit
python-policy "py-vrf-vxlan" create
description "Python script to create vrf-vxlan domains"
vsd script "l3vxlan"
exit
----------------------------------------------
The following steps are required on the VSD to provision the WAN service:
(screenshots of this workflow are available in the VSP User Guide)
Create an L3 WAN service in the VSD:
under Platform Config / Infrastructure, select the DC Gateway to add a WAN service
select Service Type "layer 3"
select "Dynamic" configuration type to allow Fully Dynamic provisioning
under Service Policy, provide the python policy configured on the DC Gateway
provide a Name and Service-ID (the Service-ID will be the name of the dynamically created service domain on the DC Gateway)
Add the metadata to the WAN service:
right-click the WAN service and select "inspect"
a pop-up dialog box appears; select the "Metadata" tag and add the metadata info; for example,
"rd=3:3,vprnAS=65000,vprnRD=65000:1,vprnRT=target:65000:1,vprnLo=1.1.1.1"
Add permissions to Enterprise1. The WAN service should now be visible in Enterprise1.
Add permissions for a group of users to use this WAN service. Instantiate an L3 domain and attach the WAN service.
After the script has completed, there should be two new services:
*A:pe-9# show service service-using
===============================================================================
Services
===============================================================================
ServiceId Type Adm Opr CustomerId Service Name
-------------------------------------------------------------------------------
64000 VPLS Up Up 1 vpls64000
64001 VPRN Up Up 1
*A:pe-9# show service id 64000 all
===============================================================================
Service Detailed Information
===============================================================================
Service Id : 64000 Vpn Id : 0
Service Type : VPLS
Name : vpls64000
Description : vpls64000
Customer Id : 1 Creation Origin : vsd
Last Status Change: 10/14/2015 18:38:44
Last Mgmt Change : 10/14/2015 18:38:44
Etree Mode : Disabled
Admin State : Up Oper State : Up
MTU : 1514 Def. Mesh VC Id : 64000
SAP Count : 0 SDP Bind Count : 0
---snip---
VSD Domain : L3-service-1
---snip---
-------------------------------------------------------------------------------
BGP Information
-------------------------------------------------------------------------------
Vsi-Import : vsi_import_64000
Vsi-Export : vsi_export_64000
Route Dist : 3:3
Oper Route Dist : 3:3
Oper RD Type : configured
Rte-Target Import : None Rte-Target Export : None
Oper RT Imp Origin: vsi Oper RT Import : None
Oper RT Exp Origin: vsi Oper RT Export : None
PW-Template Id : None
-------------------------------------------------------------------------------
---snip---
===============================================================================
VPLS VXLAN, Ingress VXLAN Network Id: 119281
===============================================================================
Egress VTEP, VNI
===============================================================================
VTEP Address Egress VNI Num. MACs Mcast Oper State L2 PBR
-------------------------------------------------------------------------------
39.0.0.94 119281 1 No Up No
-------------------------------------------------------------------------------
---snip---
The script dynamically creates a VSI-import and VSI-export policy and links it to an RT that was dynamically created by the VSC/VSG:
*A:pe-9# show router policy
===============================================================================
Route Policies
===============================================================================
Policy Description
-------------------------------------------------------------------------------
vsi_export_64000
vsi_import_64000
-------------------------------------------------------------------------------
Policies : 2
===============================================================================
*A:pe-9# show router policy "vsi_import_64000"
entry 10
from
community "_VSD_64000"
family evpn
exit
action accept
exit
exit
*A:pe-9# show router policy "vsi_export_64000"
entry 10
from
family evpn
exit
action accept
community add "_VSD_64000"
exit
exit
*A:pe-9# show router policy community "_VSD_64000"
community "_VSD_64000" members "65534:38619"
*A:pe-9# show service id 64001 all
===============================================================================
Service Detailed Information
===============================================================================
Service Id : 64001 Vpn Id : 0
Service Type : VPRN
Name : (Not Specified)
Description : (Not Specified)
Customer Id : 1 Creation Origin : vsd
Last Status Change: 10/14/2015 18:38:44
Last Mgmt Change : 10/14/2015 18:38:44
Admin State : Up Oper State : Up
Route Dist. : 65000:1 VPRN Type : regular
Oper Route Dist : 65000:1
Oper RD Type : configured
AS Number : 65000 Router Id : 10.0.0.9
ECMP : Enabled ECMP Max Routes : 1
Auto Bind Tunnel
Resolution : any
---snip---
Vrf Target : target:65000:1
---snip---
-------------------------------------------------------------------------------
Interface
-------------------------------------------------------------------------------
If Name : vpls-64000
Admin State : Up Oper (v4/v6) : Up/Down
Protocols : None
IP Addr/mask : Not Assigned
---snip---
Routed VPLS Details
VPLS Name : vpls64000
Binding Status : Up
---snip---
-------------------------------------------------------------------------------
Interface
-------------------------------------------------------------------------------
If Name : lo1
Admin State : Up Oper (v4/v6) : Up/Down
Protocols : None
IP Addr/mask : 1.1.1.1/32 Address Type : Primary
The dynamically created configuration can be inspected in enable-vsd-config mode (only enter the enable-vsd-config mode when required):
*A:pe-9>config>service# info
----------------------------------------------
customer 1 create
description "Default customer"
exit
vsd
domain L3-service-1 type vrf-vxlan create
description "L3-service-1"
no shutdown
exit
service-range 64000 to 64999
exit
vpls 64000 customer 1 create
description "vpls64000"
allow-ip-int-bind
exit
vxlan vni 119281 create
exit
bgp
route-distinguisher 3:3
vsi-export "vsi_export_64000"
vsi-import "vsi_import_64000"
exit
bgp-evpn
ip-route-advertisement
vxlan
no shutdown
exit
mpls
shutdown
exit
exit
stp
shutdown
exit
service-name "vpls64000"
vsd-domain "L3-service-1"
no shutdown
exit
vprn 64001 customer 1 create
autonomous-system 65000
route-distinguisher 65000:1
auto-bind-tunnel
resolution any
exit
vrf-target target:65000:1
interface "vpls-64000" create
vpls "vpls64000"
evpn-tunnel
exit
exit
interface "lo1" create
address 1.1.1.1/32
loopback
exit
vsd-domain "L3-service-1"
no shutdown
exit
----------------------------------------------
The EVPN tunnel NH-MAC addresses can now be learned in the Nuage VSP/VSG and sent via MP-BGP to the DC Gateway:
*A:pe-9# show service id 64000 fdb detail
Forwarding Database, Service 64000
===============================================================================
ServId MAC Source-Identifier Type Last Change
Age
-------------------------------------------------------------------------------
64000 00:00:27:00:00:5e vxlan: Evpn 07/22/15 13:38:47
39.0.0.94:119281
64000 1e:e2:ff:00:f9:3d cpm Intf 07/22/15 13:38:44
-------------------------------------------------------------------------------
The first MAC entry address is the tunnel NH-MAC for the VSG and the second is the address for the DC Gateway for EVPN-tunnel service 64000:
*A:pe-9# show router 64001 route-table
===============================================================================
1.1.1.1/32 Local Local 00h09m08s 0
lo1 0
10.32.78.0/24 Remote BGP EVPN 00h09m05s 169
vpls-64000 (ET-00:00:27:00:00:5e) 0
10.32.78.100/32 Remote BGP EVPN 00h00m04s 169
vpls-64000 (ET-00:00:27:00:00:5e) 0
-------------------------------------------------------------------------------
The following commands are useful to obtain relevant information:
show service vsd domain "L3-service-1" association to obtain svc-IDs
show service id <id> all to obtain RT/RD/VNI values
show service id <id> vxlan to obtain VTEPs in the VPLS service
show service vxlan <vtep-ip> to obtain svc-id and VNI information
Relevant EVPN tunnel NH-MAC/VNI/RT/NH information is also in the EVPN BGP RIB:
*A:pe-9# show router bgp routes evpn mac detail
---snip---
Modified Attributes
Network : N/A
Nexthop : 39.0.0.94
From : 39.0.0.94
Res. Nexthop : 192.168.39.94
Local Pref. : 200 Interface Name : toNuage
Aggregator AS : None Aggregator : None
Atomic Aggr. : Not Atomic MED : 0
AIGP Metric : None
Connector : None
Community : target:65534:38619 bgp-tunnel-encap:VXLAN
Cluster : No Cluster Members
Originator Id : None Peer Router Id : 39.0.0.94
Flags : Used Valid Best IGP
Route Source : Internal
AS-Path : No As-Path
EVPN type : MAC
ESI : ESI-0
Tag : 119281
IP Address : N/A
Route Dist. : 65534:29625
Mac Address : 00:00:27:00:00:5e
MPLS Label1 : VNI 119281 MPLS Label2 : N/A
Route Tag : 0
---snip---
VM/VSG-connected Host and network information is also in the EVPN BGP RIB:
*A:pe-9# show router bgp routes evpn ip-prefix detail
---snip---
Modified Attributes
Network : N/A
Nexthop : 39.0.0.94
From : 39.0.0.94
Res. Nexthop : 192.168.39.94
Local Pref. : 200 Interface Name : toNuage
Aggregator AS : None Aggregator : None
Atomic Aggr. : Not Atomic MED : 0
AIGP Metric : None
Connector : None
Community : target:65534:38619 ext:30b:220000000000
ext:30b:100b00b00000 bgp-tunnel-encap:VXLAN
mac-nh:00:00:27:00:00:5e
Cluster : No Cluster Members
Originator Id : None Peer Router Id : 39.0.0.94
Flags : Used Valid Best IGP
Route Source : Internal
AS-Path : No As-Path
EVPN type : IP-PREFIX
ESI : N/A
Tag : 119281
Gateway Address: 00:00:27:00:00:5e
Prefix : 10.32.78.100/32
Route Dist. : 39.0.0.94:10269
MPLS Label : VNI 119281
Route Tag : 0
---snip---
Modified Attributes
Network : N/A
Nexthop : 39.0.0.94
From : 39.0.0.94
Res. Nexthop : 192.168.39.94
Local Pref. : 200 Interface Name : toNuage
Aggregator AS : None Aggregator : None
Atomic Aggr. : Not Atomic MED : 0
AIGP Metric : None
Connector : None
Community : target:65534:38619 ext:30b:220000000000
ext:30b:100b00b00000 bgp-tunnel-encap:VXLAN
mac-nh:00:00:27:00:00:5e
Cluster : No Cluster Members
Originator Id : None Peer Router Id : 39.0.0.94
Flags : Used Valid Best IGP
Route Source : Internal
AS-Path : No As-Path
EVPN type : IP-PREFIX
ESI : N/A
Tag : 119281
Gateway Address: 00:00:27:00:00:5e
Prefix : 10.32.78.0/24
Route Dist. : 39.0.0.94:10269
MPLS Label : VNI 119281
Route Tag : 0
---snip---
The VM or VSG-connected Host should be able to ping the loopback interface of the VPRN service:
*A:ce1# ping 1.1.1.1 source 10.32.78.100
PING 1.1.1.1 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=1.67ms.
64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=1.83ms.
Troubleshooting and debug commands
When testing/troubleshooting F-D XMPP provisioning, the following show/tools/debug commands can be useful:
tools perform service vsd evaluate-script
tools perform service vsd fd-domain-sync <full|diff>
tools perform service vsd domain refresh-config
tools perform python-script reload
tools dump service vsd-services command-list
debug python python-script
debug vsd scripts event/instance
debug system xmpp
debug router bgp update
show service vsd domain
show service vsd script
show service vsd summary
show system vsd
show xmpp vsd
show python python-policy <name> {association}
show python python-script <name> {association|source-in-use}
show service vxlan [<vtep-ip>]
show service service-using {<service-type>}
show service id route-table
show service id fdb detail
show service id proxy-arp detail
show router [<router-instance>] route-table
show router [<router-instance>] arp
show router bgp routes bgp <mac|ip-prefix|inclusive-mcast> {detail}
log-id 99
Conclusion
The fully dynamic VSD integration model allows for automated provisioning of breakout services on the SR OS DC Gateway. Different domain types (l2-domain/l2-domain-irb/vrf-vxlan/vrf-gre) are supported. This chapter has shown how to construct, load, and test python scripts for this feature. It also described how to configure WAN services on the VSD and how to verify the dynamically created services.