central IP address distribution, how do you

[rebelwireless]

I'm curious as to how everyone is handling IP addresses centrally (if you are). I'm still trying to decide a direction to go from my basic routed network today, where I have CIDR subnets at each tower.

Adiarw did a nice write-up on how he does it with bridged VPLS back to the core.

Anyone else have any clever methods of handling this with a central IP pool and dynamic routing, and thus a way to distribute these addresses without wasting IPs by subnetting?

note, I'm aware of and have run PPPoE servers that handle this via making each CPE IP available on the router and that allows routing protocols like OSPF and RIP to distribute it, making it easy to add /32 IP addresses wherever. I used 'tiks usermanager and AD/RADIUS for this before, but I'm not really interested in going back to PPPoE.

The weakness I see in Adair's method (for me) is that it ties you to a single head end as the client is bridged from the CPE's VLAN all the way back to the core. I have a primary head end and then a DSL and a Cable connection at 2 other points on my network for failover. If the backhaul fails, I would have to have a duplicate VPLS endpoint hidden behind a very deep OSPF cost so that the tunnels would re-converge on the failover links. That also means that I can't add specific routes out these backup connections like I do now, for instance routing windows updates to the cable connection.

any random thoughts or ideas appreciated :)

[sirhc]

My WISP is old fashioned.

Everyone has their own valid subnet (/30 or larger for some commercial) assigned to the interface/VLAN that their AP is on and just plain old OSPF/BFD around the rings and BGP on the edge.

We keep track of IP's in a 15 year old word document (date originally created but is updated to MS WORD 2010 I THINK) - LOL - SAD

[rebelwireless]

I'm not as worried about keeping track of IPs, just not wasting them. I'm pulling data into a table right now for host and all routes so I can see which routes are at 0 distance aka local etc, but it kills to have to smoke a /26 at a micro pop for 35 customers.

I've considered to IP unnumbered routes, but that requires static routes for those addresses which adds a bunch of maintenance overhead.

I like the VPLS or EoIP tunnels to the core, but that limits my routing options. Right now I've got a single bridge on each POP that all APs sit in. Client isolation and split horizon keep clients separated.

The simplest option is to have every client on layer2 on a single DHCP server, backed by radius so that the DHCP server can create queues automagically and management is simple. But that means either all bridged w/ *stp (or SPB etc etc), or EoIP/VPLS tunnels bridged back. Which again kills my routing options. I could easily script to copy all VPLS tunnels from the core to a backup point for failover and just put in a high path cost for OSPF which handles the redundancy part, but can't route out of the bridges.

I'm all mikrotik routers at this point and don't really plan on changing that anytime soon. I'm investigating NATing out of the bridge right now. Maybe I can do this at the POP on the VLAN to VPLS bridge from Adiar's setup. maybe.

[wayneorack]

I have been reading up on PowerCode. Their recommended method is to use one DHCP server and do DHCP relay at each router in a OSPF network.

[rebelwireless]

I have been reading up on PowerCode. Their recommended method is to use one DHCP server and do DHCP relay at each router in a OSPF network.

that's essentially the same effect as I'm getting with discreet dhcp servers, just moves the pools back to the core.

[rebelwireless]

after some research, it looks like a big benefit to dhcp-relays is that 'tik will create queues from radius at the head end dhcp-server. so even if I do waste some IP addresses, I at least get queues automatically created at the head end where the CPU horsepower is.

Maybe I create a multi-level precedence and have top-level towers do DHCP-relay and the subordinate micro-pops bridge a VPLS back to it's master pop. less waste, still routing tower side. no micro-pops have real backhauls, just their trunk to the upstream full-tower. I do like the VPLS over just bridging VLANs, OSPF+BFD solves issues with STP not unfailing a path.

[LRL]

I've been playing with DHCP relay more on the AP side. I create a /30 from our tower router to the AP, place the AP in router mode and make it the clients gateway. The AP relays DHCP requests back to the router. So far this appears to be the most efficient way of handling this.

I allocate a public and a private /27 to each ap and if that fills I'll allocate another /29 or /28, but i prefer to keep each ap to >30 customers.

Chris gave me the idea of using the AP in this way. The discussion was about reducing the need for FC and by george I think we have a winner.

[mhoppes]

We run a centralized network (Chris close your ears) with routers on both ends !!!! of a flat network. You can run VRRP + BGP to allow network traffic to egress on either end of your network. You can do the same with VRRP + your backup connections.

[sirhc]

We run a centralized network (Chris close your ears) with routers on both ends !!!! of a flat network. You can run VRRP + BGP to allow network traffic to egress on either end of your network. You can do the same with VRRP + your backup connections.

[rebelwireless]

VRRP between distant routers! sounds like a terrible perversion ;)

The downside of a flat network is having to work around excessive broadcasts with clever bridging etc, and there is no routing. A single gateway or the aforementioned perversion of VRRP.

Having the radios be the DHCP relay is really no different than a VLAN per AP and DHCP relay on the router.

It comes down to solving the wasted IP addresses without giving up routing. an IP pool per AP is the opposite of that. wasting a router, network, and broadcast IP for each additional AP. Bridging all the APs together saves (n-1)*2 IPs w/ n=number of APs. Bridging all the way back to the core is the extreme example saving the same formula of IPs, but network wide, plus additional savings for PTP links.

Here is my current structure.

Each tower starts life with a public /26 or /27 (micropops often) and gets additional space as needed. I use a public /30 for PTP links. Each AP is on a VLAN (typically QinQ to a toughswitch) and that VLAN is bridged in an AP-Bridge with split horizzon and client isolation enabled. DHCP runs directly on the POP's router.

what I'm considering for a change after weighing so many options w/ pros and cons.

each POP remains configured with APs in a split horizon bridge with a single ip pool for connected clients (per POP). Radio management moved to VLAN. <-(this is partially in place, some routers are rb493 so dont have MTU for VLANs, these are being replaced.)
DHCP moved to core and DHCP relay setup at POPs. RADIUS used for DHCP authorization and accounting, as well as queue automation.
OSPF+BFD distributes all routes. Backup links set to high OSPF cost.