Cisco ISR Project – vWAAS deployment (14 of ?)

Posted on February 27, 2019February 9, 2023 by Dan Kelcher

(I just noticed that I forgot to publish this, so anyone reading my posts on IWAN deployment… Sorry this one’s a few years late…)

To get the WAAS deployment done there are a few prerequisites:

Virtual Central Manager (vCM) deployed (at HQ)
vWAAS appliance deployed (at HQ)
vWAAS appliance deployed (at branch)
WAN connectivity between branch and HQ

A couple things to be aware of right off the bad:

Default username is: admin
Default password is: default
Telnet is enabled by default, and SSH is disabled.

To enable SSH run these commands from a config prompt (make sure hostname and domain are set before running)

ssh-key-generate
sshd enable

Telnet can be disabled, however, it seems the management software

When logging into the web interface if there is a prompt to select an SSL certificate, click Cancel. That should bring up the login page.

After the OVA has been deployed you should be able to log into the appliance and it should automatically start the device configuration. If not simply enter the ‘setup’ command.

The setup between the vCM and vWAAS is pretty similar, so I’m just going to go over the vWAAS as there are more of those. However, the vCM does need to be configured before the vWAAS, as the vWAAS needs to connect to the vCM.

WAAS setup

The setup is text-based, and pretty straightforward. One thing to be aware of is if the CMS service fails to start (I set up vWAAS up without setting the correct vNIC settings) you can run the command ‘cms enable’ from a config prompt. That should force the vCM to start, or force a vWAAS appliance to register with the vCM.

After completing the setup a window will pop up with a list of commands to configure WCCP on the router.

WCCP template

To make things easier, here’s a text version of the commands:

ip wccp version 2

ip wccp 61 (optional:waas-wccp-redirect-list)

ip wccp vrf IWAN-PRIMARY/SECONDARY 62 (optional:waas-wccp-redirect-list)

interface (Router LAN interface(s))

ip wccp 61 redirect in

interface (Router WAN interface(s))

ip wccp vrf IWAN-PRIMARY/SECONDARY 62 redirect in

interface (Router NM-WAE interface)

ip wccp redirect exclude in

(optional:

ip acces-list extended waas-wccp-redirect-list

acl1

acl2

….

aclN

)

One thing that isn’t covered in this default config is the ISR uses VRFs for the WAN interface(s). For the WAN interface enter the correct VRF and then the commands should work.

Links:

WAAS: http://www.cisco.com/c/en/us/td/docs/app_ntwk_services/waas/waas/v611/configuration/guide/cnfg/traffic.html

Prime: http://www.cisco.com/c/en/us/td/docs/net_mgmt/prime/infrastructure/3-0/user/guide/pi_ug/WAAS.html

Cisco ISR Project – Cloud Web Security config (13 of ?)

Posted on July 27, 2016February 9, 2023 by Dan Kelcher

In our deployment each location will have a dedicated internet connection. Since we want to restrict access to specific URLs (sorry, no porn, no Netflix, and no Facebook) we need each location to have a filter in place. However, that seems cumbersome to manage. It would be nice to have a centralized management point for all locations, as they will all have the same policy.

Enter Cisco Cloud Web Security. There is an ISR connector that routes all web traffic through Cisco datacenters where traffic policies are applied. First things first, this is a subscription-based service, so a subscription must be purchased. Once that is done and the account is set up (the purchaser will receive a couple e-mails on account creation and provisioning) then it’s time to get things moving.

Before starting the configuration two things must be done. A company key needs to be created, and a certificate needs to be downloaded. To create the key log in to the CWS portal and click the Admin tab, then in the menu bar select Management, and then click Company Key.

Company Key

Make sure you store the company key in a secure location. If you lose it you will need to revoke and regenerate it, which means that all devices will also need to be reconfigured.

There should also be an e-mail sent with a certificate that must be installed on the router to establish the CWS tunnel.

Now on to the actual configuration. You will need to have the following information handy:

CWS certificate
LAN subnet
Tower 1 IP
Tower 2 IP
Company key

First, the certificate install. From a config prompt run these commands:

crypto pki trustpoint cws-trustpoint
revocation-check none
enrollment terminal
exit
cry pki authenticate cws-trustpoint

It will prompt you to enter the certificate. Paste in the certificate (including the Begin and End lines). After the certificate enter a blank line and then hit the Enter key. It should then prompt to accept the new certificate.

The next step is to create a couple ACLs. The first is a simple ACL to specify the source LAN, and the second is a whitelist of IP addresses to avoid CWS.

access-list 80 permit 1.2.3.4 0.0.0.0

ip access-list extended cws-whitelist
permit tcp any 10.0.0.0 0.255.255.255
permit tcp any 172.16.0.0 0.31.255.255
permit tcp any 192.168.0.0 0.0.255.255

Make sure to enter the correct LAN subnet in ACL 80. If there are any additional IPs that should be added to the whitelist then add them to the cws-whitelist ACL.

Next is importing the Cisco CWS certificate from Cisco. This does require external access and DNS to be configured on the router. Here’s the command for that import:

crypto pki trustpool import url http://www.cisco.com/security/pki/trs/ios_core.p7b

Now comes the actual CWS tunnel configuration:

parameter-map type cws-tunnel global
primary
tower ipv4 1.2.3.4
secondary
tower ipv4 1.2.3.4
license 0 123123123123
redirect-list 80
whitelist
download interval 10
acl name cws-whitelist
fail-open

Make sure to set the correct Tower IPs, and enter the Company Key that was generated through the CWS portal. One thing to be aware of is the “fail-open” line. This line configures the router to allow all web traffic if there is a CWS failure. This can be configured to drop all traffic by changing it to “fail-close”

