Cisco kills of first gen ASA’s

Cisco_ASA_5510So yesterday Cisco announced that it has EoL’d some (most) of the first generation ASA series of firewall.

It’s not really a surprise given that last year they released what I will call the second generation of ASA’s and pretty much all aspects they wiped the floor with the first generation.

It undoubtedly will cause a few headaches over the coming months with testing and evaluating the alternatives given that the ASA family has been around now for some time it has become one of the product lines that is taken for granted when it comes to hardware.

For those interested the actual EoL notices there are:

As always with Cisco when they EoL something we have quite a bit of time to transition to the new alternative and at the moment we are looking at:

  • End-of-Sale: September 16th 2013
  • End of routine failure analysis: September 16th 2014
  • End of new service attachment: September 16th 2014
  • End-of-Support: September 30th 2018

As can be seen above we have up to 5 years to transition but towards this time your not going to get much out of Cisco other than replacement hardware or a nudge to upgrade to the new products.

The options that we have within the NGFW (as Cisco are calling them) range fits in pretty well with the naming we are already using which makes it easy for the most part, for the Cisco recommendations see the EoL releases above but the gist of it is:

  • 5510 – Replace with either a 5512-X or 5515-X depending on usage
  • 5520 – Replace with 5525-X
  • 5540 – Replace with 5545-X
  • 5550 – Replace with 5555-X

Whilst the recommendations are a good rule-of-thumb to play by its worth noting that because of the performance increase it could be that you can handle dropping a step and still get better performance than the older platform.

FOr more information head over to the Cisco product pages for the new range here. There is also a handy quick reference guide here that shows all the vitals on one sheet.

It should be noted that at the moment the only model that has made it through this cull is the 5505 but no replacement has really come out to replace the home-worker/small-office device and I doubt for the moment that anything will really as it is still doing pretty well in its own little corner of the FW market.

Cisco RIB operations – AD comparisons

A post over at the IEOC forums (here) got me thinking to something I picked up a long time ago but I can’t really remember where…

When a prefix arrives at a device from two different sources the AD is compared and the lower AD wins out, simple CCNA level stuff right? Well what if the AD is the same due to AD manipulation?

The setup we are using to test this out is:

AD comparison topology

The configuration on each of the routers is pretty simple:

Router 1

int Fa0/0
 no shut
 ip add 10.1.2.1 255.255.255.0
 ip ospf 1 area 0

int Lo0
 ip add 10.10.10.10 255.255.255.255
 ip ospf 1 area 0

Router 2

int Fa0/0
 no shut
 ip add 10.1.2.2 255.255.255.0
 ip ospf 1 area 0

int Fa0/1
 no shut
 ip add 10.2.3.2 255.255.255.0

router eigrp 10
 distance eigrp 110 110
 network 10.2.3.2 0.0.0.0

Router 3

int Fa0/1
 no shut
 ip add 10.2.3.2 255.255.255.0

int Lo0
 shutdown
 ip add 10.10.10.10 255.255.255.255

router eigrp 10
 network 10.2.3.2 0.0.0.0
 network 10.10.10.10 0.0.0.0

At first the loopback interface on R3 was left shutdown so as to emulate the prefix being advertised at different times.

The poster over at the IEOC had read that when a prefix comes into a device with the same AD (for whatever reason) then the older route will win the RIB decision and be used.

When the routing had converged I saw the initial prefix be installed on R2:

*Mar  1 00:18:13.151: RT: network 10.0.0.0 is now variably masked
*Mar  1 00:18:13.155: RT: add 10.10.10.10/32 via 10.1.2.1, ospf metric [110/11]
*Mar  1 00:18:13.155: RT: NET-RED 10.10.10.10/32

I then brought up the loopback interface on R3, if the book was right then the OSPF advertised prefix would win out and the newer EIGRP route would be ignored but this is not the case:

*Mar  1 00:19:41.991: RT: closer admin distance for 10.10.10.10, flushing 1 routes
*Mar  1 00:19:41.991: RT: NET-RED 10.10.10.10/32
*Mar  1 00:19:41.991: RT: add 10.10.10.10/32 via 10.2.3.3, eigrp metric [110/409600]
*Mar  1 00:19:41.995: RT: NET-RED 10.10.10.10/32

