cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3263
Views
0
Helpful
4
Replies

Overlapping IP

BrendanGrieve
Level 1
Level 1

Hi All,

I'm hoping this is a simple one, but I'm a bit stuck for ideas.

I have the scenario of inherting a /21 public network, with the addresses fairly badly assigned in my opinion. Currently the entire /21 is allocated to a single flat network, which is made up of Colocation clients as well as our own Hosting equipment. If anyone wishes to purchase additional IP's, they are assigned them out of the /21, but really there is no security on what they get and they could potentially take over the entire /21 if they wanted. Addresses are allocated from all over the range.

What I would like to ultimately do is the following, and I'd really appreciate any input here: -

  • Allocate a /26 block for Colo 'Access IPs', and run this on a VLAN from the router. Then each Colo customer is allocated a single IP from this range, with their default route being the highest usable address in the block. This way if I run out of IPs there, and I can assign another /26 and start assign IP's from there. Potentially I could use private VLAN's to separate the clients but thats another story.
  • Should a Colo Client wish to purchase additional IP's, lets say a /28  block or /30, I reserve it and then route it to their Access IP.
  • Allocate a /26 block for our Hosting 'Access IPs', and run this on a  VLAN from the router. Similar to the Colo Access IP block, it allows me  to allocate single IP's to each of our own servers.Any of our hosting servers that require additional IP's will have a block reserved and routed to its respective Access IP.

This would properly split the network up, and I would be able to implement appropriate routing security etc. Plus its more interesting anyway.

However, and I'm sure you already guess my isse from the subject, I need to migrate from our existing setup to the above, and here I need some hints from those with experience.

I was hoping to do the following: -

  •   Maintain our /21 IP address on the router on the Interface (fa0/0), and consider this the native VLAN
  •   Add a subinterface fa0/0.101, with a /26 address for Colo Access IP, running over VLAN 101.
  •   Add a subinterface fa0/0.201, with a /26 address for Hosting Access IP, running over VLAN 201.

No address in either /26 is in use on the /21. And thus, through the use of proxy-arp, clients who are on the /21 native VLAN who try to access a client on either VLAN101 or VLAN201 are able to still work as the router will answer ARP's on their behalf, whilst the two VLANs will route correctly anyway. I can then slowly migrate everyone from the /21 into the proper routed networks, which is going to be a big big job.

I've managed to free at least 2 /24's within my /21 to start the migration, but unfortunately they will cause an overlap with the /21 address on the native VLAN. I was hoping the router would use the smallest match, but I can't bring the interface up on my test router as it complains rightly of an overlapping IP address (the /26 is overlapping with the /21, its parent).

