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.

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 4331 base config (5 of?)

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

On to the CLI config of the ISRs. For this portion we are simply going to get the basic configuration done so we can SSH into the routers.

Connect a console cable (or USB cable) to the device and open up your favorite terminal emulator, then boot the router. Eventually you should get a set up prompt. If you don’t and you get a Router> prompt type these two commands:

enable

setup

The setup wizard is pretty straightforward. Follow the prompts and enter the information needed. Note that GigabitEthernet0 is the management interface.

ISR setup

When you are done with the IP addressing it will ask if you want to run the auto secure wizard. I recommend running that, as it disables some unneeded services, and applies more secure policies. When prompted for SSH, make sure you enable that.

Unfortunately, the setup process does not create a SSL certificate for SSH. To create the certificate use this command from a config prompt (enable, conf t):

cyrpto key generate rsa

Then it will prompt for a bit size. I used 1024 in this example.

RSA key generation

After generating the key make sure to save the config. From the config prompt, it’s quickest to just type this command:

do wr

Otherwise ‘do write mem’ or ‘do copy run start’ would work. You could also exit the config session and do ‘wr’ or any other variant at the enable prompt.

The other thing that you may need to do is enable routing on the management VRF if you will be connecting from a different network. From a config prompt use this command:

ip route 0.0.0.0 0.0.0.0 Gateway IP

This will route all traffic to the default gateway that you specify. Again, save the changes, then test the SSH connection to the management IP.

The next step will be getting the licenses installed. The first thing we will need is the UDI. From an enable prompt run this command:

show license udi

