Appendix B. Sample Configurations
This appendix is intended to give you a head start in the transformation to IBN by providing pieces of configuration that can be used for IBN. This appendix does not provide a full configuration for a campus switch; the Cisco Validated Designs for non-fabric campus networks are more suitable for that. However, this appendix does provide pieces of configuration for an Intent-Based Networking design using classic VLAN. It should give you enough information to get started. This appendix does not include sample configurations for an SDA-based deployment because Cisco DNA Center is required to design and deploy Software-Defined Access.
Throughout this appendix the concept of variables is used to allow for the process of creating generic templates. The concept of variables is very common (and foundational) to programming languages and computer science in general. A variable is an identifiable storage location (often in memory) where dynamic values (such as user input) can be stored. The identification of a variable is more commonly known as the variable name. The best practice for variable names is that the name help the developer in identifying the purpose of the variable. In this appendix variables are prefixed with the $ sign and provide a description of what value can be used, such as $VLANId for the VLAN Identifier or $VTPPassword for the VTP password.
The sections that follow describe configuration examples for a classic VLAN-based approach to IBN. A classic VLAN approach to IBN is based on the concept of having a static campus foundation configuration (so that automation can deploy changes with minimal impact) with the Intents dynamically added or removed via the automation process. These configuration examples are based on Cisco IOS-XE 16.6 and higher configuration syntax. You should always refer to the appropriate configuration guide for guidance on how features are deployed and configured.
Design
Figure B-1 displays the design of a (simple) Intent-enabled campus network using classic VLANs. The design is based on the traditional two-tier hierarchical campus network with a distribution switch in the main equipment room and multiple access switches in the wiring closets. For simplicity, this campus network consists of one distribution switch and one access switch. IEEE 802.1X is used within IBN to provide authentication and authorization of the different intents. The specific configuration for IEEE 802.1X and the corresponding RADIUS server is not included in this appendix.
Figure B-1 Sample Campus Network Used for Classic VLAN Deployment
This campus design is based on the following design principles:
The distribution switch is configured with StackWise Virtual (or VSS for an IOS deployment). The minimal configuration of the distribution switch is executed manually, because StackWise Virtual is not compatible with Cisco Network PnP.
Access switches are provisioned with a bootstrap (minimal) configuration using Cisco Network PnP.
Access switches receive a management IP address dynamically from the distribution switch.
Access switches provide Layer 2 functionality and the link between connected endpoint and the distribution switch.
The uplink from an access switch to the distribution switch is always PortChannel1, whether the switch has one or two uplinks.
Spanning Tree Protocol is disabled, storm control is used to restrict broadcast storm traffic, and BPDUGuard is used to shut down a port on which any Spanning Tree packet is received.
VLANs in the range 2000–2199 are used for the different network intents.
VTP Version 3 is used to distribute VLANs across the campus network.
Dynamic VLAN assignment is used for assigning an endpoint to a specific VLAN (virtual network).
VRF-Lite is used to logically separate different virtual networks from the foundation.
The WAN router provides a default route for every virtual network (VRF-Lite/VPN) that is deployed onto the network.
Each virtual network for clients will also have a dedicated uplink-VLAN with IP connectivity between the WAN router and the distribution switch.
Foundation Configuration
One of the key designs of IBN using classic VLANs is the concept of a foundation configuration. This foundation configuration is effectively a minimal configuration on the switches that remains static. Its purpose is to allow the automation tool to automatically add and remove intents on the network. The sections that follow describe the foundation configuration examples for the distribution switch and the access switches based on the design described previously.
Distribution Switch
In this sample design and configuration for an Intent-Based Network, the distribution switch is used for Layer 3 connectivity of that location. The distribution switch is based on a VSS pair of two physical switches to which access switches are connected. Its foundation configuration contains the minimum configuration for network management access to the distribution switch, Network PnP functionality, and connectivity to the access switches. Example B-1 shows the foundation configuration required for a distribution switch, excluding the configuration of VSS or StackWise Virtual, which is switch platform specific. Standard shared configuration, such as AAA, Syslog, SNMP, and SSH access are also excluded from this sample configuration.
Example B-1 Foundation Configuration for Distribution Switch
! Layer2 configuration
!
vtp version 3
vtp mode server
vtp password $VTPPassword
vtp domain samplecompany.com
vlan $MgmtVLANId
name management
!
! Disable spanning-tree
!
no spanning-tree vlan 1-4096
spanning-tree portfast bpduguard default
!
! DS L3 configuration
!
interface Vlan$MgmtVLANId
vrf forwarding definition vrf-Management
ip address $MgmtIPAddress $IPNetmask
!
! Uplink configuration
!
vlan $MgmtUplinkId
name uplink-management
!
interface Vlan$MgmtUplinkId
vrf forwarding vrf-Management
ip address $UplinkIPAddress 255.255.255.252
!
interface $WANRouter
switchport trunk encap dot1q
switchport mode trunk
switchport trunk allowed vlan add $MgmtVLANId
!
! Routing configuration
!
router bgp $ASNumber
address-family ipv4 vrf vrf-Management
network $IPNetwork mask $IPNetmask
neighbor $WANRemotePeerIP remote-as $ASWANRouter
neighbor $WANRemotePeerIP activate
exit-address-family
!
! Network PnP configuration
!
ip dhcp excluded-address $MgmtIPAddress
ip dhcp pool pnp-pool
network $MgmtIPNetwork $MgmtIPNetmask
dns-server $DNSServer1 $DNSServer2
option 43 ascii "5A1N;B2;K4;I$DNACIPAddress;J80"
domain-name samplecompany.com
default-gw $MgmtIPAddress
!
pnp startup-vlan $MgmtVLANId
The configuration in Example B-1 leverages variables to allow for different deployment scenarios. The following variables are used in this template:
$VTPPassword: The VTP password for this site
$MgmtVLANId: The management VLAN Identifier
$DNACIPAddress: The IP address of DNA Center or other PnP server
$MgmtIPAddress: IP address of the distribution switch in the management VLAN
$IPNetmask: IP Netmask of the management network, usually 255.255.255.0
$WANRouter: The physical interface name to which the router is connected
$MgmtUplinkId: The VLAN Identifier for the uplink VLAN between the distribution switch and the WAN router
$WANRemotePeerIP: IP address of WAN router in Management VPN
$ASWANRouter: AS number of WAN router
$ASNumber: The AS number for BGP routing of specific location
$DNSServer1 and $DNSServer2: IP addresses for the DNS servers that are used for network PnP
The preceding configuration template is generic for the distribution switches on all locations that are Intent-enabled. The only site-specific foundation configuration is dependent on the number of access switches and a potential wireless LAN controller. Example B-2 shows the configuration of the port-channel configuration for the distribution switch.
Example B-2 Configuration of Port-Channel from Distribution Switch to Access Switch
interface $Downlink1AS1 channel-group $PortId mode active interface $Downlink2AS2 channel-group $PortId mode active interface PortChannel$PortId description downlink to AS1 switchport mode trunk switchport mode dynamic desirable !
The configuration in Example B-2 sets the trunk interface to desirable, so that network PnP (which uses an access port) is allowed access and so that communication from the access switch to the PnP server can occur. The following variables are used:
$PortId: The port-channel identifier, starting with 11 upwards. (PortChannel1 and PortChannel2 should be reserved for VSS.)
$Downlink1AS1: The first physical interface to which AccessSwitch 1 (AS1) is connected.
$Downlink2AS1: The second physical interface to which AccessSwitch 1 (AS1) is connected.
These variables should be extended to the number of access switches in a specific campus location where the numbering is increased, for example, $Downlink1AS10 describing the first downlink for access switch 10.
Access Switch
Within this topology and design, the access switches are used to connect endpoints to the Intent-Based Network.
The access switches are Layer 2 switches and within IBN have effectively the same configuration except devicename and IP address for management. Because network PnP is used for the initial provisioning of an access switch, the remaining foundation configuration for an access switch is rather short. Example B-2 shows the foundation configuration for an access switch. This configuration should be appended to the bootstrap configuration, which is described in the next paragraph. It includes the necessary configuration for RADIUS authentication (IEEE 802.1X Network Access Control), as well as specific security policies related to Switch Integrated Security Features (SISF).
Since the introduction of Cisco IOS-XE 16.3, several switch security features related to Layer 2 security, such as IP Device Tracking, Dynamic ARP Inspection, and DHCP Snooping, are combined into a single policy-based configuration model. SISF is implemented in an on-demand design, which means that as soon as a different feature within the switch that depends on SISF is configured, SISF is enabled and started. The default policy for SISF is the assumption that all Ethernet ports are configured as access ports, which can lead to unexpected behavior on uplink ports. Example B-3 and Example B-4 also contain sample configurations of SISF and several security features for first-hop security.
Example B-3 Foundation Configuration for an Access Switch
! ! AAA Radius configuration ! radius-server attribute 6 on-for-login-auth radius-server attribute 6 support-multiple radius-server attribute 8 include-in-access-req radius-server attribute 25 access-request include radius server $RadiusServerName address ipv4 $RadiusIPAddress auth-port 1812 acct-port 1813 key 0 $RadiusSharedSecret ! aaa group server radius aaa-servers server name $RadiusServerName aaa authentication dot1x default group aaa-servers aaa authorization network default group aaa-servers aaa accounting dot1x default group aaa-servers ! ! enable dot1x ! dot1x system auth-control ! ! DOT1X authentication order ! policy-map type control subscriber DOT1X-MAB event session-started match-all 10 class always do-all 10 authenticate using dot1x priority 10 20 authenticate using mab priority 20 ! ! SISF uplink policy ! device-tracking policy DT-Uplink trusted-port device-role switch no protocol udp ! interface PortChannel1 device-tracking attach-policy DT-Uplink ip arp inpsection trust ip arp inpsection trust storm-control broadcast level 0.05 storm-control multicast level 0.05 storm-control action shutdown !
Because within IBN the specific access policy for an access port is downloaded based on the identity (and authorization) of the endpoint connected to it, the configuration of each access port on an access switch is the same. Example B-4 displays the standard configuration of an access port and should be part of the foundation configuration.
Example B-4 Sample Default Configuration for Access Port
interface $interfaceName description standard access port switchport mode access switchport nonegotiate switchport access vlan $IsolatedVlanId storm-control broadcast level 0.05 storm-control multicast level 0.05 storm-control action shutdown no cdp enable mab dot1x pae authenticator access-session host-mode single-host access-session control-direction in access-session port-control auto service-policy type control subscriber DOT1X-MAB ip arp inspection limit ip dhcp snooping limit rate 25 !
This access port configuration should be deployed to all interfaces on each access switch. Because each access switch can have different port numbers, the programmatic capabilities of the network PnP server could be used to apply this template to all ports. Alternatively, it is possible to use the Cisco Embedded Event Manager (EEM) to configure all Ethernet ports using the template in Example B-4. Several examples exist on the Internet that demonstrate these kinds of capabilities.
Bootstrap Configuration
You can use the configuration in Example B-5 to provision new access switches with a configuration that allows the access switch to be discovered by the network management system (NMS) and enable the NMS to push the baseline configuration to the access switch.
Example B-5 Sample Bootstrap Configuration for Network PnP
hostname $HostName ! ! VTP Configuration ! vtp version 3 vtp mode client vtp password $VTPPassword vtp domain samplecompany.com ! ! AAA Authentication ! aaa new-model aaa authentication login default local aaa authorization exec default local username $NMSUsername priv 15 secret 0 $NMSPassword service password-encryption ! vlan $MgmtVLANId name ManagementVLAN ! ! SNMPv3 configuration ! snmp-server group SNMP-MGMT v3 auth read SNMP-VIEW write SNMP-VIEW snmp-server group SNMP-MGMT v3 priv read SNMP-VIEW write SNMP-VIEW snmp-server view SNMP-VIEW iso included snmp-server user $NMSUsername SNMP-MGMT v3 auth sha $SNMPShaPassword priv aes 128 $SNMPAESPassword snmp-server trap-source Vlan$MgmtVLANId snmp-server source-interface informs Vlan$MgmtVlan snmp-server host $NMSIPAddress version 3 priv nms ! logging host $NMSIPAddress logging source-interface Vlan$MgmtVLANId ! service password-encryption ! ip ssh time-out 60 ip ssh version 2 line con 0 exec-timeout 20 0 logging synchronous line vty 0 15 exec-timeout 20 0 logging synchronous transport input ssh telnet ! ! Uplink configuration, native VLAN is MgmtVLAN for Network PnP assignment interface $Uplink1 switchport mode trunk switchport trunk native vlan $MgmtVlan channel-group 1 mode on interface $Uplink2 switchport mode trunk channel-group 1 mode on switchport trunk native vlan $MgmtVlan ! interface po1 ! Set Switchport desirable for Network PnP to keep connectivity switchport mode dynamic desirable ! crypto key generate rsa mod 4096 ! ! SVI configuration int vlan1 shutdown int vlan$MgmtVlan ip add dhcp remember no shut !
Example B-5 uses the following variables that are to be entered when provisioning a new access switch:
$HostName: Hostname of the new switch
$VTPPassword: Password for the VTP Version 3 domain
$NMSUserName: Username used for the Network Management System (NMS) to log in
$NMSPassword: Password for the NMS username
$MgmtVLANId: VLAN Identifier for the management VLAN
$SNMPShaPassword: SHA secret for SNMPv3 communication of the NMS
$SNMPAesPassword: AES secret for SNMPv3 communication of the NMS
$NMSIPAddress: IP address of Network Management System
$Uplink1: Physical interface 1 connected to the distribution switch
$Uplink2: Physical interface 2 connected to the distribution switch
Virtual Network Templates
A key part of IBN is to be able to deploy Intents onto the campus network. The most common network Intent that is deployed is a new virtual network. Example B-6 describes a template to deploy a new virtual network onto the network. This template is based on a single VLAN being added to the network and to bind that specific VLAN to a new VRF for the Layer 3 isolation for that new virtual network.
Example B-6 Template of New Virtual Network for the Distribution Switch
! VLAN configuration
vlan $VLANId
name $VLANName
!
! VRF definition
vrf definition vrf-$VLANName
address-family ipv4
exit-address-family
!
! SVI configuration
!
interface vlan$VLANId
vrf forwarding $VRFName
ip address $IPAddress $IPNetmask
ip helper-address $DHCPServer1 $DHCPServer2
!
! WAN connectivity configuration
! VLAN for peering with WAN router
vlan $UplinkVLANId
name uplink-$VLANID-$VLANName
!
interface vlan $UplinkVLANId
ip address $IPUplinkAddress 255.255.255.252
no shutdown
description link to WAN router
!
interface $WANRouter
switchport trunk allowed vlan add $peerVLAN
!
! Routing configuration
!
router bgp $ASNumber
address-family ipv4 vrf vrf-$VLANName
network $IPNetwork mask $IPNetmask
neighbor $WANRemotePeerIP remote-as $ASWANRouter
neighbor $WANRemotePeerIP activate
exit-address-family
!
This template uses the following variables to allow the Intent to be specified:
$VLANId: VLAN identifier for the new network service
$VLANName: A logical name for the VLAN
$IPAddress: IP address of the default gateway for this new virtual network
$IPNetmask: Netmask for this new virtual network
$IPNetwork: IP network for this new virtual network
$DHCPServer1 and $DHCPServer2: IP addresses of the DHCP servers that will provide IP settings to the clients
$UplinkVLANId: VLAN used to set up peering with the WAN router
$IPUplinkAddress: IP address of the distribution switch in the uplink network
$ASNumber: AS number used in this campus location for the BGP configuration
$WANRemotePeerIP: IP address of the WAN router for the UplinkVLAN
With this template, a new virtual network can easily be provisioned on the distribution switch. Because VTP version 3 is used to distribute VLANs automatically, the access switch will receive that new VLAN once this template is deployed onto the distribution switch. If, for example, the new virtual network would be a dedicated Layer 2 network (with no IP connectivity), example B-6 can be adjusted to remove all Layer 3 IP information.
Removing a virtual network has a similar template structure, where the VLAN and necessary information are not created but rather removed. Example B-7 shows a template that can be used to remove a virtual network.
Example B-7 Sample Template to Remove a Virtual Network
! Remove BGP configuration router bgp $ASNumber no address-family ipv4 vrf vrf-$VLANName ! ! Remove L3 SVI's ! no interface $UplinkVLANId no interface $VLANId ! ! Remove VRF ! no vrf definition vrf-$VLANName ! ! Finally, remove L2 VLAN's no vlan $UplinkVLANId no vlan $VLANId !
The template in Example B-7 uses the following variables to remove a virtual network:
$VLANId: VLAN identifier for the new network service
$VLANName: Logical name for the VLAN
$UplinkVLANId: VLAN used to set up peering with the WAN router
$ASNumber: AS number used in this campus location for the BGP configuration