Archive

Archive for March, 2014

Why fast IGP timers aren’t always beneficial

March 31, 2014 4 comments

Introduction

When tuning your IGP of choice, the first thing people look at is usually the hello
and dead interval. This is a flawed logic, it is true that it can help in certain
cases but convergence consists of much more than just hello timers.

Why tune timers?

Detecting that the other side of the link is down is an important part of converging.
That’s why your design should avoid putting any bump in the wires such as converters
or a L2 cloud between the L3 endpoints. If you avoid such things when one end of the
link goes down the other end will as well which provides fast detection of failure.

In rare cases you can have the link being up but traffic is not passing over it. For
such cases or for those cases where there was no chance of avoiding a converter or
L2 cloud, tuning the hello timers can help with failure detection. The answer is almost
always BFD though, if the platform supports it.

Topologies where tuning timers is bad

When using a topology where VSS is involved such as Catalyst 6500 or Catalyst 4500,
tuning the timers is very bad. A common topology might look like this:

VSS1

The L3 switches are dually connected to the VSS. These L3 switches might be in the
distribution layer and the VSS is part of the core. The distribution switches run
LACP towards the VSS which acts as one device from an outside perspective.

The VSS runs Stateful Switchover (SSO) which syncs configuration, boots the standby
supervisor with the software and has the line cards ready to go in case of failure
of the primary chassis. Hardware forwarding tables are also synchronized, SSO
switchover takes somewhere up to 10 seconds.

SSO

The active VSS chassis runs the control plane. Routing protocols such as OSPF are not
HA aware, meaning that the state of the routing protocols is not synchronized between
the chassis.

When using fast timers and a switchover occurs, what happens is that OSPF detects that the
neighbor is not replying and tears down the adjacency. The secondary chassis then has to go
bring the adjacency back up by sending out hello packets, exchanging LSAs and updating
RIB/FIB. This may take as long as 20 seconds with the time included from the switchover.

VSS_failure

Non Stop Forwarding (NSF)

NSF combined with graceful restart is a technology used to forward packets when
a switchover has occured. The goal of NSF is to delay the failure detection which
may sound strange from a convergence perspective. Remember though that the VSS acts
as one device.

With NSF the forwarding is done according to the last known FIB entries. After a
switchover the secondary VSS will use graceful restart to inform its neighbors that
it has restarted and needs to synchronize its LSDB. This is done by sending hello packets
with a special bit set and the synchronization is done Out Of Band (OOB) to not tear
down the existing adjacency. The neighbors exchange LSAs and run SPF as normal. The
RIB and FIB can then be updated and and normal forwarding ensues.

This process is dependant on that the neighbors are also NSF aware otherwise they
would tear down the adjacency when the secondary VSS is restarting its routing
processes. So the key here is that the adjacency must stay up and that’s why timers
should be left at default if running VSS. This goes for both the VSS and any routers
that are neighbors to the VSS.

Conclusion

When using VSS always leave IGP timers at the default. Fast timers ruins the NSF
process and will lead to much higher convergence times than leaving them at the
default.

Advertisements

Cisco Live Customer Appreciation Event

March 13, 2014 3 comments

This year Cisco is celebrating its 25th CAE. It will be hosted at the home
of the World Series Champions – The San Francisco Giants. AT&T Ballpark is
hosting the event.

The artists playing will be Lenny Kravitz and Imagine Dragons!

Expect good food, drinks and some pretty sweet pyrotechnics!

This should be an event you that dont want to miss.

RESPONSE: Why I’m in the Cisco Champions Program

March 9, 2014 4 comments

My friend Lindsay Hill wrote about the potential negative sides of joining an
ambassador program.
Lindsay brings up lots of valid points. My response here is
to explain why I’m in one, which might not be obvious from the outside looking in.

Independence

Both Lindsay and I are CCIEs. Going after that certification is not something you
are going to do unless you find that vendors products to be of acceptable quality.
As a CCIE if I have two comparable products at the same price and one of them is Cisco,
then I’m going to lean towards Cisco.

If the Cisco device does not match the requirements or if there is a big difference in
price then I’m not going to promote the Cisco device at all costs. I’m a professional and
I’m expected to to know my way around HP, Huawei or whatever comes in my way.

I’m not afraid to speak up if I find something negative about Cisco, however the best
result is usually achieved by trying to find the right channels to bring up your issues.
Blindly writing stuff on Twitter is less likely to get any attention.

Why I’m a Cisco Champion

Let’s be honest, it’s always nice being recognized. It’s human behaviour. If I were
to list the reasons why I’m in the program though it would look something like this:

  • Earlier access to news about products/events
  • My contact list within Cisco is growing
  • The chance to actually affect what Cisco puts out on the market
  • The chance to interact with other champions and pick their brains
  • Recognition

How does that help my clients?

I’m a senior network consultant and I spend a lot of time working on Cisco. By
knowing more about what’s going on inside Cisco I can give better advice to my
clients. Obviously a lot of stuff is under NDA so I can’t talk to my clients about
it.

By having a bigger contact list I can reach out to people when I am facing issues.
I also have a chance to influence people within Cisco to bring up these issues
internally which could lead to a bug fix or a new software version.

Conclusion

I agree with Lindsay’s thoughts. In the end it’s up to the person joining if it’s
worth the benefits and if you can stay neutral. Personally I would never advocate
a Cisco solution if I think there are better options out there for my clients.
If you are in doubt you should ask your consultant to explain why they are
choosing vendor X over vendor Y. If they can’t motivate it, then they are out
on thin ice indeed.