Configuring Cisco CSR 1000V routers/firewalls

The following topics provide information about Pod and Container Management (PCM) changes and requirements to manage the Cisco Cloud Services Router (CSR) 1000V using BMC Network Automation as part of a BMC Cloud Lifecycle Management implementation:

The Cisco Cloud Services Router (CSR) 1000V is a virtualized software router that contains IOS networking and security features that an enterprise or cloud provider can deploy as a virtual machine (VM) in a provider-hosted cloud. The CSR 1000V device can run on an x86 server that supports VMware ESXi virtualization. The CSR 1000V is a single-tenant router in a virtual form-factor that delivers comprehensive wide area network (WAN) gateway functionality to multi-tenant, provider-hosted clouds. Using Cisco IOS Software networking capabilities, the CSR 1000V enables enterprises to seamlessly extend their WANs into external provider-hosted clouds and enables cloud providers to offer enterprise-class networking services to their tenants.

CSR1000V is in the form of a virtual machine that can be deployed on ESX using VMware vCentre server with open virtualization format/ open virtualization appliance (OVF/OVA). The latest OVF/OVA version is Cisco IOS/XE 3.11.

Creating the pod blueprint and the pod

You need to define separate node blueprints to use CSR 1000V as a router and as a firewall. When creating a pod, you do not need to select any device because the pod node does not need any host device.

The following code block shows an example pod node defined when CSR 1000V is configured as a router:

<nodeBlueprints>
  <nodeBlueprint xsi:type="podHostBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <balancedParamBlueprints/>
    <category>2</category>
    <defaultShareableFlag>false</defaultShareableFlag>
    <name>CSR</name>
    <optionalFlag>true</optionalFlag>
    <paramBlueprints>
      <paramBlueprint>
        <name>vCenter Address</name>
        <description>vCenter URL (e.g. https://myvcenter.mydomain.com/sdk)</description>
      </paramBlueprint>
      <paramBlueprint>
        <name>vCenter Admin Username</name>
        <description>User name of vCenter</description>
      </paramBlueprint>
      <paramBlueprint>
        <name>vCenter Admin Password</name>
        <description>Password of vCenter</description>
        <sensitiveFlag>true</sensitiveFlag>
      </paramBlueprint>
      <paramBlueprint>
        <name>ESX Cluster</name>
        <description>Name of the vCenter cluster</description>
      </paramBlueprint>
      <paramBlueprint>
        <name>ESX Data Center</name>
        <description>Name of the vCenter data center</description>
      </paramBlueprint>
      <paramBlueprint>
        <name>Data Store</name> 
        <description>Name of the vCenter data store</description> 
      </paramBlueprint>    
      <paramBlueprint>
        <name>OVA File Location</name>
        <description>Absolute path of the csr1000v ova file, e.g. c:\myfiles\csr.ova</description>
      </paramBlueprint>
      <paramBlueprint>
        <description>NIC 0 port profile for Management Network</description>
        <name>Management Nic Port Profile</name>
      </paramBlueprint>
      <paramBlueprint>
        <description>External Outside Network Port Profile</description>
        <name>External Outside Port Profile</name>
      </paramBlueprint>
    </paramBlueprints>
    <role>CSR</role>
  </nodeBlueprint>

The following figure shows a CSR 1000V node configured as a router:

The following code block shows an example pod node defined when CSR 1000V is configured as a firewall:

<nodeBlueprint xsi:type="podFirewallHostBlueprint">
  <category>4</category>
  <defaultShareableFlag>true</defaultShareableFlag>
  <name>FWH</name>
  <optionalFlag>true</optionalFlag>
  <paramBlueprints/>
  <role>FWH</role>
</nodeBlueprint>

The following figure shows a CSR 1000V node configured as a firewall:

Back to top

Defining the containerFirewallHostBlueprint as a firewall

When the CSR 1000V device is used as a firewall, you must define a node as a container firewall host blueprint. The virtual guest device points to the existing guest device that was created in CSR 1000V as a router node. You must define the following tags in the virtual guest blueprint to ensure that you do not create a new guest but instead, use an existing guest, which was created during container creation when the CSR 1000V was configured as a router node.

• <guestDeviceName>${container.name}-CSR-Guest</guestDeviceName>

• <useExistingGuestDeviceFlag>true</useExistingGuestDeviceFlag>

If CSR 1000V is used only as a firewall and not as a router, you need only one node; the CSR 1000V VM can be deployed in that node and the guest can be added in the same node. In this case,  <useExistingGuestDeviceFlag> must be set to false.

Depending on the design, you can define multiple managedInterfaceBlueprints in the virtualGuestBlueprint of the VFW. Each managedInterfaceBlueprint is mapped to a corresponding zone. During container creation, you create zones with the names of the defined managed interface and assign the Gigabit interface of the respective NIC segment to the zone.

<managedInterfaceBlueprints>
  <managedInterfaceBlueprint>
    <inboundAclBlueprint>
      <enablePathUpdates>true</enablePathUpdates>
      <name>Inbound1</name>
      <ruleBlueprints/>
    </inboundAclBlueprint>
    <outboundAclBlueprint>
      <enablePathUpdates>false</enablePathUpdates>
        <name>Outbound1</name>
        <ruleBlueprints/>
    </outboundAclBlueprint>
    <name>CustomerNetwork1</name>
    <servicedSegmentNames>
      <servicedSegmentName>Customer Network 1</servicedSegmentName>
    </servicedSegmentNames>
  </managedInterfaceBlueprint>
  <managedInterfaceBlueprint>
    <inboundAclBlueprint>
      <enablePathUpdates>true</enablePathUpdates>
      <name>Inbound2</name>
      <ruleBlueprints/>
    </inboundAclBlueprint>
    <outboundAclBlueprint>
      <enablePathUpdates>false</enablePathUpdates>
        <name>Outbound2</name>
        <ruleBlueprints/>
    </outboundAclBlueprint>
    <name>Outside</name>
    <servicedSegmentNames>
      <servicedSegmentName>Outside</servicedSegmentName>
    </servicedSegmentNames>
  </managedInterfaceBlueprint>
</managedInterfaceBlueprints>

Back to top

Creating the container blueprint and container

The container blueprint for CSR 1000V can have two nodes, one for CSR 1000V as a router and the other for CSR 1000V as a firewall. The CSR 1000V node configured as a router deploys the CSR 1000V VM and adds the required NICs depending upon the number of data networks defined.

Defining the container blueprint to configure CSR 1000V as a router

When CSR 1000V is used as a router, perform the following steps:

1. Under the <containerHostBlueprint> tag, define a separate container node as a container host blueprint.
   
   The required configure actions in this container host node first deploy the CSR 1000V VM.
   
   

    Click here to view the containerHostBlueprint tag to create a CSR 1000V VM.

   <configureActionInfoBlueprint xsi:type="externalScriptActionInfoBlueprint">
     <guid>5F09E1A8-8679-4D7F-B775-137B347AA648</guid>
     <name>Create CSR1000V VM</name>
     <runtimeProps>
       <item>
         <key>vCentreURL</key>
         <value>${pod.node.params[vCenter Address]}</value>
       </item>
       <item>
         <key>vCentreUser</key>
         <value>${pod.node.params[vCenter Admin Username]}</value>
       </item>
       <item>
         <key>vCentreUserPassword</key>
         <value>${pod.node.params[vCenter Admin Password]}</value>
       </item>
       <item>
         <key>datacenter</key>
         <value>${pod.node.params[ESX Data Center]}</value>
       </item>
       <item>
         <key>esxCluster</key>
         <value>${pod.node.params[ESX Cluster]}</value>
       </item>
       <item>
         <key>vmName</key>
         <value>${container.nodes[CSR-Guest].device.name}</value>
       </item>
       <item>
         <key>ovfFileName</key>
         <value>${pod.node.params[OVA File Location]}</value>
       </item>
       <item>
         <key>portProfile1Name</key>
         <value>${pod.node.params[Management Nic Port Profile]}</value>
       </item>
       <item>
         <key>loginUsername</key>
         <value>admin</value>
       </item>
       <item>
         <key>loginPassword</key>
         <value>###</value>
       </item>
       <item>
         <key>enablePassword</key>
         <value>###</value>
       </item>
       <item>
         <key>ipDomain</key>
         <value>xxxxx.com</value>
       </item>
       <item>
         <key>mgmtIPaddress</key>   
         <value>${container.nodes[CSR-Guest].addresses[ManagementAddress]}
         ${container.nodes[CSR-Guest].addresses[ManagementAddress].subnetMask}</value>
       </item>
       <item>
         <key>mgmtGateway</key>
         <value>${pod.addressPools[Management].gatewayAddress}</value>
       </item>
       <item>
         <key>haFlag</key>
         <value>false</value>
       </item>
     </runtimeProps>
   </configureActionInfoBlueprint>

2. Define one virtual guest blueprint under the container host blueprint. This guest blueprint adds the CSR 1000V device in BMC Network Automation as a guest device.

   1. Configure the CSR 1000V device for FTP/SCP and routing by executing the Configure Initial Configuration for CSR1000v action as shown in the following code snippet:
      
      

       Click here to view the Configure Initial Configuration - CSR1000v action.

      <configureActionInfoBlueprint xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="mergeActionInfoBlueprint">
        <description>Configure Initial Configuration for CSR1000v</description>
        <name>Configure Initial Configuration - CSR1000v</name>
        <templateGroups>
          <item>Configure Initial Configuration - CSR1000v</item>
        </templateGroups>
      </configureActionInfoBlueprint>
      

      
      To configure the FTP and SCP modes on the CSR 1000V device operating in the standalone mode, you must add the following configuration on the device. In both the samples, ‘1’ is the interface ID that is assigned to the management VRF (management interface) by default.
      
      FTP:
      
      

      Router# configure terminal 
      Router(config)#ip ftp source-interface gigabitEthernet 1
      

      
      SCP:
      
      

      Router# configure terminal 
      Router(config)#ip ssh source-interface gigabitEthernet 1
      

   2. Execute the Merge action to configure the NIC segments. This action waits for the CSR 1000V device to start up completely and must be performed after adding any NICs as shown in the following code snippet:
      
      

       Click here to view the Merge action to configure the NIC segements.

      <configureActionInfoBlueprint xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="mergeActionInfoBlueprint">
        <condition>-EXISTS- container.zones['Zone 1'].nicSegments['Customer Network 1']</condition>
        <description>Merge Action to configure Customer Network1</description>
        <name>Configure CSR1000V Router Customer Network 1</name>
        <templateGroups>
          <item>Configure CSR1000V Router Customer Network 1</item>
        </templateGroups>
      </configureActionInfoBlueprint>

      
      Back to top

   3. Increase the value of the Timeout for Establishing Connection parameter to 1800 seconds because the CSR 1000V VM takes additional time to boot and come up to a state where BMC Network Automation can perform Telnet or SSH. By default, BMC Network Automation waits for 60 seconds to establish a connection.
      
      

      The Timeout for Establishing Connections parameter applies to all the devices in BMC Network Automation and not any specific device.

      
      
      
      Back to top

3. Add NICs to the newly added CSR 1000V VM depending upon the state of the NIC segment by defining a configureActionInfoBlueprint of type External Script action as shown in the following code snippet:
   
   

    Click here to view the configureActionInfoBlueprint tag to add NICs to the newly added CSR 1000V VM.

   <configureActionInfoBlueprint xsi:type="externalScriptActionInfoBlueprint">
     <guid>5F0923B8-8679-4D7F-B775-ABCB347EB898</guid>
     <name>Add NIC for Customer Network 1</name>
     <condition>-EXISTS- container.zones['Zone 1'].nicSegments['Customer Network 1']</condition>
     <hasResultPropagation>true</hasResultPropagation>
     <runtimeProps>
       <item>
         <key>vCentreURL</key>
         <value>${pod.nodes[CSR].params[vCenter Address]}</value>
       </item>
       <item>
         <key>vCentreUser</key>
         <value>${pod.nodes[CSR].params[vCenter Admin Username]}</value>
       </item>
       <item>
         <key>vCentreUserPassword</key>
         <value>${pod.nodeS[CSR].params[vCenter Admin Password]}</value>
       </item>
       <item>
         <key>vmName</key>
         <value>${container.name}-CSR-Guest</value>
       </item>
       <item>
        <key>networkName</key>
        <value>${container.nodes[Access].portTypes[Customer Port Type 1].name}</value>
       </item>
       <item>
         <key>networkAdapter</key>
         <value>VMXNET3</value>
       </item>
       <item>
         <key>powerOffRequired</key>
         <value>false</value>
       </item>
     </runtimeProps>
     <capturedResultPatterns>
       <item>
         <key>macAddress</key>
         <value>\s*NIC MAC Address:\s+(\w+:\w+:\w+:\w+:\w+:\w+).*</value>
       </item>
      </capturedResultPatterns>
   </configureActionInfoBlueprint>  

   Back to top

4. Capture the interface ID by executing the Discover Interface Id custom action, which uses the MAC address of the NIC added in the previous. This action checks the captured MAC address and its associated interface ID and returns the interface ID, and then propagates the interface ID to the subsequent actions.

   1. Set <hasResultPropagation> to true to propagate the MAC address to the next actions.
      
      

       Click here to view the configureActionInfoBlueprint tag with hasResultPropagation set to true.

       <configureActionInfoBlueprint xsi:type="customActionInfoBlueprint">
        <guid>055FB417-3C9F-43E9-BA9C-311533A8B1D3</guid>
        <hasResultPropagation>true</hasResultPropagation>
        <name>Discover Interface Id CustomerNetwork1</name>
        <condition>-EXISTS- container.zones['Zone 1'].nicSegments['Customer Network 1']</condition>
        <runtimeProps>
          <item>
            <key>macAddress</key>
            <value>${container.node.actions[Add NIC for Customer Network 1].results[macAddress]}</value>
          </item>
        </runtimeProps>
      </configureActionInfoBlueprint>

   2. Substitute the appropriate action name as the value for <key>.
      In case of multiple NIC segments, the administrator must specify the correct action name to point to the designated MAC address.

   3. Define a dummy unconfigureActionInfoBlueprint action as shown in the following code snippet:
      
      

       Click here to view the unconfigureActionInfoBlueprint action.

      <unconfigureActionInfoBlueprint xsi:type="mergeActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <name>Discover Interface Id CustomerNetwork1</name>
        <templateGroups>
          <item>Dummy</item>
        </templateGroups>
      </unconfigureActionInfoBlueprint>

      Note

      The Discover Interface Id does not require an unconfigureActionInfoBlueprint action. However, you must define this action only because of dynamic container design. The Dummy template does not configure anything and has an “!” in the template.

      
      Back to top

5. Configure the NIC IP address that you added in step 3 with the corresponding NIC segment IP pool's IP address as shown in the following code snippet:
   
   

    Click here to view the configure the NIC IP address action.

   <configureActionInfoBlueprint xsi:type="mergeActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <condition>-EXISTS- container.zones['Zone 1'].nicSegments['Customer Network 1']</condition>
     <description>Merge Action to configure Customer Network1</description>
     <name>Configure CSR1000V Router Customer Network 1</name>
     <templateGroups>
       <item>Configure CSR1000V Router Customer Network 1</item>
     </templateGroups>
   </configureActionInfoBlueprint>

   
   The preceding merge action uses the defined template name, which must use the correct substitution parameter to resolve the interface ID of the NIC to be configured.
   
   In the following command example, the results[interfaceId], substitution parameter resolves the interface ID captured in the Discover Interface Id CustomerNetwork1 action. In case of multiple NIC segments, the administrator must specify the correct action name in this substitution parameter to get the correct interface ID:
   
   

   ${container.nodes[CSR-Guest].actions[Discover Interface Id CustomerNetwork1].results[interfaceId]}

Back to top

Defining the container blueprint to configure CSR 1000V as a firewall

When CSR 1000V is used as a firewall, you must configure the added interfaces in their respective zones. When CSR 1000V is configured as a router node and a firewall node in the container, and points to the same underlying device, you need to define all the required configure actions of the firewall in the router’s virtual guest with the VFW –EXISTS- Condition.

When CSR 1000V is used as a firewall, perform the following steps:

1. Install the evaluation license as shown in the following code snippet.
   
   

   <configureActionInfoBlueprint xsi:type="customActionInfoBlueprint">
     <guid>4FB9F0C1-CC95-477A-BB34-CE61551EEBDF</guid>
     <name>Install CSR1000V Evaluation License</name>
     <runtimeProps/>
   </configureActionInfoBlueprint>

2. Reboot the device.
   
   

   <configureActionInfoBlueprint xsi:type="rebootActionInfoBlueprint">
     <name>Reboot</name>
   </configureActionInfoBlueprint>

   
   Back to top

3. Configure the CSR 1000V NIC interface to be a part of a security zone. Depending on Customer NIC Segments, you need to define configure actions with the respective condition so that if the VFW is enabled and the particular NIC segment is enabled, this action is triggered to put the interface inside the respective zone.
   
   

   <configureActionInfoBlueprint xsi:type="mergeActionInfoBlueprint">
     <name>Configure CSR1000V Customer Network 1</name>                  
     <condition>((-EXISTS- container.nodes['VFW']) -AND- (-EXISTS- 
      container.zones['Zone 1'].nicSegments['Customer Network 
      1']))</condition>
     <templateGroups>
       <item>Configure CSR1000V Customer Network 1</item>
     </templateGroups>
   </configureActionInfoBlueprint>

  Back to top

Installing the license for the firewall

CSR 1000V does not allow you to configure zone and zone-pairs without activating the license. To use CSR 1000V as security device, you must therefore, activate the license. During container creation, you cannot install a permanent license. As a result, you need to activate the evaluation license and install the permanent license after the container is created.

Use the following custom actions to install a permanent license.

• Get Device UDI: Fetches the UDI from the Cisco CSR 1000V device. The administrator must use this UDI to get the .lic file from the Cisco portal.
• Install License: Installs the .lic file on the CSR 1000V device. Before executing this action, the administrator must place the .lic file in the directory specified in the device agent transfer mode setting.

The configure actions in the containerHostBlueprint for the firewall include the actions required for activating the evaluation license and rebooting the device, which is required after you activate the license.

 Back to top

Preserving firewall rule sorting integrity in CSR firewalls

Cisco Cloud Services Router (CSR) firewalls are examples of zone-based firewalls that follow the (Zone-based firewall) ZFW model. See Zone-based firewalls in the BMC Network Automation documentation.

The CSR 1000V device does not allow you to control the logging behavior at a per-rule level. You can only control it at a per-class-block level by adding a parameter-map reference to its action specification, where the parameter-map specifies whether logging should be performed. This shortcoming is handled in BMC Network Automation by enabling logging for a class block whenever at least one rule within its access-list should use logging, otherwise it is not enabled.

When BMC Network Automation pushes out a list of firewall rules to a given zone pair within the CSR 1000V device, those rules must be specified within a policy map in the device. A given policy map is applied to a given zone pair, and defines what the firewall should do with packets that traverse that zone pair.

The following example shows a policy map and its constituents:

ip access-list extended MyAccessList1
    deny ip any host 1.0.0.99
    deny ip any host 1.0.1.99
ip access-list extended MyAccessList2
    permit ip any 1.0.0.0/24 
    permit ip any 1.0.1.0/24

class-map type inspect MyClassMap1
    match access-group name MyAccessList1
class-map type inspect MyClassMap2
    match access-group name MyAccessList2

policy-map type inspect MyPolicyMap
    class type inspect MyClassMap1
        drop
    class type inspect MyClassMap2
        inspect
    class class-default
        drop

This policy map permits packets destined for either the 1.0.0.0/24 or the 1.0.1.0/24 subnets, unless the destination host is 1.0.0.99 or 1.0.1.99, in which case the packets are denied. All other packets are denied.

Consider another example, with the following original list of sorted rules in BMC Network Automation which must be applied to a given zone pair:

Here SSH packets destined for the 10.0.0.0/24 subnet should be denied, unless they are destined for the host at 10.0.0.1, in which case they should be permitted. SSH packets destined for the 10.0.1.0/24 subnet should be permitted, unless they are destined for a host at 10.0.1.1 or 10.0.1.2, in which case they should be denied. If you map this single list of rules to multiple lists of rules within a policy map, you have the following policy map:

ip access-list extended MyAccessList1
    permit tcp any 10.0.0.1 eq ssh
ip access-list extended MyAccessList2
    deny tcp any 10.0.1.1 eq ssh
    deny tcp any 10.0.1.2 eq ssh
ip access-list extended MyAccessList3
    permit tcp any 10.0.1.0/24 eq ssh
ip access-list extended MyAccessList4
    deny tcp any 10.0.0.0/24 eq ssh

class-map type inspect MyClassMap1
    match access-group name MyAccessList1
class-map type inspect MyClassMap2
    match access-group name MyAccessList2
class-map type inspect MyClassMap3
    match access-group name MyAccessList3
class-map type inspect MyClassMap4
    match access-group name MyAccessList4

policy-map type inspect MyPolicyMap
    class type inspect MyClassMap1
        inspect
    class type inspect MyClassMap2
        drop
    class type inspect MyClassMap3
        inspect
    class type inspect MyClassMap4
        drop
    class class-default
        drop

With this mapping, the effective sorting of the original list of rules in BMC Network Automation is successfully preserved.

 Back to top

Sample pod and container blueprints

You can find sample pod and container blueprints and related templates in the BCAN_HOME\public\bmc\bca-networks\csm\samples\sampleWithCSR1000V directory on the BMC Network Automation application server. For additional information about the sample pod and container blueprints for use with a Cisco CSR 1000V router, see Pod model and Container model.

Back to top