Almost done, the next step is to set the inbound and outbound interfaces for the tunnel.

int gi0/0/0cws-tunnel in

int gi0/0/1cws-tunnel out tunnel-number 150

For each interface (and sub-interface) that will have end-user traffic that needs to be filtered use the “cws-tunnel in” command. For the outbound connection the tunnel number must be specified. This will automatically create two tunnels, one for the tunnel number specified, and another tunnel that is incremented by 1. In the example above tunnel 150 would be created as primary, and tunnel 151 would be created as a backup. The primary tunnel uses the destination of Tower 1, and the backup uses the Tower 2 IP.

Last comes some commands to make CWS play nice with the IWAN configuration that’s been done so far. Since there are VRFs, and ZBF rules there are some extra steps.

Configure the IKE profile to use the IWAN-SECONDARY VRF:

crypto ikev2 profile cws_ikev2_profile_150
match fvrf IWAN-SECONDARY

Create a route map for routes back to the inside network:

route-map INET-Internal permit 10
description Return routing for Local Internet Access
match ip address InternalNetworks
set global

The last step is to apply the VRF, route map, and zone membership.

interface Tunnel150
description CWS connector internal primary tunnel
ip vrf forwarding IWAN-SECONDARY
tunnel vrf IWAN-SECONDARY
zone-member security Internet
ip policy route-map INET-Internal

interface Tunnel151
description CWS connector internal secondary tunnel
ip vrf forwarding IWAN-SECONDARY
tunnel vrf IWAN-SECONDARY
zone-member security Internet
ip policy route-map INET-Internal

Running the command “show cws-tunnel status” should show the tunnel as being UP-ACTIVE

From a client machine you should be able to browse to http://whoami.scansafe.net and see the correct Company name.

Cisco ISR Project – Internet failover config network config (12 of ?)

Posted on June 23, 2016February 9, 2023 by Dan Kelcher

Each office will have their own internet connection, but in the event that connection fails the desire is to have branches backhaul internet access over the MPLS to the data center. Since there is the possibility that the internet failure is located somewhere other than between the branch ISR and the ISP device there needs to be a method to verify connectivity. Enter the IP SLA commands.

The following commands will set this up. First, the actual IP SLA command. The SLA is created, a request type, target, and source is specified, the VRF is specified, then threshold and frequency are set. The threshold is how many milliseconds pass before marking the link is down. The frequency is how often the requests are sent.

ip sla 11

icmp-echo 8.8.8.8 source-interface GigabitEthernet0/0/1

vrf IWAN-SECONDARY

threshold 2500

frequency 15

ip sla 12

icmp-echo 8.8.4.4 source-interface GigabitEthernet0/0/1

vrf IWAN-SECONDARY

threshold 2500

frequency 15

ip sla 13

icmp-echo 4.2.2.2 source-interface GigabitEthernet0/0/1

vrf IWAN-SECONDARY

threshold 2500

frequency 15

ip sla 14

icmp-echo 198.41.0.4 source-interface GigabitEthernet0/0/1

vrf IWAN-SECONDARY

threshold 2500

frequency 15

ip sla 15

icmp-echo 198.41.0.4 source-interface GigabitEthernet0/0/1

vrf IWAN-SECONDARY

threshold 2500

frequency 15

As you can see, there are five listed. Two are Google DNS servers, one is a Level3 DNS server, and the last two are root DNS servers. I chose five because I thought it was enough to confirm an actual internet outage, but not so many as to bog the system down with requests.

The next step is to schedule the SLA commands to run. The commands are pretty self-explanatory. Run forever, start now.

ip sla schedule 11 life forever start-time now

ip sla schedule 12 life forever start-time now

ip sla schedule 13 life forever start-time now

ip sla schedule 14 life forever start-time now

ip sla schedule 15 life forever start-time now

Now the important part comes in. Just because we are running these commands doesn’t mean much. We want to track the reachability. The following commands do just that.

track 11 ip sla 11 reachability

track 12 ip sla 12 reachability

track 13 ip sla 13 reachability

track 14 ip sla 14 reachability

track 15 ip sla 15 reachability

Next is creating a list of these SLAs. Then setting a threshold. In this command if half the sites are down the group is marked as down.

track 10 list threshold percentage

object 11

object 12

object 13

object 14

object 15

threshold percentage down 49 up 50

The last step is to actually put this into use. The route from the default VRF needs to be removed and replaced with the same command, but with the track command added.

no ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0/1 ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0/1 Next_Hop_IP track 10

Now, if the tests to the external sites fail the default route is removed. Then, a default route can be learned through EIGRP to route back through the data center to get out to the internet.

Here are a couple commands for troubleshooting:

show ip route track-table

show ip sla summary

The other side to this is configuring the data center router to advertise the default route. First, create an ACL to define the default route.

ip access-list standard DEFAULT-ONLY

permit 0.0.0.0

Then create a route map that includes the previously created ACL.

route-map STATIC-IN permit 10

description Redistribute local default route

match ip address DEFAULT-ONLY

Finally, add the route map to the EIGRP redistribution

router eigrp IWAN-EIGRP

address-family ipv4 unicast autonomous-system 400

topology base

redistribute static route-map STATIC-IN

exit-af-topology

exit-address-family

If all went according to plan then a failure in the branch internet service should remove the default route, and then EIGRP should propagate the new default route.

Cisco ISR Project – Guest network config (11 of ?)

Posted on May 20, 2016February 9, 2023 by Dan Kelcher

