Monday, October 28, 2013

Cisco CUCM: Adding A Route-Pattern To Your CallManager

Someone always gets bit on this.  There are times when you just have to go add a route-pattern into the call routing table.  I know I have.  A lot of new guys to Cisco CUCM don't realize that when you add a route-pattern to the call routing table, the connection to the gateway gets reset.  It doesn't matter if its a SIP, MGCP, or H323 (I have done this with MGCP and H323). That means that if people are on a call, that call will get dropped.  It does this so that the route-pattern you added in can become active.
With that said, keep in mind, this only affects the gateways OR route lists that are being affected.  Meaning, if you have a gateway that the route-pattern will not be involved with, the connection will not be reset to that gateway.  Only gateways that are involved will be affected by the addition.  This is verified by this message:

With that said, you certainly do not want to do this during a busy time of the day.  In fact, I would prefer doing this at night if possible.

Friday, October 25, 2013

ACME Packet: How To Change The System Clock/Time On A 4250 ACME Packet Net-Net Device

Why is this important?  The main reason I can think of is when you take a packet capture and you need to line up your time with something you are doing.  For example, I've been making test phone calls out an ACME gateway, and when I've been troubleshooting some SIP calls, its been important that I have the correct time stamp on the log I'm taking.  If the time isn't off, sure you can figure it out, but it just takes more time.  If you have the clock set correctly on the ACME in the first place, you don't have to worry about figuring out what the system time is on the ACME and then lining up your time stamps.
Here is how you set the clock on the ACME:

ACME01# show clock
05:25:13 UTC  THU OCT 22 2013
ACME01#

ACME01# systime-set
Date YYYY MM DD: 2013 10 24
Time HH MM: 08 04

WARNING: Changing the time can have an adverse
         effect on session processing

Do you want to continue [y/n]?: y

Setting time to: THU OCT 24 08:04:00 2013
ACME01# save-config

Monday, October 21, 2013

ACME Packet 4250 Net-Net: How do you take a capture from an ACME 4250 Net-Net device?

 Ive been troublehshooting a call routing problem on a small project Im working on, and I have
had the need to figure out what the ACME in my environment is doing to my call.  I have found
out, through these captures, that my call is being forwarded out the wrong ISP.  So how do I
get this capture, so I can tell for sure what Im seeing?

To turn logging on, do the following:
ACME4250# notify sipd debug
ACME4250#
enabled SIP Debugging

ACME4250# notify sipd siplog
ACME4250#

To turn logging off, do the following:
ACME4250# notify sipd nodebug
ACME4250#
disabled SIP Debugging

ACME4250# notify sipd nosiplog
ACME4250#

Now you have to get the logs.  You will need to FTP into the ACME box and get the logs, like
this:
C:\Users\shane>ftp 10.1.1.1
Connected to 10.1.1.1.
220 ACME4250 FTP server (VxWorks 6.4) ready.
User (10.1.1.1:(none)): shane
331 Password required for user.
Password: password
230 User user logged in.
ftp> cd /ramdrv/logs
250 CWD command successful.
ftp> asc
200 Type set to A.
ftp> get sipmsg.log
200 PORT command successful.
150 Opening ASCII mode data connection for '/ramdrv/logs/sipmsg.log' (131546 bytes).
226 Transfer complete.
ftp: 135087 bytes received in 0.23Seconds 577.29Kbytes/sec.
ftp> get log.sipd
200 PORT command successful.
150 Opening ASCII mode data connection for '/ramdrv/logs/log.sipd' (625802 bytes).
226 Transfer complete.
ftp: 634808 bytes received in 0.39Seconds 1627.71Kbytes/sec.
ftp> bye
221 Goodbye.

C:\Users\shane>

That is how you get the logs.  Now just review to find out what you problems are.

Friday, October 18, 2013

SIP Conversation: T38 Does Not Negotiate For A Successful Fax

