7304 CPU goes to 90% with DLSW and Ethernet

[abekeris]

We have a pair of C7304 with IOS 12.2.20S3 and about 575 remote peers connected in each of the routers. This routers are connected to the same Ethernet segment with the host. One of the routers CPU is with an average of 3% and the other one with 90%. How is it possible ? do I have to change anything in my configuration ? or is it just normal ?

[mbinzer]

Hi,

do a show proc cpu and see what porcess is eating up

the cpu resources.

If it is dlsw msg proc than you need to filter all unwanted traffic.

How many dlsw circuits do you have on the two routers active at any time?

Start with the show proc cpu and find out which process consumes the cpu time.

thanks....

Matthias

[abekeris]

the pocess is "dlsw msg proc" and the circuits should be about 600.

[mbinzer]

Hi,

dlsw msg proc deals with everything from a test frame, to broadcasts to multicasts ect...

I assume you are using dlsw together with transparent bridging.

In that case you could do something like this:

( assuming again that you only use sna and the sap's

in use are 4,8,c )

access-list 200 permit 0x0000 0x0d0d

if you need to permit additional saps than you can

allow them like this:

access-list 200 permit 0x2020 0x0101

this would allow sap 0x20 including the response bit.

interface fastethernet x/y

bridge-group x

bridge-group x input-lsap-list 200

additional you should configure as global command:

dlsw icanreach saps 0 4 8 c

if you are only using the sap 4 then leave the 8 and c off.

This will instruct all the peering routers to not send anything else but for the saps you specify.

Better is to put the input lsap list also on all remote routers to completely block unwanted traffic as close to the source as possible.

thanks...

Matthias

[abekeris]

Thanks, I'll try it, but one more question...why this doesn't happen when the routers and the host are connected to a token ring lan?

[mbinzer]

Hi,

how do you compare this?

Did you just move from a tokenring on the host end to an ethernet?

You mentioned earlier that only one router is seeing the high cpu load. The other dont. So i guess based on this that you dont have a loop.

With multiple routers on the same ethernet you have to be extra carefull to not create a loop. You can also have a problem that you distribute information, dlsw reachability cache entries, to locations where you dont want them. I.e. a canureach for a specific

host mac address comes in on hostrouter one via a dlsw peer and a test frame is send out on the ethernet. If you have multiple host dlsw routers and if they are connected via ethernet switches in the same vlan than it depends on the status of the cam table of the ethernet switches where the frame gets deliverd to. If it is the host mac address and there is lots of traffic than the cam table will always know on what port the host is connected and forward the frame to this port.

If you send the test frame to a non known mac address it will get flooded in the vlan and in this case the second dlsw router will pick it up and forward it out again. It will then learn the source mac address as local on this lan, but in reality it is on a remote peer. If something like this happens you need to put an input address access list on the bridge-groups of the dlsw host routers and only allow the source mac of the host into those dlsw routers.

On a tokenring you have a rif field in every packet and you do source bridging. With configuring all of your routers with the same source-bridge ring-group number and a different bridge number if they are on the same physical ring you kill all possible loops.

However with just one router running very high on cpu and in the dlsw msg proc there is something coming and/or going which runs through csm, connection setup machine, which is handled by the dlsw msg proc. Most likely a lot of broadcasts or multicasts. This can also happen on a tokenring attached router.

thanks...

Matthias

[abekeris]

In effect, we are running a process of Token Ring to Ethernet migration.

When everything is Ethernet (connected to switches), I can nottice this behavior, but before the migration, everything was working good (original routers are C4500M).

In order to avoid undesirable traffic I will put the ACL's on the bridge group as you suggest.

Thanks.

[tblancha]

If you are using older 4500 series routers, you might be using 11.2 or previous IOS. 11.2 and before did ip path mtu discovery automatically. So, on the new routers, you must configure it with this command:

ip tcp path-mtu-discovery. The TCP sessions for the DLSw must be restarted for this to take effect.

You will also want to add the dlsw icannotreach sap AA E0 F0 command on the dlsw routers to stop these services from flowing over the DLSW pipes.

[abekeris]

We have configured DLSW transparent and everything is working good.