Howfunky.com

Perhaps it is a company policy or someone on your IT team feels it is important to block IPv6 tunneling across your network to 6to4 relays or Teredo relay servers or perhaps you only want internal folks using your delegated IPv6 address block. Do you have any options available to you to block this sort of traffic?

As it seems with all things tech related the answer is, it depends on what you want to do. Both 6to4 and ISATAP utilize IPv4 protocol 41 to tunnel their traffic. Therefore, it is easy enough to block IPv6 protocol 41 from traversing internally (which would stop ISATAP and 6to4) or at the edge firewall (which would stop 6to4 but might not stop ISATAP.) On Cisco IOS it might look like this on an internal router or switch:
access-list 100 deny 41 any any
access-list 100 permit any any (or whatever traffic you DO want to permit)

In addition, to this step you can blackhole the IPv4 route to 192.88.99.1 which is the IPv4 anycast address used for the 6to4 IPv4 relay. On Cisco IOS you could do:
ip route 192.88.99.1 255.255.255.255 null0

Teredo clients can be blocked in a simple method because by design it utilizes UDP over IPv4 to establish and build it's NAT traversal tunnel traffic. Simply blocking outbound UDP traffic solves the problem but certainly breaks a lot of other functions for end client machines.

If you are running a Microsoft Windows AD configuration with clients belonging to the domain you can poison the Teredo entry that is used by default on a Microsoft client machine. All Microsoft clients from Windows XP on up make use of the dns name teredo.ipv6.microsoft.com to resolve if they can utilize Teredo to build out an IPv6 connection. This likely isn't the best method but it can be effective and some might say required because from Windows Vista on up Teredo is enabled by default but is inactive. This means if an application gets installed that wants to make use of Teredo it activates the Teredo client and attempts to use it.

You can also use a GPO to change the registry keys to keep Teredo off. You can push firewall changes to the Windows clients (Vista and Windows 7) that would block Teredo or you could turn off IPv6 which would solve the problem also. Microsoft has documentation on all of those options, you can start looking here, here or here to find out more.

So, in those cases where you actually need to turn off IPv6 tunneling technologies there are options available. The next question is do you really want to block these technologies?
- Ed

Labels: IPv6, Microsoft, Security

There are many ways to help protect your network from attack, one of the simpilist and most effective is actually to filter incoming and outgoing traffic from your network. An excellent place to start is to utilize the rfc's to define IPv4 addresses that are not or never will be in use on the public Internet and not allowing that traffic inbound. In the same vein, you can use the same information to limit what is allowed to leave your network, such as only IPv4 addresses that are legitimately routable on the public Internet.

This is not a new or unique solution but it is more commonly done at the service provider and larger enterprise level because those type of operations pay attention to the rfc's but also because they recieve much higher traffic loads on average traditionally. I believe that this technique is still useful for much smaller operations to use and is relatively simple to set up and maintain.

Here is a short list of rfc's to put in your firewall or edge router of addresses you should not be seeing from the Internet and ones that you should consider filtering out before sending traffic out to the Internet.

network RFC 1112
description - Host Extensions for IP Multicasting - in RFC 1700 also
240.0.0.0 240.0.0.0

network RFC 1700
description - assigned numbers - multicast, current, host, and reserved
224.0.0.0 240.0.0.0
240.0.0.0 240.0.0.0
0.0.0.0 255.0.0.0
127.0.0.0 255.0.0.0

network RFC 1797
description - Class A Subnet Experiment - may get reallocated - use the bogon list instead
39.0.0.0 255.0.0.0

network RFC 1918
description - reserved private IPv4 addresses
10.0.0.0 255.0.0.0
172.16.0.0 255.240.0.0
192.168.0.0 255.255.0.0

network RFC 2544
description - Benchmarking Methodology for Network Interconnect Devices
198.18.0.0 255.254.0.0

network RFC 3068
description - IPv4 reserved 6to4 IPv6 gateway services
192.88.99.0 255.255.255.0

network RFC 3171
description - IANA Guidelines for IPv4 Multicast Address Assignments
224.0.0.0 224.0.0.0 (covers 224.0.0.0 through 255.255.255.255)

network RFC 3927
description - Dynamic Configuration of IPv4 Link-Local Addresses - in 5735 above
169.254.0.0 255.255.0.0

