css excessive arp requests

[ulrichdobner]

Hello all,

my CSS 11150 with WebNS 5.00 does excessive arp requests on its interfaces (up to 100 arps per second). The box seems to arp EVERYTHING especially in the 10.147.0.0 /16 subnet even if it is not used at all. My config is as follows:

ip no-implicit-service

ip opportunistic disable

ip route 0.0.0.0 0.0.0.0 10.147.1.1 1

circuit VLAN1

ip address 10.147.248.10 255.255.0.0

circuit VLAN2

ip address 10.145.45.254 255.255.255.128

service sunbl3s6-443

ip address 10.145.45.136

protocol tcp

port 443

keepalive type tcp

keepalive port 443

active

service sunbl3s6-80

ip address 10.145.45.136

protocol tcp

port 80

keepalive type tcp

keepalive port 80

active

service sunbl3s7-443

ip address 10.145.45.137

protocol tcp

port 443

keepalive type tcp

keepalive port 443

active

service sunbl3s7-80

ip address 10.145.45.137

protocol tcp

port 80

keepalive type tcp

keepalive port 80

active

owner unix-systems

content vrp-test-443

vip address 10.145.45.253

protocol tcp

port 443

balance aca

add service sunbl3s6-443

add service sunbl3s7-443

active

content vrp-test-80

vip address 10.145.45.253

protocol tcp

port 80

balance aca

add service sunbl3s6-80

add service sunbl3s7-80

active

group vrp-test

vip address 10.145.45.253

add destination service sunbl3s6-80

add destination service sunbl3s6-443

add destination service sunbl3s7-80

add destination service sunbl3s7-443

active

Does anybody have any hints?

Many thanks in advance

Uli

[Gilles Dufour]

Uli,

what 5.0 version exactly ?

I believe there was a similar issue with early version.

You should also check if there is no other device sending traffic triggering the CSS to arp for those destination.

Finally, it is a good practice not to use hugh subnet (/16) on a CSS [or any other device].

If possible you should try to fragment your /16 subnet.

Regards,

Gilles.

[ulrichdobner]

Hi,

I did a software upgrade yesterday and put ap0610405.adi.gz on the box. But the behaviour didn't change. We also checked the cabling for loops, that's also fine.

We have observed some further things:

The broadcasts are only on the 10.147.0.0 /16 subnet. As this is our local lan backbone we can't change it, I could only shift the frontend into another subnet and route it towards the backbone.

We have another two boxes (CSS11503 with 7.4) with a similar configuration - they also do excessive arp requests in the same subnet, the primary as well as the secondary. But the addresses being arped for are not necessarily the same.

I took some packet traces looking for broadcasts and multicasts that could inspire the boxes to arp for every address they see - nothing, the addresses being arped for are not seen in the seconds before the CSS arp request.

What could trigger arp requests for machines which never accessed or used the CSS services / rules??? I've never seen such a behaviour before...

Best Regards

Uli

[seilsz]

It's possible that another system is scanning through all of the host addresses (.1, .2, .3, etc.) for that /16 subnet (or larger). The traffic wouldn't necessarily be directed to a broadcast address.

I would take a sniffer trace of all arp traffic and look for similar sources of requests.

~Zach

[Gilles Dufour]

Uli,

I would recommend to insert a different subnet.

As mentioned previously it is much better.

More secure.

And the CSS can't have more than 5000 arp entries so a /16 subnets is anyway no going to scale for the CSS.

Gilles.