WE had this fax problem that when the customer tried to dial any toll free numbers with a fax machine, the fax would not go through.  The customer would complain that the call would connect, then end with an error.  Here is what the Telco found below.  They said that we were sending an "Bye" back to them.  Hmm, from below, it does look like they are correct.
Topology:
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:03:46:352  10.10.10.1     10.20.30.2     INVITE                                                                                
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:03:46:354  10.20.30.2     10.10.10.1     Status              100 Trying                                                        
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:03:48:576  10.20.30.2     10.10.10.1     Status              183 SessnProgrss                                                  
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:03:54:384  10.20.30.2     10.10.10.1     Status              200 OK                                                            
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:03:54:499  10.10.10.1     10.20.30.2     ACK                                                                                   
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:04:00:707  10.10.10.1     10.20.30.2     BYE                                                                                   
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:04:00:771  10.20.30.2     10.10.10.1     Status              200 OK     

So one of the engineers I work with found the problem.  He found that when the Telco sent the negotiations for codec, it did not negotiate correctly, causing the failure above.  However, when he moved, in our CUCM, the search order of the codec (I think he put g729 over g711), then the call would negotiate correctly with the Telco and the fax worked correctly, as seen below.

Here is what the SIP conversation looks like now:
ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:43:055  10.10.10.1     10.20.30.2     INVITE                                                                                
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:43:056  10.20.30.2     10.10.10.1     Status              100 Trying                                                        
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:45:200  10.20.30.2     10.10.10.1     Status              183 SessnProgrss                                                  
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:51:001  10.20.30.2     10.10.10.1     Status              200 OK                                                            
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:51:116  10.10.10.1     10.20.30.2     ACK                                                                                   
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:52:919  10.20.30.2     10.10.10.1     INVITE                                                                                
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:53:420  10.20.30.2     10.10.10.1     INVITE                                                                                
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:54:421  10.20.30.2     10.10.10.1     INVITE                                                                                
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:56:421  10.20.30.2     10.10.10.1     INVITE                                                                                
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:56:799  10.10.10.1     10.20.30.2     Status              200 OK                                                            
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:56:942  10.20.30.2     10.10.10.1     ACK                                                                                   
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:56:964  10.20.30.2     10.10.10.1     INVITE                                                                                
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:57:465  10.20.30.2     10.10.10.1     INVITE                                                                                
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:58:467  10.20.30.2     10.10.10.1     INVITE                                                                                
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:59:513  10.10.10.1     10.20.30.2     Status              200 OK                                                            
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:14:59:651  10.20.30.2     10.10.10.1     ACK                                                                                   
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:15:34:550  10.10.10.1     10.20.30.2     BYE                                                                                   
   ADV_PIP_SCRM_MICRONODE-SIPCloudLink 10/07/2013 20:15:34:614  10.20.30.2     10.10.10.1     Status              200 OK             

Wednesday, October 16, 2013

Cisco CUCM: Caller-ID Shows As The Hunt Group Instead Of The Caller-ID Of The Original Caller

One of the guys came to our department and was saying that the caller-ID number on an incoming call (to a call center) was the number that was actually dialed by the caller (which is directly to a hunt group).  So what happens is that on a DID coming in, it hits a hunt group, which then comes to several callers who wait to answer the phone.  To the internal guys, the caller-ID is the hunt group, until someone answers the phone.  When the phone is answered and the call is connected, THEN the actual caller's caller-ID shows up correctly.  Well, no one wants that.  They, in this case, want the actual caller-ID of the caller, not the hunt group.
So I did some research and found that from CUCM version 8.X and up, the default behavior IS to show the caller-ID of the hunt group, if one is hit on its way to the users.  I found this here:
CSCth95017 - Configurable parameter on how callingparty is displayed for hunt groups

To stop that, here is where you go:
Go to System --> Service Parameters
Select the Publisher --> Cisco CallManager
Select 'Advanced'

Monday, October 14, 2013

SIP: Anatomy Of A Good Call Setup Of A SIP Phone Call

Im doing more with SIP these days, so I wanted to post what a good, successful SIP call looks like.  Here are some things I came up with when looking at this in real time:
In one of my translators:

In another one:

Here is the actual capture:
47894366.001 |09:10:21.888 |AppInfo  |//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 817 from 10.10.90.25:[5060]:
[19287418,NET]
INVITE sip:2055677654@10.10.90.23:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.90.25:5060;branch=z9hG4bK1bf7h72008ogakst05g0.1
From: "WIRELESS CALLER"<sip:2052343232@10.10.90.25;user=phone>;tag=184490972-1381155021847-
To: "Customer"<sip:2055677654@10.10.90.23>
Call-ID: BW1410218470710132124464962@65.211.120.226
CSeq: 161518092 INVITE
Contact: <sip:2052343232@10.10.90.25:5060;transport=udp>
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY
Accept: application/media_control+xml,application/sdp,multipart/mixed
Supported:
Max-Forwards: 68
Content-Type: application/sdp
Content-Length: 203
v=0
o=BroadWorks 2978824933 1 IN IP4 10.10.90.25
s=-
c=IN IP4 10.10.90.25
t=0 0
m=audio 7176 RTP/AVP 18 0 8 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no Source Filename: SDL005_100_000390.txt


