Here is an example of a working configuration on version 8.4 to manage (via ssh and http or ASDM) a Cisco ASA over a VPN client.
interface GigabitEthernet0/0
nameif untrust
security-level 0
ip address 1.1.5.7 255.255.255.0
!
interface GigabitEthernet0/1
nameif trust
security-level 100
ip address 10.99.18.240 255.255.255.224
ip local pool vpnpool 10.99.81.1-10.99.81.254 mask 255.255.255.0
management-access trust
nat (trust,untrust) source static 10.99.0.0 10.99.0.0 destination static 10.99.81.0 10.99.81.0 route-lookup
ssh 10.99.81.0 255.255.255.0 trust
http 10.99.81.0 255.255.255.0 trust
This allows you to hit the trust interface with ASDM or ssh after you VPN into the Cisco ASA. Note that the 'route-lookup' switch under the nat (exempt) rule is often overlooked!
_k
Saturday, August 11, 2012
Monday, March 19, 2012
Multi-Homed ISP using BGP - One Primary, the Other Backup
If you are using two different ISPs and want to make one the primary (all traffic goes here for inbound and outbound) and the other a backup, the simplest way to achieve this is to use the 'advertise-map' feature in BGP. Remember that you cannot control which ISP the inbound traffic will pick when destined for your IP block when you have 2 ISPs. You will need to prevent the advertisement of your block to the backup ISP until the primary one goes down.
This is what we recently did to get this going at a client. We got tripped up initially with the route and I explain that below.
Our topology is simple. Routers WR1 (primary) and WR2 (backup) each are connected to ISP1 (primary) and ISP2 (backup) respectively with BGP enabled. They are cross connected to each other for the iBGP session on the 172.16.25.0/24 network. Our goal is to have WR2 advertise our IP block n.x.47.0/24 into ISP2 whenever ISP1 fails.
Steps
1. On WR1, advertise a route learned from ISP1 to WR2 (prefix list ROUTES-TO-WR2). Pick the route from the routing table. We were receiving partial routes from ISP1 so this was easy. You could also use the default route in this method even if both ISPs advertise the default route. We picked 99.0.0.0/12.
router bgp
neighbor 172.16.25.2 prefix-list ROUTES-TO-WR2 out
ip prefix-list ROUTES-TO-WR2 seq 10 permit 99.0.0.0/12
2. On WR2, use the advertise-map and non-exist-map to look for this route in the route table. Turns out it also looks in the BGP Table too! Our router map 'NON-EXIST' looks for two conditions - the route 99.0.0.0/12 AND that it was advertised from AT&T (AS=7018). Note that you must look for 7018 as the first AS number in the AS path which has an expression ^7018_
router bgp
neighbor y.z.32.133 advertise-map ADVERTISE non-exist-map NON-EXIST
access-list 47 permit n.x.47.0 0.0.0.255
ip as-path access-list 3 permit ^7018_
route-map NON-EXIST permit 10
match ip address prefix-list ATT-Route
match as-path 3
route-map ADVERTISE permit 10
match ip address 47
3. Here is the condition when ISP1 is working normally
WR1#sh ip bgp nei
BGP neighbor is y.z.32.133, remote AS 14265, external link
Description: TelePacific
Route map for outgoing advertisements is outgoing
Condition-map NON-EXIST, Advertise-map ADVERTISE, status: Withdraw
4. ISP1 goes down, so we lose the route 99.0.0.0/12 (as well as all other routes being advertised by ISP1)
WR1#sh ip bgp nei
BGP neighbor is y.z.32.133, remote AS 14265, external link
Description: TelePacific
Route map for outgoing advertisements is outgoing
Condition-map NON-EXIST, Advertise-map ADVERTISE, status: Advertise
5. Prior to us adding the 'match as-path 3' in the route map NON EXIST, the status would not change to Advertise. We found that WR2 had the route 99.0.0.0/12 in its BGP table even though it got removed from the routing table after ISP1 went down!
WR2#sh ip bgp 99.0.0.0/12
BGP routing table entry for 99.0.0.0/12, version 20658895
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
14265 3549 7018, (received-only)
y.z.32.133 from y.z.32.133 (y.z.224.176)
Origin IGP, localpref 100, valid, external
Community: 934871440
After adding 'match as-path 3' it worked! As you can tell from below that it receives the route with the first (and only) AS # as 7018 from it's iBGP neighbor 172.16.25.1 whereas from y.z.32.133 it has a string of AS#s 14265 3549 7018.
WR2#sh ip bgp 99.0.0.0/12
BGP routing table entry for 99.0.0.0/12, version 20658895
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
7018, (received & used)
172.16.25.1 from 172.16.25.1 (172.16.25.1)
Origin IGP, metric 0, localpref 150, valid, internal, best
14265 3549 7018, (received-only)
y.z.32.133 from y.z.32.133 (y.z.224.176)
Origin IGP, localpref 100, valid, external
Community: 934871440
Configs
WR1
router bgp
no synchronization
no bgp fast-external-fallover
bgp log-neighbor-changes
bgp bestpath as-path ignore
network n.x.47.0 mask 255.255.255.0
neighbor n.m.117.249 remote-as 7018
neighbor n.m.117.249 description AT&T Ethernet Peer
neighbor n.m.117.249 version 4
neighbor n.m.117.249 soft-reconfiguration inbound
neighbor n.m.117.249 route-map incoming in
neighbor n.m.117.249 route-map outgoing out
neighbor 172.16.25.2 remote-as
neighbor 172.16.25.2 description iBGP peer connection to WR2
neighbor 172.16.25.2 update-source Loopback0
neighbor 172.16.25.2 version 4
neighbor 172.16.25.2 next-hop-self
neighbor 172.16.25.2 soft-reconfiguration inbound
neighbor 172.16.25.2 prefix-list ROUTES-TO-WR2 out
no auto-summary
!
WR2
router bgp
no synchronization
no bgp fast-external-fallover
bgp log-neighbor-changes
bgp bestpath as-path ignore
network n.x.47.0 mask 255.255.255.0
neighbor y.z.32.133 remote-as 14265
neighbor y.z.32.133 description TelePacific
neighbor y.z.32.133 version 4
neighbor y.z.32.133 soft-reconfiguration inbound
neighbor y.z.32.133 route-map incoming in
neighbor y.z.32.133 route-map outgoing out
neighbor y.z.32.133 advertise-map ADVERTISE non-exist-map NON-EXIST
neighbor 172.16.25.1 remote-as
neighbor 172.16.25.1 description iBGP peer connection to WR1
neighbor 172.16.25.1 update-source Loopback0
neighbor 172.16.25.1 version 4
neighbor 172.16.25.1 next-hop-self
neighbor 172.16.25.1 soft-reconfiguration inbound
neighbor 172.16.25.1 prefix-list DEF-ROUTE out
no auto-summary
access-list 47 permit n.x.47.0 0.0.0.255
ip as-path access-list 3 permit ^7018_
route-map NON-EXIST permit 10
match ip address prefix-list ATT-Route
match as-path 3
route-map ADVERTISE permit 10
match ip address 47
This is what we recently did to get this going at a client. We got tripped up initially with the route and I explain that below.
Our topology is simple. Routers WR1 (primary) and WR2 (backup) each are connected to ISP1 (primary) and ISP2 (backup) respectively with BGP enabled. They are cross connected to each other for the iBGP session on the 172.16.25.0/24 network. Our goal is to have WR2 advertise our IP block n.x.47.0/24 into ISP2 whenever ISP1 fails.
Steps
1. On WR1, advertise a route learned from ISP1 to WR2 (prefix list ROUTES-TO-WR2). Pick the route from the routing table. We were receiving partial routes from ISP1 so this was easy. You could also use the default route in this method even if both ISPs advertise the default route. We picked 99.0.0.0/12.
router bgp
neighbor 172.16.25.2 prefix-list ROUTES-TO-WR2 out
ip prefix-list ROUTES-TO-WR2 seq 10 permit 99.0.0.0/12
2. On WR2, use the advertise-map and non-exist-map to look for this route in the route table. Turns out it also looks in the BGP Table too! Our router map 'NON-EXIST' looks for two conditions - the route 99.0.0.0/12 AND that it was advertised from AT&T (AS=7018). Note that you must look for 7018 as the first AS number in the AS path which has an expression ^7018_
router bgp
neighbor y.z.32.133 advertise-map ADVERTISE non-exist-map NON-EXIST
access-list 47 permit n.x.47.0 0.0.0.255
ip as-path access-list 3 permit ^7018_
route-map NON-EXIST permit 10
match ip address prefix-list ATT-Route
match as-path 3
route-map ADVERTISE permit 10
match ip address 47
3. Here is the condition when ISP1 is working normally
WR1#sh ip bgp nei
BGP neighbor is y.z.32.133, remote AS 14265, external link
Description: TelePacific
Route map for outgoing advertisements is outgoing
Condition-map NON-EXIST, Advertise-map ADVERTISE, status: Withdraw
4. ISP1 goes down, so we lose the route 99.0.0.0/12 (as well as all other routes being advertised by ISP1)
WR1#sh ip bgp nei
BGP neighbor is y.z.32.133, remote AS 14265, external link
Description: TelePacific
Route map for outgoing advertisements is outgoing
Condition-map NON-EXIST, Advertise-map ADVERTISE, status: Advertise
5. Prior to us adding the 'match as-path 3' in the route map NON EXIST, the status would not change to Advertise. We found that WR2 had the route 99.0.0.0/12 in its BGP table even though it got removed from the routing table after ISP1 went down!
WR2#sh ip bgp 99.0.0.0/12
BGP routing table entry for 99.0.0.0/12, version 20658895
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
14265 3549 7018, (received-only)
y.z.32.133 from y.z.32.133 (y.z.224.176)
Origin IGP, localpref 100, valid, external
Community: 934871440
After adding 'match as-path 3' it worked! As you can tell from below that it receives the route with the first (and only) AS # as 7018 from it's iBGP neighbor 172.16.25.1 whereas from y.z.32.133 it has a string of AS#s 14265 3549 7018.
WR2#sh ip bgp 99.0.0.0/12
BGP routing table entry for 99.0.0.0/12, version 20658895
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
7018, (received & used)
172.16.25.1 from 172.16.25.1 (172.16.25.1)
Origin IGP, metric 0, localpref 150, valid, internal, best
14265 3549 7018, (received-only)
y.z.32.133 from y.z.32.133 (y.z.224.176)
Origin IGP, localpref 100, valid, external
Community: 934871440
Configs
WR1
router bgp
no synchronization
no bgp fast-external-fallover
bgp log-neighbor-changes
bgp bestpath as-path ignore
network n.x.47.0 mask 255.255.255.0
neighbor n.m.117.249 remote-as 7018
neighbor n.m.117.249 description AT&T Ethernet Peer
neighbor n.m.117.249 version 4
neighbor n.m.117.249 soft-reconfiguration inbound
neighbor n.m.117.249 route-map incoming in
neighbor n.m.117.249 route-map outgoing out
neighbor 172.16.25.2 remote-as
neighbor 172.16.25.2 description iBGP peer connection to WR2
neighbor 172.16.25.2 update-source Loopback0
neighbor 172.16.25.2 version 4
neighbor 172.16.25.2 next-hop-self
neighbor 172.16.25.2 soft-reconfiguration inbound
neighbor 172.16.25.2 prefix-list ROUTES-TO-WR2 out
no auto-summary
!
ip prefix-list ROUTES-TO-WR2 seq 10 permit 99.0.0.0/12
WR2
router bgp
no synchronization
no bgp fast-external-fallover
bgp log-neighbor-changes
bgp bestpath as-path ignore
network n.x.47.0 mask 255.255.255.0
neighbor y.z.32.133 remote-as 14265
neighbor y.z.32.133 description TelePacific
neighbor y.z.32.133 version 4
neighbor y.z.32.133 soft-reconfiguration inbound
neighbor y.z.32.133 route-map incoming in
neighbor y.z.32.133 route-map outgoing out
neighbor y.z.32.133 advertise-map ADVERTISE non-exist-map NON-EXIST
neighbor 172.16.25.1 remote-as
neighbor 172.16.25.1 description iBGP peer connection to WR1
neighbor 172.16.25.1 update-source Loopback0
neighbor 172.16.25.1 version 4
neighbor 172.16.25.1 next-hop-self
neighbor 172.16.25.1 soft-reconfiguration inbound
neighbor 172.16.25.1 prefix-list DEF-ROUTE out
no auto-summary
access-list 47 permit n.x.47.0 0.0.0.255
ip as-path access-list 3 permit ^7018_
route-map NON-EXIST permit 10
match ip address prefix-list ATT-Route
match as-path 3
route-map ADVERTISE permit 10
match ip address 47
Wednesday, January 18, 2012
SSL Wildcard Certificate Installation on Cisco ASA 8.x
After searching high and low for instructions, I finally found this link that was most useful:
http://serverfault.com/questions/32443/any-problems-usinga-godaddy-ssl-certificate-on-a-cisco-asa-firewall
Here is the solution taken from the link above:
I have a GoDaddy (standard, not deluxe) wildcard certificate that I use on my ASA 5510 for ASDM access. ASDM says that "SSL parameters affect both ASDM and SSL VPN access," so if it works for me, it should for you and SSL VPNs.
http://serverfault.com/questions/32443/any-problems-usinga-godaddy-ssl-certificate-on-a-cisco-asa-firewall
Here is the solution taken from the link above:
I have a GoDaddy (standard, not deluxe) wildcard certificate that I use on my ASA 5510 for ASDM access. ASDM says that "SSL parameters affect both ASDM and SSL VPN access," so if it works for me, it should for you and SSL VPNs.
I did have problems importing a .pem version of my certificate chain. Using a *.pfx (like IIS uses) worked fine.
I grabbed gd_intermediate.crt from https://certs.godaddy.com/Repository.go
In ASDM, Configuration, Device Management, Certificate Management, CA Certificates; click Add, don't change any defaults, install from file, locate the gd_intermediate.crt file.
I also tried loading gd_bundle.crt which some of our certs use and that failed, but since gd_intermediate.crt worked and that's what my wildcard uses, I didn't test any more.
Once the intermediate cert is loaded, go to Identity Certificates (right above CA Certificates) and do something similar (Add, import from file, chose the .pfx file, and enter the password for the .pfx.
Now that the cert is successfully installed, set which interfaces it will be used on. That's under Device Management, Advanced, SSL Settings. Click the interface (probably outside), click Edit, and choose the Trustpoint name of the certificate you added in the last step. Click OK, Apply, and try going to your https://vpn.url and see if it loads the right cert.
Thanks to serverfault.com.
Friday, January 13, 2012
Upgrade Procedure - Cisco Nexus 5000 Switch
I did this on a Nexus 5548. The process was simple - no quirky issues. Our upgrade went from 9.5.0.3 to 9.5.1.3. I had alread established IP connectivity through the management port.
Remember that the management interface is belongs to the vrf context called "management", by default.
vrf context management
ip route 0.0.0.0/0 10.0.3.251
interface mgmt0
ip address 10.0.1.225/22
Download the relevant files. I downloaded these two:
n5000-uk9-kickstart.5.1.3.N1.1.bin
n5000-uk9.5.1.3.N1.1.bin
Fire up your tftp server. Verify that you have enough space on your bootflash: to hold the new files:
login: admin
Password:
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2011, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained in this software are
owned by other third parties and used and distributed under
license. Certain components of this software are licensed under
the GNU General Public License (GPL) version 2.0 or the GNU
Lesser General Public License (LGPL) Version 2.1. A copy of each
such license is available at
http://www.opensource.org/licenses/gpl-2.0.php and
http://www.opensource.org/licenses/lgpl-2.1.php
Nexus5548-2# dir
744 Apr 20 02:08:48 2011 license_SSI15100AW7_10.lic
49152 Apr 20 02:11:45 2011 lost+found/
1586 Nov 10 11:47:20 2011 mts.log
25136128 Apr 20 02:01:51 2011 n5000-uk9-kickstart.5.0.3.N1.1b.bin
188700150 Apr 20 02:02:52 2011 n5000-uk9.5.0.3.N1.1b.bin
4096 Jan 01 02:05:55 2009 vdc_2/
4096 Jan 01 02:05:55 2009 vdc_3/
4096 Jan 01 02:05:55 2009 vdc_4/
Usage for bootflash://
331591680 bytes used
1319313408 bytes free
1650905088 bytes total
I had plenty of space. Now tftp the kickstart and image files into the bootflash. Use management as the vrf context!
Nexus5548-2# copy tftp://10.0.1.227/n5000-uk9-kickstart.5.1.3.N1.1.bin bootflash:n5000-uk9-kickstart.5.1.3.N1.1.bin
Enter vrf (If no input, current vrf 'default' is considered): management
Trying to connect to tftp server......
Connection to Server Established.
TFTP get operation was successful
Nexus5548-2# copy tftp://10.0.1.227/n5000-uk9.5.1.3.N1.1.bin bootflash:n5000-uk9.5.1.3.N1.1.bin
Enter vrf (If no input, current vrf 'default' is considered): management
Trying to connect to tftp server......
Connection to Server Established.
TFTP get operation was successful
Run the install command on the kickstart file.
Nexus5548-2# install all kickstart bootflash:n5000-uk9-kickstart.5.1.3.N1.1.bin system bootflash:n5000-uk9.5.1.3.N1.1.bin
Verifying image bootflash:/n5000-uk9-kickstart.5.1.3.N1.1.bin for boot variable "kickstart".
[####################] 100% -- SUCCESS
Verifying image bootflash:/n5000-uk9.5.1.3.N1.1.bin for boot variable "system".
[####################] 100% -- SUCCESS
Verifying image type.
[####################] 100% -- SUCCESS
Extracting "system" version from image bootflash:/n5000-uk9.5.1.3.N1.1.bin.
[####################] 100% -- SUCCESS
Extracting "kickstart" version from image bootflash:/n5000-uk9-kickstart.5.1.3.N1.1.bin.
[####################] 100% -- SUCCESS
Extracting "bios" version from image bootflash:/n5000-uk9.5.1.3.N1.1.bin.
[####################] 100% -- SUCCESS
Performing module support checks.
[####################] 100% -- SUCCESS
Notifying services about system upgrade.
[####################] 100% -- SUCCESS
Compatibility check is done:
Module bootable Impact Install-type Reason
------ -------- -------------- ------------ ------
1 yes disruptive reset Non-disruptive install not supported if L3 was enabled
Images will be upgraded according to following table:
Module Image Running-Version New-Version Upg-Required
------ ---------- ---------------------- ---------------------- ------------
1 system 5.0(3)N1(1b) 5.1(3)N1(1) yes
1 kickstart 5.0(3)N1(1b) 5.1(3)N1(1) yes
1 bios v3.5.0(02/03/2011) v3.5.0(02/03/2011) no
1 SFP-uC v1.0.0.0 v1.0.0.0 no
1 power-seq v1.0 v1.0 no
3 power-seq v5.0 v5.0 no
1 uC v1.2.0.1 v1.2.0.1 no
Switch will be reloaded for disruptive upgrade.
Do you want to continue with the installation (y/n)? [n] y
Install is in progress, please wait.
Performing runtime checks.
[####################] 100% -- SUCCESS
Setting boot variables.
[####################] 100% -- SUCCESS
Performing configuration copy.
[####################] 100%
The switch will reboot. Login again to verify that the you are on the new version.
Nexus 5000 Switch
login: admin
Password:
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2011, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained in this software are
owned by other third parties and used and distributed under
license. Certain components of this software are licensed under
the GNU General Public License (GPL) version 2.0 or the GNU
Lesser General Public License (LGPL) Version 2.1. A copy of each
such license is available at
http://www.opensource.org/licenses/gpl-2.0.php and
http://www.opensource.org/licenses/lgpl-2.1.php
Nexus5548-2# sh ver
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Documents: http://www.cisco.com/en/US/products/ps9372/tsd_products_support_serie
s_home.html
Copyright (c) 2002-2011, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained herein are owned by
other third parties and are used and distributed under license.
Some parts of this software are covered under the GNU Public
License. A copy of the license is available at
http://www.gnu.org/licenses/gpl.html.
Software
BIOS: version 3.5.0
loader: version N/A
kickstart: version 5.1(3)N1(1)
system: version 5.1(3)N1(1)
power-seq: Module 1: version v1.0
uC: version v1.2.0.1
SFP uC: Module 1: v1.0.0.0
BIOS compile time: 02/03/2011
kickstart image file is: bootflash:///n5000-uk9-kickstart.5.1.3.N1.1.bin
kickstart compile time: 12/6/2011 22:00:00 [12/07/2011 06:30:01]
system image file is: bootflash:///n5000-uk9.5.1.3.N1.1.bin
system compile time: 12/6/2011 22:00:00 [12/07/2011 08:09:44]
Hardware
cisco Nexus5548 Chassis ("O2 32X10GE/Modular Universal Platform Supervisor")
Intel(R) Xeon(R) CPU with 8263872 kB of memory.
Processor Board ID JAF1515BBRA
Device name: Nexus5548-2
bootflash: 2007040 kB
Kernel uptime is 0 day(s), 0 hour(s), 3 minute(s), 13 second(s)
Last reset at 720106 usecs after Thu Dec 15 20:15:10 2011
Reason: Disruptive upgrade
System version: 5.0(3)N1(1b)
Service:
plugin
Core Plugin, Ethernet Plugin
Nexus5548-2#
Remember that the management interface is belongs to the vrf context called "management", by default.
vrf context management
ip route 0.0.0.0/0 10.0.3.251
interface mgmt0
ip address 10.0.1.225/22
Download the relevant files. I downloaded these two:
n5000-uk9-kickstart.5.1.3.N1.1.bin
n5000-uk9.5.1.3.N1.1.bin
Fire up your tftp server. Verify that you have enough space on your bootflash: to hold the new files:
login: admin
Password:
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2011, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained in this software are
owned by other third parties and used and distributed under
license. Certain components of this software are licensed under
the GNU General Public License (GPL) version 2.0 or the GNU
Lesser General Public License (LGPL) Version 2.1. A copy of each
such license is available at
http://www.opensource.org/licenses/gpl-2.0.php and
http://www.opensource.org/licenses/lgpl-2.1.php
Nexus5548-2# dir
744 Apr 20 02:08:48 2011 license_SSI15100AW7_10.lic
49152 Apr 20 02:11:45 2011 lost+found/
1586 Nov 10 11:47:20 2011 mts.log
25136128 Apr 20 02:01:51 2011 n5000-uk9-kickstart.5.0.3.N1.1b.bin
188700150 Apr 20 02:02:52 2011 n5000-uk9.5.0.3.N1.1b.bin
4096 Jan 01 02:05:55 2009 vdc_2/
4096 Jan 01 02:05:55 2009 vdc_3/
4096 Jan 01 02:05:55 2009 vdc_4/
Usage for bootflash://
331591680 bytes used
1319313408 bytes free
1650905088 bytes total
I had plenty of space. Now tftp the kickstart and image files into the bootflash. Use management as the vrf context!
Nexus5548-2# copy tftp://10.0.1.227/n5000-uk9-kickstart.5.1.3.N1.1.bin bootflash:n5000-uk9-kickstart.5.1.3.N1.1.bin
Enter vrf (If no input, current vrf 'default' is considered): management
Trying to connect to tftp server......
Connection to Server Established.
TFTP get operation was successful
Nexus5548-2# copy tftp://10.0.1.227/n5000-uk9.5.1.3.N1.1.bin bootflash:n5000-uk9.5.1.3.N1.1.bin
Enter vrf (If no input, current vrf 'default' is considered): management
Trying to connect to tftp server......
Connection to Server Established.
TFTP get operation was successful
Run the install command on the kickstart file.
Nexus5548-2# install all kickstart bootflash:n5000-uk9-kickstart.5.1.3.N1.1.bin system bootflash:n5000-uk9.5.1.3.N1.1.bin
Verifying image bootflash:/n5000-uk9-kickstart.5.1.3.N1.1.bin for boot variable "kickstart".
[####################] 100% -- SUCCESS
Verifying image bootflash:/n5000-uk9.5.1.3.N1.1.bin for boot variable "system".
[####################] 100% -- SUCCESS
Verifying image type.
[####################] 100% -- SUCCESS
Extracting "system" version from image bootflash:/n5000-uk9.5.1.3.N1.1.bin.
[####################] 100% -- SUCCESS
Extracting "kickstart" version from image bootflash:/n5000-uk9-kickstart.5.1.3.N1.1.bin.
[####################] 100% -- SUCCESS
Extracting "bios" version from image bootflash:/n5000-uk9.5.1.3.N1.1.bin.
[####################] 100% -- SUCCESS
Performing module support checks.
[####################] 100% -- SUCCESS
Notifying services about system upgrade.
[####################] 100% -- SUCCESS
Compatibility check is done:
Module bootable Impact Install-type Reason
------ -------- -------------- ------------ ------
1 yes disruptive reset Non-disruptive install not supported if L3 was enabled
Images will be upgraded according to following table:
Module Image Running-Version New-Version Upg-Required
------ ---------- ---------------------- ---------------------- ------------
1 system 5.0(3)N1(1b) 5.1(3)N1(1) yes
1 kickstart 5.0(3)N1(1b) 5.1(3)N1(1) yes
1 bios v3.5.0(02/03/2011) v3.5.0(02/03/2011) no
1 SFP-uC v1.0.0.0 v1.0.0.0 no
1 power-seq v1.0 v1.0 no
3 power-seq v5.0 v5.0 no
1 uC v1.2.0.1 v1.2.0.1 no
Switch will be reloaded for disruptive upgrade.
Do you want to continue with the installation (y/n)? [n] y
Install is in progress, please wait.
Performing runtime checks.
[####################] 100% -- SUCCESS
Setting boot variables.
[####################] 100% -- SUCCESS
Performing configuration copy.
[####################] 100%
The switch will reboot. Login again to verify that the you are on the new version.
Nexus 5000 Switch
login: admin
Password:
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2011, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained in this software are
owned by other third parties and used and distributed under
license. Certain components of this software are licensed under
the GNU General Public License (GPL) version 2.0 or the GNU
Lesser General Public License (LGPL) Version 2.1. A copy of each
such license is available at
http://www.opensource.org/licenses/gpl-2.0.php and
http://www.opensource.org/licenses/lgpl-2.1.php
Nexus5548-2# sh ver
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Documents: http://www.cisco.com/en/US/products/ps9372/tsd_products_support_serie
s_home.html
Copyright (c) 2002-2011, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained herein are owned by
other third parties and are used and distributed under license.
Some parts of this software are covered under the GNU Public
License. A copy of the license is available at
http://www.gnu.org/licenses/gpl.html.
Software
BIOS: version 3.5.0
loader: version N/A
kickstart: version 5.1(3)N1(1)
system: version 5.1(3)N1(1)
power-seq: Module 1: version v1.0
uC: version v1.2.0.1
SFP uC: Module 1: v1.0.0.0
BIOS compile time: 02/03/2011
kickstart image file is: bootflash:///n5000-uk9-kickstart.5.1.3.N1.1.bin
kickstart compile time: 12/6/2011 22:00:00 [12/07/2011 06:30:01]
system image file is: bootflash:///n5000-uk9.5.1.3.N1.1.bin
system compile time: 12/6/2011 22:00:00 [12/07/2011 08:09:44]
Hardware
cisco Nexus5548 Chassis ("O2 32X10GE/Modular Universal Platform Supervisor")
Intel(R) Xeon(R) CPU with 8263872 kB of memory.
Processor Board ID JAF1515BBRA
Device name: Nexus5548-2
bootflash: 2007040 kB
Kernel uptime is 0 day(s), 0 hour(s), 3 minute(s), 13 second(s)
Last reset at 720106 usecs after Thu Dec 15 20:15:10 2011
Reason: Disruptive upgrade
System version: 5.0(3)N1(1b)
Service:
plugin
Core Plugin, Ethernet Plugin
Nexus5548-2#
That's it!
Friday, April 15, 2011
WOL Directed Broadcast Configuration on Cisco Layer 3 Switches
Use directed broadcast to configure the Wake On LAN (WOL) application on Cisco L3 switches. In our case we had the WOL servers connected to VLAN 1 (10.1.20.64 and .65). They are used to wake client computers on all other private VLANs. Here's the working example for our test case with clients on VLAN2:
access-list 180 permit udp host 10.1.20.64 any
access-list 180 permit udp host 10.1.20.65 any
interface Vlan1
ip address 10.1.0.10 255.255.0.0
ip helper-address 10.2.255.255
!
interface Vlan2
ip address 10.2.0.10 255.255.0.0
ip directed-broadcast 180
Note that the helper address sends the WOL broadcast to all destination subnets that are specified there (in our case to the 10.2.0.0/16 subnet) but you control what lands up on the destination VLAN with the directed broadcast command and an acl. It works if you use a supernet in the helper address command to cover all your destination networks.
Wednesday, April 13, 2011
Cisco ASA 5500 7.2x to 8.4x upgrade
I just completed this upgrade on two firewalls and want to share some issues I encountered. Our firewalls were using the following basic features:
- IPSEC VPN client
- Site to Site IPSEC VPN tunnel
- PAT
- Static NATs
- NAT exempt
- The known documented issue with the nat exempt command must be taken care of. The keyword unidirectional is added to the nat exempt (nat 0) rule which must be changed to bidirectional for each nat exempt command you have.
- Since the new access rules now references the real IPs of translated addresses I found that none of these got changed on my outside access list! I had to change each ACL entry manually from the public address to its private IP address.
- There is a site to site IPSEC VPN tunnel built that references a translated IP of a local host in the encryption domain. The conversion process added a nat exempt rule for the encryption domain! This, of course, prevented the local host from being translated when it was trying to connect to the remote host across the tunnel. No match was found and so the tunnel never gets established! I removed that nat exempt rule to fix.
That's it! All the best in your upgrades.
Here is the Cisco reference to the 8.4x release notes.
Monday, April 4, 2011
IOS NAT and VPN
Building NAT (PAT or Static) on a Cisco router is fairly well documented and works well. However, I got tripped up again with an implementation today where the PAT would work but then the VPN tunnel would go down!
Case Study
My client has a site to site VPN tunnel to Cust2 with 6 remote networks. All local networks (192.168.0.0/21) communicate to the remote nets with their private IPs. In addition, the local networks get PAT'd to 39.100.3.68 when routed over to the Internet. There is one static NAT that only gets translated to 39.100.3.67 when communicating with 206.96.88.115 out on the Internet. In all other cases it will remain as it's real IP of 192.168.0.76.
Here is the configuration that I built. The VPN tunnel and static NAT rule using a route map to achieve our goal worked. However, as soon as I applied the PAT pool and overload translation, the tunnel went down.
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
!
crypto isakmp policy 20
encr aes
authentication pre-share
group 2
crypto isakmp key *** address 209.100.166.20
!
!
crypto ipsec transform-set 3DES-SHA esp-3des esp-sha-hmac
!
crypto map vpnmap 10 ipsec-isakmp
set peer 209.100.166.20
set transform-set 3DES-SHA
match address cust2-vpn
interface GigabitEthernet0/0
description to Inside
ip address 192.168.0.8 255.255.255.0
ip nat inside
!
interface GigabitEthernet0/1
description Internet
ip address 39.105.128.242 255.255.255.252
ip nat outside
crypto map vpnmap
!
ip nat pool natpool 39.100.3.68 39.100.3.68 netmask 255.255.255.0
ip nat inside source list ins_nat_source pool natpool overload
ip nat inside source static 192.168.0.76 39.100.3.67 route-map nat-exempt extendable
!
ip access-list extended cust2-vpn
permit ip 192.168.0.0 0.0.7.255 192.168.16.0 0.0.0.255
permit ip 192.168.0.0 0.0.7.255 70.185.0.0 0.0.255.255
permit ip 192.168.0.0 0.0.7.255 200.106.176.0 0.0.7.255
permit ip 192.168.0.0 0.0.7.255 200.106.184.0 0.0.1.255
permit ip 192.168.0.0 0.0.7.255 206.184.246.0 0.0.0.255
permit ip 192.168.0.0 0.0.7.255 208.134.161.0 0.0.0.255
ip access-list extended ins_nat_source
deny ip any 192.168.16.0 0.0.0.255
deny ip any 70.185.0.0 0.0.255.255
deny ip any 200.106.176.0 0.0.7.255
deny ip any 200.106.184.0 0.0.1.255
deny ip any 206.184.246.0 0.0.0.255
deny ip any 208.134.161.0 0.0.0.255
permit ip any any
access-list 110 permit ip host 192.168.0.76 host 206.96.88.115
access-list 110 deny ip host 192.168.0.76 any
!
!
!
route-map nat-exempt permit 1
match ip address 110
!
The fix is to also include the Internet facing interface into the NAT exempt access rules (ins_nat_source). Even though that interface is on the 'outside', it will get subjected to translation because of the 'permit any any' rule. Here's the fixed access rule:
ip access-list extended ins_nat_source
deny ip any 192.168.16.0 0.0.0.255
deny ip any 70.185.0.0 0.0.255.255
deny ip any 200.106.176.0 0.0.7.255
deny ip any 200.106.184.0 0.0.1.255
deny ip any 206.184.246.0 0.0.0.255
deny ip any 208.134.161.0 0.0.0.255
deny ip host 39.105.128.242 any
permit ip any any
Subscribe to:
Posts (Atom)