Subnetting public /22 with PPPoE and OSPF

Hi all,
We are currently carving up out public /22 into smaller subnets with a /29 being the smallest. We have a lot of small towers with PPPoE servers at most of them running OSPF. The public subnets are in stub areas and in area ranges so the routers are ABRs and only advertise the subnet and not the individual /32s. This works perfectly.

I used this as a guide:
https://wiki.mikrotik.com/wiki/OSPF_and_Area_summaries
http://forum.mikrotik.com/t/ospf-backbone-area-another-area-multiple-pppoe-servers/94306/1

However, as you would expect we still have to try and magically predict what size of subnet to allocate to each tower and we’re wasting IPs. So, it seems that one alternative is to change to allocating customer IPs out of one big pool and adverstising all the /32s. Not what I want really or is this not much of a problem at all? We’re using RB3011s as PPPoE servers.
Any opinions anyone?

Thanks for reading

Sounds like a good candidate for VPLS and a central PPPoE server exercise.

A lot of people on the forums use this centralized model, the sad part is I’m pretty sure the advertisement is centralized on the PPPoE server so all traffic backhauls to the central PPPoE server. This may not be ideal for your network.

That said, I don’t imagine their is a whole lot of traffic that stays contained within a single tower anyways.

The alternative is to ditch PPP all together and go to a different management style. The problem is your back-end is likely built on the user portion of PPP. I’m not aware of a commercial product that manages the CPE directly to toggle access but it could be coded with little difficulty. Place the user on a remediation network for unpaid bills or on the normal network if they are current. Could be tied to 802.1x or just MAC of the WiFi interface of the CPE. As long as the end-user doesn’t have a mechanism to mess with the MAC address and/or certificates on the CPE you’re fine. Not like PPP is an overly difficult protocol to sniff and attack so “security” from PPP shouldn’t be implied.

Could you elaborate a bit more please?

If you are talking about the VPLS w/a central PPPoE server option, you need a way to send layer 2 to the client device so it can perform PPP to get connected. You do this by using VPLS to provide layer 2. The CPE or sometimes the tower AP connect back to the VLAN that the PPPoE server is running on and that layer 2 segment is bridged down to the client device.

This creates a very large layer 2 domain in some networks and can significantly expand your problem domain when troubleshooting some issues. An alternative is to use EoIP to tunnel your layer 2. Some users have reported less stability and scalability with EoIP over VPLS.

Thanks for the reply, I thought that might be what you were hinting at. I’ll have a think!

NTB

Well, if you want to use /29 as a base pool size and don’t want to get painted into a corner because some tower is much more popular, then what you could do is allocate your initial /29 blocks sparsely and then simply increase to /28 at sites requiring it, then /27, etc.

I’d also recommend that if your network covers a large enough geographic region, or if you plan on getting redundant internet transit links in different locations that you make these pools remain within aggregateable blocks /24 or /23 size if possible. This way, you can have some options down the road on how to do BGP policy routing, etc.

Amusing of course that that adjacent blocks hasn’t been assigned to a different tower :slight_smile:

That’s why I suggested a sparse allocation scheme when making the initial /29 assignments.

e.g.:

10.0.0.0/29 = tower 1
10.0.2.0/29 = tower 2
10.0.1.0/29 = tower 3
10.0.3.0/29 = tower 4
10.0.0.128/29 = tower 5
etc…

Although, if it were me, I’d do sparse inside the lower /23 and save the upper /23 as free space because you never know when you may need a larger block for something.