network RFC 5735 (update of RFC 3330)
description - this rfc really collects all the other rfc with special use (reserved and limited IPv4 blocks) in a single doc, these is only a partial listing
192.0.2.0 255.255.255.0
169.254.0.0 255.255.0.0
224.0.0.0 224.0.0.0
14.0.0.0 255.0.0.0 (may be reallocated - use the bogon list instead just in case)

network RFC 5736
description - IPv4 Special Purpose Address Registry
192.0.0.0 255.255.255.0

network RFC 5737
description - reserved for test net
198.51.100.0 255.255.255.0
203.0.113.0 255.255.255.0

Here are some reference URL's to get you started to determine what you should apply for your needs.
Wikipedia
IANA
Team CYMRU

In addition to using IP address list filters there are other protections you can take at the edge. You should consider putting more aggressive ICMP filters in and also filter specific IP protocol numbers from coming in or going out. I'll post more about that another time.
- Ed

Labels: bogon, IPv4, Security

Everyone should update their IPv4 bogon lists a bit faster now that we are below 10% of IPv4 addresses left and it seems that IANA is handing them out faster to force folks to update their lists a bit quicker and I imagine to put pressure downstream for the adoption of IPv6.

January 2010 the following IP blocks were allocated to APNIC: 1/8 and 27/8. This one has some significance because a lot of network engineers in labs or to test something use 1.1.1.1/32 or 2.2.2.2/32 or some other variation within 1/8 or 2/8. Neither should be used now due to the new APNIC allocation and also because in September of 2009 2/8 and 46/8 were allocated to RIPE and should have been removed from your bogon list!

In addition, the IETF obsoleted RFC 3330 with RFC 5735 and as a result the following IP blocks have been reserved for documentation purposes: 198.51.100.0/24 and 203.0.113.0/24. That means they should be added to your bogon list.

If you don't like search around and keeping this stuff up to date yourself the best resource out there is The Team Cymru Bogon List. This list is kept up to date and is super useful as it provides the list in all sorts of useful formats. Highly recommended.
- Ed

Labels: bogon

Seems that password security is still a huge issue for enterprises and for consumers. The recent analysis report from Imperva is a little scary and enlightening at the same time. Granted this is analysis of consumer grade passwords for a website but it still offers insight into how people go about using and generating passwords.

Some fascinating items from the reports findings of the most common passwords:

1. 123456
2. 12345
3. 123456789
4. Password
5. iloveyou
6. princess
7. rockyou
8. 1234567
9. 12345678
10. abc123

I think given that the website was rockyou.com we can safely remove that one from the list. What you are left with are passwords that you should be eliminating as acceptable within your environment. In addition, the graphs show in the report that only 3.81% of users used special characters in their passwords. They also state "Nearly 50% of users used names, slang words, dictionary words or trivial passwords (consecutive digits, adjacent keyboard keys, and so on)."

Gets you thinking that OTP + pin or smartcards might be the only real way to enforce true high quality password security for consumers or enterprises.
- Ed

Labels: Passwords, Security

I just finished reading the following Infoworld article on Microsoft DirectAccess by Keith Schultz titled "Microsoft DirectAccess: The ugly truth. I think Keith is trying to get a response out of folks when there really isn't any ugly truth to reveal. I question some of Keith's claims in the article regarding some of the dependencies that he outlines and claims are ugly. Specifically, the deployment requirements for DirectAccess that are outlined are textbook Microsoft and (as is expected from the vendor) they include everything, likely far more than most customers would deploy for a working solution.

A more practical view is to realize that DirectAccess is specifically designed around a Windows Server 2008 and Windows 7 better together story. So, obviously, those two products need to be in use or planned to be deployed. Given the very fast adoption that Windows 7 is enjoying and the fact that Windows Server 2008 R2 is a solid deployment choice for an OS it is natural to start leveraging some of the better together options available. If you don't plan on using Windows 7 or Server 2008 R2 then guess what, don't deploy DirectAccess. I don't think that is an ugly truth it is just logic.

DirectAccess does not require that you replace any infrastructure but instead allows a company to simply upgrade a domain controller to Server 2008 SP1 or R2. Given the refresh cycle it is reasonable to assume that most IT shops will be adding Server 2008 SP1 or R2 into their environment very soon if they have not already. In addition, you will need to deploy (yes a new server or virtual machine) a DirectAccess server or Forefront Unified Access Gateway 2010 server. If you deploy the Forefront UAG 2010 solution you do not require a separate NAT64(NAT-PT is dead BTW) device (UAG provides this function) and UAG can be the DirectAccess solution as well.

