Beginner's guide to adding an IP range

[TheSecondCity]

Hey folks,

Please direct me to the right location if it's been answered before (because I'm sure it has).  My Google skills and rudimentary searching on this message board are failing me miserably right now.

Our existing IP range is filling up rather quickly, and we need to expand to an extra range.  We have a 2910al-48G with only a single VLAN (very simple setup).  After some searching, I came across a few posts telling me to add another IP to this VLAN, enable routing, and set hosts on each network to look toward the ProCurve as the new default gateway (I've consulted with a few people, and we decided to go this route rather than change our subnet mask).  Of course, a lot of that assumed quite a bit of my networking knowledge, which is sadly limited to dealing with one subnet at a time!  Is there a step-by-step (with CLI entry lines!) that can walk me through such a simple thing as this without making assumptions on my skill level?

I got lost down a rabbit hole of multiple forum posts earlier today and got half of things working before accidentally borking Internet access, necessitating a quick revert to backed up settings to bring our systems online again.  (yes, I know...please forgive me for doing things on a production network...the changes looked rather straightforward, but I must have missed some critical pieces).

Thanks again, all!

[paulgear]

Things you will need to do:

• Make sure you have solid connectivity already.  Don't go into this with a network that's partially working.  Can you ping the default gateway from the switch?  Can you ping your servers and workstations from the switch?
• Enable IP routing on the switch:
  ip routing
• Install a default route on the switch:
  ip route 0.0.0.0/0 1.2.3.4
  (Where 1.2.3.4 is the address of your current gateway)
• Add a new VLAN interface:
  vlan 2
    name "Name for newly-created VLAN"
    ip address 192.168.99.254 255.255.255.0
    untagged 1-5
    ip igmp
  This assumes that: your current VLAN is not VLAN 2, 192.168.2.0/24 is your preferred new range, you want the switch to be smart about multicasts, and you want ports 1-5 in the new VLAN.
  
• Change the default gateway on your end nodes to point to the switch's address for their respective VLANs.
• Add a route to your new VLAN from your old default gateway.  This part is really important: if you've got just a normal ADSL modem or something as your gateway, it will often assume that there's only one subnet behind it, and you'll have to go into the advanced setup or similar to add a route to 192.168.2.0/24.  Remember that routing is unidirectional, so to ping from one place to another you have to have correct routes to get there, and correct routes to get back.
• Confirm that you can still ping all the right places on your network.  Given a setup like the above, you should still be able to ping your old default gateway from your new VLAN.

At this time, I would strongly recommend setting up some conventions as well, for starters:

• use a consistent subnet mask (usually /24) on all VLANs
• the VLAN number is reflected in the IP address (e.g. VLAN 1 is 192.168.1.0/24, VLAN 2 is 192.168.2.0/24)
• the routing switch uses the same host bits in each VLAN (e.g. VLAN 1 192.168.1.254, VLAN 2 192.168.2.254, VLAN 3 is 192.168.3.254)

Once you go down this route (pun fully intended), you won't be going back, and you want to make life as simple for yourself as possible when looking at IP addresses and VLAN assignments.  You might want to consider splitting up the network based on role or location shortly afterwards, e.g. printers on one VLAN, workstations on another, servers on another.

Hope that helps!

[TheSecondCity]

Thanks very much for your assistance, Paul! Just to ensure I leave nothing to chance, let me try to work through this with you here, asking a few follow-up questions. I'm changing my IP listings below for obvious reasons, but wanted to use these in order to provide concrete examples for this run-through. My switch is just about as factory as you can get, but I think some of the work might already be done for me, here.

1. Connectivity: We definitely already have connectivity. The switch is at 192.168.10.246 and is pointing to our SonicWall (Enhanced OS) as the default gateway, 192.168.10.254. It's been like this for years, humming along (of course, this switch is newer, but the gateway & network addressing hasn't changed at all).
2. Enable routing: Understood. Do I need to think about RIP or ARP at all? I tried reading the switch manual, and got horribly confused when I hit those sections. With my simple deployment, should I ignore those for now?
3. Default Route for Gateway: I think this is already set. When I run the "show ip route" command, the first one listed is (Destination Gateway VLAN Type) 0.0.0.0/0 192.168.10.254 1 static. Also, the listing directly underneath it is 192.168.10.0/24 DEFAULT_VLAN 1 connected. Then, there are the default "reject" and "lo0" listings under that. Moreover, when running "show ip", I see Default Gateway listed properly and DEFAULT_VLAN shows the proper managment IP.
4. New VLAN: All my ports are already members of DEFAULT_VLAN. So should I create this other VLAN and also add all the ports to it, so they are members of both? In my case, I really just want to extend to a new IP range that will have all statically-assigned hosts (no need to span DHCP across this link). We'll be moving some statically-assigned stuff like printers and security cameras to this new network and need everything on it to talk back/forth with everything on the existing network (as well as the Internet). Let's assume I'd be using network 192.168.20.0/24 with managment IP 192.168.20.246.
5. Change Gateway: So this means that for all my hosts on the existing 192.168.10.0 network, I need to change the gateway from 192.168.10.254 to 192.168.10.246, correct? This includes all servers, printers, DHCP clients, etc...?
6. Add Route: Sorry, I might be misunderstanding. Are you saying I need to make a route on the SonicWall? And does that now point from the SonicWall's IP of 192.168.10.254 to 192.168.20.246 (the new VLAN IP) or to 192.168.10.0/24 (the new VLAN network)?
7. Confirm Ping: Understood.
8. Consistent Subnet Mask: Yep, definitely planning on that. No need for us to get fancy in our smaller network, and 500ish hosts segmented into 2 networks is plenty for us (for now). As we grow, we can add more networks/VLANs, as you outline here, correct?
9. VLAN Number: I see. So in my example, I'd rename DEFAULT_VLAN to be VLAN 10 and the 192.168.20.0/24 would then be VLAN 20.
10. Host Bits: I'm shoved into .246 right now on my existing VLAN, so I'd keep it the same on VLAN 20, then. Managment IPs would be 192.168.10.246 and 192.168.20.246, in this case.
11. Consider Segmenting: Yes, definitely.