Now, does my ultimate new design make sense (ie, is it a good design?) or do other hosting providers not bother routing smaller blocks to clients and just allocate from one large block like we currently do? (It would save on IP's this way, but has far less security IMHO).

And, if it does make sense, is there any way I can achieve it?

The router I am using to test this is a Cisco 3725, adv IP, 12.3

The relevant part of the config file is: -

interface FastEthernet0/0
description Trunk to Public Switch
ip address x.x.21.254 255.255.248.0

shutdown
speed 100
full-duplex
no cdp enable
!
interface FastEthernet0/0.101
encapsulation dot1Q 101
ip address x.x.16.126 255.255.255.192
no snmp trap link-status
no cdp enable
!        
interface FastEthernet0/0.201
encapsulation dot1Q 201
ip address x.x.20.62 255.255.255.192
no snmp trap link-status
no cdp enable

If I try a no shutdown: -

(config-if)#no shutdown
% x.x.16.0 overlaps with FastEthernet0/0.101
FastEthernet0/0: incorrect IP address assignment

EDIT:

After some experimentation, I think VRF will provide what I need. Assigning the two sub interfaces to different VRF RD's allows me to overlap. I just need to plug in some test machines to see if it actually works. For those who are interested, my new config is: -

ip vrf COLO_ACCESS_1
rd 101:1
!
ip vrf HOSTING_ACCESS_1
rd 201:1
!

interface FastEthernet0/0
description Connection to Public Switch
ip address x.x.21.254 255.255.248.0

speed 100
full-duplex
no cdp enable
!        
interface FastEthernet0/0.101
encapsulation dot1Q 101
ip vrf forwarding COLO_ACCESS_1
ip address x.x.16.126 255.255.255.192
no snmp trap link-status
no cdp enable
!        
interface FastEthernet0/0.201
encapsulation dot1Q 201
ip vrf forwarding HOSTING_ACCESS_1
ip address x.x.20.62 255.255.255.192
no snmp trap link-status
no cdp enable
!       

4 Replies 4

Mahesh Gohil
Level 7
Level 7

Hi brendan,

Look good to me using vrf. But i am having few clients who is having similar setup and i am briefing how they achieve this.

They take two blocks from us...

One /30 and other say /21.and how they use these blocks

1- /30 for connectivity between public switch and lan router.
2- /21 broken into different /24 subnets and used for different colocation services.

In your case you can break /21 into different /24 subnets and use one of the /24 (or you can further block is /30 is sufficient for this connectivity) for connectivity for public switch and rest for colocation services.

Why i am telling to break to /24 instead of /26 is because these are public IP's and to consider future requirement you can
ensure large block reserved.

I don't think you need to use vrf-lite. and also you can put null0 route with higher distance to have routing entry for whole of your /21 block.

Hope this helps to you

Regards
Mahesh

Hi Mahesh,

Thanks for your response.

I did think about assigning a /30 to each client, giving them their own VLAN, and then routing to them whatever size block they needed, but I was a bit concerned about losing 2 IP's per /30 per client. I'm still a bit torn between going this way, or going to a middle ground of assigning a block of /26 to handle 61 clients at a time and would love to hear any input from those who run service provider networks.

My current issue and the reason for VRF is that I cannot change the existing IP of the router, nor move any of our clients at the moment. So I need the full /21 to work pretty much how it does now without needing anyone to reconfigure default routes or change ip addresses. Then I can move everone one by one to the new networks and slowly shrink the legacy network down to nothing.

Ideally I'd just get another /21 and move everyone there, but thats not looking likely, so I'm trying to use what I've already got

Brendan

Hi,

If you can't change subnet assigned to clients then it is good practice to go for vrf at moment and

then you can go ahead with systematic plan step by step by considering future growth also.

Or you can take one /24 (or /30) for public switch connetivity and leave other assignment to its place, this way there will not be any overlapping of addresses.

anyway there are different approaches and it is upto you to prepare such plan with minimum affect on clients

Regards
Mahesh

I ended up going VRF Lite, with route leaking between the VRF's.

For anyone whos interested, my config I eventually ended up with is as follows: -

! Define VRF to hold our legacy network

ip vrf LEGACY
rd 100:1
route-target export 100:1
route-target import 100:1
route-target import 100:2
!

! Define VRF to hold our NEW network
ip vrf NEW
rd 100:2
route-target export 100:2
route-target import 100:2
route-target import 100:1
!

interface FastEthernet0/0
description Connection to Local Network (VLAN 1)
ip vrf forwarding LEGACY
ip address x.x.21.254 255.255.248.0
ip route-cache flow
speed 100
full-duplex
no cdp enable
!
interface FastEthernet0/0.101
encapsulation dot1Q 101
ip vrf forwarding NEW
ip address x.x.16.62 255.255.255.192
no snmp trap link-status
no cdp enable
!
interface FastEthernet0/0.201
encapsulation dot1Q 201
ip vrf forwarding NEW
ip address x.x.20.62 255.255.255.192
no snmp trap link-status
no cdp enable
!
!        
router bgp 1
no synchronization
bgp router-id x.x.21.254
bgp log-neighbor-changes
no auto-summary
!
address-family ipv4 vrf NEW
redistribute connected
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf LEGACY
redistribute connected
no auto-summary
no synchronization
exit-address-family
!

Machines in the LEGACY network can ping those in the NEW through the use of proxy-arp. Those in NEW can route to the rest of the network.

Brendan

Review Cisco Networking products for a $25 gift card