Hi folks,
Has anyone ever seen broadcasts leaking from an SVI into a layer 3
interface on a 3560?
We've got a managed Ethernet link between a 3560G-48TS (Auckland,
12.2(50)SE1 IP Services) and a 3750G-24TS (Sydney, 12.2(53)SE IP Services)
configured as a /31 layer 3 interface on both sides. The link runs OSPF in
area 64, and PIM sparse mode. Both Sydney and Auckland have a number of
SVIs.
[Hosts] -- VLAN 11 -- SVI11[Sydney]L3 -- /31 link -- L3[Auckland]
Sydney config:
interface GigabitEthernet1/0/25
description Auckland:Gi0/47
no switchport
ip address x.x.x.193 255.255.255.254
no ip redirects
no ip proxy-arp
ip pim sparse-mode
ip ospf cost 50
speed nonegotiate
priority-queue out
service-policy input SET-DSCP-TRUST
Auckland config:
interface GigabitEthernet0/47
description Sydney:Gi1/0/25
no switchport
ip address x.x.x.192 255.255.255.254
no ip redirects
no ip proxy-arp
ip pim sparse-mode
ip ospf cost 200
speed 100
duplex full
priority-queue out
service-policy input SET-DSCP-TRUST
On the Auckland 3560, OSPF constantly reports a mismatched area ID, even
though the area 64 session is up. PIM shows two neighbors, even though its
a point to point link. The IP address listed in both messages is the
Sydney 3750's Vlan11 address.
Mar 10 19:53:14.662 NZDT: %OSPF-4-ERRRCV: Received invalid packet:
mismatch area ID, from backbone area must be virtual-link but not found
from x.x.x.138, GigabitEthernet0/47
Auckland#show ip pim nei
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
P - Proxy Capable, S - State Refresh Capable
Neighbor Interface Uptime/Expires Ver DR
Address
Prio/Mode
x.x.x.138 GigabitEthernet0/47 02:25:20/00:01:20 v2 1 / S P
x.x.x.193 GigabitEthernet0/47 02:25:21/00:01:37 v2 1 / DR S P
Some debugging revealed something odd - when performing 'show mac- address
xxxx' on the internally assigned VLAN for Gi1/0/25 on Sydney, I see MAC
addresses listed against VLAN 11.
Sydney#show vlan int usage
VLAN Usage
---- --------------------
1006 GigabitEthernet1/0/3
1007 GigabitEthernet1/0/25
Sydney#show mac- vlan 1007
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
All 0100.0ccc.cccc STATIC CPU
All 0100.0ccc.cccd STATIC CPU
All 0180.c200.0000 STATIC CPU
All 0180.c200.0001 STATIC CPU
All 0180.c200.0002 STATIC CPU
All 0180.c200.0003 STATIC CPU
All 0180.c200.0004 STATIC CPU
All 0180.c200.0005 STATIC CPU
All 0180.c200.0006 STATIC CPU
All 0180.c200.0007 STATIC CPU
All 0180.c200.0008 STATIC CPU
All 0180.c200.0009 STATIC CPU
All 0180.c200.000a STATIC CPU
All 0180.c200.000b STATIC CPU
All 0180.c200.000c STATIC CPU
All 0180.c200.000d STATIC CPU
All 0180.c200.000e STATIC CPU
All 0180.c200.000f STATIC CPU
All 0180.c200.0010 STATIC CPU
All ffff.ffff.ffff STATIC CPU
11 0012.80bf.1718 DYNAMIC Gi1/0/24
11 0012.80bf.1743 DYNAMIC Gi1/0/24
11 0015.c695.b495 DYNAMIC Gi1/0/1
11 0015.c6fa.1e35 DYNAMIC Gi1/0/24
Total Mac Addresses for this criterion: 24
Sydney#show run int vlan11
Building configuration...
Current configuration : 185 bytes
!
interface Vlan11
description ASA Network
ip address x.x.x.138 255.255.255.248
no ip redirects
no ip unreachables
no ip proxy-arp
ip pim sparse-mode
ip ospf cost 5
end
I quickly threw it together in the lab and couldn't ping between a host on
the VLAN and Auckland, so suspect its broadcast/multicast traffic only.
Hunting around the network, this appears to happen on every 3560, 3560E,
and 3750 I could find. 6500 Sup720 doesn't seem to be impacted. Other than
the error message (which is uncommon, most links are in the same OSPF
area) and the PIM neighbors (new rollout), I can't see anything thats
actually causing a problem. Although I'm concerned if there's a broadcast
storm, we may exhaust bandwidth on routed links.
So, has anyone seen this before? Is it a bug or design limitation on the
3560/3750 platform? Is there any other way to make layer 3 interfaces
work other than a hardware upgrade?
Thanks,
- I.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
