Ciscoman's notes (Записки цыщика c дипломом)

I'm Cisco Champion Community member for 2017!

I'm Cisco Champion Community member for 2017!
"Cisco Champions are passionate about Cisco and happy to share our knowledge, experience, and feedback."

вторник, 27 декабря 2011 г.

MTS 3G configuration for Cisco 880G and 890G series routers

#cellular 0 gsm profile create 1 internet.mts.ru pap mts mts ipv4
!
chat-script reset_chat-script "" \d\d\d+++\d\d\d
chat-script mts_chat-script TIMEOUT 90 "" AT+CGDCONT=1,"IP","internet.mts.ru" OK ATDT*99*1# CONNECT

!

interface Cellular0
 ip address negotiated
 encapsulation ppp
 dialer in-band
 dialer string mts4
 dialer-group 1
 autodetect encapsulation ppp
 async mode interactive
 ppp authentication pap chap callin
 ppp chap hostname mts
 ppp chap password 0 mts
 ppp chap refuse
 ppp pap sent-username mts password 0 mts
!
dialer-list 1 protocol ip permit
!
line 3
 script dialer mts_chat-script
 script reset reset_chat-script
 no login
 modem InOut
 modem autoconfigure discovery
 no exec
 transport input none
 transport output all

среда, 9 ноября 2011 г.

Do you know that: redistribution and route types internal/external

Do you know how to make route internal or external during redistribution?

Look at the configuration example:

R1:

interface Loopback1
 ip address 10.20.30.40 255.255.255.255
!
interface FastEthernet1/0
 ip address 10.0.1.1 255.255.255.252
!
router eigrp 1
 network 10.0.1.1 0.0.0.0
 redistribute static metric 1000 10 10 10 1500


!
ip route 10.10.10.10 255.255.255.255 Loopback1

R1#sh ip route | b Gate
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C        10.0.1.0/30 is directly connected, FastEthernet1/0
L        10.0.1.1/32 is directly connected, FastEthernet1/0
D        10.0.3.0/30 [90/30720] via 10.0.1.2, 00:05:33, FastEthernet1/0
S        10.10.10.10/32 is directly connected, Loopback1
C        10.20.30.40/32 is directly connected, Loopback1


R1#sh ip eigrp topology 10.10.10.10/32
EIGRP-IPv4 Topology Entry for AS(1)/ID(10.0.1.1) for 10.10.10.10/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2562560
  Descriptor Blocks:
  0.0.0.0, from Rstatic, Send flag is 0x0
      Composite metric is (2562560/0), route is External
      Vector metric:
        Minimum bandwidth is 1000 Kbit
        Total delay is 100 microseconds
        Reliability is 10/255
        Load is 10/255
        Minimum MTU is 1500
        Hop count is 0
        Originating router is 10.0.1.1
      External data:
        AS number of route is 0
        External protocol is Static, external metric is 0
        Administrator tag is 1 (0x00000001)


As you can see here is redistributed static route is injected in eigrp topology as external. How to make it internal? It is simple: include redistributed subnet into network command under eigrp section.

R1(config)#router eigrp 1
R1(config-router)#network 0.0.0.0
R1(config-router)#do sh ip eigrp topology 10.10.10.10/32
EIGRP-IPv4 Topology Entry for AS(1)/ID(10.0.1.1) for 10.10.10.10/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2562560
  Descriptor Blocks:
  0.0.0.0, from Rstatic, Send flag is 0x0
      Composite metric is (2562560/0), route is Internal
      Vector metric:
        Minimum bandwidth is 1000 Kbit
        Total delay is 100 microseconds
        Reliability is 10/255
        Load is 10/255
        Minimum MTU is 1500
        Hop count is 0
        Originating router is 10.0.1.1
        Internal tag is 1

четверг, 27 октября 2011 г.

debug ip packet rcvd explanation

From the Cisco Support Community, https://supportforums.cisco.com/thread/2111309

"rcvd 0" we've decremented ttl on input.  it's now 0 but it might be for us (like OSPF MCAST which is TTL=1 from begining)

"rcvd 1" not routing this, we're passing it to bridging code. might also see this even with bridging turned off (router config'd as an endstation)

"rcvd 2" can't route the packet. final check to see if it's for us. usually packets sent to this router where debug is done.