Since offering a Guest Wifi network has become a pretty standard practice it’s something that will be added to the ISRs at the branch locations. However, since this is a guest network it is untrusted and should not have access to the internal network.

The first step is to create a VRF for the guest network. This will prevent traffic from the guest network from ever being exposed to the routes to the internal network.

vrf defInition IWAN-Guest

address-family ipv4

exit-address-family

The guest machines will require DHCP, so the router will be configured to hand out IPs. For the DHCP range the 192.168.254.0 was selected, and the IPs from 1 to 19 are excluded. The Google DNS server at 8.8.8.8 is set as the guest DNS server.

ip dhcp excluded-address vrf IWAN-Guest 192.168.254.1 192.168.254.19

ip dhcp pool IWAN-Guest

vrf IWAN-Guest

network 192.168.254.0 255.255.255.0

default-Router 192.168.254.1

dns-server 8.8.8.8

Next comes the class maps for traffic filtering. We are going to allow DHCP and ICMP between the router and the guest network, as well as allow outbound traffic. Based on the security needs ICMP can be removed, and the protocols allowed outbound can be restricted.

class-map type inspect match-any Guest-RTR-ICMP

match access-group name Guest-ICMP-In

class-map type inspect match-any RTR-Guest-ICMP

match access-group name Guest-ICMP-Out

class-map type inspect match-any Guest-RTR-DHCP

match access-group name Guest-DHCP-In

class-map type inspect match-any RTR-Guest-DHCP

match access-group name Guest-DHCP-Out

class-map type inspect match-any Guest-Outside-Class

match protocol dns

match protocol http

match protocol https

match protocol ftp

match access-group name Guest-Out

The policies are configured to pass DHCP traffic and inspect everything else.

Policy-map type inspect Guest-Outside-Policy

class type inspect Guest-Outside-Class

inspect

class class-default

drop

Policy-map type inspect Guest-Self-Policy-In

class type inspect Guest-RTR-DHCP

pass

class type inspect Guest-RTR-ICMP

inspect

class class-default

drop

Policy-map type inspect Guest-Self-Policy-Out

class type inspect RTR-Guest-DHCP

pass

class type inspect RTR-Guest-ICMP

inspect

class class-default

drop

A zone will need to be created for the guest network

zone security Guest

The new zone will need to be configured to communicate with the router and internet zone, and the policies will need to be applied

zone-pair security Guest-Router source Guest destination self

service-Policy type inspect Guest-Self-Policy-In

zone-pair security Router-Guest source self destination Guest

service-Policy type inspect Guest-Self-Policy-Out

zone-pair security Guest-Internet source Guest destination Internet

service-Policy type inspect Guest-Outside-Policy

Next the guest interface will be created. The VLAN 999 is being assigned for the guest network, and so a correlating subinterface will be created. The IP used here needs to match the default gateway that was set earlier in the DNS settings

interface GigabitEthernet0/0/0.999

description Guest-Network

encapsulation dot1Q 999

vrf forwardIng IWAN-Guest

ip address 192.168.254.1 255.255.255.0

ip nat inside

zone-member security Guest

Then a NAT statement is required to translate addresses.

ip nat inside source route-map NAT-Guest interface GigabitEthernet0/0/1 vrf IWAN-Guest overload

A static route is needed to allow access to the outside network.

ip Route vrf IWAN-Guest 0.0.0.0 0.0.0.0 GigabitEthernet0/0/1

A route map was used in the NAT statement to identify inside machines, so that route map needs to be created

Route-map NAT-Guest permit 10

match ip address Guest-Internet

match interface GigabitEthernet0/0/1

Lastly, we will create the ACLs. Again, these ACLs can be adjusted to restrict traffic as needed.

ip access-list extended Guest-DHCP-In

permit udp any eq bootpc any eq bootps

!

ip access-list extended Guest-DHCP-Out

permit udp any eq bootps any eq bootpc

!

ip access-list extended Guest-ICMP-In

permit icmp any any echo

permit icmp any any echo-reply

!

ip access-list extended Guest-ICMP-Out

permit icmp any any echo

permit icmp any any echo-reply

!

ip access-list extended Guest-Internet

deny ip 192.168.254.0 0.0.0.255 192.168.0.0 0.0.255.255

deny ip 192.168.254.0 0.0.0.255 172.16.0.0 0.15.255.255

deny ip 192.168.254.0 0.0.0.255 10.0.0.0 0.255.255.255

permit ip 192.168.254.0 0.0.0.255 any

!

ip access-list extended Guest-Out

permit ip 192.168.254.0 0.0.0.255 any

Now all that is needed is to assign the Guest SSID to VLAN 999 and configure switch ports accordingly.

Cisco ISR Project – NAT rules (10 of ?)

Posted on May 20, 2016February 9, 2023 by Dan Kelcher

With the traffic rules in place next will come getting NAT rules set up. In a nutshell Network Address Translation (NAT) is what converts internal IPs to public IPs, which allows internal machines to communicate on the internet.

With the IWAN design part of what I want to accomplish is to allow any internal site to be able to route through to another site in the event of an ISP failure. To accomplish this the scope of the NAT rules will be expanded to cover all private IP ranges. Getting NAT set up is pretty simple, though there are a number of steps.

Define inside and outside interfaces
Create ACL to define source machines
Create route map for source machines
Create NAT statement
Create an ACL for traffic destined for inside
Create route map to route traffic from internet to inside
Apply the route map to the outside interface
Create default route outbound

The NAT config will all be done via CLI, and it will all be from a config prompt.

The NAT inside interface would be the interface connected to the private side of your network, and the outside would be facing the public interface. This is where the address translation will be taking place. The interfaces in red may need to be modified to match your deployment.