47894370.001 |09:10:21.889 |AppInfo  |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 10.10.90.25:[5060]:
[19287419,NET]
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.10.90.25:5060;branch=z9hG4bK1bf7h72008ogakst05g0.1
From: "WIRELESS CALLER"<sip:2052343232@10.10.90.25;user=phone>;tag=184490972-1381155021847-
To: "Customer"<sip:2055677654@10.10.90.23>
Date: Mon, 07 Oct 2013 14:10:21 GMT
Call-ID: BW1410218470710132124464962@65.211.120.226
CSeq: 161518092 INVITE
Allow-Events: presence
Content-Length: 0
 Source Filename: SDL005_100_000390.txt


 47894443.001 |09:10:21.903 |AppInfo  |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 10.10.90.25:[5060]:
[19287420,NET]
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.10.90.25:5060;branch=z9hG4bK1bf7h72008ogakst05g0.1
From: "WIRELESS CALLER"<sip:2052343232@10.10.90.25;user=phone>;tag=184490972-1381155021847-
To: "Customer"<sip:2055677654@10.10.90.23>;tag=4185150~567e8d26-7117-4539-a1ae-3578bcf85b47-98225748
Date: Mon, 07 Oct 2013 14:10:21 GMT
Call-ID: BW1410218470710132124464962@65.211.120.226
CSeq: 161518092 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Contact: <sip:2055677654@10.10.90.23:5060>
Content-Length: 0
 Source Filename: SDL005_100_000390.txt


 47895448.001 |09:10:23.125 |AppInfo  |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 10.10.90.25:[5060]:
[19287452,NET]
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.90.25:5060;branch=z9hG4bK1bf7h72008ogakst05g0.1
From: "WIRELESS CALLER"<sip:2052343232@10.10.90.25;user=phone>;tag=184490972-1381155021847-
To: "Customer"<sip:2055677654@10.10.90.23>;tag=4185150~567e8d26-7117-4539-a1ae-3578bcf85b47-98225748
Date: Mon, 07 Oct 2013 14:10:21 GMT
Call-ID: BW1410218470710132124464962@65.211.120.226
CSeq: 161518092 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence, kpml
Supported: replaces
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Contact: <sip:2055677654@10.10.90.23:5060>
Content-Type: application/sdp
Content-Length: 259
v=0
o=CiscoSystemsCCM-SIP 4185150 1 IN IP4 10.10.90.23
s=SIP Call
c=IN IP4 10.110.135.61
b=TIAS:8000
b=AS:8
t=0 0
m=audio 27318 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15 Source Filename: SDL005_100_000390.txt


47895496.001 |09:10:23.331 |AppInfo  |//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 487 from 10.10.90.25:[5060]:
[19287453,NET]
ACK sip:2055677654@10.10.90.23:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.90.25:5060;branch=z9hG4bKgjit49107ofg7j08i4s1.1
From: "WIRELESS CALLER"<sip:2052343232@10.10.90.25;user=phone>;tag=184490972-1381155021847-
To: "Customer"<sip:2055677654@10.10.90.23>;tag=4185150~567e8d26-7117-4539-a1ae-3578bcf85b47-98225748
Call-ID: BW1410218470710132124464962@65.211.120.226
CSeq: 161518092 ACK
Contact: <sip:2052343232@10.10.90.25:5060;transport=udp>
Max-Forwards: 68
Content-Length: 0
 Source Filename: SDL005_100_000390.txt


 47899066.001 |09:10:29.980 |AppInfo  |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 10.10.90.25:[5060]:
[19287561,NET]
BYE sip:2052343232@10.10.90.25:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.10.90.23:5060;branch=z9hG4bK28496437dc5c60
From: "Customer"<sip:2055677654@10.10.90.23>;tag=4185150~567e8d26-7117-4539-a1ae-3578bcf85b47-98225748
To: "WIRELESS CALLER"<sip:2052343232@10.10.90.25;user=phone>;tag=184490972-1381155021847-
Date: Mon, 07 Oct 2013 14:10:23 GMT
Call-ID: BW1410218470710132124464962@65.211.120.226
User-Agent: Cisco-CUCM9.1
Max-Forwards: 70
CSeq: 101 BYE
Reason: Q.850;cause=16
Content-Length: 0
 Source Filename: SDL005_100_000390.txt


 47899077.001 |09:10:30.044 |AppInfo  |//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 368 from 10.10.90.25:[5060]:
[19287562,NET]
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.90.23:5060;branch=z9hG4bK28496437dc5c60
From: "Customer"<sip:2055677654@10.10.90.23>;tag=4185150~567e8d26-7117-4539-a1ae-3578bcf85b47-98225748
To: "WIRELESS CALLER"<sip:2052343232@10.10.90.25;user=phone>;tag=184490972-1381155021847-
Call-ID: BW1410218470710132124464962@65.211.120.226
CSeq: 101 BYE
Content-Length: 0
 Source Filename: SDL005_100_000390.txt

Saturday, October 12, 2013

Cisco Router: Where Is The CF Flash Card In A 2900 Router

I had to find this for a CME I was doing on a 2901 Cisco router.  Its a little different than just visually seeing it and pushing the push button in to eject the card.  See below where to find this card.  There are two slots, but circled below is the first slot for the flash card.

Use a screwdriver or something to push toward cover, as below.

Then, just eject.

Wednesday, October 9, 2013

Palo Alto: How To See The Update Progress

I went to do a "demo" Palo here recently.  I really do like this firewall.  In getting this firewall ready, my colleague got the license ready on the Palo site (Thanks Jim) and I did the config and downloaded the license and updates.  In trying to figure out where the download and install process was at in the GUI (which you cant), I thought I would find this out in CLI.
 So go into CLI and here is the command you will run to see the progress for the updates:
admin@PA-500>show jobs all
Enqueued                     ID             Type    Status Result Completed
--------------------------------------------------------------------------
2013/09/25 11:11:43           7          Install      PEND   PEND Still Pending
2013/09/25 11:10:57           6          Content       ACT   PEND        10%
2013/09/25 11:10:19           5           Downld       FIN     OK 11:11:28
2013/09/25 11:07:17           4          Install       FIN     OK 11:10:58
2013/09/25 11:05:56           3           Downld       FIN     OK 11:06:09
2013/09/25 11:03:27           2           Commit       FIN     OK 11:04:19
2013/09/25 10:48:07           1          AutoCom       FIN     OK 10:49:32

You will notice the second job being updated and its progress.  See below.  Its better than sitting in the GUI and wondering where its all on the process.

admin@PA-500>show jobs all
Enqueued                     ID             Type    Status Result Completed
--------------------------------------------------------------------------
2013/09/25 11:11:43           7          Install      PEND   PEND Still Pending
2013/09/25 11:10:57           6          Content       ACT   PEND        45%
2013/09/25 11:10:19           5           Downld       FIN     OK 11:11:28
2013/09/25 11:07:17           4          Install       FIN     OK 11:10:58
2013/09/25 11:05:56           3           Downld       FIN     OK 11:06:09
2013/09/25 11:03:27           2           Commit       FIN     OK 11:04:19
2013/09/25 10:48:07           1          AutoCom       FIN     OK 10:49:32

admin@PA-500>show jobs all
Enqueued                     ID             Type    Status Result Completed
--------------------------------------------------------------------------
2013/09/25 11:11:43           7          Install      PEND   PEND Still Pending
2013/09/25 11:10:57           6          Content       ACT   PEND        55%
2013/09/25 11:10:19           5           Downld       FIN     OK 11:11:28
2013/09/25 11:07:17           4          Install       FIN     OK 11:10:58
2013/09/25 11:05:56           3           Downld       FIN     OK 11:06:09
2013/09/25 11:03:27           2           Commit       FIN     OK 11:04:19
2013/09/25 10:48:07           1          AutoCom       FIN     OK 10:49:32

Monday, October 7, 2013

Mono-alphabetic in Java -- by Babak Hoseini

Today I have another special guest post.  Babak Hoseini has been happy to write about encryption.  He has written a cool little source code that will do some encryption for you.  Thank you Babak for writing a guest post for me.  As always, I appreciate your input.  --Shane Killen