"rcvd 3" input & output interface is the same but we can't redirect
the packet for some reason (NAT maybe?) and it's not for us

"rcvd local pkt" it came from us originally, dropping

"rcvd 4" not sure, but looks like it's for us, just not the input
interface (one of the other ones) - loopback in you case.


"rcvd 5" can't route the packet, see if it's for us before dropping
not sure but this could be failure at the output interface such as
encapsulation failure

"rcvd 6" looks like for us if we have an IP alias entry due to NAT
or something.  Should jive with "show ip alias"

"rcvd 7" goes to one of our secondary IP addresses

вторник, 25 октября 2011 г.

воскресенье, 23 октября 2011 г.

Cisco support community in Russian

А вы в курсе что сообщество NetPro теперь и на русском?  Особо приятно, что оно третье после Испанского и Японского. Присоединяйтесь: https://supportforums.cisco.com/community/russian?view=overview

Ho to track cause of high number of connections on ASA/FWSM

Today somebody asked on cisco support cummunity how to track cause of high number of connections on ASA/FWSM. I thinked little and write down this answer, hope it will be helpful for anybody facing this issue:


TIP: If you have some kind of unix box, you can use show conn  and export it to the file. This file should be placed on unix box. Than you can use on unix box:

cat | sed -e 's/:/ /g' | awk '{print $6}' | sort | uniq -c | sort -g

The output will be like this:

      7 10.96.158.1
      7 10.96.177.1
      7 10.96.19.1
      7 10.96.198.1
      7 10.97.29.1
      7 10.97.58.1
      7 10.97.60.1
      8 10.97.30.1
      8 10.97.43.1
      9 10.96.117.1
      9 10.96.34.1
      9 10.97.10.1
     10 10.96.159.1
     18 212.248.105.74
     26 10.96.2.34

Here is the first column is count and second column is address of the inside host. For outside host count use {print $3}

вторник, 18 октября 2011 г.

OSPF E1 vs N1 vs E2 vs N2

1. N1 & E1 are preferred over N2 & E2 for the same route
2. When N1 & E1 have the same route to the destination, The one that have lower cost / Metric will win and get into the route table
3. If both N1 & E1 have the same cost, P-bit in N1 will be used to break the tide.
4. If P-bit is 0 (Then it would become E1) then we will have 2 E1 routes install into the routing table. (otherwise if maximum-path = 1, LSA with Higher Router-ID will get installed)

See rfc 3101 for details.

Update1. Cisco IOS OSPF realization is significantly differs from RFC:
http://blog.ioshints.info/2008/01/e1-and-e2-routes-in-ospf.html This article is outdated.

Update2.  Enable 'capability rfc1587' to fall back to the "E2 is preferred over N2" route selection algorithm.

четверг, 13 октября 2011 г.

How to filter annoying syslog messages from Cisco IOS

SW_MATM-4-MACFLAP_NOTIF due to wifi devices
These messages can be annoying if you run a wireless network where there is a lot of roaming on a Cisco architecture such as C3750's.

Here is how to ensure the messages get completely ignored if you are tired of seeing them:

logging discriminator nolog msg-body drops flapping
logging buffered discriminator nolog
logging console discriminator nolog
logging monitor discriminator nolog
logging host X.X.X.X discriminator nolog

понедельник, 10 октября 2011 г.

VTI-based IPSec NB

With the Cisco IOS Software crypto map based system, the IPsec subsystem will
request SAs to be established upon seeing interesting traffic that matches the crypto map.
In a VTI-based IPsec VPN, IPsec requests SA establishment as soon as the virtual tunnel
interface (VTI)s are fully configured.

четверг, 22 сентября 2011 г.

Dirty Marketing Technologyes of Cisco

I respect both companies Cisco and Juniper, but I could not go over the link that was given to me by my friend. Here is it: http://www.overpromisesunderdelivers.net/
The essence of the matter: Cisco is trying to accuse Juniper for failing to their promises and announcements.
Simply speaking there is no facts, only two well produces videos and white-paper with same "facts". Of course, you decide themselves who is right, but I did not saw that the same methods below the belt was used anywhere by Juniper .

четверг, 15 сентября 2011 г.

Анекдот из жизни

