Thursday, December 31, 2009

Cisco VSS configuration

I just finished standing up a Cisco VSS 1440 configuration for a client and thought I would put down a few notes about getting the system up and configured (with a script) plus some basic commands that are useful to know. Also, there are some quick notes on how to set up detecting a dual active configuration.

A basic configuration requires that both 6500 series chassis have the Sup720-10G and currently VSS will only support X67xx series line cards with some additional service modules like the FWSM, ACE and NAM. Seems that VSS really prefers line cards with the PFC 3C also.

You have to prep the two chassis so they are able to connect and function as a VSS pair. To do this they must be running SSO and NSF prior to pairing plus have the port-channel built out for the Virtual Switch Link (VSL.)

So, the bit of script to do that on each chassis is:
!
redundancy
mode sso
exit
!
router ospf {process id}
nsf
exit
!

Next is to build out the virtual switch domain, it should be unique to the VSS pair:
!
switch virtual domain {domain # between 1-255}
switch {1 or 2 - designated switch number for that chassis}
exit
!

The VSL should run across a port-channel of ten gig:
! - switch 1
interface port-channel 1
switch virtual link 1
no shut
!
! - switch 2
interface port-channel2
switch virtual link 2
no shut
!
! - next set up the ten gig ports - putting in the ten gig port on the sup720-10G in slot 5 plus a port from a x6708-10G in slot 6
! - switch 1
interface ten5/4
channel-group 1 mode on
no shut
! - add a second port
interface ten6/1
channel-group 1 mode on
no shut
!
! - switch 2
interface ten5/4
channel-group 2 mode on
no shut
! - add a second port
interface ten6/1
channel-group 2 mode on
no shut
!

Cisco recommends you set the Policy Feature Card (PFC) operating mode to 3C - this is assuming all your linecards have 3C PFC's in them - not always the case but here is how to do it:
!
platform hardware vsl pfc mode pfc3c
!

Now you finally get to issue commands that convert the existing chassis to a VSS ready configurations. Basically, by putting in the next command it uses the information that you gave it (which switch it is) plus knowledge of the existing port configuration to generate a new configuration file that will work when paired with the other unit. It effectively pre-pends its switch number to the slot/port numbers. For example, in switch 1, slot 5, port 4 - ten gig the current configuration refers to that port as simply tengigabitethernet5/4 but in the new configuration it will be tengigabitethernet1/5/4. After it does this a reload is required to get the configuration and pairing to work as expected. The command is:
!
switch convert mode virtual
!

The first time the VSL comes up and pairs you need to put in a command telling the primary switch to pull configuration information over from the secondary. You do that with the following command:
!
switch accept mode virtual
!

That should be it, you should have a working configuration. The first time I did this it was very confusing because using the traditional command sets for checking port-channels or modules or power status worked - they just didn't display what I thought they would. There are specific commands for a VSS and once you figure them out the whole configuration makes a lot more sense.

Some specific VSS common commands to use are:
!
show switch virtual link
show switch virtual link port-channel
show switch virtual link port
!
show switch role
!
! - commands that are modified for VSS so you can see information per switch chassis:
show mod switch 1
show mod switch 2
show power switch 1
show power switch 2
!

Of special note, if you look at the port-channel configuration for the VSL using traditional commands it will show it as down/down. At first this was very confusing for me until I realized that the port-channel had been effectively virtualized and controlled by the VSS process and you had to look at the status of the virtual link to determine what was happening. It also makes sense as you would never set up a port-channel to and from the same switch so the switch should NOT bring the link up in that logical context so having it only visible via the virtual link commands makes a lot of sense.

I think they should do some special reserved or locking commands for the port-channels you do set up for the virtual link because someone who is NOT familiar with VSS could easy think there are unused port-channels and potentially try and clean them out of the configuration, that could be bad. Hey, sometimes people don't read the descriptions on interfaces as much as you would like them too!

The next item to set up is Dual-Active Detection which is how the switches detect that both chassis think they are the active system and how to avoid this situation and detect it quickly to tell one of the switches to stop acting as the active system. I think the quickest way to set this up is with Fast Hello using a Layer 2 Ethernet link between the two chassis but you also have PagP and BFD options. You can optionally use all of the methods to help detect a Dual-Active condition.

To set up the Fast Hellow Dual-Active Detection simply pick two Ethernet ports on each chassis and do:
!
switch virtual domain {domain ID}
dual-active detection
exit
interface {type}{switch id/module/port}
switchport
dual-active hello
no shut
!

- Correction (01/18/10) - thanks Jay:
The correct syntax should be:
!
interface {type}{switch id/module/port}
no switchport
no ip address
dual-active fast-hello
!

To see if it is working do:
show switch virtual dual-active summary
show switch virtual dual-active fast-hello

That should get you started on the Cisco VSS bandwagon quickly, send me a note if you see problems, this was based on 12.2(33)SXH code so earlier code might have different commands.

- Correction (01/18/10) - thanks Jay:
The code release should be 12.2(33)SXI - I am running s72033-advipservicesk9_wan-mz.122-33.SXI3.bin and the configuration works.
- Ed

Monday, December 28, 2009

So, what advatages are there to having a Cisco VSS configuration?

I've been in several discussions with clients who are trying to understand the benefit of Cisco VSS vs a Nexus 7k approach for new data center deployments. Cisco has some excellent information out there on differences between the two platforms but if you haven't been on the lookout to upgrade your network infrastructure you might have missed the discussion.

I think both the Cisco VSS and Nexus solutions address many of the frustrations that people who are building larger data centers with virtualization are looking for. Specifically, a way to get redundancy and high availability plus very large bandwidth into their server farms while not building out a massive layer 3 network which can cause limitations for virtualization solutions. One of the advantages for companies that are not doing virtualization (perhaps their applications require all the cpu and memory of the host server) is that the architecture works equally well for them.

Cisco has build some specific solutions around virtualization plus data center, this is their recent announcement of the UCS products. I am not going to bother discussing that in this post and if you want to know more about that I suggest reading Colin McNamara's blog - he covers it really well so no reason to repeat it here.

So why would you pick a Cisco VSS solution vs a Cisco Nexus solution. There isn't an obvious answer at first blush.

Here would be the short list of why VSS first. They would be:
1. Having staff who understand and are familiar with the Cisco 6500 series and support a lot of them already.
2. The requirement for having service modules in the solution, something VSS supports but Nexus does not.
3. Moving from an existing investment in 6500's with Sup720-10G's to a high available, redundant solution split across multiple chassis - gear reuse.
4. Want tight fault tolerance solutions with other Catalyst switching platforms.
5. Able to provide Multichassis EtherChannel (MEC) to downstream or upstream devices.

Here would be the short list of why Nexus first. They would be:
1. Running into throughput and performance problems with a 6500 solution at core or distribution. Especially due to service modules impacting performance.
2. Would like to move to having independent point devices for services like firewalling, load balancing, network analysis and wireless. Perhaps you like a different vendors load balancer or firewall product that run at much higher throughputs.
3. Moving to very high density 1 and 10G server solutions that can grow and scale for investment protection.
4. Moving to the next generation platform where Cisco will be investing research and dollars into.
5. Able to provide Multichassis EtherChannel (MEC) to downstream or upstream devices.

So, if you are building out a data center soon that will require a 5-7 year lifespan then I really suggest moving to the Nexus platform now. Cisco is making the pricing just as attractive as the 6500 series but you gain all the advantages of moving to the next generation of platform.

If your time horizon is shorter for changing out your data center network equipment then the Cisco 6500 VSS solution is a great transition product which allows the re-use of your 6500 chassis and investment in supervisors (if you have Sup720-10G's already) and service modules.

The reality is that you will likely have both within your data center if you are making reuse of service modules. You can then run those service modules in 6500 series with 10Gig to a core Nexus plaform with the 6500's running VSS MEC to the Nexus 7000's running vPC MEC.

Both solution will work to your downstream server farms for MEC and the VSS has been upgraded to support 512 Port-Channels in a single chassis, more than enough considering many servers are getting 4 x 1Gig ports or more channeled together to the network.
- Ed

Tuesday, December 22, 2009

Cisco IP SLA

There was an interesting request on the Silicon Valley Cisco User Group mailing list the other day regarding how to get a Cisco switch to do a continuous ping, similar to how you do ping -t via the windows command line.

The idea I mentioned was using Cisco IP SLA's to do the same function and simply watch the statistics of the SLA to determine if things are working as expected. I had just set this up to keep an IPSec tunnel up and tested for a client so it seemed timely.

In addition to that, you can use this to watch IPSec tunnels or other links and change routing behavior based on the tunnel status using the track command.

A bit of code to get you started:
! - define an SLA
ip sla 1
icmp-echo {IP to ping} source-ip {IP to source traffic from}
timeout 1000
!
! - set up a schedule for the SLA to run - this will run forever
ip sla schedule 1 life forever start-time now
!
! - set up a track and make it's status dependent on the SLA
track 1 ip sla 1
!

To see the statistics simply do:
show ip sla statistics 1

That is it, simple but effective. Great tool to use if you are doing site to site tunnels with a firewall that is not participating in routing, it allows you to route around tunnels being down so you can have a semi-dynamic failover.
- Ed

Monday, December 21, 2009

Remote network console hardware options

There are a lot of good options available today in the remote network console management devices. I think the following are some pretty common manufactures out there and some brief thoughts on each, the opinions are my own so do your own homework!
On the high end is Uplogix who has tailored solutions for remote Cisco automated management and recovery plus remote console management. They have an excellent solution that is great for enterprise customers who need the sort of features and support that their product provides. As a result they have a tendency to be a more expensive solution but you get what you pay for in this case.

On the flexible and cool side is Opengear who have some of the most cost effective remote console management devices out there and they are also running open source code. They allow you to script and do lots of other nice things due to their openness. A great option for labs or if you have time to invest to write the scripts to automate things. So you can do much of what Uplogix is doing but you have to create it on your own. Their advanced console unit even includes storage space to store IOS images and configurations files.

There is also APC which has nice integration with their PDU solutions. They have been around a long time but their console management is only a portion of a much bigger solution so I don't think it gets as much attention as the likes of Opengear or others.

Avocent purchased Cyclades several years ago and Cyclades has been in use in data centers for years and years. Avocent has kept the Cyclades product line and has done a good job maintaining it. It is a getting a bit long in the tooth now but it is still an excellent console management device.

To round it out, Raritan, to be honest I haven't used them much and don't see them deployed very often as console management. I see them a lot for remote KVM. I am sure their solution is a workable one I just don't have any experience with it.
- Ed

Saturday, December 19, 2009

Henry M. Gunn High School makes US News top 100 school list

Seems my HS is still making the US News and World Report top 100 school list. Proud to see they are still keeping high standards even in the face of all the recent suicide issues, state cutbacks, etc. I hope it can weather through and continue to do well.
Go Titans!
- Ed

Friday, December 18, 2009

Cisco DMVPN - useful commands

Once you have a Cisco dmvpn deployment up and running there are some useful commands that you should know to figure out what is going on. Primarily these are no different then the routing and vpn command sets you already know and use. Commands like:
show ip interface brief
show ip eigrp neighbor
show crypto isakmp sa
show crypto ipsec sa
show ip route

The dmvpn specific commands would be:
show dmvpn {detail}
sh ip nhrp {brief}

If you have multiple dmvpn tunnel configuration on the router (the spoke is connected to two different dmvpn hubs) then:
show dmvpn interface tunnel {number}
is a useful command to know what peers and routes are coming from which dynamic tunnel.

I think one of the toughest things with dmvpn compared to a static ipsec/gre/eigrp configuration is that you don't have a specific logical tunnel for each remote router that is connecting. This can cause two problems, it is tough to know what sites are having issues and it is hard to get specific bw parameters out of the router without watching crypto maps. With a static ipsec/gre/eigrp configuration you can graph the tunnel interface and know how much traffic that tunnel is consuming at any given moment. With dmvpn this is a much tougher thing to do as the tunnel are transit and only up when they are needed between spoke locations. The only constant is the tunnel between the spoke and the hub/hubs.

To be honest, the thing I love the most about dmvpn is the fact that it behaves from a routing perspective very much like a fullmesh mpls deployment which are very common today. So a dmvpn solution is an excellent mpls backup solution that leverages local Internet access connections while not requiring odd routing tricks to make the sites behave correctly. For voice deployments with remote offices or soho sites it is an excellent solution and gives the remote site all the characteristics and advantages of a fullmesh site but with the cost effective bw of high speed Internet access available today.
- Ed

Thursday, December 17, 2009

Cisco DMVPN sample spoke script

Now that you have the hub script lets set up a spoke. This configuration will get the remote site up and connected to the hub via ipsec/gre/eigrp so you can actually see your routing neighbor peers with commands like:
show ip eigrp neighbor

!#####
! - DMVPN Spoke script - sample 2811 router running 12.2.x ios code
!
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
!
hostname {router hostname}
!
logging count
logging message-counter syslog
logging buffered 4096
!
no aaa new-model
clock timezone PST -8
clock summer-time PDT recurring
!
no ip source-route
!
ip cef
!
no ip domain lookup
ip domain name {example.com}
no ipv6 cef
!
username {name} privilege 15 secret {some super secret password}
!
crypto isakmp policy 1
encr aes
authentication pre-share
group 2
crypto isakmp key {some long preshared key} address 0.0.0.0 0.0.0.0
crypto isakmp invalid-spi-recovery
crypto isakmp keepalive 10
!
crypto ipsec transform-set {some string like companyname-tset} esp-aes esp-sha-hmac
!
crypto ipsec profile {some string like companyname-prof}
set transform-set {same string like companyname-tset}
!
interface Loopback0
ip address {loopback IP} 255.255.255.255
no shut
!
interface Tunnel0
description - DMVPN Tunnel Interface - Spoke configuration
bandwidth {set to the same as the internet bw - like 1544}
ip address 10.100.100.2 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication {some string - has to match on the spokes}
ip nhrp map multicast {Public IP of Hub}
ip nhrp map 10.100.100.1 {Public IP of Hub}
ip nhrp network-id {some id - match it to the eigrp AS}
ip nhrp holdtime 300
ip nhrp nhs 10.100.100.1
ip virtual-reassembly
ip tcp adjust-mss 1360
no ip mroute-cache
load-interval 60
delay 400
keepalive 5 4
tunnel source FastEthernet0/1
tunnel mode gre multipoint
tunnel key {some number - needs to match the hub}
tunnel protection ipsec profile {same string like companyname-prof}
no shut
!
interface FastEthernet0/0
description ***Internal LAN connection to switching core***
ip address {LAN IP} 255.255.255.0
no ip redirects
ip virtual-reassembly
duplex auto
speed auto
no shut
!
interface FastEthernet0/1
description ***External Internet connection to outside switch***
ip address {Public IP of Spoke} {Subnet of Public IP}
ip access-group inet in
no ip redirects
ip virtual-reassembly
duplex auto
speed auto
no shut
!
router eigrp {eigrp AS number}
redistribute connected route-map redistribute-connected-rm
network 10.100.100.0 0.0.0.255
network {LAN IP} 0.0.0.255
no auto-summary
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 {DG of Public IP}
no ip http server
no ip http secure-server
!
ip access-list standard redistribute-connected
permit {Lookback IP}
!
ip access-list standard vty_access
! - permit remote IP's
permit {public ip} {inverse public subnet} log
! - permit internal IP's
permit 10.0.0.0 0.255.255.255 log
!
ip access-list extended inet
remark Access list for Internet interface - permits DMVPN
permit udp any host {public IP of spoke} eq non500-isakmp
permit udp any host {public IP of spoke} eq isakmp
permit esp any host {public IP of spoke}
permit ahp any host {public IP of spoke}
permit gre any host {public IP of spoke}
! allow ssh to the public interface
permit tcp {remote public ip} {inverse public subnet} host {public IP of spoke} eq 22
! allow icmp if you want
permit icmp any any echo
permit icmp any any echo-reply
permit icmp any any time-exceeded
permit icmp any any unreachable
deny ip any any
!
snmp-server community {some string} RO
snmp-server location {some location}
snmp-server contact {some contact and number}
!
route-map redistribute-connected-rm permit 10
match ip address redistribute-connected
!
banner login ^

--------------------------------------------------------------------------


{Some Company Name}

{some threatening statement telling people to go away}

{some statement claiming everything is being logged}


----------------------------------------------------------------------------
^
!
alias exec st sh ip int brief
!
line con 0
login local
line aux 0
line vty 0 4
access-class vty_access in
exec-timeout 10 0
login local
transport input ssh
line vty 5 15
access-class vty_access in
exec-timeout 10 0
login local
transport input ssh
!
ntp server {public NTP server IP}
end
!
!#####

As with the previous hub script this doesn't have any CBAC or Zone Based firewalling in the script for the same rational. This is also using preshared keys and the router has to do an enrollment process to do certificates which I will cover in a later post. As before,
this is provided as is, it isn't perfect but should get you started in getting something up and running with minimal effort.
- Ed

Wednesday, December 16, 2009

Cisco DMVPN sample hub script

I've done enough dmvpn turn ups now that having some scripts is really useful. The first one is for the hub configuration. I have left it with an eigrp routing protocol configuration but it isn't that different to use ospf and it will give you something to look up and figure out. I'll post a separate entry for the spoke configuration next.

!#####
! - DMVPN Hub script - sample 2821/51 or 3825/45 routers running 12.2.x ios code
!
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
!
hostname {router hostname}
!
logging count
logging message-counter syslog
logging buffered 4096
!
no aaa new-model
clock timezone PST -8
clock summer-time PDT recurring
!
no ip source-route
!
ip cef
!
no ip domain lookup
ip domain name {example.com}
no ipv6 cef
!
username {name} privilege 15 secret {some super secret password}
!
crypto isakmp policy 1
encr aes
authentication pre-share
group 2
crypto isakmp key {some long preshared key} address 0.0.0.0 0.0.0.0
crypto isakmp invalid-spi-recovery
crypto isakmp keepalive 10
!
crypto ipsec transform-set {some string like companyname-tset} esp-aes esp-sha-hmac
!
crypto ipsec profile {some string like companyname-prof}
set transform-set {same string like companyname-tset}
!
interface Loopback0
ip address {loopback IP} 255.255.255.255
no shut
!
interface Tunnel0
description - DMVPN Tunnel Interface - Hub configuration
bandwidth {set to the same as the internet bw - like 1544}
ip address 10.100.100.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication {some string - has to match on the spokes}
ip nhrp map multicast dynamic
ip nhrp network-id {some id - match it to the eigrp AS}
ip nhrp holdtime 300
ip virtual-reassembly
ip tcp adjust-mss 1360
no ip split-horizon eigrp {eigrp AS number}
no ip mroute-cache
load-interval 60
delay 400
keepalive 5 4
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
tunnel key {some number - needs to match the hub}
tunnel protection ipsec profile {same string like companyname-prof}
no shut
!
interface GigabitEthernet0/0
description ***Internal LAN connection to switching core***
ip address {LAN IP} 255.255.255.0
no ip redirects
! - sample summary route statement
! ip summary-address eigrp 10.10.0.0 255.255.0.0 5
duplex auto
speed auto
no shut
!
interface GigabitEthernet0/1
description ***External Internet connection to outside switch***
ip address {Public IP of Hub} {Subnet of Public IP}
ip access-group inet in
no ip redirects
duplex auto
speed auto
no shut
!
router eigrp {eigrp AS number}
redistribute connected route-map redistribute-connected-rm
network 10.100.100.0 0.0.0.255
network {LAN IP} 0.0.0.255
no auto-summary
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 {DG of Public IP}
no ip http server
no ip http secure-server
!
ip access-list standard redistribute-connected
permit {Lookback IP}
!
ip access-list standard vty_access
! - permit remote IP's
permit {public ip} {inverse public subnet} log
! - permit internal IP's
permit 10.0.0.0 0.255.255.255 log
!
ip access-list extended inet
remark Access list for Internet interface - permits DMVPN
permit udp any host {public IP of hub} eq non500-isakmp
permit udp any host {public IP of hub} eq isakmp
permit esp any host {public IP of hub}
permit ahp any host {public IP of hub}
permit gre any host {public IP of hub}
! allow ssh to the public interface
permit tcp {remote public ip} {inverse public subnet} host {public IP of hub} eq 22
! allow icmp if you want
permit icmp any any echo
permit icmp any any echo-reply
permit icmp any any time-exceeded
permit icmp any any unreachable
deny ip any any
!
snmp-server community {some string} RO
snmp-server location {some location}
snmp-server contact {some contact and number}
!
route-map redistribute-connected-rm permit 10
match ip address redistribute-connected
!
banner login ^

--------------------------------------------------------------------------


{Some Company Name}

{some threatening statement telling people to go away}

{some statement claiming everything is being logged}


----------------------------------------------------------------------------
^
!
alias exec st sh ip int brief
!
line con 0
login local
line aux 0
login local
line vty 0 4
access-class vty_access in
exec-timeout 10 0
login local
transport input ssh
line vty 5 15
access-class vty_access in
exec-timeout 10 0
login local
transport input ssh
!
ntp server {public NTP server IP}
end
!
!#####

The script doesn't have any CBAC or Zone Based Firewalling configured on it - honestly that is easier to set up after you have the dmvpn up and working. This is for a preshared key configuration which is the easiest to get up and running but is nowhere near as secure as certificate based dmvpn deployments. Just setting up the certificate server on the router deserves its own post so I will wait on that one. This is provided as is, it isn't perfect but should get you started in getting something up and running with minimal effort.
- Ed

Tuesday, December 15, 2009

Network Troubleshooting - some thoughts

After doing several late night and weekend cutover and integration projects I realized that much of my network troubleshooting ability is not based on a specific checklist of items (though I am going to build one) but on disciplines that I learned while in engineering school.

Specifically, much of my time is spent gathering known variables, quickly writing up what the problem statement and conditions are and then forming a hypothesis that I can work off of to solve the problem at hand. Often, keeping the scope of the problems small and discrete helps, utilizing the engineering principle of KISS (Keep It Simple Stupid) minimize the impact of feeling overwhelmed by an issue. This is especially true when you are in a stressful situation due to limited time or the inability to rollback a solution - both are to be avoid at all cost but often in the world of consulting they are why you are brought into a project in the first place. I guess that goes with the territory.

There are lots of great resources out there that define the principles of engineering so I won't bother with links to those. I have found that the major process I use is not so different from the design principles you use to design and deploy networks. Cisco has a whole methodoly build around this and those that have suffered through their study materials know the PPDIOO mantra.

I think I prefer the more classic engineering school outline, something like:
Identify and understand the problem
Gather information
Generate several solutions
Choose the best of those solutions (KISS)
Prototype the solution
Deploy the solution
Redesign/Retest
Report on results

Each problem you face can be broken down and solved with this method, the difference between those who do network troubleshooting well and those who do not seems to be in the ability to quickly gather and analysis a situation, pick the best solution and then rapidly deploy and tweek the solution. This often comes with age and experience but I am amazed at how many colleagues I have watched over the years who do not follow any of these principles while troubleshooting problems. I primarily have noticed the lack of the engineering principle trait in those who did not go through formal engineer school or a technical trade. I have found that those with a military background adhere to a similar principle though slightly adjusted to the function the military provides. They seem to function well in solving these sort of technical problems also so clearly there is a reason I meet some many former military in the networking field.

Another funny item I have noticed over the years is the fact that no matter how much planning and scripting you do it is the small things that seem to get you. I am not entirely sure why this is, perhaps they are easily overlooked while planning and deploying. Regardless, to catch them the KISS principle is remarkably useful in ferreting out those small problems.

I by no means claim that my engineering degree makes me a better troubleshooter than some of my peers who do not have one, I have meet some amazing people in this field and clearly some people simply have the native instinct and problem solving skills needed to outperform others.
- Ed

Sunday, December 13, 2009

Shrew Soft - 2.1.5 vpn client released

From my previous posts about 64-bit vpn clients there is a good addition to the list of options outside of Cisco for Windows 7 64-bit OS and that is Shrew Soft who just released an update to their client which supports Windows 7. The best part is the fact you can import Cisco PCF files. I've had good success when using it will Cisco ASA and PIX vpn configurations and some mixed results with Cisco VPN 3000 concentrator.
The current version is 2.1.5 but the 2.1.4 release worked on my Windows 7 64-bit client also. I have several clients also using it and they have not had any issues either. Hats off to the folks at Shrew Soft - appreciate having a working 64-bit IPsec client that is easy to use for Windows 7.
- Ed