[c-nsp] 12.2 SRC opinions?

Saku Ytti saku+cisco-nsp at ytti.fi
Sun Mar 30 06:51:41 EDT 2008


On (2008-03-30 08:58 +0200), Andrew Alston wrote:

> All in all... I don't recommend SRC in production unless you have a damn
> good reason for it.

This is always true for early piece of new software, use only if you must.
Having said that, for our config SRB2 didn't work, would just freeze,
that issue will be addressed in SRB3 and has been addresed in SRC,
so for now, we're stuck with SRC on few boxes, with particularly
large configuration.
One box for example has ~450 VRF's and ~1300 interfaces, using
QoS, MPLS, EoMPLS, L3 MPLS VPN's, full BGP table, ES20 with EVC config,
RIP, OSPF, IS-IS, LDP, BGP, VRF Select, CoPP, IPv6, 6PE, so not particularly
simple config by any means, but it seems to work, been up +10 weeks
with only few issues:

1) one time in interface with ACL and VRF select by policy route,
both were populated in BANK1 TCAM, causing anything that matches
ACL not evalute policy route. Workaround was to do dummy
change to ACL which moved it to BANK0. I don't have DDTS yet for it,
may take while to solve, as I have no clue how to recreate.

2) platform capacity pfc has cosmetic bug, where SUPs route
usage is incorrectly displayed, in SP sh mls cef .. will
however show correct number. DDTS's CSCso19968, CSCsk49409

3) there was change in SRB (so SRB is affected also) how
eBGP verifies that route is connected. It broke our static
MGMT routes. Fix is to configure 'disable-connected-check'.
This issue was introduced to fix CSCei10769, to get better
BGP-MTR performance.

So actually only one real issue, we have 3 SRC's running
and 4th box (even larger then the currently mentioned)
being installed shortly


For every negative 'it'll blow up in your face in 1s' there are
large bunch of people you'll never hear from who are happy with
given solution. Unfortunately as IOS is rather bug-ridden,
like all large pieces of software are, it's really hard
to use other success or catastrophe stories are reliable 
measurements on how the software will fare on your network.
 Best practice is to pick late software that's had few
rebuilds and start labbing from there.

-- 
  ++ytti


More information about the cisco-nsp mailing list