Friday, December 26, 2008

NAT Hairpinning using NAT pools & PBR

Here is an interesting problem i met some days ago...



All hosts want to communicate each other by using their respective external (inside global) ip addresses, while dynamic/static NAT takes places in front of them.

1) Introducing the problem

This is an issue being "resolved" in RFC 4787 (for UDP) & RFC 5382 (for TCP), known also as NAT hairpinning, but Cisco doesn't seem to have implemented any of these in its routers (although Cisco's name is included in both RFCs). According to the 2nd RFC:

NATs that forward packets originating from an internal address, destined for an external address that matches the active mapping for an internal address, back to that internal address are defined in [BEHAVE-UDP] as supporting "hairpinning". If the NAT presents the hairpinned packet with an external source IP address and port (i.e., the mapped source address and port of the originating internal endpoint), then it is defined to have "External source IP address and port" for hairpinning. Hairpinning is necessary to allow two internal endpoints (known to each other only by their external mapped addresses) to communicate with each other. "External source IP address and port" behavior for hairpinning avoids confusing implementations that expect the external source IP address and port.

To make it more interesting i have added multiple wan connections, each one serving a specific block of ips, so a little bit of load-balancing plus redundancy is happening too.

HOST1 and HOST2 access the internet through the same wan connection, HOST3 uses another wan connection (through the same router as HOST1 and HOST2) and so does HOST4 (through a different router than all other hosts).

Concisely:

HOST1 -> HGW S1/0 -> R1 S1/0
HOST2 -> HGW S1/0 -> R1 S1/0
HOST3 -> HGW S1/1 -> R1 S1/1
HOST3 -> HGW S1/2 -> R2 S1/2

HGW is the router where all these hosts are directly connected, probably your home gateway. It has 3 wan connections to your ISP for load-balancing/redundancy reasons. This is where all the serious stuff (NAT & PBR) is taking place.

R1, R2 are the ISP routers where the wan connections are and CORE represents (in our case) the internet.

2) Finding solutions

In order to implement my solution, you'll need to have static ips for your wan connection plus a block of extra ips (one ip is enough) per static account. I couldn't think of a way to implement it without using extra ips (besides an idea of using VRFs, but i still don't feel confident enough to experiment with them; maybe in an later version). You'll also need some extra private ips for your HGW, but these come in cheap, so no need to worry.

The whole concept is heavily based on policy-based routing (PBR). The general idea is to have each host's source of the packet being translated to an ip not known internally (nat pool), so static NAT won't be used and PBR can actually take place.

3) Connection and ip details

WAN1 : 100.1.12.0/30 (extra ips : 100.10.12.0/30)
WAN2 : 100.1.33.0/30 (extra ips : 100.10.33.0/30)
WAN3 : 100.1.44.0/30 (extra ips : 100.10.44.0/30)

HOST1 : 10.10.10.1
HOST2 : 10.10.10.2
HOST3 : 10.10.10.3
HOST4 : 10.10.10.4

4) Configurations

HGW



! Interface Loopback0 is used as an intermediate hop for doing NAT and PBR
! for the inside->outside direction.

interface Loopback0
ip address 11.11.11.1 255.255.255.252
ip nat outside
ip virtual-reassembly
ip policy route-map LOOPBACK->OUTSIDE-ROUTE-MAP
!

! Interface Loopback1 is used as an intermediate hop for doing NAT
! for the outside->inside direction (PBR is not needed because
! all hosts are connected on the same inside interface).
! Since Loopback interfaces do not have a direction,
! we cannot use a single loopback for both directions (PBR will apply in both).
! If every host was using a different nat pool, then we wouldn't need
! this interface. We can probably avoid using this interface too,
! if we make ACLs used in PBR match ports as well as ips.

interface Loopback1
ip address 22.22.22.2 255.255.255.255
ip nat outside
ip virtual-reassembly
!

! Fa0/0 interface is the interface where all hosts are directly connected to.

interface FastEthernet0/0
ip address 10.10.10.254 255.255.255.0
ip nat inside
ip virtual-reassembly
ip policy route-map INSIDE->OUTSIDE-ROUTE-MAP
!

! Interfaces S1/0, S1/1, S1/2 are the wan connections to the ISP,
! each one serving a specific block of host ips.

interface Serial1/0
description ** R1 S1/0 **
ip address 100.1.12.2 255.255.255.252
ip policy route-map OUTSIDE->INSIDE-ROUTE-MAP
!
interface Serial1/1
description ** R1 S1/1 **
ip address 100.1.33.2 255.255.255.252
ip policy route-map OUTSIDE->INSIDE-ROUTE-MAP
!
interface Serial1/2
description ** R2 S1/2 **
ip address 100.1.44.2 255.255.255.252
ip policy route-map OUTSIDE->INSIDE-ROUTE-MAP
!

! These default routes are not actually needed, if we use PBR for all our host ips.
! So we need these, only if we don't use PBR under Loopback0 and Fa0/0.

ip route 0.0.0.0 0.0.0.0 Serial1/0
ip route 0.0.0.0 0.0.0.0 Serial1/1
ip route 0.0.0.0 0.0.0.0 Serial1/2
!

! We use a nat pool for each group of hosts that we want to treat differently.

ip nat pool HOST12-NAT-POOL 100.10.12.1 100.10.12.1 prefix-length 30
ip nat pool HOST3-NAT-POOL 100.10.33.1 100.10.33.1 prefix-length 30
ip nat pool HOST4-NAT-POOL 100.10.44.1 100.10.44.1 prefix-length 30
ip nat inside source list HOST12-ACL pool HOST12-NAT-POOL overload
ip nat inside source list HOST3-ACL pool HOST3-NAT-POOL overload
ip nat inside source list HOST4-ACL pool HOST4-NAT-POOL overload
!

! We use static nat, so each host keeps an open port for incoming connections.
! Different hosts use different ports, so many of them can be used simultaneously
! with the same inside global ip.

ip nat inside source static tcp 10.10.10.1 1081 100.10.12.1 1081 extendable
ip nat inside source static tcp 10.10.10.2 1082 100.10.12.1 1082 extendable
ip nat inside source static tcp 10.10.10.3 1083 100.10.33.1 1083 extendable
ip nat inside source static tcp 10.10.10.4 1084 100.10.44.1 1084 extendable
!

! These ACLs are used when doing NAT and PBR under Fa0/0.

ip access-list extended HOST12-ACL
permit ip host 10.10.10.1 any
permit ip host 10.10.10.2 any
ip access-list extended HOST3-ACL
permit ip host 10.10.10.3 any
ip access-list extended HOST4-ACL
permit ip host 10.10.10.4 any
!

! These ACLs are used when doing PBR under Loopback0.
! We match on the inside global ip as the source, because inside NAT has already happened,
! while outside hasn't.

ip access-list extended HOST12-NATTED-SRC-ACL
permit ip host 100.10.12.1 any
ip access-list extended HOST3-NATTED-SRC-ACL
permit ip host 100.10.33.1 any
ip access-list extended HOST4-NATTED-SRC-ACL
permit ip host 100.10.44.1 any
!

! This ACL is used when doing PBR under all Serial interfaces.
! We match on the inside global ip as the destination,
! because outside nat hasn't happened yet.

ip access-list extended HOSTS-NATTED-DST-ACL
permit ip any host 100.10.12.1
permit ip any host 100.10.33.1
permit ip any host 100.10.44.1
!

! This route-map is applied under Fa0/0 and forwards packets from all hosts to Loopback0.
! You can also use a single ACL for all hosts, instead of an ACL per group of hosts.
! In our case we have the ACLs ready because of nat.

route-map INSIDE->OUTSIDE-ROUTE-MAP permit 10
match ip address HOST12-ACL HOST3-ACL HOST4-ACL
set interface Loopback0
!

! This route-map is applied under Loopback0 and forwards packets
! to the correct Serial interface according to the natted (inside global) source ip.
! For redundancy reasons all Serial interfaces are defined as outgoing
! and for load-balancing reasons, each group uses the Serial interfaces
! in a specific order.

route-map LOOPBACK->OUTSIDE-ROUTE-MAP permit 10
match ip address HOST12-NATTED-SRC-ACL
set interface Serial1/0 Serial1/1 Serial1/2
!
route-map LOOPBACK->OUTSIDE-ROUTE-MAP permit 20
match ip address HOST3-NATTED-SRC-ACL
set interface Serial1/1 Serial1/2 Serial1/0
!
route-map LOOPBACK->OUTSIDE-ROUTE-MAP permit 30
match ip address HOST4-NATTED-SRC-ACL
set interface Serial1/2 Serial1/0 Serial1/1
!

! This route-map is applied under all Serial interfaces and forwards
! incoming (from ISP) packets to Loopback1, so the hosts' inside global ip can be translated
! to the appropriate inside local ip.

route-map OUTSIDE->INSIDE-ROUTE-MAP permit 10
match ip address HOSTS-NATTED-DST-ACL
set interface Loopback1


R1

interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
ip address 100.5.0.1 255.255.255.0
!
interface Serial1/0
description ** HGW S1/0 **
ip address 100.1.12.1 255.255.255.252
!
interface Serial1/1
description ** HGW S1/1 **
ip address 100.1.33.1 255.255.255.252
!
router ospf 100
router-id 1.1.1.1
redistribute connected subnets
redistribute static subnets
passive-interface Loopback0
network 1.1.1.1 0.0.0.0 area 0
network 100.5.0.1 0.0.0.0 area 0
!

! These static routes are used on the ISP router, so our incoming traffic can
! be forwarded to the appropriate interface.

ip route 100.10.12.0 255.255.255.252 100.1.12.2
ip route 100.10.33.0 255.255.255.252 100.1.33.2


R2

interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
ip address 100.5.0.2 255.255.255.0
!
interface Serial1/2
description ** HGW S1/2 **
ip address 100.1.44.1 255.255.255.252
!
router ospf 100
router-id 2.2.2.2
redistribute connected subnets
redistribute static subnets
passive-interface Loopback0
network 2.2.2.2 0.0.0.0 area 0
network 100.5.0.2 0.0.0.0 area 0
!

! These static routes are used on the ISP router, so our incoming traffic can
! be forwarded to the appropriate interface.

ip route 100.10.44.0 255.255.255.252 100.1.44.2


CORE

interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
interface FastEthernet0/0
ip address 100.5.0.5 255.255.255.0
ip ospf priority 2
!
router ospf 100
router-id 5.5.5.5
passive-interface Loopback0
network 5.5.5.5 0.0.0.0 area 0
network 100.5.0.5 0.0.0.0 area 0


HOST1,HOST2,HOST3,HOST4 do not have something special, besides an http server (each one on a different port), so incoming connections can be checked and verified.


5) Test cases

We're going to examine three different cases of connections between various hosts. Each host is acting as a client (initiating connections to the internet) and as a server (accepting connections from the internet). In our case, the internet can be any of the other hosts too.

We'll keep the following debugs enabled, so we can watch better what is happening.

"debug ip nat det"
"debug ip policy"
"debug ip packet det" - used partially

In a production environment, you'll probably want to take some precautions before enabling them.

Before we start, let's take a look the the nat translation table. Only static nat entries should be there.

HGW#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 100.10.12.1:1081 10.10.10.1:1081 --- ---
tcp 100.10.12.1:1082 10.10.10.2:1082 --- ---
tcp 100.10.33.1:1083 10.10.10.3:1083 --- ---
tcp 100.10.44.1:1084 10.10.10.4:1084 --- ---


5.1) HOST1 is trying to access HOST2 (same wan connections, same router)

First we test HOST1's and HOST2's connectivity to the internet (dynamic NAT) :

HOST1#p 5.5.5.5 rep 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 200/200/200 ms

HOST2#p 5.5.5.5 rep 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 196/196/196 ms


HGW debugs


! Request from 10.10.10.1:7 (100.10.12.1:7) to 5.5.5.5:7 (5.5.5.5:7)

! Traffic leaving the router towards the ISP
! 10.10.10.1 ==(PBR)(NAT)==> Loopback0 ==(PBR)==> Serial1/0