Make a note of the PID and SN. They will be needed to get the license registered. Now go to the Cisco licensing portal (https://tools.cisco.com/SWIFT/LicensingUI/Quickstart) and select the PAK you want to use, then Get New License. Follow the prompts, making sure to set the quantity, enter the PID and SN, then accept the agreement. This will allow you to download the license file.

Before we can continue, we need a way to move the license file. My personal favorite is the SolarWinds free TFTP server that can be found here: http://www.solarwinds.com/products/freetools/free_tftp_server.aspx

As a side note, if you’re not familiar with Thwack, the SolarWinds user community you should check it out. There’s a lot of good information about both SolarWinds products, but also some general IT info. Plus they have some pretty awesome contests. Check it out: https://thwack.solarwinds.com

Place the downloaded license file (should be a .lic file, so you may need to unzip) into the TFTP root folder and start the TFTP server. Then run the following from an enable prompt:

license install tftp://IP of the TFTP server/license file name.lic

You will of course need to enter the IP of your TFTP server, and the license file name including extension. The process should be pretty quick, and you will get a result that looks like this:

ISR license install

Repeat that process for all licenses needed.

The last step of the base setup of the device will be to get the firmware to the right level. I decided to match my ISRs and CSRs on 3.16. First, you’ll need to find the current firmware version. You can do that with this command:

show ver

The version should be listed at or near the top of the result. You will also want to make a note of the System image file name and path. If you are going to upgrade the firmware then you will need to download if from Cisco if you haven’t already. When you have the firmware you want you will need to place the .bin file in your TFTP root folder. Then you copy the file to the bootflash directory on the router using this command:

copy tftp://IP of the TFTP server/firmware file name.bin bootflash:

Again, set the IP of your TFTP server, and the firmware file name of the firmware downloaded. It will prompt to confirm the file name, and you can just accept the default, which keeps the same name. The copy process will take a while to complete. When it completes we will verify the file integrity by running this command from and enable prompt:

verify bootflash:firmware file name.bin

This will also take some time to complete. Now we want to check if there is an existing setting for the firmware boot. Run this command from an enable prompt:

show run | in boot system

If nothing is displayed then you are good to move on, but if something is displayed you’ll need to note it and then we will clear it out by running this at a config prompt:

no boot system firmware file location:firmware file name.bin

You could also simply copy the output from the show command, then from a config prompt type “no ” and then paste the command.

The next step is to set the system to boot from that image by issuing this command from a config prompt:

boot system bootflash:firmware file name.bin

Now it’s just a matter of saving the config and reloading the router.

When the router is done booting you can verify the new firmware by logging and running ‘show ver’ again. Verify that the firmware is now the desired version.

Lastly, if you want to clean up the router you can delete the old image file. From an enable prompt type this command:

delete old firmware file location:old firmware file name.bin

You should have the file name and location from the output of the ‘show ver’ command that was done to find the firmware version initially.

Now, one very important note- If this is being done in a lab, and private IP addresses are being used there could be an issue caused by the auto secure script. During the auto secure script it asks if an interface is internet facing. For interfaces that are listed as internet facing it configures the interface to drop packets from private IPs. Since I’m using private IPs to create a virtual internet the auto secure script caused major problems since it effectively dropped all traffic. To check if this could be a problem run this:

show run interface gi0/0/X

In the command replace “X” with the interface that might be internet facing. If this line is present int the config “ip verify unicast source reachable-via rx” then it will cause issues. To remove that command go to a config prompt, then the interface in question, and run this command:

no ip verify unicast source reachable-via rx

The Cisco guide for the ISR initial config can be found here: http://www.cisco.com/c/en/us/td/docs/routers/access/4400/hardware/installation/guide4400-4300/C4400_isr/initconfig.html#45656

Firmware update guide: https://supportforums.cisco.com/document/98421/how-upgrade-or-downgrade-ios-isr-or-similar-router

Cisco ISR Project – Cisco Prime Infrastructure deployment (4 of ?)

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

After the OVA is deployed it’s time to set up Cisco Prime. Prime will be the monitoring and management software for the IWAN deployment, so it’s a logical place to start.

Before starting the process, we will fix an issue discussed in my post here: https://www.mytechgnome.com/2016/02/cisco-prime-infrastructure-vm-error.html

Edit the settings of the VM and add a serial port. (I just set it to output to a .txt file in the VM’s folder)

Time to power up the VM and connect to the console.

Prime Setup

To begin the setup, type “setup”

Prime config

Then you will get a series of prompts to configure the device. Most are self explanatory, except the timezone. Cisco has a list of accepted timezone names, which can be found here: http://www.cisco.com/c/en/us/td/docs/net_mgmt/prime/infrastructure/3-0/user/guide/pi_ug/timezones.html It’s also worth noting that the ‘admin’ account entered here is for CLI access. A web user is added later.

Prime config

The setup process will enable the network interface and run a few tests. After that you will receive a notification that the install completed and it will ask if this is for an HA node. I’m not setting up an HA node, so I entered “no” and continued on.

Prime Config

The default admin account on the web interface is ‘root’ so here you set the password. After that you’ll get a prompt confirming that all is well. After confirmation the server will finish the setup script and reboot. This process takes a while, like 10-15 minutes.

While this is working, it would be a good opportunity to get the license key for Prime downloaded, as well as the patches and tech pack. There is a bug in the licensing that will report the license is invalid (https://tools.cisco.com/bugsearch/bug/CSCuw89435)

The patches and tech pack can be found here: https://software.cisco.com/download/release.html?mdfid=286285348&flowid=76142&softwareid=284272933&release=3.0.2&relind=AVAILABLE&rellifecycle=&reltype=latest (note that they need to be installed in order – 3.0.2, tech pack, 3.0.2 update 2)

The device pack can be found here: https://software.cisco.com/download/release.html?mdfid=286285348&flowid=76142&softwareid=286208063&release=3.0.3&relind=AVAILABLE&rellifecycle=&reltype=latest

When the Prime startup is complete you should be able to access it from a web browser.

Prime web UI login

Remember that the login name is ‘root’ and the password is what you set for the root account, not the admin account.

After logging in you will see an icon in the top left to open a menu. Click that, then Administration > Software Update.

Prime Menu

In the Software Update window there is a link to upload files. Click that, browse to the update you want, and then upload it.

Prime Software Update

After the file is uploaded you will have an Install button next to the file. Click Install and it will confirm the install and inform you if a reboot is required.

If a reboot is required go back to console of the Prime VM and log in. To restart Prime there are two commands needed:

ncs stop

ncs start

And the link to the Cisco document on restarting Prime: http://www.cisco.com/c/en/us/td/docs/net_mgmt/prime/infrastructure/2-2/administrator/guide/PIAdminBook/maint_sys_health.html#pgfId-1088333

The restart will ofcourse take about 10 minutes, and you will need to do it multiple times to get the patches installed.

When all the patches are installed then the license(s) can be installed. However, before starting that, grab the UDI of the VM. Click the menu button in the top left, then Administration > Appliance

Prime Appliance settings

The UDI is in the right column, in the middle. You will want to make note of the product ID and serial number. Those may be needed to license a PAK.

After downloading the licenses from the PAK registrations (they may be in .zip files, and if so, they need to be extracted) the keys can be installed. Again, open the menu at the top left, the Administration > Licenses.

Prime Appliance settings

To load a license click Files > License Files on the left side. Then click Add and browse to the license file (it should be a .lic file). Repeat those steps to install all the Prime licenses.

That will get Prime installed, patched, and on the network. Adding devices into Prime will be covered later.

Cisco ISR Project – Deploying the OVAs (3 of ?)

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

The next stage of the process is relatively straight forward. The deployment of the OVAs for the virtual appliances.

First and foremost is the resource requirements. Each OVA will be unpacked into a VM in the environment, so we need to make sure there are sufficient resources.

Name	vCPU	GB vRAM	GB Disk (thin)	GB Disk (thick)	Notes
vCM 100	2	2	1.6	254
vWAAS 2500	4	8	1.5	754
vNAM	2	4		100	Thin not available
LiveAction	4	16		230	Thin not available
Prime Infrastructure – Express	4	12		300	Thin TBD
Prime Infrastructure – Express-Plus	8	16		600	Thin TBD
Prime Infrastructure – Standard	16	16		900	Thin TBD
Prime Infrastructure – Professional	16	24		1200	Thin TBD
CSR 1000V – Small	1	4	0.6	8.3
CSR 1000V – Medium	2	4	0.6	8.3
CSR 1000V – Large	4	4	0.6	8.3
CSR 1000V – Large w/ DRAM upgrade	4	8	0.6	8.3	Requires DRAM SKU

For Cisco Prime, the Scaling information can be found in the Quickstart guide here: http://www.cisco.com/c/en/us/td/docs/net_mgmt/prime/infrastructure/3-0/quickstart/guide/cpi_qsg.html#pgfId-67786

For the OVA deployment it should be pretty self-explanatory. From the vSphere client click File – Deploy OVF Template.

From the VMware vSphere Web Client select your cluster, then on the top bar click the Actions drop down and select Deploy OVF Template.

Now it’s just a matter of following the prompts based on the environment. Find the OVA file, name the VM, set the appropriate host, network, and datastore, and the rest of the things the wizard asks for.

The CSR will prompt for a bunch of information for the setup.

CSR OVA properties

The PNSC and Intercloud settings can be left blank. The rest depends on your environment. I would recommend enabling SSH, so you will need to have a domain name configured for the key generation.

Cisco ISR project – Licensing (2 of ?)

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

After the hardware has been purchased comes what might be the most difficult part of the project – sorting out Cisco licenses.

Hopefully you’re well aware of the Cisco licensing and support process. I’ll try and make this clear as mud…

First and foremost, you need a Cisco account. If you don’t have one you can go here: https://tools.cisco.com/IDREG/guestRegistration.do?exit_url=https%253A%252F%252Fslogin.cisco.com%252Fwaa%252FauthJump.do&locale=en_US Your account will need to be associated with the business you work for, so this can get more complicated. If you get stuck, contact your reseller.

For reasons beyond me, Cisco likes to send out the cardboard mailers with the PAK licenses (and EULA, and paper license, and sometimes T&Cs on a CD…). Sort through the material you receive and find everything that lists a PAK. Also, be careful to actually look at each piece of paper, as sometimes there are specific instructions for product access.

To register a PAK you need to go to: https://tools.cisco.com/SWIFT/LicensingUI/Quickstart

Again, you’ll need to log in with a Cisco account. When you are logged in you will be able to register the PAK.

You should be able to follow the instructions to register the PAK. I would suggest waiting on actually generating licenses until you are ready to use the specific product. Some require the SN or UDI of the device the license is applied to. It’s easier to just do that when you are ready. So, now the PAKs should be done.

But wait, there’s more! You still need to register your support contract.

Log into your Cisco account, and at the top of the screen click “Account” then “Customer Profile Manager” (Note: the link at the bottom for Cisco Service Contract Center is very helpful. It will show all the contracts and details that are linked to your account)

Under your account you can add access to your Cisco contract. Click the “Access” tab at the top and this will list your contracts and allow you to add more by clicking the “Add Access” button.

Typically, I just use the Full Support option, as that allows me to download software and open TAC cases for the products.

The next page can be difficult. I use a Cisco reseller, so the Bill-to ID on my orders is for my reseller. Usually, I just open a chat session and provide the agent with my Cisco SO# (it can be found on the packing slip, in the eDelivery e-mail, or it will be listed in the licensing page when you activate a PAK). The agent then can find the specific contract number(s) to add.

After the contracts are added you should be able to download firmware for the hardware.

Here are the links for what I downloaded:

It seems that vCM OVA isn’t downloadable, but media for that should be sent with the PAK. The vCM can be upgraded by using the “Universal Binary Image” which can be downloaded from the WAAS software location

LiveAction

VMware vSphere

Cisco USB console driver Not needed, but it’s nice to have the USB console driver

Cisco ISR project – IWAN, WAAS, UCS-E, Prime, and more (1 of ?)

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

This is the start of a series of posts about my adventures in getting a Cisco IWAN project deployed.

To start with, the new gear order was as follows:

Two Cisco ISR 4331 routers (Cisco ONE for WAN license)

One to terminate MPLS and one for Internet

Two CSR 1000V routers in an HA pair
Cisco WAAS virtual central manager (vCM)
Cisco WAAS virtual application engine (AE)
Cisco Prime VM
Cisco virtual network analysis module (vNAM)
LiveAction Pro

Site 1 (MPLS only)

Cisco ISR 4351 (Cisco ONE for WAN license)
UCS E-160D-M2 server

64GB RAM
3x 900GB drives in RAID 5

Site 2 (Dual connected)

Two Cisco ISR 4351 (Cisco ONE for WAN license)
Two UCS E-160D-M2 servers

64GB RAM
3x 900GB drives in RAID 5

Site 3 (VPN Only)

Cisco ISR 4351 (Cisco ONE for WAN license)
UCS E-160D-M2 server

64GB RAM
3x 900GB drives in RAID 5

For the remote sites, this will completely replace any routers, firewalls, servers, and/or WAN accelerators deployed. From the HQ side this will augment the existing environment, as the current hardware still needs to support sites that aren’t migrating to the ISR solution yet.

IWAN topology

There were a few iterations of the design process. I would recommend working with your Cisco partner to figure out what the best design would be for your environment