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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