int gi0/0/0 ip nat inside

int gi0/0/1 ip nat outside

The next step is creating the ACL to define all inside networks. Adjust this as needed.

ip access-list extended Inside_IPs

permit ip 10.0.0.0 0.255.255.255 any

permit ip 172.16.0.0 0.15.255.255 any

permit ip 192.168.0.0 0.0.255.255 any

Then a route map is created with the previous ACL and the interface being used.

route-map NAT-Inside permit 10

match ip address Inside_IPs

match interface GigabitEthernet0/0/1

Next would be NAT statement. In it we specify that traffic from the inside interface that matches the route map is translated to the outside interface (and uses the IP of that interface), and “overload” means that it will be a many-to-one NAT. Since it is many-to-one we are allowing multiple inside machines to use the single outside IP, and the router tracks the traffic by altering the source port and matching the return traffic.

ip nat inside source route-map NAT-Inside interface GigabitEthernet0/0/1 overload

That concludes the actual NAT portion, but without the related routing it really doesn’t help. So there are two routes that are needed. One to get the traffic out and the other to get traffic back in. We’ll start with the return traffic. First we need a ACL to define the traffic coming back in.

ip access-list extended InternalNetworks

permit ip any 10.0.0.0 0.255.255.255

permit ip any 172.16.0.0 0.15.255.255

permit ip any 192.168.0.0 0.0.255.255

Then we create a route map for it.

route-map Internet-Internal permit 10

description Return routing for Local Internet Access

match ip address InternalNetworks

set global

That route map is then applied to our external interface

interface GigabitEthernet0/0/1

ip policy route-map Internet-Internal

The last step is to create the default route from the inside to get to the outside.

ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0/1 Next_Hop_IP

Now internal machines should have internet access. Here are a few commands that help with troubleshooting if there are issues:

show ip nat translation (shows current NAT translations)

clear ip nat translation * (clears all current translations, which is helpful if the NAT statement needs to be changed.)

Cisco ISR Project – Router access rules (9 of ?)

Posted on May 20, 2016February 9, 2023 by Dan Kelcher

Now that most connectivity has been configured the next step will be creating access rules to restrict access as needed, as well as grant access where needed. This is going to primarily apply to the branch routers, but the HQ routers can (and should) be configured similarly.

Before we get into what that means let’s cover how this is going to work.

Much to my chagrin, gone are the days of the “permit any any established” rules. Those have been replaced with packet inspection to perform the stateful firewall feature. What this means is that inbound packets are inspected to see if they match an existing outbound flow. If the traffic is part of an established flow then it is allowed. If not, then it’s dropped.

This gets a bit more complicated with the addition of the Zone-based Firewall (ZBF) in the ISR. Instead of applying rules to the interface they are applied to the zone pairs.

Here’s the high level flow.

Class maps are created (and specify ACLs as needed)
Policy maps are created (and specify class maps as needed)
Security zones are created
Zone pairs are created, with source and destination specified, then the policy map is applied
Interfaces are assigned to security zones
ACLs are created for traffic definitions

Maybe a diagram will help. This diagram shows the commands needed to allow traffic to flow from the inside IP range of 10.0.0.0/8 from the inside interface Gi0/0/0 to any IP on the outside interface Gi0/0/1. Lines in red are the commands.

Access Control

For the ISR deployment there are a number of rules that we need to allow for the creation of VPN tunnels on the external interfaces. Now, let’s get to what the basic config will look like.

This is all CLI commands, so you will need to be at a config prompt. The first command is simply logging packets that are dropped by the policies.

parameter-map type inspect global

log dropped-packets

The next step will be class maps. There are five maps, inside to outisde, and then both pass and inspect traffic between the outside and the router.

class-map type inspect match-any Inside-Outside-Class

match protocol ftp

match protocol icmp

match protocol udp

match protocol tcp

class-map type inspect match-any Inspect-ACL-Out-Class

match access-group name ACL-RTR-Out

class-map type inspect match-any PASS-ACL-In-Class

match access-group name ESP-In

match access-group name GRE-In

class-map type inspect match-any PASS-ACL-Out-Class

match access-group name ESP-Out

class-map type inspect match-any Inspect-ACL-In-Class

match access-group name ACL-RTR-In

Next comes the policy maps. These are the policies that specify the classes that were just created.

Policy-map type inspect Inside-Outside-Policy

class type inspect Inside-Outside-Class

inspect

class class-default

drop

Policy-map type inspect ACL-In-Policy

class type inspect Inspect-ACL-In-Class

inspect

class type inspect PASS-ACL-In-Class

pass

class class-default

drop

Policy-map type inspect ACL-Out-Policy

class type inspect Inspect-ACL-Out-Class

inspect

class type inspect PASS-ACL-Out-Class

pass

class class-default

drop

By looking at the policies it’s easy to see that we will be passing inbound ESP and GRE traffic (the ACLs will follow), as well as outbound ESP traffic. Everything else that is allowed through the ACLs will be inspected.

The next step will be to create the security zones for the ZBF.

zone security Internet

zone security MPLS

zone security default

For now we are just creating a zone for each connection type. More zones will be added later as the config is built out.

Now that the zones are created we create zone pairs, which link a source and destination zone and apply one of the policies that were created to the traffic between those zones. One thing to be aware of is the router itself uses the “Self” zone. That means that traffic to the router will use the “Self” zone, so we can use that in the zone pairs.

zone-pair security Router-Internet source self destination Internet

service-Policy type inspect ACL-Out-Policy

zone-pair security Router-MPLS source self destination MPLS

