VLAN IP and DHCP

I want to configure VLAN 101 on three 3550 switches. Can the virtual interface for VLAN 1 have the same IP address on all three switches? (10.1.101.1) If so, why isn't there an IP address conflict?

If each switch needs it's own unique IP address for VLAN 101, how can all the clients get the correct default gateway from DHCP?

If I configure the switches as a cluster, does this affect the way VLANs are addressed or managed?

Reply to
bobneworleans
Loading thread data ...

Sounds like what you need is to run HSRP, one virtual IP address shared by all the switches in the group, check the cisco manual below to see how to config.

formatting link

Reply to
die.spam

As I understarnd HSRP, it's used when you need a backup device ready to take over if the primary device fails. In my situation, I need the ports on all three switches to be on all the time. No backup device is needed in this application so HSRP does not apply.

I want to know how to configure the virtual interface on switches hosting a common VLAN. Do they all need an IP address? If so, does that address need to be unique on each virtual interface?

Reply to
bobneworleans

I think you need to give us a more complete explanation of your requirements.

You won't be able to use the same address on three seperate switches. Give them different addresses. Chose one switch to do dhcp. Or of course two with non-overlapping ranges - then you might have additional resilience but some more management complexity.

You need an IP address on a VLAN for two seperate purposes. You can do one of these, both of these or none of these depending on your requirements.

  1. To do IP routing.

If you are not doing IP routing then you don't *need* an address at all since the switches will forward the traffic at Layer 2.

  1. To permit remote switch management.

Please clarify what you need to do.

I have never fancied clustering much. Stacking of course is a different matter due to the high speed bus.

Reply to
bod43

Hello Bod43, Your explanation helped me a lot. Thanks!

Here are some parameters of the installation:

600 clients 4507 in MDF 20 3550 switches on 4 floors IDFs wireless network

Here's what I plan to do. Does anything here go against standard practices?

  1. Set up a VLAN for each floor plus wireless plus management.
  2. All routing between VLANs will be done by the 4507.
3, Set up every switch with the management VLAN plus floor vlan (or wireless vlan).
  1. Set up unique virtual addresses for each virtual interface on their own subnet.
  2. The 4507 will have a virtual interface for each floor VLAN addressed as 10.1..1. All DHCP default routes will point to virtual interfaces on the 4507.
  3. Assign each port (access) to the appropriate vlan.
  4. Trunks will include all necessary VLANs and exclude the rest.

I have some more questions: The servers need to be reachable by clients on all floors. Should they be on their own separate VLAN? How will DHCP know which scope to use when assigning IP addresses to clients from every floor? Do I need a helper address configured on the VLAN virtual interface for each floor switch so client traffic will reach the DHCP server? Is it acceptable to use vlan 1 for management? Is a native vlan needed? If so, what traffic (other than management traffic) will it carry?

Reply to
bobneworleans

ok - so for the "user" vlans, only the 4507 needs an IP address within the VLAN, and that will be the default gateway.

each 3550 needs its management IP address in the management vlan (the default vlan is 1. since the 3550 is operating as layer 2 they do not need IP addrsses in other VLANs. if you use that for management please be aware that any switch where the config is not applied will have the users "dropped" into vlan 1.

it is years since i worked on 3550s, and i cannot remember if you have to put management in vlan 1 or if you can move it. either way some of the cisco overhead protocols use vlan 1.

cisco is really good for docs (although they keep reorganising the web site, so finding them can be a problem)

there are some cisco best practice designs around that may help. note cisco always show 3 layers of switches and dual units for resilience. you only need 2 layers. duplicates are about increasing up time. there is no reason you cannot plug your servers direct into the core switch if the central port count is sufficient.

formatting link

1 thing to watch is high port count GigE cards for the 4507 may be contended depending on the cards and supervisor. If you contend here you are saving a bit of money in the centre, but cutting heavily into the overall capacity of the system....

and 1 design guide for high availability campus (main difference is duplicated central switches)

formatting link

you only need a virtual address if you want to use HSRP and dual core switches - but it doesnt do any harm to do it, and it lets you add a

2nd core for resilience without changing address plans later.

depends, but generally yes, in case you want to tinker with the core of the design later, or put the servers on separate switches.

the DHCP "helper" fills in source subnets as it forwards the address to the DHCP server.

Yes

yes - read the best practice stuff.

might depend on IOS version?

ideally keep everything else off there (although the performance issues that triggered that recommendation have mainly gone away as processors got better). isolating management makes filtering out access to it easier.

good luck

Reply to
Stephen

Not with ipv4. If you are building three subnets, you should address each differently, the switch would take an address on all three if it was providing a gateway, and the gateway address would be in the same subnet as the end hosts.

(I am assuming here that the three VLANs are not in different VRFs, if so all bets are off, but you would have mentioned VRFs if you were using them, right?)

The dhcp server would have three pools, one for each subnet, normally listen ln all three VLANs, and serve up a different gateway address to hosts in each subnet.

Andy

Reply to
Andy Davidson

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.