This is the "baby step" for us to at least expand our addressable space and allow for more hosts. In the future, I'd definitely like to get slightly more complex with the deployment. We're actually working with a consultant now to help us with planning a more intelligent network structure, but I'm backed into a corner now by my bosses who want to install a bunch of new security cameras that I don't have available IPs for. So this is our "get it done" solution ahead of the proper network remapping. And yes, the consultant knows I'm doing this and suggested going down this route (yes, same pun intended!) rather than adjusting our subnet mask to allow for more hosts. He's only been contracted for the information gathering at this time, not the implementation, so it's on me to make this work!

Thanks once again for your assistance, Paul. It sounds like I'm on the right track, but some good work is ahead of me.

John

[paulgear]

Hi John,

Let's look at your points:

1. When i say check your connectivity, i mean check it again when you're just about to start. You don't want a cable that you or someone else knocked out 10 minutes ago wrecking your plan.
2. You shouldn't need to worry about ARP at the moment, although there may be some things down the track that would be worth looking at from a security perspective.  I wouldn't recommend using RIP at all.  It is an antiquated protocol that should have died long ago.
3. To confirm your default route, i would recommend pasting your switch config from 'show run' and your diagnostic output from 'show ip' and 'show ip route' into this forum topic. That way we can confirm for sure.  'show ip' has a section at the top which should clearly indicate whether or not routing is on.
4. Your PC, printer, camera, and (usually) server ports need to be in one VLAN or the other.  A port cannot be an untagged member of more than one VLAN.  You can have tagged VLANs, but they are usually used for switch-to-switch trunks or servers that must have an interface in more than one VLAN. Generally, your servers will just be untagged like PCs.  As soon as you say "vlan 20; untagged 1-5", ports 1-5 will immediately switch from VLAN 1 to VLAN 20, so you need to be ready for this by having the right things connected to the right ports.
5. The decision about whether to change the default gateway on the existing VLAN is a bit of a tricky one.  It should work either way.  The basic rule i try to follow is: whichever gateway the hosts in the existing network will communicate through more frequently should be their default. If they need to communicate through the other, the default gateway will send them an ICMP redirect to point them in the right direction.
6. As i said, this is the really important bit.  At the moment, your Sonicwall probably has only a couple of routes: a connected route for 192.168.10.0/24 and a default route heading out to the Internet.  It needs a route to 192.168.20.0/24 that points to the right gateway address, and that address must be reachable from one of its other routes, so the gateway for 192.168.20.0/24 must be the switch's address on 192.168.10.0/24: 192.168.10.246.  If you miss this, or get it wrong, nothing on the new VLAN will be able to access the Internet, and nothing on the existing network that uses the Sonicwall as its gateway will be able to get to 192.168.20.0/24.
7. ...
8. Yes, once you've added one VLAN in this, the rest will follow a similar pattern.  Make sure you plan for it now.
9. General best practice is to eliminate VLAN 1 (the DEFAULT_VLAN) and use the specific VLANs that you need.  If it were me, i would be inclined to take the existing config on VLAN 1 (including ports and ports) and move it to VLAN 10 so that your numbering is all consistent, and leave VLAN 1 unused.  But make sure you test it before going on with the rest of the work on VLAN 20.
10. I think that's preferable, but it is a matter of taste.  You may prefer to have the gateway for each VLAN on the same address in the VLAN, so if your Sonicwall is .10.254, then you might want the gateway to be .20.254.  My feeling is that it's better to have the convention that the IP follows a consistent pattern for each device rather than each role.
11. ...