Dec 26 14:37:55.367: IP: s=10.10.10.1 (FastEthernet0/0), d=5.5.5.5, len 100, FIB policy match
Dec 26 14:37:55.367: IP: s=10.10.10.1 (FastEthernet0/0), d=5.5.5.5, len 100, FIB policy match
Dec 26 14:37:55.375: IP: s=10.10.10.1 (FastEthernet0/0), d=5.5.5.5, len 100, policy match
Dec 26 14:37:55.375: IP: route map INSIDE->OUTSIDE-ROUTE-MAP, item 10, permit
Dec 26 14:37:55.379: IP: s=10.10.10.1 (FastEthernet0/0), d=5.5.5.5 (Loopback0), len 100, policy routed
Dec 26 14:37:55.383: IP: FastEthernet0/0 to Loopback0 5.5.5.5
Dec 26 14:37:55.383: NAT: address not stolen for 10.10.10.1, proto 1 port 7
Dec 26 14:37:55.387: mapping pointer available mapping:0
Dec 26 14:37:55.387: NAT: creating portlist proto 1 globaladdr 100.10.12.1
Dec 26 14:37:55.391: NAT: [0] Allocated Port for 10.10.10.1 -> 100.10.12.1: wanted 7 got 7
Dec 26 14:37:55.395: NAT: i: icmp (10.10.10.1, 7) -> (5.5.5.5, 7) [7]
Dec 26 14:37:55.399: NAT: s=10.10.10.1->100.10.12.1, d=5.5.5.5 [7]
Dec 26 14:37:55.403: IP: s=100.10.12.1 (Loopback0), d=5.5.5.5, len 100, policy match
Dec 26 14:37:55.403: IP: route map LOOPBACK->OUTSIDE-ROUTE-MAP, item 10, permit
Dec 26 14:37:55.407: IP: s=100.10.12.1 (Loopback0), d=5.5.5.5 (Serial1/0), len 100, policy routed
Dec 26 14:37:55.411: IP: Loopback0 to Serial1/0 5.5.5.5

! Reply from 5.5.5.5:7 (5.5.5.5:7) to 100.10.12.1:7 (10.10.10.1:7)

! Traffic entering the router from the ISP
! Serial1/0 ==(PBR)==> Loopback1 ==(NAT)==> 10.10.10.1

Dec 26 14:37:55.463: IP: s=5.5.5.5 (Serial1/0), d=100.10.12.1, len 100, FIB policy match
Dec 26 14:37:55.467: IP: s=5.5.5.5 (Serial1/0), d=100.10.12.1, len 100, FIB policy match
Dec 26 14:37:55.475: IP: s=5.5.5.5 (Serial1/0), d=100.10.12.1, len 100, policy match
Dec 26 14:37:55.479: IP: route map OUTSIDE->INSIDE-ROUTE-MAP, item 10, permit
Dec 26 14:37:55.479: IP: s=5.5.5.5 (Serial1/0), d=100.10.12.1 (Loopback1), len 100, policy routed
Dec 26 14:37:55.483: IP: Serial1/0 to Loopback1 100.10.12.1
Dec 26 14:37:55.487: NAT: o: icmp (5.5.5.5, 7) -> (100.10.12.1, 7) [7]
Dec 26 14:37:55.491: NAT: s=5.5.5.5, d=100.10.12.1->10.10.10.1 [7]


! Request from 10.10.10.2:1 (100.10.12.1:1) to 5.5.5.5:1 (5.5.5.5:1)

! Traffic leaving the router towards the ISP
! 10.10.10.2 ==(PBR)(NAT)==> Loopback0 ==(PBR)==> Serial1/0

Dec 26 14:37:59.115: IP: s=10.10.10.2 (FastEthernet0/0), d=5.5.5.5, len 100, FIB policy match
Dec 26 14:37:59.119: IP: s=10.10.10.2 (FastEthernet0/0), d=5.5.5.5, len 100, FIB policy match
Dec 26 14:37:59.123: IP: s=10.10.10.2 (FastEthernet0/0), d=5.5.5.5, len 100, policy match
Dec 26 14:37:59.127: IP: route map INSIDE->OUTSIDE-ROUTE-MAP, item 10, permit
Dec 26 14:37:59.131: IP: s=10.10.10.2 (FastEthernet0/0), d=5.5.5.5 (Loopback0), len 100, policy routed
Dec 26 14:37:59.131: IP: FastEthernet0/0 to Loopback0 5.5.5.5
Dec 26 14:37:59.131: mapping pointer available mapping:0
Dec 26 14:37:59.135: NAT: [0] Allocated Port for 10.10.10.2 -> 100.10.12.1: wanted 1 got 1
Dec 26 14:37:59.135: NAT: i: icmp (10.10.10.2, 1) -> (5.5.5.5, 1) [1]
Dec 26 14:37:59.139: NAT: s=10.10.10.2->100.10.12.1, d=5.5.5.5 [1]
Dec 26 14:37:59.143: IP: s=100.10.12.1 (Loopback0), d=5.5.5.5, len 100, policy match
Dec 26 14:37:59.147: IP: route map LOOPBACK->OUTSIDE-ROUTE-MAP, item 10, permit
Dec 26 14:37:59.147: IP: s=100.10.12.1 (Loopback0), d=5.5.5.5 (Serial1/0), len 100, policy routed
Dec 26 14:37:59.151: IP: Loopback0 to Serial1/0 5.5.5.5

! Reply from 5.5.5.5:1 (5.5.5.5:1) to 100.10.12.1:1 (10.10.10.2:1)

! Traffic entering the router from the ISP
! Serial1/0 ==(PBR)==> Loopback1 ==(NAT)==> 10.10.10.2

Dec 26 14:37:59.183: IP: s=5.5.5.5 (Serial1/0), d=100.10.12.1, len 100, FIB policy match
Dec 26 14:37:59.187: IP: s=5.5.5.5 (Serial1/0), d=100.10.12.1, len 100, FIB policy match
Dec 26 14:37:59.195: IP: s=5.5.5.5 (Serial1/0), d=100.10.12.1, len 100, policy match
Dec 26 14:37:59.199: IP: route map OUTSIDE->INSIDE-ROUTE-MAP, item 10, permit
Dec 26 14:37:59.203: IP: s=5.5.5.5 (Serial1/0), d=100.10.12.1 (Loopback1), len 100, policy routed
Dec 26 14:37:59.207: IP: Serial1/0 to Loopback1 100.10.12.1
Dec 26 14:37:59.211: NAT: o: icmp (5.5.5.5, 1) -> (100.10.12.1, 1) [1]
Dec 26 14:37:59.211: NAT: s=5.5.5.5, d=100.10.12.1->10.10.10.2 [1]


We check the nat translation table and two new dynamic entries have been created :

HGW#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 100.10.12.1:7 10.10.10.1:7 5.5.5.5:7 5.5.5.5:7
tcp 100.10.12.1:1081 10.10.10.1:1081 --- ---
icmp 100.10.12.1:1 10.10.10.2:1 5.5.5.5:1 5.5.5.5:1
tcp 100.10.12.1:1082 10.10.10.2:1082 --- ---
tcp 100.10.33.1:1083 10.10.10.3:1083 --- ---
tcp 100.10.44.1:1084 10.10.10.4:1084 --- ---


Then we test connectivity between the 2 hosts (dynamic/static NAT) :

HOST1#tel 100.10.12.1 1082
Trying 100.10.12.1, 1082 ... Open


HOST2#sh tcp br
TCB Local Address Foreign Address (state)
66504154 10.10.10.2.1082 100.10.12.1.24495 ESTAB


HGW debugs


! Request from 10.10.10.1:24495 (100.10.12.1:24495) to 100.10.12.1:1082 (10.10.10.2:1082)

! Traffic leaving the router towards the ISP
! 10.10.10.1 ==(PBR)(NAT)==> Loopback0 ==(PBR)==> Serial1/0

Dec 26 14:16:21.007: IP: s=10.10.10.1 (FastEthernet0/0), d=100.10.12.1, len 44, FIB policy match
Dec 26 14:16:21.011: IP: s=10.10.10.1 (FastEthernet0/0), d=100.10.12.1, len 44, FIB policy match
Dec 26 14:16:21.015: IP: s=10.10.10.1 (FastEthernet0/0), d=100.10.12.1, len 44, policy match
Dec 26 14:16:21.019: IP: route map INSIDE->OUTSIDE-ROUTE-MAP, item 10, permit
Dec 26 14:16:21.019: IP: s=10.10.10.1 (FastEthernet0/0), d=100.10.12.1 (Loopback0), len 44, policy routed
Dec 26 14:16:21.023: IP: FastEthernet0/0 to Loopback0 100.10.12.1
Dec 26 14:16:21.027: NAT: address not stolen for 10.10.10.1, proto 6 port 24495
Dec 26 14:16:21.031: mapping pointer available mapping:0
Dec 26 14:16:21.031: NAT: [0] Allocated Port for 10.10.10.1 -> 100.10.12.1: wanted 24495 got 24495
Dec 26 14:16:21.035: NAT: i: tcp (10.10.10.1, 24495) -> (100.10.12.1, 1082) [24314]
Dec 26 14:16:21.039: NAT: s=10.10.10.1->100.10.12.1, d=100.10.12.1 [24314]
Dec 26 14:16:21.055: IP: s=100.10.12.1 (Loopback0), d=100.10.12.1, len 44, policy match
Dec 26 14:16:21.055: IP: route map LOOPBACK->OUTSIDE-ROUTE-MAP, item 10, permit
Dec 26 14:16:21.059: IP: s=100.10.12.1 (Loopback0), d=100.10.12.1 (Serial1/0), len 44, policy routed
Dec 26 14:16:21.063: IP: Loopback0 to Serial1/0 100.10.12.1

! Traffic entering the router from the ISP
! Serial1/0 ==(PBR)==> Loopback1 ==(NAT)==> 10.10.10.2

Dec 26 14:16:21.087: IP: s=100.10.12.1 (Serial1/0), d=100.10.12.1, len 44, FIB policy match
Dec 26 14:16:21.091: IP: s=100.10.12.1 (Serial1/0), d=100.10.12.1, len 44, FIB policy match
Dec 26 14:16:21.095: IP: s=100.10.12.1 (Serial1/0), d=100.10.12.1, len 44, policy match
Dec 26 14:16:21.099: IP: route map OUTSIDE->INSIDE-ROUTE-MAP, item 10, permit
Dec 26 14:16:21.103: IP: s=100.10.12.1 (Serial1/0), d=100.10.12.1 (Loopback1), len 44, policy routed
Dec 26 14:16:21.103: IP: Serial1/0 to Loopback1 100.10.12.1
Dec 26 14:16:21.111: NAT: o: tcp (100.10.12.1, 24495) -> (100.10.12.1, 1082) [24314]
Dec 26 14:16:21.111: NAT: s=100.10.12.1, d=100.10.12.1->10.10.10.2 [24314]


! Reply from 10.10.10.2:1082 (100.10.12.1:1082) to 100.10.12.1:24495 (10.10.10.1:24495)

! Traffic leaving the router towards the ISP
! 10.10.10.2 ==(PBR)(NAT)==> Loopback0 ==(PBR)==> Serial1/0

Dec 26 14:16:21.187: IP: s=10.10.10.2 (FastEthernet0/0), d=100.10.12.1, len 44, FIB policy match
Dec 26 14:16:21.191: IP: s=10.10.10.2 (FastEthernet0/0), d=100.10.12.1, len 44, FIB policy match
Dec 26 14:16:21.195: IP: s=10.10.10.2 (FastEthernet0/0), d=100.10.12.1, len 44, policy match
Dec 26 14:16:21.199: IP: route map INSIDE->OUTSIDE-ROUTE-MAP, item 10, permit
Dec 26 14:16:21.203: IP: s=10.10.10.2 (FastEthernet0/0), d=100.10.12.1 (Loopback0), len 44, policy routed
Dec 26 14:16:21.207: IP: FastEthernet0/0 to Loopback0 100.10.12.1
Dec 26 14:16:21.211: NAT: i: tcp (10.10.10.2, 1082) -> (100.10.12.1, 24495) [61514]
Dec 26 14:16:21.211: NAT: s=10.10.10.2->100.10.12.1, d=100.10.12.1 [61514]
Dec 26 14:16:21.215: IP: s=100.10.12.1 (Loopback0), d=100.10.12.1, len 44, policy match
Dec 26 14:16:21.219: IP: route map LOOPBACK->OUTSIDE-ROUTE-MAP, item 10, permit
Dec 26 14:16:21.223: IP: s=100.10.12.1 (Loopback0), d=100.10.12.1 (Serial1/0), len 44, policy routed
Dec 26 14:16:21.227: IP: Loopback0 to Serial1/0 100.10.12.1

