Category: Cisco

Linux to Cisco Openswan IPSec Configuration

Reading Time: 6 minutes

[notice]For this example I use the following IP scheme    192.168.0.12|–O–42.42.42.42—–[INTERNET]——12.12.12.12–O–|10.42.42.42[/notice]

I was approached a few weeks back to assist in creating a VPN Tunnel between two end points. Of course in my naivety I readily assumed it was between to Cisco devices but that turned out not to be the case. The tunnel was to be between a Linux box (in this case Ubuntu on a hosted VPS provider) and an unknown endpoint. This tunnel was going to be host to host as opposed to LAN to LAN. After some quick discovery work, getting access to the Linux box, and seeing the required proposal from the other side I started diving into the unknown of Openswan. Luckily, after doing som research for the configuration and verification things started shaping up and much to my approval, a lot of what you would look for in Cisco verification was the same on the Linux box. The configuration goes as such.

Naturally the first step is to install Openswan. As per usual use your distributions software management to install this. The first thing I configured was the ipsec configuration file. On the Ubuntu box this resided in “/etc/ipsec.conf”. The configuration was as follows.

Continue reading

Share this article:

Permanent link to this article: https://www.packetpilot.com/linux-to-cisco-openswan-ipsec-configuration/

Route-Targets Explained

Reading Time: 3 minutes

 

As I began to study MPLS L3VPNs I was excited to start flinging my fingers around the keyboard. However, I ran into a little snafu during my learning. All of the videos and configuration example I was finding didn’t separate the difference between the Route Distinguisher (RD) and the Route Targets. Most of the examples simply matched the RD to the Route Targets and/or used the same Route Targets for both import and export. This left me feeling like I wasn’t really understanding what those commands and numbers were accomplishing. I decided to make a visual representation to make it easier to understand.

Router-Target Policy Visualization

Router-Target Policy Visualization

To make this concept easier to understand we first need to know that the RD does not dictate what routes a route will import or export into it’s PE-CE routing process. The purpose of the RD so to add an additional label to prefixes so overlaps can be inserted in the BGP table and shared amongst the various PE routers. For example, my RD of 65000:8 indicates any routers in the BGP table from my customer vrf would indicate a prefix of 10.20.30.40 as 65000:8:10.20.30.40. This means if another vrf with a different RD of 4242:42 could also install 10.20.30.40 in the providers BGP table as 4242:42:10.20.30.40.

Now that we are clear on the use of the RD we can move onto the Route Targets. There are two route targets we define in our VRF policy. The import and export targets. Many examples and videos show these as the same (which is a perfectly valid configuration) often times matching the RD. To clarify exactly what they are used for I have used three different Router Targets. I am going to correlate their indicators with colors to make the example easier to visualize.

Routes exported from the headquarters use 30:8 which we will call the “Blue Routes”
Routes exported from Branch 1 will use 10:8 which we will call the “Red Router”
Routes exported from Branch 2 will use 20:8 which we will call the “Green Routes”

This exporting is done by the PE routers connecting to the CE routers. The CE routers in this example our peering via eBGP with the PE routers inside of a VRF. The VRF configuration on the PE routers is what indicates the Router Target identifier to export. At this point we can write a policy of which routers should be allowed into the individual CE routes using the VRF Route Target import. Lets follow a case from the HQ to Branch 1.

HQ CE peers with its PE router which has a VRF policy stating to export its routes as the color Blue. These routes are passed around to the other PE routers. When the Branch 1 PE peer receives the routes it sees that it’s VRF policy is stating to export its routes as the color Red as well as import any routes that are colored Blue. Back at the headquarters we have our VRF policy set to import both the Red and Green routes. Branch 2 does the same as Branch 1 but swapping out Red for Green.

By writing the VRF policies this way we have created a Branch to HQ connection while not passing routes Branch to Branch. In my diagram I show the routes coming into the CE routes as it is the ultimate end goal however, please keep in mind that the VRF configuration is done on the PE routes.