Conclusion

There are a few other comparisons that are made when a prefix is compared on the RIB but when the prefixes come from different protocols and have the same AD then the original unaltered AD always wins out, in this case it was EIGRP which before I changed it to 110 it was 90 for an internal route.

DHCP and conflict logging

DHCP is something that is kind of overlooked sometimes and is treat as a given.

There was a recent DHCP issue at a customer site and I wanted to clarify my thoughts on what happened behind the scenes but I can’t say I have ever actually checked and proved that the conflict process works in the way I expected.

When a fresh DHCP client first goes live on the network it carries out a pretty standard ‘handshake’ of:

  • DHCPDISCOVER – This is broadcasted on the local LAN with a request for an address, as it doesn’t know anything about the network it is simply asking anyone who is listening for an address
  • DHCPOFFER – This is a message from a listening DHCP server with and address that can be used by the new client
  • DHCPREQUEST – This is a reply to the offer where the client takes the address that has been offered and formally requests it
  • DHCPACK – The DHCP server acknowledges the request, the client now has an address and related parameters to operate on the network

That is the CCNA view of what happens but behind the scenes there are a couple of things that are done in between the DISCOVER and the OFFER packets.

The DHCP server keeps an index of the addresses it has used and the next address that will be ditched out during a transaction.

When a new DISCOVER comes into the DHCP server it looks at its index and before it offers the address out it first ARP’s for and if successful tries to ping the address, why does it do this though?

If you were to have a device for example that had a static IP configured on it at 192.168.1.23 and .23 happened to be the next address that the server was going to allocate then without these checks it could end up giving out an address that is in use and cause an issue on the network, it ARP’s and then pings the address to make sure nobody is using it.

When a Cisco DHCP server discovers a conflict like this as default it will place it into a conflict table stating the address that was conflicting and how it came to that conclusion, this table is then used by the DHCP process to know which addresses to not even attempt to use as it has already been deemed that they are in use.

R1#sh ip dhcp conflict
IP address        Detection method   Detection time          VRF
10.10.123.2       Ping               Mar 01 2002 12:01 AM

This conflict logging can cause issues where sometimes due to a device reload it loses its DHCP bindings table, once this happens when the devices try to refresh their binding the DHCP will think there is a conflict (due to the existing machine answering the ICMP echo) and the conflict table can end up filling up pretty quickly.

If you want the conflict logging can be disabled with no ip dhcp conflict logging

It is handy to also know that even though you disable the LOGGING of the conflicts it will still go through the process of trying to find if the address is in use before offering it out.

If for whatever reason the client doesn’t respond to the ping from the DHCP server it will hand out the address (that has a conflict) as it can’t see any issues, when it does this the fist thing once the assignment is complete is the new host sends out a gratuitous ARP message with its new IP address, if it received no reply then all is good, if however it receives a reply then it indicates that there is another device on the network that is using that address.

If this happens then the client sends a DECLINE message back to the server and because the server also received the double gratuitous ARP from the previous section it puts the address in its conflict table (or not if its been disabled) and moves onto the next available address.

Time to put my SP hat on

Well I’ve decided to take on the CCIE SP next.

Given that there is a lot of overlap between the two tracks and that I use a lot of the technology (multicast aside) in my day job it should be quite good.

I’ve started as I did with the R&S by going through the INE ATC videos and have been going over IS-IS tonight, it’s something that is new to me as by the time I did the CCNP it had been removed so its my first time on the subject and compared to OSPF it seems pretty similar however (not surprising seen as they were developed at pretty much the same time and both using SPF) at the same time a bit easier.

I might try and get an IS-IS post up tomorrow just to cover off some things and so anyone can point any glaring holes in my logic 😛

Whats next?

Well since passing my CCIE R&S I’ve been sat at the crossroads of where to go to next.

I have multiple things that I’m interested in doing:

  • CCIE SP
  • CCIE DC
  • CCDA / CCDP

I think I’m going to go for the SP track next, it makes the most sense in what I do day-to-day but at the same time some of the new DC technologies are pretty interesting.

Continue reading