! Traffic entering the router from the ISP
! Serial1/0 ==(PBR)==> Loopback1 ==(NAT)==> 10.10.10.1

Dec 26 14:16:21.247: IP: s=100.10.12.1 (Serial1/0), d=100.10.12.1, len 44, FIB policy match
Dec 26 14:16:21.247: IP: s=100.10.12.1 (Serial1/0), d=100.10.12.1, len 44, FIB policy match
Dec 26 14:16:21.259: IP: s=100.10.12.1 (Serial1/0), d=100.10.12.1, len 44, policy match
Dec 26 14:16:21.263: IP: route map OUTSIDE->INSIDE-ROUTE-MAP, item 10, permit
Dec 26 14:16:21.263: IP: s=100.10.12.1 (Serial1/0), d=100.10.12.1 (Loopback1), len 44, policy routed
Dec 26 14:16:21.267: IP: Serial1/0 to Loopback1 100.10.12.1
Dec 26 14:16:21.271: NAT: o: tcp (100.10.12.1, 1082) -> (100.10.12.1, 24495) [61514]
Dec 26 14:16:21.275: NAT: s=100.10.12.1, d=100.10.12.1->10.10.10.1 [61514]


We check the nat translation table and we see that :
a) a new dynamic entry for 10.10.10.1 has been created
b) a new dynamic entry based on the static nat for 10.10.10.2:1082 has been created

HGW#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 100.10.12.1:1081 10.10.10.1:1081 --- ---
tcp 100.10.12.1:24495 10.10.10.1:24495 100.10.12.1:1082 100.10.12.1:1082
tcp 100.10.12.1:1082 10.10.10.2:1082 100.10.12.1:24495 100.10.12.1:24495
tcp 100.10.12.1:1082 10.10.10.2:1082 --- ---
tcp 100.10.33.1:1083 10.10.10.3:1083 --- ---
tcp 100.10.44.1:1084 10.10.10.4:1084 --- ---



5.2) HOST1 is trying to access HOST3 (different wan connections, same router)

First we test HOST3's connectivity to the internet (dynamic NAT) :

HOST3#p 5.5.5.5 rep 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 168/168/168 ms


HGW debugs


! Request from 10.10.10.3:0 (100.10.33.1:0) to 5.5.5.5:0 (5.5.5.5:0)

! Traffic leaving the router towards the ISP
! 10.10.10.3 ==(PBR)(NAT)==> Loopback0 ==(PBR)==> Serial1/1

Dec 26 14:43:07.567: IP: s=10.10.10.3 (FastEthernet0/0), d=5.5.5.5, len 100, FIB policy match
Dec 26 14:43:07.571: IP: s=10.10.10.3 (FastEthernet0/0), d=5.5.5.5, len 100, FIB policy match
Dec 26 14:43:07.579: IP: s=10.10.10.3 (FastEthernet0/0), d=5.5.5.5, len 100, policy match
Dec 26 14:43:07.579: IP: route map INSIDE->OUTSIDE-ROUTE-MAP, item 10, permit
Dec 26 14:43:07.583: IP: s=10.10.10.3 (FastEthernet0/0), d=5.5.5.5 (Loopback0), len 100, policy routed
Dec 26 14:43:07.587: IP: FastEthernet0/0 to Loopback0 5.5.5.5
Dec 26 14:43:07.587: NAT: address not stolen for 10.10.10.3, proto 1 port 0
Dec 26 14:43:07.591: mapping pointer available mapping:0
Dec 26 14:43:07.591: NAT: creating portlist proto 1 globaladdr 100.10.33.1
Dec 26 14:43:07.595: NAT: [0] Allocated Port for 10.10.10.3 -> 100.10.33.1: wanted 0 got 0
Dec 26 14:43:07.599: NAT: i: icmp (10.10.10.3, 0) -> (5.5.5.5, 0) [0]
Dec 26 14:43:07.603: NAT: s=10.10.10.3->100.10.33.1, d=5.5.5.5 [0]
Dec 26 14:43:07.607: IP: s=100.10.33.1 (Loopback0), d=5.5.5.5, len 100, policy match
Dec 26 14:43:07.607: IP: route map LOOPBACK->OUTSIDE-ROUTE-MAP, item 20, permit
Dec 26 14:43:07.611: IP: s=100.10.33.1 (Loopback0), d=5.5.5.5 (Serial1/1), len 100, policy routed
Dec 26 14:43:07.611: IP: Loopback0 to Serial1/1 5.5.5.5

! Reply from 5.5.5.5:0 (5.5.5.5:0) to 100.10.33.1:0 (10.10.10.3:0)

! Traffic entering the router from the ISP
! Serial1/1 ==(PBR)==> Loopback1 ==(NAT)==> 10.10.10.3

Dec 26 14:43:07.675: IP: s=5.5.5.5 (Serial1/1), d=100.10.33.1, len 100, FIB policy match
Dec 26 14:43:07.679: IP: s=5.5.5.5 (Serial1/1), d=100.10.33.1, len 100, FIB policy match
Dec 26 14:43:07.687: IP: s=5.5.5.5 (Serial1/1), d=100.10.33.1, len 100, policy match
Dec 26 14:43:07.687: IP: route map OUTSIDE->INSIDE-ROUTE-MAP, item 10, permit
Dec 26 14:43:07.691: IP: s=5.5.5.5 (Serial1/1), d=100.10.33.1 (Loopback1), len 100, policy routed
Dec 26 14:43:07.695: IP: Serial1/1 to Loopback1 100.10.33.1
Dec 26 14:43:07.699: NAT: o: icmp (5.5.5.5, 0) -> (100.10.33.1, 0) [0]
Dec 26 14:43:07.699: NAT: s=5.5.5.5, d=100.10.33.1->10.10.10.3 [0]


We check the nat translation table and a new dynamic entry has been created :

HGW#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 100.10.12.1:1081 10.10.10.1:1081 --- ---
tcp 100.10.12.1:1082 10.10.10.2:1082 --- ---
icmp 100.10.33.1:0 10.10.10.3:0 5.5.5.5:0 5.5.5.5:0
tcp 100.10.33.1:1083 10.10.10.3:1083 --- ---
tcp 100.10.44.1:1084 10.10.10.4:1084 --- ---


Then we test connectivity between the 2 hosts (dynamic/static NAT) :

HOST1#tel 100.10.33.1 1083
Trying 100.10.33.1, 1083 ... Open

HOST3#sh tcp br
TCB Local Address Foreign Address (state)
65C3C7C8 10.10.10.3.1083 100.10.12.1.39074 ESTAB


HGW debugs


! Request from 10.10.10.1:39074 (100.10.12.1:39074) to 100.10.33.1:1083 (10.10.10.3:1083)

! Traffic leaving the router towards the ISP
! 10.10.10.1 ==(PBR)(NAT)==> Loopback0 ==(PBR)==> Serial1/0

Dec 26 14:57:15.111: IP: s=10.10.10.1 (FastEthernet0/0), d=100.10.33.1, len 44, FIB policy match
Dec 26 14:57:15.115: IP: s=10.10.10.1 (FastEthernet0/0), d=100.10.33.1, len 44, FIB policy match
Dec 26 14:57:15.119: IP: s=10.10.10.1 (FastEthernet0/0), d=100.10.33.1, len 44, policy match
Dec 26 14:57:15.123: IP: route map INSIDE->OUTSIDE-ROUTE-MAP, item 10, permit
Dec 26 14:57:15.127: IP: s=10.10.10.1 (FastEthernet0/0), d=100.10.33.1 (Loopback0), len 44, policy routed
Dec 26 14:57:15.131: IP: FastEthernet0/0 to Loopback0 100.10.33.1
Dec 26 14:57:15.131: NAT: address not stolen for 10.10.10.1, proto 6 port 39074
Dec 26 14:57:15.135: mapping pointer available mapping:0
Dec 26 14:57:15.135: NAT: [0] Allocated Port for 10.10.10.1 -> 100.10.12.1: wanted 39074 got 39074
Dec 26 14:57:15.139: NAT: i: tcp (10.10.10.1, 39074) -> (100.10.33.1, 1083) [33863]
Dec 26 14:57:15.143: NAT: s=10.10.10.1->100.10.12.1, d=100.10.33.1 [33863]
Dec 26 14:57:15.155: IP: s=100.10.12.1 (Loopback0), d=100.10.33.1, len 44, policy match
Dec 26 14:57:15.159: IP: route map LOOPBACK->OUTSIDE-ROUTE-MAP, item 10, permit
Dec 26 14:57:15.163: IP: s=100.10.12.1 (Loopback0), d=100.10.33.1 (Serial1/0), len 44, policy routed
Dec 26 14:57:15.167: IP: Loopback0 to Serial1/0 100.10.33.1

! Traffic entering the router from the ISP
! Serial1/1 ==(PBR)==> Loopback1 ==(NAT)==> 10.10.10.3

Dec 26 14:57:15.215: IP: s=100.10.12.1 (Serial1/1), d=100.10.33.1, len 44, FIB policy match
Dec 26 14:57:15.219: IP: s=100.10.12.1 (Serial1/1), d=100.10.33.1, len 44, FIB policy match
Dec 26 14:57:15.223: IP: s=100.10.12.1 (Serial1/1), d=100.10.33.1, len 44, policy match
Dec 26 14:57:15.227: IP: route map OUTSIDE->INSIDE-ROUTE-MAP, item 10, permit
Dec 26 14:57:15.227: IP: s=100.10.12.1 (Serial1/1), d=100.10.33.1 (Loopback1), len 44, policy routed
Dec 26 14:57:15.231: IP: Serial1/1 to Loopback1 100.10.33.1
Dec 26 14:57:15.239: NAT: o: tcp (100.10.12.1, 39074) -> (100.10.33.1, 1083) [33863]
Dec 26 14:57:15.239: NAT: s=100.10.12.1, d=100.10.33.1->10.10.10.3 [33863]


! Reply from 10.10.10.3:1083 (100.10.33.1:1083) to 100.10.12.1:39074 (10.10.10.1:39074)

! Traffic leaving the router towards the ISP
! 10.10.10.3 ==(PBR)(NAT)==> Loopback0 ==(PBR)==> Serial1/1

Dec 26 14:57:15.363: IP: s=10.10.10.3 (FastEthernet0/0), d=100.10.12.1, len 44, FIB policy match
Dec 26 14:57:15.367: IP: s=10.10.10.3 (FastEthernet0/0), d=100.10.12.1, len 44, FIB policy match
Dec 26 14:57:15.375: IP: s=10.10.10.3 (FastEthernet0/0), d=100.10.12.1, len 44, policy match
Dec 26 14:57:15.375: IP: route map INSIDE->OUTSIDE-ROUTE-MAP, item 10, permit
Dec 26 14:57:15.379: IP: s=10.10.10.3 (FastEthernet0/0), d=100.10.12.1 (Loopback0), len 44, policy routed
Dec 26 14:57:15.383: IP: FastEthernet0/0 to Loopback0 100.10.12.1
Dec 26 14:57:15.387: NAT: i: tcp (10.10.10.3, 1083) -> (100.10.12.1, 39074) [31485]
Dec 26 14:57:15.387: NAT: s=10.10.10.3->100.10.33.1, d=100.10.12.1 [31485]
Dec 26 14:57:15.395: IP: s=100.10.33.1 (Loopback0), d=100.10.12.1, len 44, policy match
Dec 26 14:57:15.395: IP: route map LOOPBACK->OUTSIDE-ROUTE-MAP, item 20, permit
Dec 26 14:57:15.399: IP: s=100.10.33.1 (Loopback0), d=100.10.12.1 (Serial1/1), len 44, policy routed
Dec 26 14:57:15.403: IP: Loopback0 to Serial1/1 100.10.12.1

! Traffic entering the router from the ISP
! Serial1/0 ==(PBR)==> Loopback1 ==(NAT)==> 10.10.10.1