I hope that by using simple colors for the routes it has simplified the reasons we use the RD, and the import and export Route Target. I found it difficult to understand the true use of these configuration when they were using the same value for the RD as well as the import and export Route Targets.

 

Share this article:

Permanent link to this article: https://www.packetpilot.com/route-targets-explained/

Infocus Mondopad Registered with CUCM – SIP

Reading Time: 2 minutes

This post is primarily for archived documentation for myself in the event of possible future need. However, I was having a hard time finding any configuration examples for this task. The steps below are those I used to connect a 70inch Infocus Mondopad to our CUCM environment to be able to make video calls including sharing the Mondopads screen over the called Cisco phone.

Continue reading

Share this article:

Permanent link to this article: https://www.packetpilot.com/infocus-mondopad-registered-with-cucm-sip/

Synapps Paging Delays – An HTTP/TCP Wireshark diagnosis

Reading Time: 5 minutes

The Scenario goes like this: A Synapps – SA Announce paging and messaging server integrated with Cisco’s CUCM hosting around 30 phone to phone paging groups. The paging had been working fine for months and out of no where one of thirty particular groups was putting in multiple trouble tickets over multiple days that the paging isn’t working.

So begins the troubleshooting and diagnosis. My first action was to monitor the paging server as it has a real time display of who is calling a paging group and which group they are calling at in given time. When I was monitoring this I could see multiple people calling multiple groups including the one in question. So this brings up one of those “what gives” questions. Are they just doing something wrong up in the area. Time to take a trip and raise that pedometer count.

I arrive in the area and try and locate and area where I can visually see and hear multiple phones. Easier said than done but in this case I was the only one available to work on the issue and knowing that the paging server will activate the speakerphone and mute lights when a group the phone is a member of is called this was my best bet and understanding what was going on. After making my first test page I can see that lights on the phones I can see are immediately lighting up, however I can’t hear audio. As I stand there dumbfounded with the phone still off hook all of a sudden the audio starts picking up the background noise. However, paging shouldn’t have a 6 second delay before you can start talking. Six seconds is a long time to wait after hitting page to start talking. So whats going on? It’s only one group experiencing this. What is different about their group? Time for a deep dive in the diagnostics world. Enter Wireshark.

Continue reading

Share this article:

Permanent link to this article: https://www.packetpilot.com/it-was-broke-but-the-sharks-got-to-it/

Trouble shoot with TDR

Reading Time: 5 minutes

This article is another example of trouble shooting by putting multiple pieces together. While it relies upon existing knowledge of the environment in which the article is based it should prove to be a good example of a trouble shooting process that will hopefully be able to spark some creative thinking the next time you have a problem that needs to be resolved.

The scenario starts out with a user ticket stating that the phone isn’t working. After some fact gathering the below details and possible solutions were outlined.
Continue reading

Share this article:

Permanent link to this article: https://www.packetpilot.com/trouble-shoot-with-tdr/

IP SLA for Single Default Route Change

Reading Time: 5 minutes

The scenario goes like this. You are working at your office (R1) and need to change the IP address and default route on the remote device (R2). The issue a factor of two things. The first is the fact that R2 is connected to your network with only one link. The other issue is R2 cannot use any dynamic routing protocols so you are stuck with a default route that is pointing at the next hop. If you are to change either of these facts you lose connectivity to R2. While there are other solutions to making this change, I am going to take the concept of floating static routes and an IP SLA to change both the IP address and the default route.

Continue reading

Share this article:

Permanent link to this article: https://www.packetpilot.com/ip-sla-for-single-default-route-change/

Initial Router Setup For Remote Access

Reading Time: 3 minutes

[notice]PacketPilot / P2Labs does not guarantee any certification results in using the content of this website. Please keep in mind these are free tools to aid in your learning and certification goals. All efforts are made to ensure the accuracy and content in these labs. Hard work, dedication, and official Cisco training materials are recommended for your training.[/notice]

