cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2078
Views
5
Helpful
12
Replies

Running out of internal IPs

julito4589
Level 1
Level 1

I'm running out of internal IPs in one of our main production subnets.

My options at this point are:

1. Add another internal IP subnet and ensure routing between subnets works

OR

2. Change subnet mask in the existing subnet (i.e. go from /24 to /23 or /22)
 

Right now I'm going for option 1. Option 2 requires changing a lot of configurations (e.g. access lists, firewalls, subnet masks in IP assignments, etc) throughout the network to ensure the new scope works everywhere.

Am I approaching this correctly?

 

Some info about my environment:

- Cisco 3800 is at the core of the network and deals with all inter vlan routing. It also currently acts as the gateway for internal clients.

- Cisco WS-3560X connects to the 3800. All clients connect through this switch (either directly or through second-tier switches). Routing is NOT enabled on this switch (at some point in the future I'll enable routing so this switch does the inter vlan traffic and it doesn't have to traverse to the 3800, but that'll take some planning).

- The interface in the 3800 that I'd attach the new subnet to has a few subinterfaces configured

C3825_2#sh ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         10.0.0.2      YES NVRAM  up                    up
GigabitEthernet0/1         unassigned      YES NVRAM  up                    up
GigabitEthernet0/1.1       10.0.2.10       YES NVRAM  up                    up
GigabitEthernet0/1.6       192.168.70.1    YES NVRAM  up                    up
GigabitEthernet0/1.7       192.168.90.1   YES NVRAM  up                    up
GigabitEthernet0/1.8       192.168.100.1   YES NVRAM  up                    up
GigabitEthernet0/1.9       192.168.110.1   YES NVRAM  up                    up

 

In order to achieve option 1, I'd be adding a subnet thus:

interface GigabitEthernet0/1.2
 encapsulation dot1Q 1 native
 ip address 10.0.3.10 255.255.255.0
 ip access-group 101 in
 no cdp enable

 

I'm going to need that the subnet in

GigabitEthernet0/1.1       10.0.2.10      

connects with no restrictions with the new subnet that I'm adding.

Other than tweaking access lists to ensure that all traffic between these two flows with no restrictions, do I have to do anything else in the router to achieve this?

thanks for any input.

1 Accepted Solution

Accepted Solutions

Jon Marshall
Hall of Fame
Hall of Fame

I would go with the same option as you ie. adding a new vlan/IP subnet.

I would also, as you mention, look to move the routing to the 3560 because you are limiting the bandwidth between vlans to the speed of the 3800 interface at the moment.

In terms of configuration what you have posted is correct although there is no mention of DHCP (assuming you need it).

If the 3800 is doing the DHCP then you will need a new DHCP pool configured.

If there is a dedicated DHCP server then you would need to add an "ip helper-address x.x.x.x" command to the subinterface.

Edit - if the trunk from the 3560 to the 3800 is only allowing the current vlans then you will also need to add the new vlan to that.

Jon

View solution in original post

12 Replies 12

Jon Marshall
Hall of Fame
Hall of Fame

I would go with the same option as you ie. adding a new vlan/IP subnet.

I would also, as you mention, look to move the routing to the 3560 because you are limiting the bandwidth between vlans to the speed of the 3800 interface at the moment.

In terms of configuration what you have posted is correct although there is no mention of DHCP (assuming you need it).

If the 3800 is doing the DHCP then you will need a new DHCP pool configured.

If there is a dedicated DHCP server then you would need to add an "ip helper-address x.x.x.x" command to the subinterface.

Edit - if the trunk from the 3560 to the 3800 is only allowing the current vlans then you will also need to add the new vlan to that.

Jon

Jon,

Thanks for the input and for pointing out the dhcp helper piece.

The trunk configuration in the 3560 doesn't specify the vlans going through it, so I won't have to add it there. Although for control purposes, I should start limiting what vlans are trunked there.

No problem.

One thing I didn't notice (until now) is that the configuration for your new subinterface that you posted is using vlan 1 and saying it is the native vlan ?

Is this really what you want to do ie. usually you would use another vlan and you wouldn't put any end devices in the native vlan.

Or is that just an example ?

Must admit I assumed because of the interface number it was vlan 2, I should have looked more closely.

Sorry for not spotting that sooner.

Jon

Well, actually, one of the main internal VLANs is on the native vlan.

Since the new subnet is intended as an extension of that, I was thinking of keeping it on the native vlan, until I get to change them both. But now that you mentioned it, I could just add this new subnet on a different vlan.

Another point that I hadn't mentioned and that now I'm questioning is related to the new subnet scope. I was planning on adding it as a /22 or /23. This however will potentially make the routing tables on the 3825 bigger and this can have a performance effect. Should I be worried about this at all? There are only 9 vlans configured here and six /24 subnets for everything else. I'm assuming that this model cna handle this load, but some confirmation would be great.

Not sure I understand.

If one of the existing vlans is on the native vlan already what do you mean by extend it.

Is there a subinterface already for that vlan ?

If there is and by extend you mean use another IP subnet within the native vlan then you don't do that by creating another subinterface. You would have to add a secondary IP to the existing subinterface.

Perhaps I am not understanding what you mean by extend.

In terms of the new subnet scope your configuration shows a /24 but you are saying it will be larger ?

I'm not sure what you mean in terms of the routing table ie. it will simply add one more connected route for that subnet (however large) and a 3800 can easily handle this.

Perhaps you can clarify exactly what it is you are trying to do. I assumed it was the addition of a new vlan  and IP subnet but I'm not sure now.

Jon

Sorry if I made things for confusing.

Is there a subinterface already for that vlan ?

YES.

Below see the configuration for the interface.

Subinterface g0/1.1 is the existing subnet. It's on VLAN1.

C3825_2#sh ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         10.0.0.2      YES NVRAM  up                    up
GigabitEthernet0/1         unassigned      YES NVRAM  up                    up
GigabitEthernet0/1.1       10.0.2.40       YES NVRAM  up                    up
GigabitEthernet0/1.6       192.168.70.1    YES NVRAM  up                    up
GigabitEthernet0/1.7       192.168.90.1   YES NVRAM  up                    up
GigabitEthernet0/1.8       192.168.100.1   YES NVRAM  up                    up
GigabitEthernet0/1.9       192.168.110.1   YES NVRAM  up                    up

 

I used the "extend" word incorrectly. In this case, I need to add more internal IPs on the network. Hence the addition of another subnet. Based on what you're saying, I'd simply have to add this line to the existing subinterface configurations

ip address 10.0.3.40 255.255.255.0

So the ending configurations on that subinterface would be thus:

interface GigabitEthernet0/1.2
 encapsulation dot1Q 1 native
 ip address 10.0.4.40 255.255.255.0
 ip address 10.0.3.40 255.255.255.0
 ip access-group 101 in
 no cdp enable

Can you confirm?

Regarding the scope, I know I put in my original example a /24, but I was considering a bigger subnet, so that I don't have to deal with this again for a while. You confirmed what I was thinking though and the 3825 should be able to support this without issues.

 

You can do it like this although I have never used secondary IPs on subinterfaces but I can't see why it wouldn't work.

However I wouldn't do it like this. Secondary IPs in most cases are more of a short term fix than anything else and in your case I can't see the need for them.

What I was assuming was that you create a new vlan on the switch, then using your new IP subnet you create a new subinterface on the 3800 and allocate it an IP from that subnet.

As long as your acl is not blocking traffic between subnets you should be fine.

Note also that if your DHCP server is on a different subnet you also need to allow this in your acl.

It's really up to you as to which you do.

Edit - if you do create a new vlan then you would need to allocate ports into that vlan for the relevant clients. If you use secondary IP addressing then you wouldn't (assuming they are already in the correct vlan).

Jon

 

Hmm. Now I am confused.

I intend this to be a solution that will be in place for a while. Based on your last response, using a subinterface with two IP's is not necessarily used long term.

So, should I go back to the initial approach, namely:

1. create a new subinterface and assign the IP address from the new subnet (scope of, say, /23)

2. Modify ACL's so traffic between existing subnet (i.e. 10.0.2.0/24) and new subnet (i.e. 10.0.3.0 /23) is allowed.

 

If this is the best long term approach, should I put the new subnet in its own vlan and eventually put the existing subnet on this same vlan?

Sorry for going in circles about this.

No need to apologise, this all started because I didn't read the original question correctly :-)

Using secondary IPs is more often than not a temporary fix rather than a long term solution. It is useful when you are changing the IP subnet within the same vlan and also if you need to extend the scope but still need all the devices in the same vlan.

But saying it is temporary doesn't mean you can't use it ie. it's not suddenly going to stop working.

However from your description it doesn't sound like you need either of the above. You just need more IP addresses because you are running out.

So as long as the new devices don't need to be in the same vlan (and I can't see anything from what you have said so far that suggest they do) personally I would go down the new vlan/IP subnet route.

