[Netdisco] vlan bleeding

[Kirk Olson]

I recently inherited a network with some interesting design methods. For
instance, protected (i.e. user) and unprotected (i.e. dmz) traffic vlans are
terminated in the same switch which is not (whether you agree with this
method or not) uncommon. What is interesting about this particular design is
that layer two traffic travels freely between the two vlans. :-o

This particular network has roughly thirty vlans and maybe twently Cisco
switches. My fear is that this bleeding is occuring elsewhere. I am
wondering if Netdisco could assist me in finding where this bleeding is
occuring.

Thanks all
Kirk

[Bill Fenner]

I think the data you're looking for is in the back-end database, but
there's probably no straightforward UI to it. You might find the
'[ports]' links at /netdisco/device_inv.html?show_vlan=1#vlan handy.

How is traffic bleeding between vlans? Access ports connected to each
other with different native vlans?

Bill

[Brian De Wolf]

Post by Kirk Olson
I recently inherited a network with some interesting design methods. For
instance, protected (i.e. user) and unprotected (i.e. dmz) traffic vlans
are terminated in the same switch which is not (whether you agree with
this method or not) uncommon. What is interesting about this particular
design is that layer two traffic travels freely between the two vlans. :-o
This particular network has roughly thirty vlans and maybe twently Cisco
switches. My fear is that this bleeding is occuring elsewhere. I am
wondering if Netdisco could assist me in finding where this bleeding is
occuring.

Netdisco generally builds a map based on CDP, which might help you find it,
depending on where your bridge between vlans is. As Bill stated, there's no UI
for displaying this kind of map specific to one vlan (the closest I've done is a
patch that I haven't released which modifies graphing to only follow certain
vlans). Of course, everything netdisco can tell you from cdp isn't difficult to
come by on your own. Logging into each switch, issuing "show cdp neighbor", and
looking for neighbors on ports you don't recognize should show anything netdisco
would tell you.

The problem is that, if the traffic is passing through an intermediate device
(switch/hub), CDP doesn't help you, and netdisco doesn't help you. I think
you're looking for some awareness of the spanning tree, and Netdisco is
completely unaware of it.

I think the easiest way to find the bridge would be to trace the path a packet
would follow using the "show mac-address-table" command. For example, to find
the bridge between vlans 2 and 3, find the mac address of a device (we'll call
it $mac) on vlan 2. On device $a with vlan 3, use the command "show
mac-address-table address $mac vlan 3", note that $mac is learned via an
interface connected to some device $b, log into $b and look at the interface
that is connected to device $a. Repeat this until you find some devices $a and
$b that the interface on device $a is on vlan 3 whereas the interface on device
$b is on vlan 2. Then you've found your bridge.

[Kirk Olson]

This is 100% a configuration issue on the part of the previous network
engineer. VLANs, like physically seperate network segments, don't allow
traffic from one to travel to the other. I know that much. Now that I have
that on the table let me be more specific about what I have termed vlan
bleeding.

A sister company has placed a router in our data center. The sister
company's connection to that router is a T1. There are two ethernet ports on
that router. One ethernet is connected on vlan 1 to our core network. The ip
address of that interface is 192.168.0.248/24. The second ethernet is on
vlan 440 and has an address 192.168.22.10/24. Vlan 440 is configured as a
DMZ subnet on the firewall. On vlan 440 there are, among other things, some
MS-Windows systems that belong to this sister company. These systems require
various MS and anti-virus updates and our company has been tasked with
keeping those systems up to date. We have an MS-SUS server internally but
the anti-virus updates come direct from the web. When we need to connect to
those systems we use remote desktop.

The updates failed recently and being new to this network I eventually
discovered that the firewall entries to specific update servers were
outdated. When the updates began to work properly I focused my attention on
the 192.168.0.248 interface which was wide open to our core network. I
started to capture port traffic on the 192.168.0.248 interface and could not
find the rdp traffic to the servers using ip address filters. There was no
rdp traffic found because it was going layer 2 to those servers.