Dec 26 14:57:15.415: IP: s=100.10.33.1 (Serial1/0), d=100.10.12.1, len 44, FIB policy match
Dec 26 14:57:15.415: IP: s=100.10.33.1 (Serial1/0), d=100.10.12.1, len 44, FIB policy match
Dec 26 14:57:15.419: IP: s=100.10.33.1 (Serial1/0), d=100.10.12.1, len 44, policy match
Dec 26 14:57:15.423: IP: route map OUTSIDE->INSIDE-ROUTE-MAP, item 10, permit
Dec 26 14:57:15.423: IP: s=100.10.33.1 (Serial1/0), d=100.10.12.1 (Loopback1), len 44, policy routed
Dec 26 14:57:15.427: IP: Serial1/0 to Loopback1 100.10.12.1
Dec 26 14:57:15.431: NAT: o: tcp (100.10.33.1, 1083) -> (100.10.12.1, 39074) [31485]
Dec 26 14:57:15.435: NAT: s=100.10.33.1, d=100.10.12.1->10.10.10.1 [31485]


We check the nat translation table and we see that :
a) a new dynamic entry for 10.10.10.1 has been created
b) a new dynamic entry based on the static nat for 10.10.10.3:1083 has been created

HGW#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 100.10.12.1:1081 10.10.10.1:1081 --- ---
tcp 100.10.12.1:39074 10.10.10.1:39074 100.10.33.1:1083 100.10.33.1:1083
tcp 100.10.12.1:1082 10.10.10.2:1082 --- ---
tcp 100.10.33.1:1083 10.10.10.3:1083 100.10.12.1:39074 100.10.12.1:39074
tcp 100.10.33.1:1083 10.10.10.3:1083 --- ---
tcp 100.10.44.1:1084 10.10.10.4:1084 --- ---



5.3) HOST1 is trying to access HOST4 (different wan connections, different routers)

First we test HOST4's connectivity to the internet (dynamic NAT) :

HOST4#p 5.5.5.5 rep 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 136/136/136 ms


HGW debugs


! Request from 10.10.10.4:0 (100.10.12.1:0) to 5.5.5.5:0 (5.5.5.5:0)

! Traffic leaving the router towards the ISP
! 10.10.10.4 ==(PBR)(NAT)==> Loopback0 ==(PBR)==> Serial1/2

Dec 26 15:12:02.591: IP: s=10.10.10.4 (FastEthernet0/0), d=5.5.5.5, len 100, FIB policy match
Dec 26 15:12:02.595: IP: s=10.10.10.4 (FastEthernet0/0), d=5.5.5.5, len 100, FIB policy match
Dec 26 15:12:02.599: IP: s=10.10.10.4 (FastEthernet0/0), d=5.5.5.5, len 100, policy match
Dec 26 15:12:02.603: IP: route map INSIDE->OUTSIDE-ROUTE-MAP, item 10, permit
Dec 26 15:12:02.607: IP: s=10.10.10.4 (FastEthernet0/0), d=5.5.5.5 (Loopback0), len 100, policy routed
Dec 26 15:12:02.607: IP: FastEthernet0/0 to Loopback0 5.5.5.5
Dec 26 15:12:02.611: NAT: address not stolen for 10.10.10.4, proto 1 port 0
Dec 26 15:12:02.615: mapping pointer available mapping:0
Dec 26 15:12:02.615: NAT: creating portlist proto 1 globaladdr 100.10.44.1
Dec 26 15:12:02.619: NAT: [0] Allocated Port for 10.10.10.4 -> 100.10.44.1: wanted 0 got 0
Dec 26 15:12:02.623: NAT: i: icmp (10.10.10.4, 0) -> (5.5.5.5, 0) [0]
Dec 26 15:12:02.623: NAT: s=10.10.10.4->100.10.44.1, d=5.5.5.5 [0]
Dec 26 15:12:02.631: IP: s=100.10.44.1 (Loopback0), d=5.5.5.5, len 100, policy match
Dec 26 15:12:02.631: IP: route map LOOPBACK->OUTSIDE-ROUTE-MAP, item 30, permit
Dec 26 15:12:02.635: IP: s=100.10.44.1 (Loopback0), d=5.5.5.5 (Serial1/2), len 100, policy routed
Dec 26 15:12:02.639: IP: Loopback0 to Serial1/2 5.5.5.5

! Reply from 5.5.5.5:0 (5.5.5.5:0) to 100.10.44.1:0 (10.10.10.4:0)

! Traffic entering the router from the ISP
! Serial1/2 ==(PBR)==> Loopback1 ==(NAT)==> 10.10.10.4

Dec 26 15:12:02.703: IP: s=5.5.5.5 (Serial1/2), d=100.10.44.1, len 100, FIB policy match
Dec 26 15:12:02.707: IP: s=5.5.5.5 (Serial1/2), d=100.10.44.1, len 100, FIB policy match
Dec 26 15:12:02.711: IP: s=5.5.5.5 (Serial1/2), d=100.10.44.1, len 100, policy match
Dec 26 15:12:02.715: IP: route map OUTSIDE->INSIDE-ROUTE-MAP, item 10, permit
Dec 26 15:12:02.719: IP: s=5.5.5.5 (Serial1/2), d=100.10.44.1 (Loopback1), len 100, policy routed
Dec 26 15:12:02.719: IP: Serial1/2 to Loopback1 100.10.44.1
Dec 26 15:12:02.723: NAT: o: icmp (5.5.5.5, 0) -> (100.10.44.1, 0) [0]
Dec 26 15:12:02.727: NAT: s=5.5.5.5, d=100.10.44.1->10.10.10.4 [0]


We check the nat translation table and a new dynamic entry has been created :

HGW# sh ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 100.10.12.1:1081 10.10.10.1:1081 --- ---
tcp 100.10.12.1:1082 10.10.10.2:1082 --- ---
tcp 100.10.33.1:1083 10.10.10.3:1083 --- ---
icmp 100.10.44.1:0 10.10.10.4:0 5.5.5.5:0 5.5.5.5:0
tcp 100.10.44.1:1084 10.10.10.4:1084 --- ---


Then we test connectivity between the 2 hosts (dynamic/static NAT) :

HOST1#tel 100.10.44.1 1084
Trying 100.10.44.1, 1084 ... Open

HOST4#sh tcp br
TCB Local Address Foreign Address (state)
663E8378 10.10.10.4.1084 100.10.12.1.14201 ESTAB


HGW debugs


! Request from 10.10.10.1:14201 (100.10.12.1:14201) to 100.10.44.1:1084 (10.10.10.4:1084)

! Traffic leaving the router towards the ISP
! 10.10.10.1 ==(PBR)(NAT)==> Loopback0 ==(PBR)==> Serial1/0

Dec 26 15:13:54.579: IP: s=10.10.10.1 (FastEthernet0/0), d=100.10.44.1, len 44, FIB policy match
Dec 26 15:13:54.583: IP: s=10.10.10.1 (FastEthernet0/0), d=100.10.44.1, len 44, FIB policy match
Dec 26 15:13:54.591: IP: s=10.10.10.1 (FastEthernet0/0), d=100.10.44.1, len 44, policy match
Dec 26 15:13:54.591: IP: route map INSIDE->OUTSIDE-ROUTE-MAP, item 10, permit
Dec 26 15:13:54.595: IP: s=10.10.10.1 (FastEthernet0/0), d=100.10.44.1 (Loopback0), len 44, policy routed
Dec 26 15:13:54.599: IP: FastEthernet0/0 to Loopback0 100.10.44.1
Dec 26 15:13:54.599: NAT: i: tcp (10.10.10.1, 14201) -> (100.10.44.1, 1084) [4409]
Dec 26 15:13:54.603: NAT: s=10.10.10.1->100.10.12.1, d=100.10.44.1 [4409]
Dec 26 15:13:54.607: IP: s=100.10.12.1 (Loopback0), d=100.10.44.1, len 44, policy match
Dec 26 15:13:54.611: IP: route map LOOPBACK->OUTSIDE-ROUTE-MAP, item 10, permit
Dec 26 15:13:54.611: IP: s=100.10.12.1 (Loopback0), d=100.10.44.1 (Serial1/0), len 44, policy routed
Dec 26 15:13:54.615: IP: Loopback0 to Serial1/0 100.10.44.1

! Traffic entering the router from the ISP
! Serial1/2 ==(PBR)==> Loopback1 ==(NAT)==> 10.10.10.4

Dec 26 15:13:54.667: IP: s=100.10.12.1 (Serial1/2), d=100.10.44.1, len 44, FIB policy match
Dec 26 15:13:54.671: IP: s=100.10.12.1 (Serial1/2), d=100.10.44.1, len 44, FIB policy match
Dec 26 15:13:54.679: IP: s=100.10.12.1 (Serial1/2), d=100.10.44.1, len 44, policy match
Dec 26 15:13:54.683: IP: route map OUTSIDE->INSIDE-ROUTE-MAP, item 10, permit
Dec 26 15:13:54.683: IP: s=100.10.12.1 (Serial1/2), d=100.10.44.1 (Loopback1), len 44, policy routed
Dec 26 15:13:54.687: IP: Serial1/2 to Loopback1 100.10.44.1
Dec 26 15:13:54.691: NAT: o: tcp (100.10.12.1, 14201) -> (100.10.44.1, 1084) [4409]
Dec 26 15:13:54.695: NAT: s=100.10.12.1, d=100.10.44.1->10.10.10.4 [4409]


! Reply from 10.10.10.4:1084 (100.10.44.1:1084) to 100.10.12.1:14201 (10.10.10.1:14201)

! Traffic leaving the router towards the ISP
! 10.10.10.4 ==(PBR)(NAT)==> Loopback0 ==(PBR)==> Serial1/2

Dec 26 15:13:54.779: IP: s=10.10.10.4 (FastEthernet0/0), d=100.10.12.1, len 44, FIB policy match
Dec 26 15:13:54.779: IP: s=10.10.10.4 (FastEthernet0/0), d=100.10.12.1, len 44, FIB policy match
Dec 26 15:13:54.783: IP: s=10.10.10.4 (FastEthernet0/0), d=100.10.12.1, len 44, policy match
Dec 26 15:13:54.787: IP: route map INSIDE->OUTSIDE-ROUTE-MAP, item 10, permit
Dec 26 15:13:54.791: IP: s=10.10.10.4 (FastEthernet0/0), d=100.10.12.1 (Loopback0), len 44, policy routed
Dec 26 15:13:54.791: IP: FastEthernet0/0 to Loopback0 100.10.12.1
Dec 26 15:13:54.791: NAT: i: tcp (10.10.10.4, 1084) -> (100.10.12.1, 14201) [13502]
Dec 26 15:13:54.795: NAT: s=10.10.10.4->100.10.44.1, d=100.10.12.1 [13502]
Dec 26 15:13:54.799: IP: s=100.10.44.1 (Loopback0), d=100.10.12.1, len 44, policy match
Dec 26 15:13:54.803: IP: route map LOOPBACK->OUTSIDE-ROUTE-MAP, item 30, permit
Dec 26 15:13:54.807: IP: s=100.10.44.1 (Loopback0), d=100.10.12.1 (Serial1/2), len 44, policy routed
Dec 26 15:13:54.807: IP: Loopback0 to Serial1/2 100.10.12.1

! Traffic entering the router from the ISP
! Serial1/0 ==(PBR)==> Loopback1 ==(NAT)==> 10.10.10.1

Dec 26 15:13:54.835: IP: s=100.10.44.1 (Serial1/0), d=100.10.12.1, len 44, FIB policy match
Dec 26 15:13:54.835: IP: s=100.10.44.1 (Serial1/0), d=100.10.12.1, len 44, FIB policy match
Dec 26 15:13:54.843: IP: s=100.10.44.1 (Serial1/0), d=100.10.12.1, len 44, policy match
Dec 26 15:13:54.847: IP: route map OUTSIDE->INSIDE-ROUTE-MAP, item 10, permit
Dec 26 15:13:54.847: IP: s=100.10.44.1 (Serial1/0), d=100.10.12.1 (Loopback1), len 44, policy routed
Dec 26 15:13:54.847: IP: Serial1/0 to Loopback1 100.10.12.1
Dec 26 15:13:54.847: NAT: o: tcp (100.10.44.1, 1084) -> (100.10.12.1, 14201) [13502]
Dec 26 15:13:54.851: NAT: s=100.10.44.1, d=100.10.12.1->10.10.10.1 [13502]