I would also argue there are many AD configurations deployed today that are starting to use machine certificates for wireless 802.1x requirements and domain signed certificates for SharePoint and therefore a reasonable amount of customers have started deploying or are looking to deploy certificate services. DirectAccess can piggyback on the CA infrastructure in place or being planned. (As a side note, if you are deploying a CA on Windows Server 2008 R2 - remember to launch IE with "Run as administrator" when you are trying to see the newly copied certificate templates options you have added to the CA server.)

If you end up deploying DirectAccess with Forefront UAG 2010 the issue of having services internally not running IPv6 natively is a mute since it has the NAT64 option. Additionally, there is no requirement to run IPv6 or any transition services at all on the DirectAccess server if desired as it has the option to simply do DA over IP-HTTPS. You will notice in the TechNet article that it outlines transition services "available" for use in DA - not a requirement. Granted, I think running Teredo or 6to4 would be a good deployment option but it is NOT a requirement. Also, regardless of what any of the Microsoft documentation says, do not deploy DA with ISATAP, you will have nothing but headaches and no management or troubleshooting tools to determine why things are not working. You've been warned - no ISATAP!

One of the additional items listed is Network Access Protection (NAP). NAP is far from a requirement to deploy DA. All that Microsoft did was insure that DA conformed to previously designed deployment specification for NAP. That way shops that already have NAP deployed in their environment can continue to leverage and use it for health checks against machines regardless of how they are gaining entry to the network (wired, wireless, DA, ipsec vpn, ssl vpn, pptp.) So, if you are not running NAP and don't plan to then there is nothing to worry about. If you are running NAP already just know you can do integration with DA to leverage your existing investment in NAP.

So, more than likely the purchase of Forefront UAG 2010 with some small upgrades in a typical environment would allow for a successful DirectAccess deployment assuming you have decided that Windows Server 2008 R2 and Windows 7 are where you are going. I don't see a lot of ugly in any of that. The nice thing about choosing Forefront UAG 2010 is that it a high available solution option and builds the group policy configurations for you for DA, a pretty nice plus if you ask me.
- Ed

Labels: Microsoft DirectAccess, Microsoft Forefront UAG

I'm really excited to be heading up to Redmond from Feb 15th to Feb 19th to participate in the Microsoft MVP 2010 Summit. I was first awarded in June of 2004 as a Windows Server - Networking MVP and was in that awardee category until it was eliminated in 2008. I was moved to the Enterprise Security category and continue to focus on networking and was re-awarded in that category in June of 2009.