I have decided to build layer two maps of all the vlans. This is a tedious
project but I will know the network when I am done. I thought perhaps
Netdisco would help me with that but I foresaw that Netdisco might have
trouble with this issue or, if it was capable of catching something like
this, that I might not be able to interpret the data correctly. I am working
my way up in terms of vlan numbers so I have a way to go before I get into
vlan 440. There are a number of configuration mistakes that could cause
this. I have no idea if other vlans are affected or if other issues exist
and so I want a comprehensive and methodical approach to resolution.

If you are interested in what I find say so and I will post my results here.

Thank you all for your thoughtful responses.

Kirk

[Alan Buxey]

hi,

..VLANs shouldnt bleed into each other until they hit an L3 device which
routes them...however..if at sme point on the network you have
a switch with eg vlan 40 on a port...and a cables goes from that port
to a port on another switch that is eg vlan 100, then vlan 40 and vlan 100
are now mixed.

you could stop the 'leakage' by ensuring that your router for that VLAN is
hardened up for that VLAN interface - eg 'no ip proxy-arp' will only
lets systems with vlaid addresses on that VLAN from traversing the routed
interface. you should be able to hunt down the source of the bleeding
by various means...

eg stick system onto the VLAN you know and try DHCP'ing and see where responses
come from - if you have DHCP on both VLANs then you should see a nice
return from a system that ISNT your DHCP server... then just hunt that MAc down
through the CAM tables.

alternatively, if you know the routed interface, you can do a trace through the
network for that Mac address (put yourself on the linked network and ping the
IP address of their router..get its MAC and follow the above.

also, look for switch ports with many or large numbers of Mac addresses on it

alan

[Smith, Jonathan]

I would be interested in what you find. I have just started working on a similar network with very similar configurations. A cable modem here with a VPN concentrator connected to it and then on its own VLAN inside our network. This is actually setup for several vendors so I have multiple of these.
I'd be interested in seeing what you find as it may help me with what I am sorting through.


Jon Smith



-----Original Message-----
From: Kirk Olson [mailto:***@gmail.com]
Sent: Thursday, January 28, 2010 8:22 AM
To: netdisco-***@lists.sourceforge.net
Subject: [Netdisco] vlan bleeding

This is 100% a configuration issue on the part of the previous network engineer. VLANs, like physically seperate network segments, don't allow traffic from one to travel to the other. I know that much. Now that I have that on the table let me be more specific about what I have termed vlan bleeding.

A sister company has placed a router in our data center. The sister company's connection to that router is a T1. There are two ethernet ports on that router. One ethernet is connected on vlan 1 to our core network. The ip address of that interface is 192.168.0.248/24. The second ethernet is on vlan 440 and has an address 192.168.22.10/24. Vlan 440 is configured as a DMZ subnet on the firewall. On vlan 440 there are, among other things, some MS-Windows systems that belong to this sister company. These systems require various MS and anti-virus updates and our company has been tasked with keeping those systems up to date. We have an MS-SUS server internally but the anti-virus updates come direct from the web. When we need to connect to those systems we use remote desktop.

The updates failed recently and being new to this network I eventually discovered that the firewall entries to specific update servers were outdated. When the updates began to work properly I focused my attention on the 192.168.0.248 interface which was wide open to our core network. I started to capture port traffic on the 192.168.0.248 interface and could not find the rdp traffic to the servers using ip address filters. There was no rdp traffic found because it was going layer 2 to those servers.

I have decided to build layer two maps of all the vlans. This is a tedious project but I will know the network when I am done. I thought perhaps Netdisco would help me with that but I foresaw that Netdisco might have trouble with this issue or, if it was capable of catching something like this, that I might not be able to interpret the data correctly. I am working my way up in terms of vlan numbers so I have a way to go before I get into vlan 440. There are a number of configuration mistakes that could cause this. I have no idea if other vlans are affected or if other issues exist and so I want a comprehensive and methodical approach to resolution.

If you are interested in what I find say so and I will post my results here.

Thank you all for your thoughtful responses.

Kirk
This E-mail and any of its attachments may contain Time Warner
Cable proprietary information, which is privileged, confidential,
or subject to copyright belonging to Time Warner Cable. This E-mail
is intended solely for the use of the individual or entity to which
it is addressed. If you are not the intended recipient of this
E-mail, you are hereby notified that any dissemination,
distribution, copying, or action taken in relation to the contents
of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any
copy of this E-mail and any printout.