All things related to multicast

[Bill Nickless <>]

-----BEGIN PGP SIGNED MESSAGE-----

At 04:12 PM 7/24/2000 -0700, Hugh LaMaster wrote:

>An alternative is 12.0(x)S.  We have run or are currently running
>12.0(10)S and 12.0(10.6)S operationally on GSR, 7500 (RSP4 and RSP8),
>and 7200 (NPE-150, NPE-200, VXR-300), and are testing 12.0(11.6)S,
>(so far on GSR and 7200), with no problems.  On the 7500, RSP8 has
>been supported for a while.  Likewise, GE-IP.  Things have generally
>been quite stable for a while, since about 12.0(8)S or so.  My
>experience with 12.0()S has been very good, although it doesn't
>have some QoS features that are in 12.1.

Yes, I concur regarding 12.0S.  I've been running 12.0(10)S1 on my primary 
border router GSR for nearly two months and it's been running great.

> > Sadly 12.1(3) is not available for the 6509-MSFC, however.
>
>Obviously 12.0(x)S is not available for 6509-MSFC either.
>The selection of images available for the 6509-MSFC still
>seems to be quite limited, unfortunately.
>
>However, 12.1(1)E2 is available for the 6509-MSFC, and seems
>to have most of the latest code.  Did any 6509-MSFC's
>running it crash?  And, while we are on the subject,
>how many folks out there are using this combination as a
>border router (with BGP, MBGP, MSDP, PIM-SM, the usual stuff)?
>Any comments?

I've tried the integrated IOS version of 12.1(2)E and am currently running 
12.1(2)E on the MSFC and 5.4(4) on the Supervisor. While it's not running 
MBGP and MSDP it is running PIM-SM.  Both of these seem to suffer from a 
bug in programming the hardware TCAM, CSCdr67481, Version Found 12.1(1)E 
Fixed-in Version 12.1(3)E01:

>Under certain circumstances, for example bouncing an interface
>with an exccess-group configured, you can get messages
>00:51:40: %FM-4-TCAM_CAPMAP: Interface FastEthernet3/2 hardware TCAM LOU 
>usage capability exceeded
>00:51:40: %FM-4-RACL_REDUCED: Interface FastEthernet3/2 routed traffic 
>will be software switched in ingress direction(s)
>indicating that the TCAM has been exceeded but the sh tcam count
>output reports free space.

I'm doing NAT, policy routing, access lists, and GRE tunneling on the 
MSFC.  All but (possibly) the GRE tunneling impact the TCAM.  Generally I'm 
OK but if an Access Grid session fires up I have to turn off policy routing 
while the session is going to keep the CPU below 100%.  When the CPU gets 
that saturated I can see 25-50% packet loss through the 6509-MSFC.

The upshot is that I would be hesitant to run a 6509-MSFC as a border 
router until this access control list / TCAM problem is solved.  In 
contrast to my 6509-MSFC, my GSR is handling the access grid sessions, 
including distributing multicast traffic to half a dozen peer networks, 
without breaking a sweat.

The good news is that Cisco tells me there is a fix for this problem in 
test now.  I look forward to trying it when they can make it available to me.
===
Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7     


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>

iQCVAwUBOX2Vgawgm7ipJDXBAQHQPAP+Ip1SwV5ADX91D1vD9C59KlIVyIxJ8o4K
G1jcDe/wlhPcNci9GMUUQNkd8GV6WZwj497Is3/6pDL0cbFAFe4XWDO+5JHGOow3
gPZLHFl5zL2HUNY7A7S9F8w97JWjTOvGRGTuzvdx2x3ej2qUze4I+6oZy2gsxzFx
NTWN4Dzs++s=
=TBWh
-----END PGP SIGNATURE-----