I think where the confusion has come in is, as I said to CF above, I assumed a new vlan as well as an IP subnet because you posted a new subinterface configuration whereas you were only talking about a new IP subnet in an existing vlan.

In terms of the longer term, again unless you need these devices to be in the same vlan, I would stick to the one vlan, one IP subnet design. That is by far the most common approach and it works well. There is rarely a need to have multiple subnets allocated to the same vlan.

Bear in mind also that a vlan constrains broadcasts. Having multiple subnets per vlan increases the number of broadcasts within that vlan, simply because you have more clients. Not necessarily a problem but it does depend on what applications you are running.

But like I say either would work so it really is up to you.

If you do decide to go down the new vlan/IP subnet route then yes you would do as you suggested but you would also need to add the following steps -

1) add new vlan to the 3560 switch

2) allocate ports for the end devices into that vlan.

Sorry for all the confusion. If there is anything that is still unclear or you want to discuss further please feel free to post back.

Jon

 

Cisco Freak
Level 4
Level 4

Hi John,

Instead of introducing a new sub-interface, why can't we change the subnet mask of existing sub-interface from /24 to /23. That should make the subnet large enough,,right?

CF

CF

You can do that but as pointed out in the original question you then need to do other modifications to acls, firewalls etc.

It is much easier to simply create a new vlan/IP subnet and route that off the 3800.

I think the confusion at the moment is that I assumed a new vlan and IP subnet whereas I think the question was only talking about a new IP subnet within an existing vlan.

Just trying to clear that up at the moment :-)

Jon

I got your point!!

CF