We check the nat translation table and we see that :
a) a new dynamic entry for 10.10.10.1 has been created
b) a new dynamic entry based on the static nat for 10.10.10.4:1084 has been created

HGW#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 100.10.12.1:1081 10.10.10.1:1081 --- ---
tcp 100.10.12.1:14201 10.10.10.1:14201 100.10.44.1:1084 100.10.44.1:1084
tcp 100.10.12.1:1082 10.10.10.2:1082 --- ---
tcp 100.10.33.1:1083 10.10.10.3:1083 --- ---
tcp 100.10.44.1:1084 10.10.10.4:1084 100.10.12.1:14201 100.10.12.1:14201
tcp 100.10.44.1:1084 10.10.10.4:1084 --- ---


6) Notes

6.1) In my test, all routers were 7200s and were running 12.4(20)T.

6.2) You'll be probably getting the following warning while configuring route-maps, but there is no need to worry, since everything will be working fine afterwards :

HGW(config-route-map)#set interface lo0
%Warning:Use P2P interface for routemap
set interface clause


6.3) Regarding the redundancy part, the HOST->CORE part is already configured. For the CORE->HOST part, you can use static routes & ospf route-maps with a bigger metric.

Saturday, November 22, 2008

Solving routing asymmetry due to HSRP by using EEM & EOT

This is a topic that comes up at least once in a year at the c-nsp list (and everywhere else i believe), but i still cannot understand why Cisco doesn't provide a solution about it.

1) Introducing the problem

The scenario is simple. You have 2 routers running HSRP on a LAN serving various hosts. These 2 routers have a third -common- router as an uplink and all three of them are running a routing protocol. Since HSRP enabled interfaces are always (regardless of their state) included in the connected routes table, the uplink router will always know 2 paths to reach the hosts. You can change the metrics of connected/static routes when redistributing them into the routing protocol so you can give preference only to the active HSRP router's path, but this is something static. If the HSRP changes state, the routes will continue to follow the initial path (which leads to routing asymmetry...or is it asymmetric routing?), unless somehow you change the routes too.
Asymmetric routing can cause communication problems when the packets pass through different "stateful inspection enabled" (Reflexive ACLs, CBAC, older Firewalls, etc.) paths, or unicast flood problems when the mac (on L2 devices) and arp (on L3 devices) timers do not match.

2) Finding solutions

The previous week i decided to experiment with EEM (Embedded Event Manager) & EOT (Enhanced Object Tracking) in order to change dynamically the paths of HSRP related routes. This is more a hack than a solution. But it should work fine for most simple cases.

There are mainly 2 kinds of routes that need to be changed : connected routes and static routes. Connected routes are the most difficult to handle, so the only easy way i could come up with was to change their redistribution metric by changing the relevant configuration under the routing protocol (you can also use prefix-lists/route-maps with redistribution, if you want to be more selective). On the other hand, static routes can depend on the state of a tracked object, so they are much easier to handle.

Note : Although Cisco has the IP Event Dampening code ready (which removes connected/static routes from dampened interfaces), it doesn't seem they are really interested in using it for removing a connected route from an interface when it's in the HSRP standby state. I guess a good reason is that IP Event Dampening doesn't support subinterfaces and it also blocks HSRP, so it probably needs to be redesigned.

These are the steps needed to accomplish our solution:

2.1) Creating tracked objects for static routes

In latest IOS (where EEM 2.2 is supported), EOT is integrated with EEM so you can have EEM events based on tracked object states ("event track X state Y") or EEM actions for manipulating tracked object states ("action X track set/read Y"). Also a new type of tracking object—a stub object—is created. The stub object can be manipulated easily using the existing CLI commands that already allow tracked objects to be manipulated. That way we can change its state through EEM.

First we have to make sure that all our static routes that point to HSRP interfaces depend on tracked objects. We're using the stub-object of EOT in order to accomplish this.


track 1 stub-object
default-state up
!
ip route 4.4.4.4 255.255.255.255 10.10.10.3 track 1

R1#sh track
Track 1
Stub-object
State is Up
2 changes, last change 01:38:36, by Undefined
Tracked by:
STATIC-IP-ROUTING 0


2.2) Detecting HSRP states using EEM

Then we're using EEM in order to detect HSRP state changes on both routers; one event for the Active state and another event for every other state. There are probably other and more elegant ways, but i have tested only the following two:

Checking syslog logs for HSRP messages:


event manager applet HSRP-SYSLOG-EVENT-UP
event syslog pattern "FastEthernet0/0 Grp 1 state .* -> Active"
!
event manager applet HSRP-SYSLOG-EVENT-DOWN
event syslog pattern "FastEthernet0/0 Grp 1 state Active -> .*"


Checking HSRP states through snmp


event manager applet HSRP-SNMP-EVENT-UP
event snmp oid "1.3.6.1.4.1.9.9.106.1.2.1.1.15.1.1" get-type exact entry-op eq entry-val "6" entry-type value exit-op ne exit-val "6" exit-type value poll-interval 1
event manager applet HSRP-SNMP-EVENT-DOWN
event snmp oid "1.3.6.1.4.1.9.9.106.1.2.1.1.15.1.1" get-type exact entry-op ne entry-val "6" entry-type value exit-op eq exit-val "6" exit-type value poll-interval 1


"1.3.6.1.4.1.9.9.106.1.2.1.1.15.1.1" is an OID containing the following 3 parts:

1.3.6.1.4.1.9.9.106.1.2.1.1.15 = cHsrpGrpStandbyState
1 = interface index (you can easily find it by using "show snmp mib ifmib ifindex" or snmpwalk)
1 = HSRP group number (the one you use as "standby X" under the interface)

The result returned by snmp is a number representing the current HSRP state of this group on this interface:

6 = Active
5 = Standby
4 = Speak
3 = Listen
2 = Learn
1 = Init

Don't forget to enable the snmp agent ("snmp-server enable traps X") and the snmp ifindex persistence ("snmp-server ifindex persist"), if you're going to use the snmp method.

Note : In my example, i'll be using the syslog based detection, because it's a lot easier to watch/debug. Nevertheless, i believe the snmp based detection is much better (although maybe harder to implement), because it doesn't rely on logging (which for various reasons could be disabled/rate-limited; try using severity level 4 for your logs!) and it can "fix" the routing behavior at any time (polling every 1") vs the syslog which "fixes" the routing behavior only once (while log is caught at a specific time).


2.3) Acting on HSRP state changes using EEM

At the end we have to make some actions based on our events. For static routes we just change the tracked object's state. For connected routes we have to change their redistribution metric under the routing protocol.

Changing the state of the tracked object:


event manager applet HSRP-SYSLOG-EVENT-UP
action 2.1 track set 1 state up
action 2.3 track read 1

event manager applet HSRP-SYSLOG-EVENT-DOWN
action 2.1 track set 1 state down
action 2.3 track read 1


Changing the redistribution metric of connected routes


event manager applet HSRP-SYSLOG-EVENT-UP
action 3.1 cli command "enable"
action 3.3 cli command "conf t"
action 3.5 cli command "router ospf 100"
action 3.7 cli command "redistribute connected metric 100 subnets"

event manager applet HSRP-SYSLOG-EVENT-DOWN
action 3.1 cli command "enable"
action 3.3 cli command "conf t"
action 3.5 cli command "router ospf 100"
action 3.7 cli command "redistribute connected metric 200 subnets"


3) Testing the solutions

3.1) The test network

Ok, time to try it on a test network.



For the CORE->HOST direction, we want to have (on the CORE router) the 4.4.4.4/32 route (L0 of HOST) to point always to the active HSRP router (R1 or R2). The HOST->CORE direction is handled by HSRP, so we don't need to worry about it.

We're using OSPF as our routing protocol, but i suppose it could be anything else.

3.2) The router configurations

These are the interesting configuration parts of all participant routers:

CORE

ip host HOST-F0-0 10.10.10.3
ip host R2-S1-0 23.23.23.2
ip host R1-S1-0 13.13.13.1
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Serial1/1
description ** R1 **
ip address 13.13.13.3 255.255.255.0
!
interface Serial1/2
description ** R2 **
ip address 23.23.23.3 255.255.255.0
!
router ospf 100
passive-interface Loopback0
network 3.3.3.3 0.0.0.0 area 0
network 13.13.13.0 0.0.0.255 area 0
network 23.23.23.0 0.0.0.255 area 0
!


R1

track 1 stub-object
default-state up
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.0
standby version 2
standby 1 ip 10.10.10.50
standby 1 priority 101
standby 1 preempt
!
interface Serial1/0
description ** CORE **
ip address 13.13.13.1 255.255.255.0
!
router ospf 100
redistribute connected metric 100 subnets
redistribute static subnets
passive-interface Loopback0
network 1.1.1.1 0.0.0.0 area 0
network 13.13.13.0 0.0.0.255 area 0
!
ip route 4.4.4.4 255.255.255.255 10.10.10.3 track 1
!
event manager applet HSRP-SYSLOG-EVENT-UP
event syslog pattern "FastEthernet0/0 Grp 1 state .* -> Active"
action 1.1 syslog msg "HSRP : Active"
action 2.1 track set 1 state up
action 2.3 track read 1
action 3.1 cli command "enable"
action 3.3 cli command "conf t"
action 3.5 cli command "router ospf 100"
action 3.7 cli command "redistribute connected metric 100 subnets"
!
event manager applet HSRP-SYSLOG-EVENT-DOWN
event syslog pattern "FastEthernet0/0 Grp 1 state Active -> .*"
action 1.1 syslog msg "HSRP : NOT Active"
action 2.1 track set 1 state down
action 2.3 track read 1
action 3.1 cli command "enable"
action 3.3 cli command "conf t"
action 3.5 cli command "router ospf 100"
action 3.7 cli command "redistribute connected metric 200 subnets"
!


R2

track 1 stub-object
default-state down ! this is the default and not shown
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
ip address 10.10.10.2 255.255.255.0
standby version 2
standby 1 ip 10.10.10.50
standby 1 priority 99
standby 1 preempt
!
interface Serial1/0
description ** CORE **
ip address 23.23.23.2 255.255.255.0
!
router ospf 100
redistribute connected metric 200 subnets
redistribute static subnets
passive-interface Loopback0
network 2.2.2.2 0.0.0.0 area 0
network 23.23.23.0 0.0.0.255 area 0
!
ip route 4.4.4.4 255.255.255.255 10.10.10.3 track 1
!
event manager applet HSRP-SYSLOG-EVENT-UP
event syslog pattern "FastEthernet0/0 Grp 1 state .* -> Active"
action 1.1 syslog msg "HSRP : Active"
action 2.1 track set 1 state up
action 2.3 track read 1
action 3.1 cli command "enable"
action 3.3 cli command "conf t"
action 3.5 cli command "router ospf 100"
action 3.7 cli command "redistribute connected metric 100 subnets"
!
event manager applet HSRP-SYSLOG-EVENT-DOWN
event syslog pattern "FastEthernet0/0 Grp 1 state Active -> .*"
action 1.1 syslog msg "HSRP : NOT Active"
action 2.1 track set 1 state down
action 2.3 track read 1
action 3.1 cli command "enable"
action 3.3 cli command "conf t"
action 3.5 cli command "router ospf 100"
action 3.7 cli command "redistribute connected metric 200 subnets"


HOST

ip host R1-F0-0 10.10.10.1
ip host R2-F0-0 10.10.10.2
ip host CORE-S1-1 13.13.13.3
ip host CORE-S1-2 23.23.23.3
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
interface FastEthernet0/0
ip address 10.10.10.3 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 10.10.10.50


As you can see, the EEM configurations of R1 & R2 are the same. The only thing that's different is the initial state of the tracked object and the initial redistribution metric.

3.3) R1 Active - R2 Standby

By default, R1 is in the Active HSRP state and R2 is in the Standby state.


R1#sh standby br
P indicates configured to preempt.
|
Interface Grp Pri P State Active Standby Virtual IP
Fa0/0 1 101 P Active local 10.10.10.2 10.10.10.50