You're on the right track. Have a good plan written down, test before and afterwards to make sure you're not trying to troubleshoot someone else's problem, and remember that small, incremental changes are better for stability than one big hit.

[TheSecondCity]

Thanks again for your time, Paul.  Unfortunately, the limitations of having 1 VLAN per port really hurt me here, as I have an older building with some difficult cabling.  Add in a nonexistent budget, and you can see where provisioning separate "downstream" switches from this one isn't very possible for me in order to provide two separate VLANs.

Is it inadvisable to apply two network addresses to a single VLAN?  I was able to do this on my first, botched attempt...I obviously missed a few steps that we've gone over already here.  Plus, I had no idea how to properly "enable routing", so I think I turned on RIP by mistake.  (of course, now that I've revived my switch to pre-botch status, that's turned back off).

The original forum post I saw this off of is: 

http://h30499.www3.hp.com/t5/LAN-Routing/HP-procurve-switch-2824-2-subnets-IP-address-on-the-same-switch/td-p/5602071

For curiosity's sake, what routing protocal is being used by the ProCurve?

Running configuration:

; J9147A Configuration Editor; Created on release #W.14.49

hostname "CORE Chicago"
module 1 type J9147A
ip default-gateway 192.168.10.254
vlan 1
name "DEFAULT_VLAN"
untagged 1-48
ip address 192.168.10.246 255.255.255.0
exit
snmp-server community "public" unrestricted
snmp-server location "Chicago"
no autorun
password manager
password operator

Internet (IP) Service

IP Routing : Disabled

Default Gateway : 192.168.10.254
Default TTL : 64
Arp Age : 20
Domain Suffix :
DNS server :

VLAN | IP Config IP Address Subnet Mask Proxy ARP
-------------------- + ---------- --------------- --------------- ---------
DEFAULT_VLAN | Manual 192.168.10.246 255.255.255.0 No

IP Route Entries

Destination Gateway VLAN Type Sub-Type Metric Dist.
------------------ --------------- ---- --------- ---------- ---------- -----
0.0.0.0/0 192.168.10.254 1 static 250 1
192.168.10.0/24 DEFAULT_VLAN 1 connected 1 0
127.0.0.0/8 reject static 0 0
127.0.0.1/32 lo0 connected 1 0

[TheSecondCity]

Annnd I *just* noticed that you were the one who replied to that query I linked to, above!  Does my use case fit this particular option (single VLAN)?

[paulgear]

The short answer is: yes, it's inadvisable, but if you don't have the option of dedicating particular ports to particular VLANs or changing your subnet mask, then you don't really have any choice in the matter. You can do it, but expect some latency issues down the track.

The steps are basically the same for this plan, only you would put the new IP address on the same VLAN instead of a new one. The same routing concerns with the Sonicwall apply.

However, you may choose to do the same on the Sonicwall side and simply add an extra IP address to the same interface. This would mean that you don't need to enable routing on the switch at all, nor would you need to add a new IP address. Just define the new address on the Sonicwall, set it to be the default gateway of the new range, and start using it.

[TheSecondCity]

Thanks again, Paul...you've been an invaluable resource.

I think I'll press ahead with doing things on the switch, since my SonicWall is a little taxed at this time and probably can't spare the CPU cycles for LAN routing.

What kind of latency issues should I be aware of?

[paulgear]

Nothing comes to mind, other than you want to have a plan to split into separate VLANs ASAP.

Note that you will still have to add a route to the Sonicwall no matter which way you go.

[TheSecondCity]

Certainly, I understand that the SonicWall side was one of the (major) missing pieces from my eariler, failed attempt.

Assuming I go forward with this, then, the steps can be boiled down to:

1) Turn IP routing on and create the new 192.168.20.246 address on the existing VLAN (what's the syntax for adding that IP, again?)

2) Create routes to the 192.168.10.246 and 192.168.20.246 addresses on the SonicWall.

3) Rewrite all my hosts on the 192.168.10.0/24 network to use 192.168.10.246 (the ProCurve) as the default gateway rather than 192.168.10.254 (the SonicWall).

4) Begin using the 192.168.20.0/24 network alongside the .10 one.  Set 192.168.20.246 as the default gateway on hosts using that network.

Assuming all this is done, both networks will be able to talk to eachother AND the Internet, while the ProCurve takes care of the inter-LAN traffic routing (not the SonicWall).  Is that assumption correct?

Also, just so I know the timeline...it'll take me some time to rewrite gateways on all my statically-assigned hosts.  Will they simply not have Internet connectivity between steps 2 and 3?  Or, since I'll have those routes configured in the SonicWall after step 2, will leaving the SonicWall's 192.168.10.254 address as gateway still allow those hosts to talk to others on the .10 network as well as the Internet (i.e., they just wouldn't be able to talk to .20 hosts until after I change the gateway)?  If I can keep .10 LAN and Internet connectivity on the old gateway, it allows me much more time to get the job done!

Thanks once more, Paul.