The following lab can be completed using any Cisco Emulator supporting the appropriate feature(s).

The purpose of this lab is to reinforce basic router configuration including naming the router, connecting two routers via an ethernet connection, and establishing logon procedures for remote access including secure remote access. Remote access if a key design feature of any network. It provides efficiency of management by preventing unnecessary trips to distant devices for simple tasks. Secure access is provided to prevent unauthorized access and data gathering from packet captures on plain text traffic.

Continue reading

Share this article:

Permanent link to this article: https://www.packetpilot.com/initial-router-setup-for-remote-access/

SRT: Offline type 7 decrypt

Reading Time: < 1 minutes

I was recently working on deploying a new device into our network infrastructure. I was working off a configuration template that had a standard arguments for AAA leveraging TACACS+. I was offsite and had asked a fellow colleague to enter the new device into our ACS deployment to allow authentication and command authorization. The long and short of it is, it was copied off of a different group of devices than what my configuration template was based of. The issue was a mismatch in TACACS server keys. The problem was I was currently offline as I was connecting to the device what would let me out to the network. So what is the stupid router trick? The stupid router trick consists of using the key chains to decrypt a type 7 TACACS (or other key) that is hidden via service password-encryption in your configuration template. The trick is pretty simple. Create a temporary key chain that won’t be applied anywhere, enter the key(s) into the key chain in their type 7 format, and then do a simple show key chains. Really! That’s all there is to it. See the output below.

 

R1(config)#key chain tempkeys
R1(config-keychain)#key 1
R1(config-keychain-key)#key-string 7 06150A225E4B1D12000E
R1(config-keychain-key)#exit
R1(config-keychain)#key 2
R1(config-keychain-key)#key-st
R1(config-keychain-key)#key-string 7 095F4B0A0B0003190E15
R1(config-keychain-key)#end
R1#
R1#show key chain
Key-chain tempkeys:
key 1 -- text "secretkey"
accept lifetime (always valid) - (always valid) [valid now]
send lifetime (always valid) - (always valid) [valid now]
key 2 -- text "secretkey"
accept lifetime (always valid) - (always valid) [valid now]
send lifetime (always valid) - (always valid) [valid now]
Share this article:

Permanent link to this article: https://www.packetpilot.com/srt-offline-type-7-decrypt/

Automated IP Communicator Launch against Multiple Clusters

Reading Time: 3 minutes

If you manage multiple CUCM clusters you are likely to have Cisco’s IP Communicator installed on your computer. Cisco IP Communicator is a software based phone installed on your computer that connects up to CUCM and lets you utilize your PC as if it’s a Cisco desk phone. This is a pivotal tool to quickly move a phone between different call managers. I recently fell into this demographic while working on a migration/collapse of multiple CUCM clusters. A lot of time was spent in the GUI of IP Communicator changing TFTP Server address (let alone trying to remember them all). I took a couple of hours and figured out what would be needed to automate this task via a batch script with a simple menu based script. The details are found below.

To start, I found that the TFTP servers were stored in the registry. However, these TFTP servers were not in standard IP address form. They were actually stored in Hex, but the octets were rolled over while keeping the bits in the standard left to right order. The process to create the correct value’s for the registry is as follows.

Continue reading

Share this article:

Permanent link to this article: https://www.packetpilot.com/automated-ip-communicator-launch-against-multiple-clusters/

Cisco OSPF MD5 Authentication

Reading Time: 2 minutes

Continuing with our OSPF and interior gateway protocols we will not look at an MD5 implementation utilizing OSPF on a Cisco router. We will again continue with our 3 router topology as used in both the EIGRP MD5 example and the OSPF plain text example. There are very few changes that will need to be made to our earlier OSPF example using plain text. The topology is as follows.

Continue reading

Share this article:

Permanent link to this article: https://www.packetpilot.com/cisco-ospf-md5-authentication/

Load more