Идет разговор о работе с коллегами о лучшем месте для работы.

Я: Хотите я вас расстрою? Знаете где находится группа по взаимоотношению с клиентами, ну те, кто занимаются проблемами с аккаунтами на cisco.com и так далее?
Коллега: Обезьянья работа?
Я: Да, именно.
Коллега: Нет, не знаю. Так где?
Я: На Мальдивах!
Коллега: Правильно. Где ещё должна делаться обезьянья работа, на пальме, конечно :-)

воскресенье, 8 мая 2011 г.

суббота, 16 апреля 2011 г.

ns-2 network simulator installation on Ubuntu 10.10

Today I was required to install ns-2 from scratch in Ubuntu 10.10.
For this purpose it is needed to download archive from official site, extract it and run ./install in it's directory.
Before that build-essentials package is required to be installed via
apt-get install build-essentials.
After build-essential is installed, you can run ./install. This script will give you the error about undefined reference to `__stack_chk_fail_local' in otcl.c. How can you fix it? Simplest way:
disable stack protection: set the CFLAGS to -fno-stack-protector
For this purpose you can modify "install" on line 497 and set

        ./configure CFLAGS=-fno-stack-protector || die "otcl-$OTCLVER configuration failed! Exiting ...";
instead of
        ./configure || die "otcl-$OTCLVER configuration failed! Exiting ...";
 








пятница, 1 апреля 2011 г.

Do you know what...

- Default ARP entry timeout is 4 hours in IOS!
- DHCP Offer can be sent to all ones broadcast address instead of unicast address in certain situations.
- You can policy route route locally generated broadcast and multicast traffic with "ip local policy". For example this can lead to problems with dhcp server responses  to broadcast address.
- You can't use "match interface" in "ip local policy route-map"
- 255 is inaccessible administrative distance in IOS, you can use it for route filtering
- RIP doesn't generates corresponding Null0 routes for summary addresses opposit to EIGRP and OSPF. This can lead to different interesting situations like routing loops.
- You can't make as-path repend for IBGP routes
- "ip split-horizon" is disabled by default on frame-relay physical interfaces

вторник, 29 марта 2011 г.

ECMP voodo magic


Hi! Today I would like to talk about ECMP in Cisco IOS. As you probably know there are two different methods – per-packet and per-destination load balancing. http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094820.shtml
Default method for IOS is to use per-destination load balancing with CEF. It is possible also to configure per-packet load balancing with CEF, or you can disable CEF and fast-switching to do per-packet.
Let’s look at the following simple topology:

Figure 1. ECMP topology


There is no really nothing unclear with except of two facts. On R1 ECMP is working.  R5 prefer R3 as the default route.   Routing protocol used here has no difference to achieve this configuration.  You can use static routing for simplicity.
Let’s look at the Router2 cef table for prefix 196.254.1.1:

Router2#sh ip cef 196.254.1.1/32 detail
196.254.1.1/32, epoch 0
  NetFlow: Origin AS 0, Peer AS 0, Mask Bits 32
  nexthop 9.8.7.217 GigabitEthernet0/1.996

Then let’s look at the traceroute (1):

Router2#traceroute 196.254.1.1 numeric source l0

Type escape sequence to abort.
Tracing the route to 196.254.1.1

  1 9.8.7.217 0 msec 4 msec 0 msec
  2 172.29.94.83 4 msec 0 msec 4 msec
  3 196.254.1.1 4 msec 0 msec 0 msec

As we expected it, it is per-destination and all three packets gone through 172.29.94.83 gateway, although on Router2 equal cost multipath load sharing is working.  Let’s look at the Router1 CEF table for prefix 196.254.1.1/32 and confirm this:

Router1#sh ip cef 196.254.1.1/32 detail
196.254.1.1/32, epoch 0, per-destination sharing
  NetFlow: Origin AS 0, Peer AS 0, Mask Bits 32
  nexthop 172.29.94.83 GigabitEthernet0/1.324
  nexthop 172.29.94.84 GigabitEthernet0/1.324

Let’s look at the traceroute results now (2):

Router1#traceroute 196.254.1.1 numeric source l0
Type escape sequence to abort.
Tracing the route to 196.254.1.1

  1 172.29.94.84 0 msec
    172.29.94.83 4 msec
    172.29.94.84 4 msec
  2 196.254.1.1 0 msec 0 msec 4 msec
Router1#

Do you see this strange behavior? Nothing strange really except it is per-packet, not per-destination as we was expecting.
Let’s recheck it again with extended ping command on Router2 (3):

Router2#ping
Protocol [ip]:
Target IP address: 196.254.1.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: loopback0
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]: yes
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: Record
Number of hops [ 9 ]:
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 196.254.1.1, timeout is 2 seconds:
Packet sent with a source address of 172.22.255.100
Reply data will be validated
Packet has IP options:  Total option bytes= 39, padded length=40
 Record route: <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)

Reply to request 0 (4 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:
   (9.8.7.218)
   (172.29.94.81)
   (172.27.175.1)
   (196.254.1.1)
   (196.254.1.1)
   (172.29.94.83)
   (9.8.7.217)
   (172.22.255.100) <*>
   (0.0.0.0)
 End of list

Reply to request 1 (4 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:
   (9.8.7.218)
   (172.29.94.81)
   (172.27.175.2)
   (196.254.1.1)
   (196.254.1.1)
   (172.29.94.83)
   (9.8.7.217)
   (172.22.255.100) <*>
   (0.0.0.0)
 End of list

Reply to request 2 (4 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:
   (9.8.7.218)
   (172.29.94.81)
   (172.27.175.1)
   (196.254.1.1)
   (196.254.1.1)
   (172.29.94.83)
   (9.8.7.217)
   (172.22.255.100) <*>
   (0.0.0.0)
 End of list

Reply to request 3 (4 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:
   (9.8.7.218)
   (172.29.94.81)
   (172.27.175.2)
   (196.254.1.1)
   (196.254.1.1)
   (172.29.94.83)
   (9.8.7.217)
   (172.22.255.100) <*>
   (0.0.0.0)
 End of list

Reply to request 4 (4 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:
   (9.8.7.218)
   (172.29.94.81)
   (172.27.175.1)
   (196.254.1.1)
   (196.254.1.1)
   (172.29.94.83)
   (9.8.7.217)
   (172.22.255.100) <*>
   (0.0.0.0)
 End of list

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

Now it is again very confusing! It is per-packet load sharing again. Packets go through 172.27.175.1 and 172.27.175.2 in round-robin fashion! What’s wrong with it?
As I already mentioned, nothing strange there. Answer is simple – packet destined to device itself is processed by control plane of the router and control plane packet is process switched on CPU on IOS. If you know this fact you can understand this behavior easily. In (1) packets processed through router are simply managed by data plane, TTL exceeded is sent.  In (2) and (3) packets processed by R1 control plane. That’s all. There is no cisco voodoo magic.

суббота, 26 марта 2011 г.

How to strike self with a TCL or accidently hang up a router.


We all know that IOS supports TCL scripting. Many of us uses it for different purposes. Some of us uses TCL in IVR/Fax applications, but another frequently usage of TCL is the simple scripts to test reachability:

(tcl)#foreach ip {
+>192.168.1.1
+>150.1.3.3
+>155.1.58.5
+>} {
+>ping $ip rep 3 timeout 1
+>}
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 192.168.1.1, timeout is 1 seconds:
...
Success rate is 0 percent (0/3)
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 150.1.3.3, timeout is 1 seconds:
...
Success rate is 0 percent (0/3)
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 155.1.58.5, timeout is 1 seconds:
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 8/13/20 ms

I often use another script "for start test next command" when working with INE workbook volume 1 to test reachability for each loopback address in the network:

(tcl)#for {set i 1} {$i < 11} {incr i} {
ping 150.1.$i.$i rep 3 time 1 }
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 150.1.1.1, timeout is 1 seconds:
...
Success rate is 0 percent (0/3)
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 150.1.2.2, timeout is 1 seconds:
...
Success rate is 0 percent (0/3)
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 150.1.3.3, timeout is 1 seconds:
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 8/108/292 ms

and so on for ten addresses, output omitted.

Note the difference to the following script:

for {set $i 1} {$i < 11} {incr $i} {
+>ping 150.1.$i.$i rep 3 time 1 }

Do you see the difference? There is a dollar sign added to the variable $i in “set” and “incr” statements.
The result will be lamentable:

Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 150.1.1.1, timeout is 1 seconds:
...
Success rate is 0 percent (0/3)
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 150.1.1.1, timeout is 1 seconds:
...
Success rate is 0 percent (0/3)
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 150.1.1.1, timeout is 1 seconds:
...
Success rate is 0 percent (0/3)
Type escape sequence to abort. 

And so on infinitively. You can not even interrupt it with help of ctrl+shift+6 combination. It will stops only one ping command at once. You will be required to reboot your device to stop this. In the real CCIE lab or production network it can be dangerous and very time wasting.

This infinite loop happens because there is two variables really - “i” and “$i” and operations should reference them as “$i” and “$$i”, but $i variable is not defined yet:

(tcl)#for {set $i 1} {$$i < 11} {incr $i} {
+>ping 150.1.$$i.$$i rep 3 time 1 }   
can't read "i": no such variable

This is very easy and basic problem for anybody who was learning non-interpreted programming languages, but with interpreted script languages such as TCL it can be tricky if you is a network engineer with no programming experience although I hope here is no such people already ;)

вторник, 15 февраля 2011 г.

Cisco IOS Petition

Hi, Fiends! Hope you already know that etherealmind.com in be half of Cisco Networking Community is collecting signatures to make internal Cisco emulators like IOU and L2IOU avaible for education purpose. If not so - don't loose opportunity to sign up for this petition here: http://etherealmind.com/cisco-ios-petition-reloaded/

пятница, 11 февраля 2011 г.

How to conditionally replace two trings with sed

Yesterday I spotted trouble while editing my cisco text configs with large bash script.
 Let's assume we have part of configuration like this:
!
interface FastEthernet0/11
description BB1 E0/0
switchport access vlan 100
switchport mode dynamic desirable
!
interface FastEthernet0/12
switchport mode dynamic desirable
!
If you need to replace "switchport mode dynamic desirable" with "switchport mode trunk", you need first delete string  "switchport mode dynamic desirable" if preceding string is "switchport access vlan 100". In other case your configuration will not work appropriately. You can use vim text editor's command:

:%s/\( switchport access vlan 100\)\n switchport mode dynamic desirable/\1/
But I was unable to do something like this via sed or perl.
It was necessary to ask the opennet.ru community. Thanks to user with nickname temny. He provided this solution:


sed '/switchport access vlan/{N;s!\nswitchport mode dynamic desirable!!;}' file

среда, 9 февраля 2011 г.

eachping.tcl

#-----------------------------------------------------------------------------------------------
#    Simple TCL script for Cisco IOS to ping each device in a column of some command output
#    Author: Eugene K.
#
#    invoke with tclsh eachping.tcl "IOS exec command" "column index"
#    please remeber to quote command argument
#-----------------------------------------------------------------------------------------------

set command [lindex $argv 0]
set index [lindex $argv 1]

if { [ catch {
  foreach line_a [split [exec $command] "\n"] {
      if {[ regexp -inline {[0-9/.]+} [lindex $line_a $index] ] != "" } { ping [lindex $line_a $index] }
  } } e]}  {
  puts "Not enougth arguments or command error. $e"
}

вторник, 1 февраля 2011 г.

Cisco to Juniper point-to-multipoint IPsec solution - spoke devices migration

Cisco to Juniper point-to-multipoint IPsec solution - spoke devices migration.


Concept


Example of multivendor point-to-multipoint VPN solution with Junipers SRX as a spokes.

Description


It is common issue in different network environments, for example corporate retailer network where numerous of small remote offices connected using star topology (as known as hub-and-spoke) in the same fashion. Commonly there is Cisco 870, 880, 1800 series routers and ASA 5505 security appliances used in the market. But things changes and sometimes it is required to migrate to other vendors equipment (or add new vendors equipment simultaneously), Juniper’s SRX 100B in our case is a perfect example. Often Cisco’s proprietary technologies like DMVPN or EasyVPN are used for point-to-multipoint topologies implementations. When you move to other vendors it is required to use industry-standard technologies like Site-to-Site IPSEC VPN. But this can lead to huge administrative overheads and nightmare, because you will be required to add a new configuration for every new spoke device added. At this point we can make a Solomonic solution – use Cisco’s proprietary technology on a Hub device that will allow us to configure hub just once (“one-touch” configuration) and standard-based Site-to-Site IPsec VPN on spoke devices which configurations can be cloned and where configuration templates can be used. This Cisco’s proprietary technology is named dynamic crypto map and it will be used in my example. There will be Juniper SRX series device configuration template for policy-based IPsec VPN also shown.

Diagram

 

Example


Our example consists of two parts – Cisco hub configuration and Juniper spoke configuration steps. Pre-shared keys will be used for simplicity, but certificate-based authentication also can be used without any restrictions.  Policy-based VPN will be used for spokes configuration.  We selected following IKE policies – 128 bit AES encryption with SHA hash and DH-group 5 protection.  “secretkey” will be used as pre-shared key for authentication. IPsec configuration is similar to IKE - 128 bit AES encryption with SHA hash in tunnel mode. Our spokes will have /24 subnets (10.139.100.0/24 in my example) each from 10.139.0.0/16 block, it will be defined in crypto ACL on cisco 7206VXR hub. Dynamic crypto map will place it all together. As you can see below, junipers spokes configuration is more straightforward. Obviously, IKE and IPsec policies are the same on a hub and the spokes. 1.2.3.2 is the public IP-address of our hub device, 4.3.2.1 is the public address of out spoke. 10.0.255.255 – is the loopback IP-address on the hub. fe-0/0/0 is the external interface on the spoke.
Cisco HUB configuration steps:
1.      Define IKE policy (isakmp policy) for IPSEC on hub device (phase 1):

crypto isakmp policy 1
 encr aes
 authentication pre-share
 group 5

2.      Define IKE pre-shared key:

crypto isakmp key secretkey address 0.0.0.0 0.0.0.0

3.      Define IPSEC policy (phase 2) – (ipsec transform-set):

crypto ipsec transform-set transport-aes-ipsec esp-aes esp-sha-hmac
 mode tunnel

4.      Define crypto ACL - it will be used for interested traffic definition (traffic to our remote locations):

ip access-list extended INTERESTED_NETS_ACL
 permit ip any 10.139.0.0 0.0.255.255

5.      Optionally define more specific summarized static route via interface where crypto map will be used for remote offices subnets if you are using more specific routes in you network (e.g. you have no default route pointing to outside interface with crypto map configured or you have default route and one or more routes pointing to other locations than interface with crypto map configured). 1.2.3.4 is the ip-address of our gateway:

ip route 10.139.0.0 255.255.0.0 1.2.3.4 name P2MP_PEERS

6.      Configure dynamic crypto map:

crypto dynamic-map dynmap 10
 description *** DYNAMIC MAP ***
 set transform-set tunnel-aes-ipsec
 set pfs group2
match address INTERESTED_NETS_ACL
!
crypto map ipsecvpn 990 ipsec-isakmp dynamic dynmap


7.      Assign crypto map to interface:

interface G0/0
 crypto map ipsecvpn


Juniper spoke configuration steps:
1.      Define IKE proposals:

set security ike proposal IKE_PROPOSAL authentication-method pre-shared-keys
set security ike proposal IKE_PROPOSAL dh-group group5
set security ike proposal IKE_PROPOSAL authentication-algorithm sha1
set security ike proposal IKE_PROPOSAL encryption-algorithm aes-128-cbc
set security ike proposal IKE_PROPOSAL lifetime-seconds 86400

2.      Define IKE policy:

set security ike policy IKE_POLICY mode aggressive
set security ike policy IKE_POLICY proposals IKE_PROPOSAL
set security ike policy IKE_POLICY pre-shared-key ascii-text secretkey

3.      Define IKE gateway:

set security ike gateway IKE_GATEWAY ike-policy IKE_POLICY
set security ike gateway IKE_GATEWAY address 1.2.3.2
set security ike gateway IKE_GATEWAY external-interface fe-0/0/0.0

4.      Define IPSEC proposals:

set security ipsec proposal IPSEC_PROPOSAL protocol esp
set security ipsec proposal IPSEC_PROPOSAL authentication-algorithm hmac-sha1-96
set security ipsec proposal IPSEC_PROPOSAL encryption-algorithm aes-128-cbc
set security ipsec proposal IPSEC_PROPOSAL lifetime-seconds 3600

5.      Define IPSEC policy:

set security ipsec policy IPSEC_POLICY perfect-forward-secrecy keys group2
set security ipsec policy IPSEC_POLICY proposals IPSEC_PROPOSAL

6.      Configure IPsec VPN section, IPSec tunnels will be established immediately either there is no traffic from the spoke:

set security ipsec vpn IPSEC_VPN ike gateway IKE_GATEWAY
set security ipsec vpn IPSEC_VPN ike ipsec-policy IPSEC_POLICY
set security ipsec vpn IPSEC_VPN establish-tunnels immediately

7.      Define security zones,  add address-book entry for local LAN subnet, configure allowed services (don’t forget to allow IKE on the outside interface or zone), assign interfaces to zones:

set security zones security-zone trust address-book address LAN_SUB 10.139.100.0/24
set security zones security-zone trust host-inbound-traffic system-services all
set security zones security-zone trust host-inbound-traffic protocols all
set security zones security-zone trust interfaces vlan.0
set security zones security-zone untrust host-inbound-traffic system-services ike
set security zones security-zone untrust host-inbound-traffic system-services ping
set security zones security-zone untrust interfaces fe-0/0/0.0

8.      Define security policies:

set security policies from-zone trust to-zone untrust policy trust-to-untrust_lan_encrypt match source-address LAN_SUB
set security policies from-zone trust to-zone untrust policy trust-to-untrust_lan_encrypt match destination-address any
set security policies from-zone trust to-zone untrust policy trust-to-untrust_lan_encrypt match application any
set security policies from-zone trust to-zone untrust policy trust-to-untrust_lan_encrypt then permit tunnel ipsec-vpn IPSEC_VPN

Bringing it all together


Here is the security section of our spoke configuration after commit. It was added on top of the default configuration with exception of the nat. It is not required in our case because we don’t use split tunneling (all traffic from the spokes will be directed to the hub). Don’t forget to remove more specific interface-specific host-inbound-services from default configuration for untrust zone member (fe-0/0/0.0). By default it allows only dhcp and tftp services inbound. Also don’t forget to remove default policy for traffic from zone trust to zone untrust. By default it will allow outbound traffic without encryption:

ike {
    proposal IKE_PROPOSAL {
        authentication-method pre-shared-keys;
        dh-group group5;
        authentication-algorithm sha1;
        encryption-algorithm aes-128-cbc;
        lifetime-seconds 86400;
    }
    policy IKE_POLICY {
        mode aggressive;
        proposals IKE_PROPOSAL;
        pre-shared-key ascii-text "$9$qfF/u0IcSeuOhrlK7NaZUjHm69p"; ## SECRET-DATA
    }
    gateway IKE_GATEWAY {
        ike-policy IKE_POLICY;
        address 1.2.3.2;
        external-interface fe-0/0/0.0;
    }
}
ipsec {
    proposal IPSEC_PROPOSAL {
        protocol esp;
        authentication-algorithm hmac-sha1-96;
        encryption-algorithm aes-128-cbc;
        lifetime-seconds 3600;
    }
    policy IPSEC_POLICY {
        perfect-forward-secrecy {
            keys group2;
        }
        proposals IPSEC_PROPOSAL;
    }
    vpn IPSEC_VPN {
        ike {
            gateway IKE_GATEWAY;
            ipsec-policy IPSEC_POLICY;
        }
        establish-tunnels immediately;
    }
}
screen {
    ids-option untrust-screen {
        icmp {
            ping-death;
        }
        ip {                           
            source-route-option;
            tear-drop;
        }
        tcp {
            syn-flood {
                alarm-threshold 1024;
                attack-threshold 200;
                source-threshold 1024;
                destination-threshold 2048;
                timeout 20;
            }
            land;
        }
    }
}
zones {
    security-zone trust {
        address-book {
            address LAN_SUB 10.139.100.0/24;
        }
        host-inbound-traffic {
            system-services {
                all;                   
            }
            protocols {
                all;
            }
        }
        interfaces {
            vlan.0;
        }
    }
    security-zone untrust {
        screen untrust-screen;
        host-inbound-traffic {
            system-services {
                ike;
                ping;
            }
        }
        interfaces {
            fe-0/0/0.0 {
            }
        }
    }
}
policies {
        from-zone trust to-zone untrust {
            policy trust-to-untrust_lan_encrypt {
                match {
                    source-address LAN_SUB;
                    destination-address any;
                    application any;
                }
                then {
                    permit {
                        tunnel {
                            ipsec-vpn IPSEC_VPN;
                        }
                    }
                }
            }
        }                              
        from-zone untrust to-zone trust {
            policy untrust-to-trust_lan_encrypt {
                match {
                    source-address any;
                    destination-address LAN_SUB;
                    application any;
                }
                then {
                    permit {
                        tunnel {
                            ipsec-vpn IPSEC_VPN;
                        }
                    }
                }
            }
        }
    }
}

Verification and troubleshooting


On spoke we will be able to notice established IPsec phases 1 and 2 (bidirectional IKE tunnel for session key exchange and two unidirectional IPsec tunnel s for data transfer).
Let’s check IKE SA:

admin@spoke> show security ike security-associations
Index   Remote Address  State  Initiator cookie  Responder cookie  Mode
7       1.2.3.2   UP     40572f77e286c8d3  7be75aaee7105bfc  Aggressive  

Here we will check IPSec SAs:

admin@spoke > show security ipsec security-associations
  Total active tunnels: 1
  ID    Gateway          Port  Algorithm       SPI      Life:sec/kb  Mon vsys
  <2    1.2.3.2    4500  ESP:aes-128/sha1 c8b96ce9 3555/  838855 -  root
  >2    1.2.3.2    4500  ESP:aes-128/sha1 9cf1a4ee 3555/  838855 -  root

Let’s check IKE SA on the hub:

C7206#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
1.2.3.2   4.3.2.1    QM_IDLE          13372 ACTIVE

Now let’s check IPsec SAs on the hub:

c7206#show crypto ipsec sa peer 4.3.2.1

interface: GigabitEthernet0/0
    Crypto map tag: ipsecvpn, local addr 1.2.3.2

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (10.139.100.0/255.255.255.0/0/0)
   current_peer 4.3.2.1 port 500
     PERMIT, flags={}
    #pkts encaps: 853682, #pkts encrypt: 853682, #pkts digest: 853682
    #pkts decaps: 779630, #pkts decrypt: 779630, #pkts verify: 779630
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 1.2.3.2, remote crypto endpt.: 4.3.2.1
     path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0
     current outbound spi: 0x228C99F4(579639796)
     PFS (Y/N): Y, DH group: group2

     inbound esp sas:
      spi: 0x4A51CAC9(1246874313)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 6607, flow_id: VAM2+:4607, sibling_flags 80000046, crypto map: ipsecvpn
        sa timing: remaining key lifetime (k/sec): (4400144/2947)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x228C99F4(579639796)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 6608, flow_id: VAM2+:4608, sibling_flags 80000046, crypto map: ipsecvpn
        sa timing: remaining key lifetime (k/sec): (4399675/2947)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:

Ping from the hub’s loopback IP address toward the spoke will be successful now:

ping 10.139.100.1 source loopback0 repeat 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 10.139.100.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.255.255
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 4/7/20 ms

Conclusion


In this document we have covered one of the approaches used during migration to multivendor hub-n-spoke IPsec topology.  It was shown that it is possible to implement such configuration in clear fashion and support it easily because of the ability to use standard template for spokes configuration and “one-touch” hub configuration.

суббота, 22 января 2011 г.

EasyVPN hardware client & loopback addresses

Hi! Yesterday I was testing EasyVPN implementation in my tested and have noticed interesting behavior of reverse route injection feature (RRI) in conjunction with network extension mode (NEM) of operation. EasyVPN server on ASA with 8.2(3) OS can't inject routes for client loopback addressed, if address is configured on client with /32 bit mask. Any shorter mask makes thing works well. It was tested on Cisco IOS 12.4-24.T4 and 15.0-1.M4 on 881 and 877 models.
Another interesting result was received while testing NEM+. Although it is not supported on ASA, client can obtain address and it will be installed in routing table, but any other routes will not (although it is appears in SAs as proxy-identities).
So finally I should notice that DMVPN is removed from ASA OS 9.0 roadmap. Maybe we will wait until 10 branch ;)

Постоянные читатели

Архив блога

Поиск по этому блогу