[c-nsp] Catalyst 3550 VRF-lite problems

[Tom Zingale (tomz)]

The Catalyst 3550 requires that you configure an extended-match SDM
template before you can use VRF-lite, policy-based routing, or WCCP
support.  Extended-match is available for the default, access, and
routing templates.  You will also need to reboot the switch after
changing the SDM template before the new template can take effect.

   sdm prefer {access | default | routing} extended-match

The VRF route was not added to hardware because extended-match template
was not implemented.

The document outlines this:
http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/12225seb/scg/s
wiprout.htm#wp1206101


> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Reuben Farrelly
> Sent: Tuesday, April 03, 2007 5:20 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Catalyst 3550 VRF-lite problems
> 
> Has anyone or does anyone ever done any small scale VRF configuration
on
> Catalyst 3550s or 3750s?
> 
> The reason I ask is today while diagnosing a fault that a customer was
> experiencing on a L2 link (we provide L2 transit through the switch
only, no
> L3), I decided to configure a VRF on one of our 3550s, put the newly
> customer's
> routed VLAN interface in that VRF with one of their IP addresses, and
added
> a
> default route to that VRF so I could replicate the fault (which was a
> routing
> problem on a specific VLAN).  I would have thought that was fairly
> straightforward and should pose no problems.  This was with
12.1(22)EA8
> i5q3l2.
> 
> The testing worked reasonably well, but it caused a total and utter
meltdown
> on
> the switch when I removed the VRF.  The switch jumped to 99% CPU,
> experienced a
> massive decrease in performance (approximately halved throughput),
started
> seeing packet loss on some of the traffic through it but not all, and
> required a
> reload mid afternoon to clear it.
> 
> Needless to say, this was not an especially favourable outcome
especially at
> that time of day.
> 
> After the event I noticed this in the syslog (this did not appear on
the vty
> session when I started to configure the VRF):
> 
> 
> %L3TCAM-3-SIZE_CONFLICT: VRF requires enabling extended routing
> 
> 
> Bug toolkit lists no VRF bugs with this release of code but it seems
like a
> pretty nasty bug to get a message like this logged on a
console/syslog, not
> to
> the terminal which issued it, let alone allow the command to actually
> succeed
> and then totally fry the crap out of some of the switch's internal
data
> structures (I guess, the TCAM).
> 
>
http://www.cisco.com/en/US/customer/products/hw/switches/ps628/products_
syst
> em_message_guide_chapter09186a00805e0b19.html#wp1292555
> suggests that up to 7 VRFs should be supported, and I had no other
VRFs
> configured.
> 
> Was this a known problem with this branch of code?  Or do people just
avoid
> VRF's on these switches altogether?
> 
> What effect will enabling extended routing have on my current TCAM
> parameters?
> 
> switch#
>   The current template is the default template.
>   The selected template optimizes the resources in
>   the switch to support this level of features for
>   8 routed interfaces and 1K VLANs.
> 
>   number of unicast mac addresses:   5K
>   number of igmp groups:             1K
>   number of qos aces:                1K
>   number of security aces:           1K
>   number of unicast routes:          8K
>   number of multicast routes:        1K
> switch#
> 
> [Now, that message about only 8 routed interface is interesting given
the
> switch
> lets you configure many more with no apparent side effects, and I
wonder if
> it
> is actually correct, but that's another topic entirely.]
> 
> Thanks,
> Reuben
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/