service-Policy type inspect ACL-Out-Policy

zone-pair security Inside-Internet source default destination Internet

service-Policy type inspect Inside-Outside-Policy

zone-pair security Inside-MPLS source default destination MPLS

service-Policy type inspect Inside-Outside-Policy

zone-pair security Internet-Router source Internet destination self

service-Policy type inspect ACL-In-Policy

zone-pair security MPLS-Router source MPLS destination self

service-Policy type inspect ACL-In-Policy

The next step is to associate the interfaces with the corresponding security zones. Since there are only two actual zones (Internet and MPLS) this is pretty straightforward. All the other interfaces are using the default zone for now. Replace the interface in red with the correct interface for your deployment.

int gi0/0/1

zone-member security Internet

int gi0/0/2

zone-member security MPLS

Now the only thing left to do would be to create the ACLs. The ACLs here are based off a Cisco IWAN document. There are a number of areas where they can be tweaked. The obvious change would be disabling ICMP if that is a requirement for your environment. Another change would be to put in specific addresses instead of “any” for the VPN related rules. I would strongly recommend making at least the inbound rules more restrictive.

ip access-list extended ACL-RTR-In

permit udp any any eq non500-isakmp

permit udp any any eq isakmp

permit icmp any any echo

permit icmp any any echo-reply

permit icmp any any ttl-exceeded

permit icmp any any port-unreachable

permit udp any any gt 1023 ttl eq 1

ip access-list extended ACL-RTR-Out

permit udp any any eq non500-isakmp

permit udp any any eq isakmp

permit icmp any any

permit tcp any any eq 8080

permit udp any any eq domain

ip access-list extended ESP-In

permit esp any any

ip access-list extended ESP-Out

permit esp any any

ip access-list extended GRE-In

permit gre any any

Now that these rules are in place the routers should still establish the VPN tunnels, and traffic from the outside world should be restricted.

Unable to add Cisco ISR to WAAS Central Manager

Posted on March 7, 2016February 9, 2023 by Dan Kelcher

If you are trying to add an ISR to the WAAS CM and the process fails with no error (and it detects as WAAS Express) then I may have found the solution. Use the CLI. I know, seems obvious in hindsight, the CLI working where the GUI fails. The issue for me was actually finding the process for the CLI in the documentation.

Well, here’s the link to the documentation: http://www.cisco.com/c/en/us/td/docs/app_ntwk_services/waas/waas/v611/configuration/guide/cnfg/other.html#pgfId-1070077

The short version is you need to do the following:

Create a user with privilege level 15

For a local account – from config#: username user privilege 15 password 0 password

Export WAAS vCM cert

From exec: show crypto certificate-detail admin
Copy the cert (including the —Begin Certificate— and —End Certificate—)

Import the certificate into the router

From config#:

crypto pki trustpoint wcm
enroll terminal pem
exit
crypto pki authenticate wcm
Paste the certificate, and then enter a blank line to complete
accept the certificate

Create a router certificate

From config#:

crypto pki trustpoint local
enrollment selfsigned
subject-alt-name RouterFQDN
exit
crypto pki enroll local

Answer the questions as prompted
Serial number: Yes
IP address: Yes
Enter IP: IP_address
Generate certificate: Yes

Enable the web server and set authentication

From config#:

ip http secure-server
ip http authentication local

Enable SSH V2

From config#: ip ssh version 2

From exec: appnav cm-register https://vCMIP:8443/wcm/register

Unfortunately, there’s no output to the command, so you have to go to the Central Manager to see if it worked. If it didn’t here are a few things to look at:

Make sure the two devices can ping each other
Verify that NTP is configured on both devices
Verify that the AppX license is installed and activated on the router

Cisco ISR Project – IWAN Branch deployment (8 of?)

Posted on February 19, 2016February 9, 2023 by Dan Kelcher

To get a branch router deployed simply log into Prime Infrastructure and go to IWAN Enablement again (Menu – Services – IWAN Enablement).

IWAN Enablement

Hit Next on the intro page and then enter the configuration. For my site I am doing a single router branch. It becomes apparent quiet quickly that the rest of the information is nearly identical to what was needed to set up the DC routers.

Single Router Branch

After setting the category and role the rest of the fields are automatically filled. Next will come the device selection.

For the branch locations I decided to do this the hard way. Since I am using new routers they aren’t on the existing network I wanted to try doing an offline configuration. Since you can’t continue without selecting a device I just selected on of the routers I have at the Hub. Before committing the changes to the router I will just copy the CLI commands and run them on the router.

Most of the DMVPN fields should be familiar:

The loopback is just a local /32 address. Internet bandwidth is in Kb, not KB, so that’s easy enough. The tunnel IP needs to be on the same subnet as the Internet tunnel IP from the HQ side. The Internet Hub Tunnel IP is the IP that was assigned to the tunnel interface from the Internet Hub deployment. The interface is the router interface that will connect to the ISP. Lastly, the pre-shared key is the DMVPN key that was set on the hub router.

The MPLS fields are essentially the same as the Internet fields, but with the MPLS addressing.

Under the Internet WAN section you will enter the public IP address that will be assigned to the router, and the same applies for the subnet mask and gateway. Now, according to Cisco’s documentation, the remote DMVPN router supports a dynamic address, but the wizard requires an IP address assigned. I presume this can be cleaned up in the CLI after the deployment.

Again, the MPLS WAN settings are self explanatory. Enter the IP, mask, and gateway. If you are unsure of this information for either the MPLS or Internet interface contact your ISP.

The last section for the DMVPN is the EIGRP settings. For the LAN subnet you would enter the LAN subnet that will be at the remote site. The wizard doesn’t allow multiple subnets to be entered, but they can be added via the CLI later.