Mono-alphabetic in Java   -- by Babak Hoseini
A mono-alphabetic cipher is a simple substitution cipher wherein each letter of the plaintext is replaced by another letter in the ciphertext. An example of a mono-alphabetic cipher key follows:

Plain  : A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Cipher : z y x w v u t s r q p o n m l k j i h g f e d c b a

This key means that any 'M' in the plaintext will be replaced by a 'n' in the ciphertext, any 'P' in the plaintext will be replaced by a 'k' in the ciphertext, and so on.

For instance, plaintext is  : “meet me at the party” and after encrypt you get “nvvg1nv1zg1gsv1kzigb
I wrote the program below in Java that will encrypt plaintext to ciphertext:

package encryption;

public class Encryption {

public static void main(String[] args) {
// TODO Auto-generated method stub
String plaintext = "meet me at the party";
char[] myarr = plaintext.toCharArray();
for(int count=0 ; count < myarr.length ; count++){
char cipher = myarr[count];
switch (cipher) {
case 'a':
System.out.print("z");
break;
case 'b':
System.out.print("y");
break;
case 'c':
System.out.print("x");
break;
case 'd':
System.out.print("w");
break;
case 'e':
System.out.print("v");
break;
case 'f':
System.out.print("u");
break;
case 'g':
System.out.print("t");
break;
case 'h':
System.out.print("s");
break;
case 'i':
System.out.print("r");
break;
case 'j':
System.out.print("q");
break;
case 'k':
System.out.print("p");
break;
case 'l':
System.out.print("o");
break;
case 'm':
System.out.print("n");
break;
case 'n':
System.out.print("m");
break;
case 'o':
System.out.print("l");
break;
case 'p':
System.out.print("k");
break;
case 'q':
System.out.print("j");
break;
case 'r':
System.out.print("i");
break;
case 's':
System.out.print("h");
break;
case 't':
System.out.print("g");
break;
case 'u':
System.out.print("f");
break;
case 'v':
System.out.print("e");
break;
case 'w':
System.out.print("d");
break;
case 'x':
System.out.print("c");
break;
case 'y':
System.out.print("b");
break;
case 'z':
System.out.print("a");
break;
case ' ':
System.out.print("1");
break;
case '1':
System.out.print(" ");
}
}
}

}


Thursday, October 3, 2013

Cisco ASA: How Can You Tell How Many User Licenses Is Being Used On The ASA

Have you ever had a site where you had an ASA with 10 or 50 user licenses, and they were really close to the user license count?  I have, several times.  You get some users who cant 'get on the Internet'.  This IP phone doesnt work anymore (cant stay registered).  Any number of things you could hear.
So how do you know for sure if you are over that license limit?  Good question.
Do the following command below, and keep in mind that this is concurrent connections.
.5505# sho local-host
Detected interface 'outside' as the Internet interface. Host limit applies to all other interfaces.
Current host count: 48, towards licensed host limit of: 50

Interface outside: 44 active, 209 maximum active, 0 denied
local host: <111.221.74.13>,
    TCP flow count/limit = 0/unlimited
    TCP embryonic count to host = 0
    TCP intercept watermark = unlimited
    UDP flow count/limit = 1/unlimited

  Conn:
    UDP outside 111.221.74.13:40016 inside 192.168.104.28:15197, idle 0:01:41, bytes 170, flags -
local host: <91.190.216.61>,
    TCP flow count/limit = 1/unlimited
    TCP embryonic count to host = 0
    TCP intercept watermark = unlimited
    UDP flow count/limit = 0/unlimited

... the rest is deleted for brevity...

This helps to know where you are in the user usage.  No one wants to count devices.
And, if you are close and need to run the timer down from the default 3 hours, you can do the following (if people are coming and going, like a guest to the network that just pushes you over that license limit).
This is the default:
timeout xlate 3:00:00

This is what you can do to run the timeout to 5 minutes:
timeout xlate 0:05:00



Tuesday, October 1, 2013

Cisco: Route-Map Explanations For Policy Based Routing (PBR)

I wrote this out for one of my customers so that they would have a good understanding of route-maps.  This is a basic route-map to just set the next-hop of packets defined in the ACL.  On the left is the config.  On the right is the explanation.