From: Daniel Cisco Group Study (danielcgs@imc.net.au)
Date: Thu Feb 27 2003 - 09:02:49 GMT-3
Tim,
The problem that I've experiencing is actually the one described under the 2nd section titled:
Limited VLAN Isolation:
Exposure to MAC-Level Spoofing
You are right about hard coding MAC addresses - The devices can talk to each other if you statically define each other's MAC addresses.
Daniel
-----Original Message-----
From: Ouellette, Tim [mailto:tim.ouellette@eds.com]
Sent: Thursday, 27 February 2003 22:25
To: Daniel Cisco Group Study
Cc: 'ccielab@groupstudy.com'
Subject: RE: Cat 1900 Limited VLAN Isolation Problem
After reading the first couple of paragraphs of that interesting article
I've come to understand that this "feature" of the two boxes being able to
communicate is only after a VLAN change and the communication will stop once
the arp/cam table clears out.
" The local VLAN isolation feature of the Enterprise Edition software
prevents this temporary communication of stations after VLAN changes as long
as stations AA and BB are connected to the same switch."
In your question you mention "I verified that the two routers were connected
to two different vlans"... It appears that if they were once on the same
VLAN and then changed, per that doc, they should be able to talk (until
entries time out)
The other part I saw was "After the address of station BB is learned, the
operator could insert a static address entry for station BB into the local
ARP cache of station AA and establish communication directly between the
stations. "
The document says that if you hardcode the ARP entry on both routers,
they'll be able to talk (right?)
I'm going to have to take a deeper look into this.
Hopefully one of the other people has a better idea.
Tim
-----Original Message-----
From: Daniel Cisco Group Study [mailto:danielcgs@imc.net.au]
Sent: Thursday, February 27, 2003 4:02 AM
To: ccielab@groupstudy.com
Subject: Cat 1900 Limited VLAN Isolation Problem
I've racked my brain over this one for quite a while now.....
I'm stuck using a single CAT 1900 for now, and I was configuring & testing
DLSW+ when I noticed that the two routers being used to test DLSW+ (using
DSPU) were communicating directly instead of via the DLSW+ tunnel. I
verified that the two routers were connected to two different vlans, and
searched high and low for an answer. I verified that there was no other
bridging happening and I even turned off DLSW everywhere... I even found
that the two routers could ping each other if you hard coded the mac
addresses on both routers. So the symptom was as follows - Cat 1900 will not
forward broadcasts between vlans (as expected), but will forward unicast
between vlans (??????).
I eventually came across the following doc:
http://www.cisco.com/en/US/products/hw/switches/ps574/products_configuration
_guide_chapter09186a008007d0f8.html
The problem that I'm experiencing is described under the section "Limited
VLAN Isolation", and the solution is as follows :
"The Enterprise Edition software local VLAN isolation feature prevents this
spoofing effect as long as the operator's station AA and the target station
BB are connected to the same switch".
So, how do you turn on this "VLAN isolation feature"?
I'm running the latest Enterprise Edition software.
Any ideas?
Daniel
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
This archive was generated by hypermail 2.1.4 : Sat Mar 01 2003 - 11:06:37 GMT-3