R2#sh standby br
P indicates configured to preempt.
|
Interface Grp Pri P State Active Standby Virtual IP
Fa0/0 1 99 P Standby 10.10.10.1 local 10.10.10.50


The 4.4.4.4/32 static route is active only on R1, due to our tracked object's state :


R1#sh ip route track-table
ip route 4.4.4.4 255.255.255.255 10.10.10.3 track 1 state is [up]

R1#sh track 1
Track 1
Stub-object
State is Up
6 changes, last change 00:00:54, by EEM
Tracked by:
STATIC-IP-ROUTING 0

R1#sh ip route static
4.0.0.0/32 is subnetted, 1 subnets
S 4.4.4.4 [1/0] via 10.10.10.3



R2#sh ip route track-table
ip route 4.4.4.4 255.255.255.255 10.10.10.3 track 1 state is [down]

R2#sh track 1
Track 1
Stub-object
State is Down
5 changes, last change 00:00:57, by EEM
Tracked by:
STATIC-IP-ROUTING 0

R2#sh ip route static



The 10.10.10.0/24 connected route is inserted twice (by R1 and R2) into the ospf database, but only the one with the lowest metric (from R1) is used by the CORE's RIB.


CORE#sh ip ospf data ext 10.10.10.0 | i Advert|Metric:
Advertising Router: 1.1.1.1
Metric: 100

Advertising Router: 2.2.2.2
Metric: 200


Traffic between CORE and HOST should (according to our initial setup) pass through R1 in both directions. CORE is using OSPF to decide, HOST is using static routing + HSRP.


CORE#sh ip route 4.4.4.4
Routing entry for 4.4.4.4/32
Known via "ospf 100", distance 110, metric 20, type extern 2, forward metric 64
Last update from 13.13.13.1 on Serial1/1, 02:28:05 ago
Routing Descriptor Blocks:
* 13.13.13.1, from 1.1.1.1, 02:28:05 ago, via Serial1/1
Route metric is 20, traffic share count is 1

CORE#sh ip route 10.10.10.3
Routing entry for 10.10.10.0/24
Known via "ospf 100", distance 110, metric 100, type extern 2, forward metric 64
Last update from 13.13.13.1 on Serial1/1, 02:28:25 ago
Routing Descriptor Blocks:
* 13.13.13.1, from 1.1.1.1, 02:28:25 ago, via Serial1/1
Route metric is 100, traffic share count is 1


CORE => HOST

CORE#tr 4.4.4.4 so l0

Type escape sequence to abort.
Tracing the route to 4.4.4.4

1 R1-S1-0 (13.13.13.1) 32 msec 36 msec 8 msec
2 HOST-F0-0 (10.10.10.3) 44 msec * 64 msec
CORE#


HOST => CORE

HOST#tr 3.3.3.3 so l0

Type escape sequence to abort.
Tracing the route to 3.3.3.3

1 R1-F0-0 (10.10.10.1) 48 msec 60 msec 12 msec
2 CORE-S1-1 (13.13.13.3) 56 msec * 76 msec
HOST#


3.4) R1 Standby - R2 Active

Now let's make the R2 Active by increasing its HSRP priority (we have preempt enabled). As you can see from the logs below, EEM and tracking worked fine.

R2

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#interface FastEthernet0/0
R2(config-if)#standby 1 priority 103
R2(config-if)#^Z
R2#

*Nov 22 15:00:46.239: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active
*Nov 22 15:00:46.407: %SYS-5-CONFIG_I: Configured from console by console
*Nov 22 15:00:46.447: %HA_EM-6-LOG: HSRP-SYSLOG-EVENT-UP: HSRP : Active
*Nov 22 15:00:46.447: %TRACKING-5-STATE: 1 Down->Up
*Nov 22 15:00:47.167: %SYS-5-CONFIG_I: Configured from console by vty0


R1

*Nov 22 15:00:45.875: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Speak
*Nov 22 15:00:46.055: %HA_EM-6-LOG: HSRP-SYSLOG-EVENT-DOWN: HSRP : NOT Active
*Nov 22 15:00:46.063: %TRACKING-5-STATE: 1 Up->Down
*Nov 22 15:00:46.607: %SYS-5-CONFIG_I: Configured from console by vty0
*Nov 22 15:00:57.839: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Speak -> Standby


Now R2 is in the Active HSRP state and R1 is in the Standby state.


R1#sh standby br
P indicates configured to preempt.
|
Interface Grp Pri P State Active Standby Virtual IP
Fa0/0 1 101 P Standby 10.10.10.2 local 10.10.10.50



R2#sh standby br
P indicates configured to preempt.
|
Interface Grp Pri P State Active Standby Virtual IP
Fa0/0 1 103 P Active local 10.10.10.1 10.10.10.50


The 4.4.4.4/32 static route is active only on R2, due to our tracked object's new state :


R1#sh ip route track-table
ip route 4.4.4.4 255.255.255.255 10.10.10.3 track 1 state is [down]

R1#sh track 1
Track 1
Stub-object
State is Down
3 changes, last change 00:00:06, by EEM
Tracked by:
STATIC-IP-ROUTING 0

R1#sh ip route static



R2#sh ip route track-table
ip route 4.4.4.4 255.255.255.255 10.10.10.3 track 1 state is [up]

R2#sh track 1
Track 1
Stub-object
State is Up
2 changes, last change 00:00:06, by EEM
Tracked by:
STATIC-IP-ROUTING 0

R2#sh ip route static
4.0.0.0/32 is subnetted, 1 subnets
S 4.4.4.4 [1/0] via 10.10.10.3


The 10.10.10.0/24 connected route is again inserted twice (by R1 and R2) into the ospf database, but this time the one from R2 is used by the CORE's RIB.


CORE#sh ip ospf data ext 10.10.10.0 | i Advert|Metric:
Advertising Router: 1.1.1.1
Metric: 200
Advertising Router: 2.2.2.2
Metric: 100



This time, traffic should pass through R2 in both directions.


CORE#sh ip route 4.4.4.4
Routing entry for 4.4.4.4/32
Known via "ospf 100", distance 110, metric 20, type extern 2, forward metric 64
Last update from 23.23.23.2 on Serial1/2, 00:02:09 ago
Routing Descriptor Blocks:
* 23.23.23.2, from 2.2.2.2, 00:02:09 ago, via Serial1/2
Route metric is 20, traffic share count is 1

CORE#sh ip route 10.10.10.3
Routing entry for 10.10.10.0/24
Known via "ospf 100", distance 110, metric 100, type extern 2, forward metric 64
Last update from 23.23.23.2 on Serial1/2, 00:02:19 ago
Routing Descriptor Blocks:
* 23.23.23.2, from 2.2.2.2, 00:02:19 ago, via Serial1/2
Route metric is 100, traffic share count is 1


CORE => HOST

CORE#tr 4.4.4.4 so l0

Type escape sequence to abort.
Tracing the route to 4.4.4.4

1 R2-S1-0 (23.23.23.2) 36 msec 64 msec 20 msec
2 HOST-F0-0 (10.10.10.3) 44 msec * 44 msec
CORE#


HOST => CORE

HOST#tr 3.3.3.3 so l0

Type escape sequence to abort.
Tracing the route to 3.3.3.3

1 R2-F0-0 (10.10.10.2) 80 msec 28 msec 12 msec
2 CORE-S1-2 (23.23.23.3) 60 msec * 84 msec
HOST#


3.5) R1 Active - R2 Standby (again)

Ok, let's return to the initial state again (R1 Active, R2 Standby).

R2

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#interface FastEthernet0/0
R2(config-if)#standby 1 priority 99
R2(config-if)#^Z
R2#
*Nov 22 16:10:40.538: %SYS-5-CONFIG_I: Configured from console by console
*Nov 22 16:10:41.070: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Speak
*Nov 22 16:10:41.282: %HA_EM-6-LOG: HSRP-SYSLOG-EVENT-DOWN: HSRP : NOT Active
*Nov 22 16:10:41.282: %TRACKING-5-STATE: 1 Up->Down
*Nov 22 16:10:41.810: %SYS-5-CONFIG_I: Configured from console by vty0
*Nov 22 16:10:51.918: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Speak -> Standby


R1

*Nov 22 16:10:40.602: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active
*Nov 22 16:10:40.754: %HA_EM-6-LOG: HSRP-SYSLOG-EVENT-UP: HSRP : Active
*Nov 22 16:10:40.754: %TRACKING-5-STATE: 1 Down->Up
*Nov 22 16:10:41.270: %SYS-5-CONFIG_I: Configured from console by vty0


Traffic in both directions should go through R1 again.

CORE => HOST

CORE#tr 4.4.4.4 so l0

Type escape sequence to abort.
Tracing the route to 4.4.4.4

1 R1-S1-0 (13.13.13.1) 24 msec 72 msec 12 msec
2 HOST-F0-0 (10.10.10.3) 44 msec * 80 msec
CORE#


HOST => CORE

HOST#tr 3.3.3.3 so l0

Type escape sequence to abort.
Tracing the route to 3.3.3.3

1 R1-F0-0 (10.10.10.1) 40 msec 32 msec 20 msec
2 CORE-S1-1 (13.13.13.3) 32 msec * 96 msec
HOST#


4) Comments

4.1) If you're making some kind of load-sharing using MHSRP or you're using many HSRP groups on many interfaces, then the whole thing gets much more complicated because you end up having a lot of extra EEM configuration. And you don't want to begin troubleshooting it!

4.2) Hosts directly connected to either router (R1 or R2) will always prefer the local connected route, so you cannot avoid the asymmetry there.

4.3) You might get into confusion when EEM changes the configuration. I don't know if adding a "wr mem" as the last action command would help in such a situation (although i don't want to imagine what would happen if there were many consecutive HSRP state changes).

4.4) EEM 2.2 is needed for support of Enhanced Object Tracking. According to CCO, it should be supported in 12.4(2)T, 12.2(31)SB3, 12.2(33)SRB and above. My test was done on 7200s running 12.4(20)T.

4.5) In IOS 12.4(11)T and above, BFD comes with support for HSRP. According to CCO this is particular useful in architectures where a single interface hosts a large number of HSRP groups, due to BFD's low CPU memory consumption and processing overhead. If you want to use it, just enable BFD ("bfd interval ...") under the HSRP interfaces and you're done.

I hope Cisco will soon provide the "suppress-connected-route-on-standby-interfaces" functionality, as other vendors already do for their FHRPs. It's a so much needed feature. Also the HSRP state detections can be made much easier if Cisco implements an EEM event detector that watches the state of a redundancy group. After all, isn't that the reason "standby X name XXX" got implemented in the first place?

PS: Can someone tell me why Cisco insists on using the "standby" keyword instead of "hsrp"?

Thursday, August 21, 2008

Possible new CCIE logos

Few hours ago i received an email from Cisco, asking certified professionals, to provide feedback on the possible new logos that will represent Cisco career certifications on learning materials, as well as on promotional items such as shirts, hats, and jackets.

The two choices i was given were the following:



©2008 Ipsos Interactive Services
©2008 Cisco Systems, Inc


I personally prefer the 1st one...maybe even more than the current one. On the other hand, the second one would probably be good for stickers.