I don't know if I ever expected to be a 6 year running Microsoft MVP awardee but it has been a wonderful experience and I am really looking forward to seeing a bunch of my fellow MVP's up in Redmond to hear about all the interesting things Microsoft is doing and to exchange ideas and information. I've managed to make it up every year I've been awarded so while not a veteran (compared to some MVP's out there) I am certainly no stranger to the whole extravaganza.

I owe a few shout outs to some Microsoft folks: Emily Freet, Connie Rennie, Jake Grey, Chris Avis, Stephen Rose, Joey Snow, Beth Massi, Chris Avis, Mike Wolfe, Joe Davies, Chris Henley, Sean Siler, Abolade Gbadegesin, Eddie Malik, Kevin Engman, Loretta Duncan-Brantley, Devrim Iyigun, Jeff Sigman, and many more (I hate knowing I forgot someone!)

And to non-Microsoft or former Microsoft, or Microsoft MVP folks: Kathy Jacobs, Steve Riley (ex-Microsoft, now Amazon cloud stud),Bill Pytlovany, Betsy Weber(the most awesome third party MVP supporter - love Techsmith!), Jennelle Crothers and of course PacITPros (and again, forgetting someone, I will correct the list as they come to me!)
- Ed

Labels: Microsoft MVP

I've been running the ASA 8.2.1(11) code on several platforms for a couple of months now and have run into a few problems with it now, primarily site to site VPN issues. Seems that 8.2.1 is slightly better for some of those items (some cosmetic and some outright bugs), I am hoping a new code release comes out soon as the 8.2.1 release has some AnyConnect Client VPN issues with long split tunnel lists that are problematic.

Also, a new 8.0.5ED release came out in Nov for those that are staying on the 8.0 train. Given how stable 8.0.4 is and the fact that it was the default shipping code release on the platform for a long time I don't know how quickly folks will be updating to 8.0.5 now. I guess I will have to test it in the lab to determine if there are issues with running it.
- Ed

Labels: Cisco ASA

There are often times when you need to provide layer 2 isolation for servers that logically make sense to keep on the same subnet. A good example are web servers that reside in a dmz that perform the same function but do not have any reason to communicate with each other, just with the public and the common back end application services they are addressing through a firewall. In this scenerio you could either put each server in a /30 subnet and write specific ACL's for that subnet or simply make use of a larger subnet and utilize private vlans.

The Nexus OS allows you to build out private vlans to perform this function. There are two types of secondary vlans you can create in a private vlan. A secondary vlan is one that is bound behind a primary vlan which is how you can control the behavior of the vlan ports. The two secondary types are community (a port that is in a community can talk to those that are in its community) and isolated (it can only talk to itself.) The primary interface should be a promiscuous port so everyone in a community or isolated port can talk to it. In this situation you can build out as many community and isolated secondary pvlans as you require and simply assign them to a primary vlan that is associated with a specific subnet. There are a couple of items to be aware of, things like multicast applications (those that are participating in multicast have to be in the same community) and some other minor requirements for things like clustering which might require those ports to be promiscuous instead of just in a community.

Here is a short sample script you can use to get started.
! - Nexus 7000 script
!
! - configuring private vlans
! - enable pvlans feature
feature private-vlan
! - create primary vlan 100
vlan 100
private-vlan primary
!
! - to confirm that the vlan is a primary do
show vlan private-vlan
!
! - create a secondary community vlan
vlan 200
private-vlan community
!
! - create a secondary isolated vlan
vlan 201
private-vlan isolated
!
! - now associate the secondary vlans with the primary
vlan 100
private-vlan association 200-201
!
! - to see the pvlan mappings do
sh vlan private-vlan
!
! - to put a port in a private-vlan do
interface eth1/1
switchport
switchport mode private-vlan host
switchport private-vlan host-association 100 201
!
! - to see the port status do
show interface eth1/1 switchport
!
! - to set up a promiscuous port
interface eth2/1
switchport
switchport mode private-vlan promiscuous
switchport private-vlan mapping 100 200-201
!
! - to see the port status do
show interface eth2/1 switchport
!
! - to set up an SVI (Layer 3 interface) association
feature interface-vlan
interface vlan 100
private-vlan mapping 200-201
!
! - to see the state of the vlan interface
show vlan internal vlan-info

That should get things started for a private vlan configuration on a Cisco Nexus platform.
- Ed

Labels: Cisco Nexus

It is official, I have been the sponsor coordinator (the person who make arrangements for vendors to pay and present at our monthly IT Pro user group meetings) for 6 years now. Somehow I have managed to get a lot of companies to come present and sponsor our group over the years and I want to thank them for being so generous and also seeing the value in coming to talk to a user group.

I've been involved with PacITPros (formerly SFNTUG) for well over 10 years now and have meet and had the pleasure of knowing a ton of people due to my time in the group. I also helped run and do the same roll over at TVNUG before we ran out of steam and I am involved with the East Bay Cisco User Group and the Silicon Valley Cisco User Group which I highly recommend for those that are involved with networking at all.

So, with any luck I will still be doing this in another 6 years and PacITPros will still be going strong. I've been fortunate to watch in grow from 20-30 folks meeting at a law office in the Embarcadero Center to well over 70 people per meeting per month with several thousand on the mailing list. A quick thank you to Doug Spindler (President) for trusting me to get sponsors, Jennelle Crothers for dealing with the pizza, raffle items and general organization of the group, Blaine Busse for dealing with troublesome folks who might show up from time to time, Robert Riebs for giving time and sweat to help keep Doug organized and to lots of others in the group who make the whole user group experience worth the time and effort.
- Ed

Labels: PacITPros

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

Labels: Cisco VSS

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

Labels: Cisco Nexus, Cisco VSS

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

Labels: Cisco IP SLA

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

Labels: Remote Console

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

Labels: Gunn High School