Phil Mayers wrote:
Sam Stickland wrote:
Hi,
We have a pair of 4948s and some DDOS devices configured in this
topology (this is an inheritated design btw!):
SW1 SVI ---VLANA-- SW2 SVI
| |
DDOS Std DDOS Act
| |
SW1 (L2) --VLANB-- SW2 (L2)
X |
| |
Inside ----VLANB--- Inside
The Standby DDOS device does not pass traffic, but VLANs A and B are
effectively bridged by the Active DDOS device on the right.
What is a DDOS device? Do you mean IDS/IPS?
Yup.
The SVIs on SW1 and SW2 are in a seperate "outside" VRF, and they
provide a HSRP address that the inside network has a default pointing
towards.
The CPU on the active side (SW2) is pegged at 99% and it's all in
host learning. The log buffer reports:
Aug 5 07:44:34.467 UTC: %C4K_L2MAN-5-ROUTERMACADDRESSRXASSOURCE:
(Suppressed 61591949 times)Packet received with my own MAC address
(X:X:X:X:X:X) as source on port Gix/y in vlan B
(Gix/y connects to the inside port on the DDOS appliance).
I believe this is because the switches MAC tables aren't VRF aware and
MAC tables aren't VRF aware. They only need to be VLAN-aware.
I'm aware of this, I was just stating my reasoning in a perhaps not to
clear way :)
Frankly I'm surprised this isn't working; if the SW2(L2) are really at
layer2 with no SVI, and no L2 control protocols passing the DDoS
device e.g. spanning tree, CDP, LLDP etc.
The have no SVI, but spanning-tree instances are running for VLANs A and B.
the only way to solve the CPU problem is to use physically seperate
switches: i.e. replace the L2 portions in the diagram with separate
L2 switches.
You could try changing the MAC address of the SVI e.g. to a locally
assigned one:
int VlanX
mac-address H.H.H
...I'm not familiar with the C4k platform, but it's common that
devices have a finite number of MAC addresses they can use. Also when
I tried it on our 6500s I had problems where it didn't pick up the MAC
change on an existing SVI until reboot, but would on a newly-created SVI.
Unfortunately the C4k platform doesn't support changing the BIA
addresses, but given the nature of the error I don't think it would
help. I think it's caused by the layer 2 portion of the switches seeing
traffic sourced from it's own SVI on ones it's ports, which is confusing
the host learning.
Sam
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