PS: I hope they do the same (create new ones and give the chance to people to "choose') for the plaque too. The current one sucks!

Sunday, August 10, 2008

Exam Discounts, Vouchers & Promotional Codes

Lately i'm finding quite a few of "free" voucher codes on the internet that provide you with 20%-30% off the price of a Cisco written exam.

According to Cisco, these third-party vouchers should not be used, but i have seen a lot of people giving them for free (Brandon being the latest example) and many other people using them without any problems. I respect Brandon's movement and intentions (everyone reading his excellent blog will probably agree with me), but i'm just wondering... how can someone get a voucher that is valid for many candidates? Is it some kind of multiple use voucher? And if there are multiple use vouchers, why does Cisco insist on denying them?

Anyway, this is the part from Cisco's policy i'm talking about:

Exam Discounts, Vouchers & Promotional Codes

Neither Cisco nor Pearson Vue, its primary test delivery partner, guarantee the authenticity of any discount or promotional code (e.g., voucher or promotional code) obtained from any third party individual or entity.

Cisco recommends that vouchers be purchased directly through Pearson VUE. Individuals who use any unauthorized discount or promotional code may have their exam results invalidated and/or risk up to and including a lifetime ban on all future exams and the nullification of all previous certifications. Cisco will not replace any voucher that is found to be fraudulent or used.


To be honest, i cannot quite justify the above "lifetime ban" and "nullification" statements. Losing all your certs because of using someone else's discount code?

Why should someone be banned after using an unauthorized discount/promotional code?

Where exactly do the words "unauthorized" & "authenticity" refer to? Do vouchers have any kind of AAA (minus accounting) functionality?


1st Update 12 Aug 2008 : According to Brandon's answer, Certified Cisco Systems Instructors (CCSIs) get such coupons and they are valid (and within the guidelines of the Exam Policy).

2nd Update 12 Aug 2008 : According to Brandon's new answer :
While the Terms of participation from vue state that the voucher is for students that are trained "online", and this blog was founded and provided at add to the learning experience of my students, the Terms of participation also include the verbage : "Such activities include, but are not limited to, false or deceptive use, or misuse of pre-assigned codes, mass electronic distribution, including but not limited to posting of pre-assigned codes on Internet Web sites, chat sites or via publicly available banner ads or Web links, or resale of pre-assigned codes or bundling packages that include pre-assigned codes."


Monday, July 28, 2008

CCO documentation errors & the VTP v2 transparent issue

Dear Cisco Customer,


Thank you for your recent feedback on Cisco technical documentation submitted through
the embedded feedback form. Your feedback has highlighted a potential change to our
documentation and this has formally been raised as an error with the relevant
technical documentation organization.


We look forward to your continued participation on improving our product documentation.

Thank you,

The Cisco Documentation Team


I don't know how many times you have seen the above message in your email, but i'm getting around 1 or 2 of those per month.

I belong to the category of people that fill the feedback form for every small or big "error" they come through when reading a document on CCO. It usually doesn't take more than a minute, as long as there is a working feedback form somewhere on the page. I don't even remember every feedback i submit; that's why i believe Cisco should include the customer submitted form in the answer too.

In a previous post of mine i had talked about VTP v2 in transparent mode and how it should work according to the current CCO documentation (VTP is Cisco proprietary so it's difficult to find information elsewhere).


Version-Dependent Transparent Mode — In VTP Version 1, a VTP transparent switch
inspects VTP messages for the domain name and version and forwards a message only if
the version and domain name match. Because VTP Version 2 supports only one domain,
it forwards VTP messages in transparent mode without inspecting the version and domain name
.


As it proved out (check the comments on my old post; thx to Antonie for making me search it deeper), this specific CCO documentation is totally wrong (switches with VTP v2 in Transparent mode should not forward VTP updates unless the domain name matches the locally configured domain name) and a bug (CSCsi65330) has been raised a long time ago about it. This bug has been opened to correct the documentation guides for VTP v2 transparent mode behavior due to another bug (CSCea40015).

In the meanwhile, the above CCO documentation is correct when using NM-16ESW as switches, so a new bug (CSCsr22106) has been opened in order to correct this behavior too.

The first bug is waiting for many months to be fixed (still in Assigned state), while all the new documentation pages that are being added to CCO, still include the wrong description. There should be around 100 pages right now that include the above wrong description.


The answer that i got from Cisco was:


Certainly the documents currently on CCO have not been updated and even the
new ones are reflecting the same info. I apologize if this caused any
inconveniences for you, and would like to ensure that our technical
documentation team is working to get this fixed, but as if now the documents
are reflecting incorrect information.
...

About the other documentation part, I am still waiting for an official note
that would be replacing the wrong one, however it should be replaced by
something like: "Switches running VTPv2 in transparent mode only forward VTP
frames if the domain name of the VTP frame matches the locally configured
VTP domain, or the switch has an un-configured NULL VTP domain".


To be honest, i don't expect this documentation to be corrected soon. It stayed there for many months and it keeps on reproducing itself.

I also have another issue with the 802.1q tunneling documentation on CatOS, but i have a feeling that this one is going to be harder to be fixed.

What's your own experience?

Update 1 Aug 2008 : I have added a poll to the right, so you choose whether you submit feedback for documentation errors on CCO or not. If YES what is the result? If NO, why?

Update 1 Sep 2008 : These are the results of the above poll:

Friday, July 25, 2008

Minor blog redesign & advertisements addition

During the last months i have been experimenting with and doing small changes in the design of my blog, ranging from the addition of a custom Google search to the addition of today's advertisement.

Here is a summary of all of them:

  • Profile details have been moved inside the profile, so they are not viewable from the main page. You have to click on "View my complete profile" in order to view them.
  • A picture of me and John (Chambers, who else?) from Cisco Live 2008 has been added as a profile photo. I hope it's blurred enough, so i cannot be recognized easily. You wouldn't believe how friendly the CEO of a network giant can be.
  • A custom Google search engine has been added, which includes all the blogs links shown at the right sidebar. Everyone interested can add his/her own links to this custom search engine by following the appropriate links.
  • A blog list has been added, which displays the latest news/posts for each one of the blog links at the right sidebar. I'm thinking of removing the blog links at some time in the future if the blog list satisfies both needs.
  • An advertisement area has been added, something different than the adsense area which is at the bottom of the right sidebar. This started when some days ago i was contacted by Mike Down of IP Expert, regarding a mutual "cooperation". I was offered some free "gifts" from IP Expert's training material in exchange of a banner of his company on my blog. I'm not generally a fan of training products that teach you the technologies, especially in a non-interactive way (that goes for all vendors), because i have the bad habit of focusing mostly on my own strengths in order to understand them, to get into them, to mess with them. That's why i usually prefer the kind of graded mock labs, so i can better evaluate my knowledge after i have acquired it using my own means (too bad i haven't found any vendor offering these for the SP track). To be honest, Mike's offer was quite generous, but it didn't fit me; at least not for the present (we had a very interesting talk about all this). Nevertheless i decided to add his company's banner on my blog, because i enjoyed all this conversation with Mike and of course you never know what the future will hold (when J.Chambers talks so eagerly about "The Power of Collaboration" in Live 2008, you'd better keep notes).
  • The disclaimer at the bottom of the page has been updated to include information about 3rd party content, blog posts/comments and advertisements.
  • The width of the main column (where the posts are shown) has been increased, so most IOS configuration examples can be displayed without the need to scroll left-right.


My next step is to finalize the css style regarding my posts, so everything has a common format. HTML/CSS isn't my best, but i like messing almost with everything.

Wednesday, July 16, 2008

Embedded Packet Capture - How to make routers more active

How many times where you in a need to get a remote packet capture and either ERSPAN wasn't available or the network architecture couldn't help you accomplish it easily?
How many times were you wondering what packets are being dropped in a interface or are being punted to the CPU?
Can you think of an easy way to capture traffic with source and destination on the same router?

Using EPC you can solve -quite easily- all of these issues.

Cisco IOS Embedded Packet Capture (EPC) (available in latest 12.4(20)T; Cisco says 12.2SR too, but SRC on 7200 and SRB on 7600 do not support it) is a powerful troubleshooting and tracing tool which allows network administrators to capture data packets flowing through, to, and from, a Cisco router.

It's actually a onboard packet capture facility that facilitates troubleshooting, the gathering of information on packet format, application analysis, and security. The devices become active participants in the management and operation of the network.

Generally Cisco seem to be investing a lot on this kind of active management; We see EEM get expanded release by release and new Embedded XXX features are coming often into surface on each new release. Long gone are the days of dumb passive routers; the future needs active devices (maybe "I, Robot" was sponsored by Cisco?)

Ok, back to reality...EPC now...

EPC can be used in troubleshooting scenarios where it is helpful to see the actual data being sent through, from, or to the network device. It simplifies operations by allowing the devices to become active participants in the management and operation of the network.

To capture packet data and analyze it, the following tasks need to be performed:

1) Define a capture buffer on a device
2) Define a capture point on a device
3) Associate some capture points with a capture buffer
4) Start (& stop if needed) the capture point
5) View the buffer data either locally or remotely in pcap format


1) Defining a capture buffer on a device

The Capture Buffer is where the packet data will be contained. Capture Buffers are user-named and you can define how the buffer handles the data going into it.

The available configuration offers the following options:

You can specify the size (why only 512KB?) and type of buffer: linear or circular.

• A linear buffer will stop capturing automatically when full.
• A circular buffer will continue to capture packet data (overwriting old data with newer as it fills up).


R1#monitor capture buffer EPC-BUFFER-1 ?
circular Circular Buffer
...
linear Linear Buffer(Default)
...
size Packet Dump buffer size (in Kbytes)


R1#monitor capture buffer EPC-BUFFER-1 size ?
<1-512> Buffer size in Kbytes : 512K or less (default is 256K)


The maximum number of bytes to capture per packet can be limited to save space. But why only 1024?


R1#monitor capture buffer EPC-BUFFER-1 ?
...
max-size Maximum size of element in the buffer (in bytes)
...


R1#monitor capture buffer EPC-BUFFER-1 max-size ?
<68-1024> Element size in bytes : 1024 bytes or less (default is 68 bytes)


Rate limiting can also be enabled to:

• Specify a max capture rate (in packets per second).
• Capture every "nth" packet.

Or an automatic limit criteria can be defined to:

• Stop the capture after a specified time interval.
• Stop the capture after capturing a given number of packets.


R1#monitor capture buffer EPC-BUFFER-1 limit ?
allow-nth-pak Allow every nth packet through
duration Duration of capture
packet-count Limit total Number of packets captured
packets-per-sec Limit number of packets copied per sec


Filters can also be set for packets being stored in a buffer via ACLs.


R1#monitor capture buffer EPC-BUFFER-1 ?
...
filter Configure filters

R1#monitor capture buffer EPC-BUFFER-1 filter ?
access-list Set access list


Two types of data are stored in a capture buffer: Meta Data and Packet Data.

Meta Data (which helps in filtering too) contains:

• A timestamp of when it is added to a buffer.
• Direction, egress or ingress.
• The switch path it captured.
• Encapsulation type corresponding to input/output interface to allow the decoding of L2.
• Offset to network_start, to facilitate the decoding of L3, if complete L2 decoders are unavailable.
• L3 protocol ID, to facilitate the decoding of L3, if complete L2 decoders are unavailable.


R1#sh monitor capture buffer EPC-BUFFER-1 filter ?
direction Filter output based on direction
input-interface Filters packet on an input interface
l3protocol Filter packets with specific L3 protocol
output-interface Filters packet on an output interface
pak-size Filter output based on packet size
time Filter packets from a specific clock time/date


The packet data starts from datagram-start and copies a minimum of the per packet capture size or datagram-size.

In our example we'll use a circular capture buffer (so it won't stop automatically), 512 Kbytes long ("size"), set to include up to 1024 bytes per packet ("max-size"). We'll call the buffer EPC-BUFFER-1.


R1#monitor capture buffer EPC-BUFFER-1 size 512 max-size 1024 circular

R1#sh monitor capture buffer all parameters
Capture buffer EPC-BUFFER-1 (circular buffer)
Buffer Size : 524288 bytes, Max Element Size : 1024 bytes, Packets : 0
Allow-nth-pak : 0, Duration : 0 (seconds), Max packets : 0, pps : 0
Associated Capture Points:
Configuration:
monitor capture buffer EPC-BUFFER-1 size 512 max-size 1024 circular


Note: The "monitor capture" commands are on exec-level, so they are not stored in the config/nvram. So, it's a nice addition that you can see them using the appropriate show commands.


2) Defining a capture point on a device

The Capture Point is a traffic transit point where the packet capture takes place. It is also identified by a user-defined name.

The following protocols are available as capture points:

• IPv4
• IPv6

And each one of them can be combined with the following forwarding methods:

• CEF
• process switching


R1#monitor capture point ?
...
ip IPv4
ipv6 IPv6
...

R1#monitor capture point ip ?
cef IPv4 CEF
process-switched Process switched packets

R1#monitor capture point ipv6 ?
cef IPv6 CEF
process-switched Process switched packets


Capture points can be interface specific or include all interfaces.


R1#monitor capture point ip cef EPC-POINT-1 ?
...
Async Async interface
BVI Bridge-Group Virtual Interface
Dialer Dialer interface
FastEthernet FastEthernet IEEE 802.3
Group-Async Async Group interface
Loopback Loopback interface
all All interfaces
...


