Re: Native VLAN mismatch on Cisco 2950

fugettaboutit - Thank you for the correction. I read the article that you
linked.

KDawg44 - Perhaps on such a small network there would not be as much
benefit, but the concept is to put the management IP addresses of switches
in a LAN on a seperate VLAN. This would keep users from having their
connected switch IP addresses in an accessible IP address range or
accessible VLAN. The router connecting to these switches would have a trunk
connection which would have a seperate IP address in both VLANs - the
management VLAN and the user VLAN.
Maybe your setup does not need it, but the idea is to keep networks more
secure by later allowing through access-lists that only certian IP addresses
or IP address subnets can connect to the administrative IP address ranges
used for the management IP addresses on the switches and routers. It is
better than giving the switches a management IP address in the same VLAN and
IP subnet as all of the users who could attempt to access it.

--

===========
Scott Perry
===========
Indianapolis, Indiana
________________________________________
"KDawg44" <KDawg44@xxxxxxxxx> wrote in message
news:1186765092.934705.194290@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Aug 10, 11:38 am, fugettaboutit <n...@xxxxxxx> wrote:
This is a bad idea. It's also a bad practice on a number of fronts
ranging from security, node trust, and inband vs. out of band management:

http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_...

In particular, from a security perspective, not addressing the native
VLAN 1 issue opens you up to a VLAN hopping attack.

Change your native VLAN to something other than 1 (as it's the default
on all Cisco devices), prune it, and don't assign ANY hosts to it...

Scott Perry wrote:
<bav...@xxxxxxxxx> wrote in message
news:1186698608.352502.202130@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
1. Any benefit/reason in using VLAN 1 for management and create
another VLAN for users compare to using VLAN 1 for users and create
another VLAN for management?

There is a benefit: what is the one VLAN that you cannot delete or
remove
and will therefore always be there? VLAN1
The books and prudence suggest manking VLAN 1 the management VLAN and
to put
your network device management IP addresses on there. Laziness says
that it
is easier to leave all switchports VLAN 1 for the users and
workstations and
to just move the management IP address ports to the other VLAN.
If you are going to seperate them, make VLAN 1 for your network
administration and move the users to another VLAN.

When you say separate management traffic, what traffic do you refer to
exactly? We are in a small network that has one firewall, one network
switch, and a couple servers. How would this benefit this particular
network and what traffic should I segregate?

Thanks.



.

Relevant Pages

  • Re: VLANs
    ... Most switches will not restrict broadcasts -- it's one of the things ... Most vlan ... > separation of a highly critical data collection network. ... layout and/or configuration changes. ...
    (comp.os.linux.networking)
  • Re: Native VLAN mismatch on Cisco 2950
    ... KDawg44 - Perhaps on such a small network there would not be as much ... in a LAN on a seperate VLAN. ... The router connecting to these switches would have a trunk ... management VLAN and the user VLAN. ...
    (comp.dcom.sys.cisco)
  • VLAN Issues
    ... We have about 16 switches that are located across 4 ... floors in 4 seperate closets. ... out to our radiology dept. Vlan3 is our wireless network. ... VLAN 7 is a new VLAN that I am trying to create for the following ...
    (comp.dcom.sys.cisco)
  • Re: Clueless firewall configuration ?
    ... "drop" an IDS on a VLAN without adding network taps or other tricks. ... Having untrusted traffic on your core switch can cause the ... VLAN hopping attacks. ... Download FREE whitepaper on how a managed service can ...
    (Pen-Test)
  • Re: NLB Terminal Servers
    ... > NLB on Windows 2003 it seems pretty straight forward. ... This was causing network ... > VLAN: 1 ... > "Management" NIC ...
    (microsoft.public.windows.server.clustering)