When complete, click Apply, then Next. This will bring up the PfR settings. Enter it IP of the Master Controller and the PfR password. Again, click Apply and Next

The next page will be the QoS settings. The wizard asks for the interfaces for Internet, LAN, and MPLS, as well as bandwidth.

There are a few things to be aware of- QoS Marking LAN Interface is the inside interface. When entering the interface names spelling counts. I would recommend just copying the interface name from the router CLI to eliminate the risk of typos. The Device Type field needs to be left with “Product Series” as the value. Finally, select the bandwidth that is the closest match to what you have, and again, this is Mbps, not MBPS.

Click Next through the AVS settings, then review the CLI Summary. As I mentioned, I did an offline config, so I essentially copied the CLI summary to the router CLI. One thing the be aware of is that if the CLI commands are copied it should be done is small batches. There may be issues with commands, and it’s much easier to spot issues if it’s in small chunks. If you are doing an online config then the deployment can be scheduled and confirmed.

If all goes according to plan, the deployment should go without issue. When it finishes make sure to save the config (unless that was selected as part of the deployment options. Then I would reload the router so it can come up with the new config.

In theory, when the routers are up the DMVPN should connect, and you should be able to ping the tunnel IP across the tunnels. Then run ‘show ip route’ and verify that routes are being added via EIGRP.

If so, you should be set to move on. If not, well something went wrong. Unfortunately, what the issue is could be one of many. Here are a couple things to try:

Ping remote public interface
Ping the remote tunnel interface
The ‘show int’ command can help identify if interfaces might be down
It might be worth looking through the running config for any misconfigurations, like mistyped IP addresses, or incorrect masks.
Traceroute can also be helpful to make sure that things are getting where they need to
Check the routing table with ‘show ip route’ to verify routes, including the default route, are correct.

Cisco ISR Project – IWAN Deployment to DC1 (7 of?)

Posted on February 18, 2016February 9, 2023 by Dan Kelcher

Now that Prime and the routers are deployed it’s time to start getting them added in. I have a deployed a set-up lab using an old Catalyst 2960 and a 2911 router to simulate Internet and MPLS connections between my HQ and remote routers. Since the MPLS isn’t in place yet I can’t add the remote routers, but I will add the CSR and the ISR devices at HQ.

Log into Prime and click the Menu button in the top left corner, the Inventory – Network Devices

Prime Network Devices

A Discovery could be created to find and add all the devices, but since there’s only three devices I added them manually. Simply click “Add Device” in the All Devices pane and then fill out the connection information.

Add Device window

Compete the fields in the Add Device window. Make sure to complete the SNMP and SSH windows to make sure you are able to get a full inventory collection from the devices.

After the devices are added it takes a few minutes for the initial sync to complete.

Once the devices are added then we can start the IWAN deployment. Initially, I am going to have a single CSR at my primary datacenter, with a second being added later at a DR DC. At the HQ there will be a pair of ISR 4331s, one for terminating MPLS and the other for terminating Internet connections.

To start the process of IWAN Enablement first click on the menu button in the top left corner, then Services – IWAN Enablement.

IWAN Enablement

First off, there’s a picture of the IWAN topologies.

The IWAN design is a hub and spoke topology, though there can be a redundant hub. At the hub site there are three rolls, the Master Controller which basically oversees the IWAN topology, and both an Internet and MPLS router. If a second hub location is used then it would have a Transit Master Controller, as well as the Internet and MPLS routers. For the branch locations they can be single router or dual router. With a single router location both MPLS and Internet connections terminate on a single router. The dual router sites have two routers, so MPLS terminates on one router and Internet terminates on the other.

Cisco also has a link to their YouTube video on the IWAN deployment process. https://www.youtube.com/watch?v=5LMpJtf2uuw

I did notice that the video is for the non-updated version of Prime Infrastructure 3.0, so it doesn’t match up with the prompts I was seeing. However, it’s still an awesome resource.

After clicking Next on the first page the wizard prompts to chose the configuration. The first options are:

IWAN Branch

IWAN Hub DC1

IWAN Hub DC2

Since this is at the primary HQ site (the DR site will be added at a later date) the selection is IWAN Hub DC1. Once that selection is made it will prompt to determine the device role:

Master Controller DC1

MPLS Hub DC1

Internet Hub DC1

The first thing needed is the Master Controller, so that’s the selection to make. It will then prompt for a template. One thing to be aware of is CVD stands for Cisco Validated Design. So the default (and only) option is the CVD template for the Master Controller at DC1.

DC1 Master Controller

After clicking Next the wizard will prompt to select a Device

Master Controller Device selection

Find the CSR 1000V and check the box next to that. The only thing the CSR will do is serve as the Master Controller for the IWAN deployment.

Here’s a diagram Cisco provides on the DC topology:

DC Topology

Now comes setting the Master Controller specific settings.

Master Controller settings

There is a little help bubble next to each field that will give additional information about that field. Additionally, there is a help button near the top right of the page. However, here’s what the fields are asking for.

The Loopback IP is an IP address that is basically used for the device to communicate with itself. It’s not used by any other device on the network. With that said, it is recommended to use a /32 mask for the address. So, pick an address that’s not going to overlap with anything in the network and assign that.

The PfR-Auth-Password is the password that all routers will use to authenticate routing updates. Make a note of this, as this password will need to be used on all PfR devices.

Wondering what PfR means? It is Performance Routing. Traditional routing protocols look at network stats, like hop count, and link speed to determine the best path. PfR actually monitors traffic on a per-flow basis, so it finds the best path for a specific application. For example, route VoIP calls over MPLS as it has the lowest latency, but route a file transfer over the Internet VPN as there’s better throughput. Now, to clarify this a little bit… PfR doesn’t replace a routing protocol, but instead it augments the protocol. Later on, we will select the overlay routing protocol that is used. More information on PfR can be found here: http://www.cisco.com/c/en/us/products/ios-nx-os-software/performance-routing-pfr/index.html

Enterprise_Prefix is the network prefix for the entire network. This includes HQ and all remote locations. I’m still not clear on how to handle this field if you have a non-contiguous network, like some 10.X.X.X networks, and a few 172.16.X.X networks.

The DC1_Prefix is the networks at the DC the Master Controller is being installed at. The field does allow multiple networks to be entered with a comma (,) separator.

The Netflow Collector IP is the Prime Sever, or VIP if there is a HA deployment of PI.

After everything has been entered you click Apply. This will populate the CLI preview, which shows what the commands are that will be entered.

Clicking on Next will bring up the CLI Summary. Since there was only one configuration step this shows the same thing as the CLI Preview from the previous step. If there were more configuration pages then this would compile all the CLI entries for all the pages.

By clicking Next again it brings up the option to schedule the deployment.

Master Config deployment schedule

Personally, I leave it set to run now since the device isn’t in production. I also check both boxes to Copy Running Config to Startup and Archive Config after Deploy. This way I have the config committed, and I have a backup of it.

All that’s left is to click Next, and then on the Confirmation page click Deploy. Then wait while this configuration is deployed. The deployment process can be monitored from the Job Dashboard. Once this is complete then the MPLS and Internet routers can be configured.

To configure the MPLS router go back into the IWAN Enablement wizard. This time select the IWAN Hub DC1 category, then MPLS Hub DC1.

MPLS Hub DC1 config

After the device role is selected a number of additional options become available. The Overlay Protocol is the routing that is used to build the network route topology, and then is used by PfR to determine the best application pathing. There are two options here, EIGRP and BGP. Since this a Cisco shop, and EIGRP is generally an easier protocol to configure, that is the option I selected.

The rest of the dropdowns only have the default setting. The only other customization is the Deploy PKI checkbox. When unchecked the DMVPN uses a pre-shared key to authenticate routers. If a PKI is used then certificates are used for authentication. The PKI deployment requires an APIC-EM (

Application Policy Infrastructure Controller Enterprise Module), which I don’t have, so pre-shared keys are fine by me.

After clicking Next the wizard will prompt to select the device that the config will be applied to.

MPLS Hub DC1 Device selection

Find and select the MPLS router, then click Next.

Now comes setting the MPLS DMVPN settings.

MPLS Hub DC1 setting (1 of 2)

Again, a loopback IP is required. Use a /32 that doesn’t overlap with the rest of the network.

For the bandwidth don’t get confused by the use of all CAPS. It is asking for the bandwidth in Kbps.

The tunnel IP address is the virtual IPs that will be used to create the tunnel endpoints. These IPs are what allow the devices to think they are peers even over an Internet or MPLS connection. A single subnet will be used for the tunnel IPs for all MPLS endpoints, and another subnet will be used for all Internet VPN endpoints. As an example, 192.168.10.0/24 for MPLS and 192.168.20.X/24 for Internet endpoints.

Set the Tunnel Subnet Mask according to the IP range selected.

The Tunnel subnet field is a bit confusing. This is just the network IP for the subnet selected. In the example of using 192.168.10.X/24 for the MPLS Tunnel IPs the fields would look like this:

Tunnel IP: 192.168.10.1

Tunnel Subnet Mask: 255.255.255.0

Tunnel Subnet: 192.168.10.0

The MPLS WAN Interface is self explanatory. This is the interface of the router connected to the WAN.

The Pre-shared key here is the DMVPN key, not the PfR key that was set on the Master Controller. Enter a key, then make note of it as it will be needed for the spoke routers.

When those fields are done then we can scroll down…

MPLS Hub DC1 settings (2 of 2)

This should all be pretty straight forward. For the MPLS WAN, enter the WAN IP of the router, the subnet mask for the MPLS link, and the gateway IP for the MPLS. If unsure of this info, contact the ISP as they should be able to provide it.

Under the EIGRP section, the Master Controller IP is the address of the CSR 1000V. The PI IP address is for the Prime Infrastructure server (or VIP if clustered), the APIC-EM IP is if a APIC-EM appliance is being used for PKI, and lastly, the DC prefix is the network range for the datacenter. As before, if needed, additional IP ranges can be applied to the DC prefix field using a comma separator.

Click Apply, then click Next. It will now ask for the PfR information. Again, enter the IP of the Master Controller and the Auth password. This is the PfR password that was set up when the Master Controller was deployed. Again, click Apply, then click Next.

For the MPLS settings leave the Device Type as “ProductSeries” and set the WAN bandwidth (again, ignore the capital B, this field should be in kilobits per second) and the physical interface that the MPLS connection is on.

I must admit, I find it odd that the wizard asks for the same information that was previously entered. It seems like this is just asking for a misconfiguration, as it doesn’t compare the two values. The one that really surprises me is that for the DMVPN-Physical-Interface it doesn’t give a dropdown for the interface names, so you have to correctly type it. With that said, type the full name, not the CLI shorthand, so use “GigabitEthernet0/0/1” as opposed to “gi0/0/1”

When that’s completed click Apply and Next. Then it will bring up the AVC-MPLS page. Even though there’s a log on the page there’s nothing that can be modified.

Clicking Next again will bring up the CLI summary for everything that was entered. Review the CLI summary if desired, then click Next.

Again, the page to schedule the job deployment will come up. Select the desired option and click Next. At the Confirmation page click Deploy to complete the wizard and start the deployment (if it was set to run now).

The deployment process will take a few minutes to complete.

For the Internet Hub DC1 router settings it’s nearly identical to the MPLS settings. Just replace the word MPLS with Internet. All the fields, and even the order are identical, just for the Internet side instead of the MPLS.

When the deployments are complete the next thing to do is to integrate the new routers into the existing topology. It seems the wizard uses EIGRP AS 400. That AS can be modified to match an existing EIGRP AS, or it could be configured on the existing gear. Route redistribution or static routes could also be used, all depending on the existing environment.

Cisco ISR Project – ISR 4351 and UCS E-Series base config (6 of?)

Posted on February 15, 2016February 9, 2023 by Dan Kelcher

For the base config of the router you can follow this guide: https://www.mytechgnome.com/2016/02/cisco-isr-project-isr-base-config-5-of.html

The config of the router portion is the same between the two models. The difference comes in with the UCS E-Series server.

By default the CIMC of the blade (out-of-band management) is set to use the dedicated management port (the one labeled with a green background with an “M”) and it’s set for DHCP. If you are running DHCP you should be able to find the record in your DHCP server. The client name will be the model and serial of the server, so E160D-FOCXXXXXXXX for example. If you don’t have DHCP or if you want to assign a static IP you can run these commands from a config prompt on the router:

ucse subslot 1/0

imc ip address A.B.C.D E.F.G.H

You’ll need to replace A.B.C.D with the desired IP and E.F.G.H with the subnet mask. As usual, remember to save the config after making changes.

You can also set up the CIMC address by booting into the CIMC manager (press F8 during boot to get to the CIMC manager) and setting it there, but I think it’s easier to just use the router CLI.

To simplify my life, I set up a management station on the same subnet as the management IPs I used on the CIMC and router management. This way I don’t need to worry about getting routing set up yet.

You should be able to open a browser window and connect to the CIMC IP address. First, the CIMC web interface requires Adobe Flash Player, so you may need to install/update that.

CIMC login page

The default username is: admin

The default password is: password

You will be prompted to change the password when you log in for the first time.

First things first. Let’s get the CIMC firmware updated. If you haven’t done this yet, go to the Cisco site and download the latest CIMC software. https://software.cisco.com/download/release.html?mdfid=286281321&flowid=&softwareid=284480160&release=3.0.2&relind=AVAILABLE&rellifecycle=&reltype=latest

When logged in click the admin tab in the left pane.

CIMC Admin

Then select Firmware Management

CIMC Firmware Management

Now click Install CIMC Firmware through Browser Client

Firmware install

In the window that pops up browse to the firmware download and click Install. This process will take some time, and it’s not actually installing the firmware. It’s just getting the firmware copied and ready. When this process is complete you will need to activate the firmware by click Activate CIMC firmware.

Activate firmware

You’ll get a popup to select the firmware version to activate. Select the version you just installed and click Activate Firmware. Since the server isn’t in production yet we are going to ignore the recommendation to set the maintenance mode. When the firmware is activated it will restart the CIMC service, so remote access will be lost temporarily.

That should get the CIMC configuration done, and now an OS can be installed.

First, we need to set the boot order. Click BIOS in the left pane on the Server tab, then select Configure Boot Order. If there is a pop up click OK on it.

Boot order

For my deployment I am going to be installing the OS on the embedded SD card. For that, I set the boot order to first look at the Linux Virtual CD/DVD, then Cypress (the SD card).

Set boot order

Once things are moved as needed click Apply. To start the OS install click the KVM icon (it’s in the top bad, and it looks vaguely like a keyboard.

Start KVM

The KVM does require Java, so that may need to be installed. Also, since it uses Java expect a series of security prompts, as well as the difficulty that can accompany. One thing to be aware of is if it downloads a file that looks like this ‘viewer.jnlp(1.2.3.4@0@215634295136582)’ it can be renamed to remove everything in the parenthesis, as well as the parenthesis leaving just ‘viewer.jnlp’ and then you can run that.

You will likely see this pop up more than once during the install. Just click ‘Accept this session’ and then check the box to remember the setting. Since we are doing an install of a OS there’s nothing that needs to be encrypted. If encryption is needed, it can be enabled on the CIMC interface, under Remote Presence. On the Virtual KVM tab check the box the enable video encryption, and on the Virtual Media tab check the box to enable virtual media encryption.

Unencrypted Virtual Media Session

When the session is connected, click the Virtual Media tab at the top, then Add Image on the right.

Add image

Browse to the VMware ISO and select it. When selected, it will be listed in the window, and you will need to check the box under Mapped. Then go back to the KVM tab and boot the server (or reboot if it is running).

The VMware install is pretty self explanatory, and I presume familiar. If not, here’s the VMware install guide: http://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.install.doc/GUID-6FFA928F-7F7D-4B1A-B05C-777279233A77.html

When the installation finishes the server will reboot into a two-tone page that will have the machine info, including DHCP address. If you need to modify the network settings press ‘F2’ and then log in.

Since this is a text based configuration I won’t bother with screenshots for most of this. In the menu select Configure Management Network.

For Network Adapters, determine what adapter will be used. VMNIC0 and VMNIC1 are built into the UCS server, and are connected internally to the ISR. VMNIC2 and VMNIC3 are matched to GE2 and GE3 on the server module.

After selecting the adapters then set the IP address, and make any needed DNS changes.

Once the server is online these changes can be made from the GUI as well.