They can also include specific kinds of traffic like :

• Punt
• Drop
• From-us (locally generated packets) - This applies only to process switched traffic


R1#monitor capture point ip cef EPC-POINT-1 ?
...
drop Drop on any interface
punt Punt on any interface
...

R1#monitor capture point ip process-switched EPC-POINT-2 ?
...
from-us Packets originating locally
...


Capture points can also be specific to traffic direction:

• In (meaning capture at ingress)
• Out (meaning capture at egress)
• Both


R1#monitor capture point ip cef EPC-POINT-1 S1/0 ?
both capture ingress and egress
in capture on ingress
out capture on egress

R1#monitor capture point ip process-switched EPC-POINT-2 ?
both Inbound and outbound and packets
...
in Inbound packets
out Outbound packets


Note: I couldn't find the combination of process-switched traffic and an interface. Also Cisco provides an example of a combination of CEF switched traffic and local originated. Strange...

We'll use 2 capture points : One for IPv4 process switched traffic originated from the router itself and another one for IPv4 CEF switched traffic passing through S1/0 in both directions.


R1#monitor capture point ip process-switched EPC-POINT-1 from-us
R1#
*Jul 16 01:37:14.571: %BUFCAP-6-CREATE: Capture Point EPC-POINT-1 created.

R1#monitor capture point ip cef EPC-POINT-2 S1/0 both
R1#
*Jul 16 01:36:06.027: %BUFCAP-6-CREATE: Capture Point EPC-POINT-2 created.

R1#sh monitor capture point all
Status Information for Capture Point EPC-POINT-2
IPv4 CEF
Switch Path: IPv4 CEF , Capture Buffer: None
Status : Inactive

Configuration:
monitor capture point ip cef EPC-POINT-2 Serial1/0 both

Status Information for Capture Point EPC-POINT-1
IPv4 Process
Switch Path: IPv4 Process , Capture Buffer: None
Status : Inactive

Configuration:
monitor capture point ip process-switched EPC-POINT-1 from-us



3) Associating some capture points with a capture buffer

Association (and disassociation) are actions that can be performed in order to combine a capture point with a capture buffer. A capture point can only be associated with one capture buffer (an ACL filter can also be applied). A capture buffer can be associated with many capture points. So, a buffer can collect data from many points but a point can send data to only one buffer.


R1#monitor capture point ?
associate Associate capture point with capture buffer
disassociate Dis-associate capture point from capture buffer


Multiple packet capture points may be active on a given interface simultaneusly; i.e. BGP packets can be captured into one capture buffer and OSPF packets into another. You just have to use the filter/acl option while creating each capture buffer.

We'll associate our 2 capture points with our single capture buffer..


R1#monitor capture point associate EPC-POINT-1 EPC-BUFFER-1

R1#monitor capture point associate EPC-POINT-2 EPC-BUFFER-1

R1#sh monitor capture point all
Status Information for Capture Point EPC-POINT-2
IPv4 CEF
Switch Path: IPv4 CEF , Capture Buffer: EPC-BUFFER-1
Status : Inactive

Configuration:
monitor capture point ip cef EPC-POINT-2 Serial1/0 both

Status Information for Capture Point EPC-POINT-1
IPv4 Process
Switch Path: IPv4 Process , Capture Buffer: EPC-BUFFER-1
Status : Inactive

Configuration:
monitor capture point ip process-switched EPC-POINT-1 from-us

R1#sh monitor capture buffer all parameters
Capture buffer EPC-BUFFER-1 (circular buffer)
Buffer Size : 524288 bytes, Max Element Size : 1024 bytes, Packets : 0
Allow-nth-pak : 0, Duration : 0 (seconds), Max packets : 0, pps : 0
Associated Capture Points:
Name : EPC-POINT-1, Status : Inactive
Name : EPC-POINT-2, Status : Inactive
Configuration:
monitor capture buffer EPC-BUFFER-1 size 512 max-size 1024 circular
monitor capture point associate EPC-POINT-1 EPC-BUFFER-1
monitor capture point associate EPC-POINT-2 EPC-BUFFER-1



4) Starting (& stopping if needed) the capture

The creation of capture points doesn't automatically start them too. You have to do it manually for all capture points that you need to enable.


R1#monitor capture point ?
...
start Enable Capture Point
stop Disable Capture Point

R1#monitor capture point start ?
WORD Name of the Capture Point
all All Capture Points

R1#monitor capture point stop ?
WORD Name of the Capture Point
all All Capture Points


So everything is ready for us to start capturing. Just note that in all of our previous outputs, status was inactive. After staring them, it turns to active.


R1#monitor capture point start EPC-POINT-1
R1#
*Jul 16 01:55:13.475: %BUFCAP-6-ENABLE: Capture Point EPC-POINT-1 enabled.
R1#monitor capture point start EPC-POINT-2
R1#
*Jul 16 01:55:21.503: %BUFCAP-6-ENABLE: Capture Point EPC-POINT-2 enabl

R1#sh monitor capture point all
Status Information for Capture Point EPC-POINT-2
IPv4 CEF
Switch Path: IPv4 CEF , Capture Buffer: EPC-BUFFER-1
Status : Active

Configuration:
monitor capture point ip cef EPC-POINT-2 Serial1/0 both

Status Information for Capture Point EPC-POINT-1
IPv4 Process
Switch Path: IPv4 Process , Capture Buffer: EPC-BUFFER-1
Status : Active

Configuration:
monitor capture point ip process-switched EPC-POINT-1 from-us

R1#sh monitor capture buffer all parameters
Capture buffer EPC-BUFFER-1 (circular buffer)
Buffer Size : 524288 bytes, Max Element Size : 1024 bytes, Packets : 0
Allow-nth-pak : 0, Duration : 0 (seconds), Max packets : 0, pps : 0
Associated Capture Points:
Name : EPC-POINT-1, Status : Active
Name : EPC-POINT-2, Status : Active
Configuration:
monitor capture buffer EPC-BUFFER-1 size 512 max-size 1024 circular
monitor capture point associate EPC-POINT-1 EPC-BUFFER-1
monitor capture point associate EPC-POINT-2 EPC-BUFFER-1
R1#



5) Viewing the packet data either locally or remotely in pcap format

You can display the buffer contents in either an ASCII-like format (not very useful) or in HEX format (by using the "dumb" keyword at the end).

Below, you can see a ping from 9.9.9.2 (R2) to 9.9.9.1 (R1) passing through S1/0.


R2#ping 9.9.9.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 9.9.9.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/40/60 ms


Let's check the buffer contents in R1:


R1#sh monitor capture buffer EPC-BUFFER-1
02:03:02.579 UTC Jul 16 2008 : IPv4 CEF Turbo : Se1/0 None

02:03:02.579 UTC Jul 16 2008 : IPv4 LES CEF : Se1/0 None

02:03:02.583 UTC Jul 16 2008 : IPv4 Process : None Se1/0

02:03:02.663 UTC Jul 16 2008 : IPv4 CEF Turbo : Se1/0 None

02:03:02.663 UTC Jul 16 2008 : IPv4 LES CEF : Se1/0 None

02:03:02.663 UTC Jul 16 2008 : IPv4 Process : None Se1/0

02:03:02.683 UTC Jul 16 2008 : IPv4 CEF Turbo : Se1/0 None

02:03:02.683 UTC Jul 16 2008 : IPv4 LES CEF : Se1/0 None

02:03:02.683 UTC Jul 16 2008 : IPv4 Process : None Se1/0

02:03:02.719 UTC Jul 16 2008 : IPv4 CEF Turbo : Se1/0 None

02:03:02.719 UTC Jul 16 2008 : IPv4 LES CEF : Se1/0 None

02:03:02.719 UTC Jul 16 2008 : IPv4 Process : None Se1/0

02:03:02.735 UTC Jul 16 2008 : IPv4 CEF Turbo : Se1/0 None

02:03:02.735 UTC Jul 16 2008 : IPv4 LES CEF : Se1/0 None

02:03:02.735 UTC Jul 16 2008 : IPv4 Process : None Se1/0
...

R1#sh monitor capture buffer EPC-BUFFER-1 dump
02:03:02.579 UTC Jul 16 2008 : IPv4 CEF Turbo : Se1/0 None

6771C8A0: 0F000800 45000064 00000000 FE019884 ....E..d....~...
6771C8B0: 09090902 09090901 08008E62 00000000 ...........b....
6771C8C0: 00000000 0003EFE4 ABCDABCD ABCDABCD ......od+M+M+M+M
6771C8D0: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
6771C8E0: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
6771C8F0: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
6771C900: ABCDABCD ABCDABCD 00 +M+M+M+M.

02:03:02.579 UTC Jul 16 2008 : IPv4 LES CEF : Se1/0 None

6771C8A0: 0F000800 45000064 00000000 FE019884 ....E..d....~...
6771C8B0: 09090902 09090901 08008E62 00000000 ...........b....
6771C8C0: 00000000 0003EFE4 ABCDABCD ABCDABCD ......od+M+M+M+M
6771C8D0: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
6771C8E0: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
6771C8F0: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
6771C900: ABCDABCD ABCDABCD 00 +M+M+M+M.
...


Analyzing the first part we get the following for the header :


0F000800 45000064 00000000 FE019884

0F00 = Cisco HDLC, Address: Unicast (0x0f)
0800 = Protocol: IP (0x0800)
45 = 0100 0101 = IP v4
00 = TOS/DSCP 0x00
0064 = Total Length: 100
01 = Protocol: ICMP (0x01)

09090902 09090901 08008E62 00000000

09090902 = Source 9.9.9.2
09090901 = Destination 9.9.9.1
08 = Type: 8 (Echo (ping) request)
00 = Code: 0


Now, if we send 36 bytes ICMP packets, we can see the difference:


R2#ping 9.9.9.1 size 36

Type escape sequence to abort.
Sending 5, 36-byte ICMP Echos to 9.9.9.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/32/48 ms


We check again the buffer contents:


R1#sh monitor capture buffer EPC-BUFFER-1 dump
02:30:47.419 UTC Jul 16 2008 : IPv4 Process : None Se1/0

6771C8A0: 0F000800 45000024 000A0000 FF0197BA ....E..$.......:
6771C8B0: 09090901 09090902 0000A8C4 00020000 ..........(D....
6771C8C0: 00000000 001D571C 00 ......W..

02:30:47.491 UTC Jul 16 2008 : IPv4 Process : None Se1/0

6771C8A0: 0F000800 45000024 000B0000 FF0197B9 ....E..$.......9
6771C8B0: 09090901 09090902 0000A88F 00020001 ..........(.....
6771C8C0: 00000000 001D5750 00 ......WP.


And analyze again the header:


0F000800 45000024 000A0000 FF0197BA

0F00 = Cisco HDLC, Address: Unicast (0x0f)
0800 = Protocol: IP (0x0800)
45 = 0100 0101 = IP v4
00 = TOS/DSCP 0x00
0024 = Total Length: 36
01 = Protocol: ICMP (0x01)


You can also export the buffer contents to an external location in the pcap format. Then you can use Wireshark to examine them more thoroughly.


R1#monitor capture buffer EPC-BUFFER-1 export ?
ftp: Location to dump buffer
http: Location to dump buffer
https: Location to dump buffer
pram: Location to dump buffer
rcp: Location to dump buffer
scp: Location to dump buffer
tftp: Location to dump buffer



PS: Btw, you can find a lot of sample pcap files in Jeremy's excellent site, PacketLife.


Generally, EPC provides the following :

• Ability to capture IPv4 and IPv6 packets in the Cisco Express Forwarding path
• A flexible method for specifying the capture buffer size and type
• EXEC-level commands to start and stop the capture
• Show commands to display packet contents on the device
• Facility to export the Packet Capture in PCAP format suitable for analysis using an external tool such as Wireshark
• Extensible infrastructure for enabling packet capture points


Another hooray for Cisco!!!

There seem to be some inconsistencies on this release of EPC plus some without-obvious-reason limitations, but i hope newer releases will improve its functionality (an extra option showing the basic fields of the packet header in understandable format would be a welcome addition). We needed it and we welcome it!.

 
Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.
Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Greece License.