[c-nsp] Routing performance of ME3400

[Dmitry Valdov]

Hello,

You're using a layer-2 SDM template. In this case all L3 switching is done by 
CPU which is extremely slow. 
You should switch to L3 template which named "default" and supported only by
metro IP access image.

http://www.cisco.com/en/US/docs/switches/metro/me3400/software/release/12.2_46_se/configuration/guide/swsdm.html


On Wed, 27 Oct 2010, Garry wrote:

> Hi,
>
> I'm trying to pinpoint a problem with a customer site ... it's hooked up
> via dual 1G SM to a central 4500. There are multiple VLANs connected.
>
> Weird thing is this:
>
> VLAN 999 is distributed on L2 between three sites - the customer, the
> site with the 4500, and the backbone site. All three boxes have L3
> addresses in that VLAN.
> VLAN 1999 is used only at the customer site, with its own IP subnet.
>
> The backbone site has additional VLANs, one of which has a Linux server.
>
> When I hook up a PC to the customer site switch, using VLAN 999 and
> another IP out of the VLAN, doing an iperf run results in "appropriate"
> throughput in either direction (server only has 100M, so the 95-98mbit
> iperf reports should be OK). In this setup, the ME3400 only does L2 with
> the packets.
>
> Doing the same using VLAN 1999, with an IP out of that IP range, and the
> ME3400 doing L3 forwarding, incoming (towards the customer site) traffic
> throughput drops to something like 30-50Mbit, while outgoing throughput
> results in a constant (!) 16777 kbit. Remember, this is still on a 2GB
> PortChannel in uplink!
>
> Even worse, on bidirectional traffic (incoming 30mbit e.g.), output even
> drops further, as if there were some Halfduplex issue (which there
> isn't, at least not on any interface involved, checked everything
> multiple times).
>
> Could it be that the ME3400, albeit having the "largest" IOS on it
> (metro-ipacess) for BGP etc., is severely limited as far as L3
> performance goes? Also, I'm sporadically seeing this error:
>
> *Mar  1 00:41:15.366: %PLATFORM_UCAST-4-PREFIX:  One or more, more
> specific prefixes could not be programmed into TCAM and are being
> covered by a less specific prefix, and the packets may be software forwarded
>
> I did a "show platform ip unicast failed route" and got this output:
>
> Entries covered by Actual default route(0.0.0.0/0)
>                  240.0.0.0/4 Tbl:0 : Cover:0.0.0.0/0 Tbl:0
>                  0.0.0.0/8 Tbl:0 : Cover:0.0.0.0/0 Tbl:0
>                  127.0.0.0/8 Tbl:0 : Cover:0.0.0.0/0 Tbl:0
>                  x.x.y.0/24 Tbl:0 : Cover:0.0.0.0/0 Tbl:0
>                  x.x.x.y/29 Tbl:0 : Cover:0.0.0.0/0 Tbl:0
>        Total of 5 entries covered by 0.0.0.0/0 Tbl:0
> Entries covered by Actual default route(0.0.0.0/0)
>                  240.0.0.0/4 Tbl:1 : Cover:0.0.0.0/0 Tbl:1
>                  0.0.0.0/8 Tbl:1 : Cover:0.0.0.0/0 Tbl:1
>                  127.0.0.0/8 Tbl:1 : Cover:0.0.0.0/0 Tbl:1
>        Total of 3 entries covered by 0.0.0.0/0 Tbl:1
> Entries covered by Actual default route(0.0.0.0/0)
>                  240.0.0.0/4 Tbl:2 : Cover:0.0.0.0/0 Tbl:2
>                  0.0.0.0/8 Tbl:2 : Cover:0.0.0.0/0 Tbl:2
>                  127.0.0.0/8 Tbl:2 : Cover:0.0.0.0/0 Tbl:2
>                  10.10.0.0/16 Tbl:2 : Cover:0.0.0.0/0 Tbl:2
>        Total of 4 entries covered by 0.0.0.0/0 Tbl:2
>
> Checking Cisco's docs, the "recommended action" isn't really useful:
>
> Quote: "Recommended Action    No action is required. "
>
> Great. So seeing that CPU might be used for L3 forwarding does not
> warrant any action? Seeing that 0/8 route there has me somewhat worried,
> but what might cause the performance hit is the other two network routes
> listed as being covered by 0/0 ... any comments on this? Can I avoid it
> somehow? Anyway, the customer site at the moment does not report this
> error, but performance is still bad, so I reckon it's not necessarily
> caused by this ...
>
> Hints appreciated!
>
> Tnx, Garry
> _______________________________________________
> 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/
>

-- 
Dmitry Valdov
CCIE #15379 (R&S and SP)