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
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 !
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.
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
! 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.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...