Hello!

This is my network topology:
I have 4 routers and a radius server. On every router we have a PPP server which authenticates customers with radius server and gives them an external IPv4 address from our IP pool. I want to route the external IP addresses with IBGP and internal equipment with OSPF and I have the following questions:

1 - Do I need to add a filter for OSPF to not announce our external IPs so the other routers can get them only from IBGP? Is it the right way?
2 - PPP server gives /32 addresses, is there any way to automatically sumarize them or do I need to create a separate pool for every router? We have about 3.000 customers connected. I think it's will be a problem to keep them all in routers memory as /32 and the network is not growing up proportionally so I have more customers on some routers.

I have never done this before so I feel a little bit confused and I don't know if I'm on the right way.

Regards, Anton.

You should use OSPF to route your public IPs to the proper PPPoE server as well.
The purpose of iBGP is for multiple border routers to share their information amongst themselves so that your network can come to a consensus on its exterior routing policy.

In OSPF terms, your goal is to configure the PPPoE concentrators as "ASBR" routers - i.e. routers which inject external routes (in your case, the /32 route for a customer with a live IP address) into OSPF. These /32 routes will be distributed throughout your network in OSPF. BGP will only need to signal the existence of your main IP prefixes (/24 or shorter) into the global internet routing table. Once packets reach your border router, they will follow the guidance of OSPF to reach the specific destination within your network.

Think of BGP routing like airline routing - it basically gets you to whatever city or region you're interested in, and OSPF would be a taxi / uber / rental car / shuttle / metro transit / etc. which gets you through the local streets to reach your actual destination (say a particular hotel you're travelling to).

iBGP would be like going to airport A and looking at the flights from that airport, as well as flights from airport B in the same city, and then deciding that a better flight is available at airport B.


As for the route aggregation, you can (and should) group your public IP assignments by which router they're on, and inject the pool's prefix into OSPF (e.g. 192.0.2.32/27) and then individual customers on this router can be assigned an address of 192.0.2.32 - 192.0.2.63

You can filter the redistributed static routes using the ospf-out filter on the ospf instance itself.

You should use OSPF to route your public IPs to the proper PPPoE server as well.
The purpose of iBGP is for multiple border routers to share their information amongst themselves so that your network can come to a consensus on its exterior routing policy.

In OSPF terms, your goal is to configure the PPPoE concentrators as "ASBR" routers - i.e. routers which inject external routes (in your case, the /32 route for a customer with a live IP address) into OSPF. These /32 routes will be distributed throughout your network in OSPF. BGP will only need to signal the existence of your main IP prefixes (/24 or shorter) into the global internet routing table. Once packets reach your border router, they will follow the guidance of OSPF to reach the specific destination within your network.

Think of BGP routing like airline routing - it basically gets you to whatever city or region you're interested in, and OSPF would be a taxi / uber / rental car / shuttle / metro transit / etc. which gets you through the local streets to reach your actual destination (say a particular hotel you're travelling to).

iBGP would be like going to airport A and looking at the flights from that airport, as well as flights from airport B in the same city, and then deciding that a better flight is available at airport B.


As for the route aggregation, you can (and should) group your public IP assignments by which router they're on, and inject the pool's prefix into OSPF (e.g. 192.0.2.32/27) and then individual customers on this router can be assigned an address of 192.0.2.32 - 192.0.2.63

You can filter the redistributed static routes using the ospf-out filter on the ospf instance itself.

Thank you.

How do I seperate my customer prefixes from the backplane without using filters. I thought ibgp could be used to carry customer prefixes while ospf takes care of the backplane on the network. iBGP will know how to route out customer prefixes recursively thru ospf?

Hi Guys,

Still looking to carry my pppoe with ibgp. Anyone who's tried this? How do you summarize the /32s? I suppose redistribute connected routes into bgp and route filter what you dont want bgp to advertise. But then how to supernet the many /32s?

Any help much appreciated.

Still looking to carry my pppoe with ibgp. Anyone who's tried this? How do you summarize the /32s? I suppose redistribute connected routes into bgp and route filter what you dont want bgp to advertise. But then how to supernet the many /32s?

Hi davey,
I have the same problem.
We just migrated from OSPF routing everything (backbone + customer's /32) to this situation:
OSPF only routes backbone loopbacks and management IP (BTS loopbacks, radio link management, etc.) --> redistribute connected=no, redistribute static=no
BGP (with private AS) routes customer's IP or subnets internally --> redistribute connected=yes
eBGP is used on the edge, of course, to announce public subnets

OSPF routes were about 4000, while now they are about 200.

Unfortunately, I found no way to group (summarize) the customer's /32, because they are assigned from radius from a centralized pool and I cannot afford the subnetting of my public subnets (we have many BTS and we would waste a lot of IPs. Also we should assign the blocks statically and this is not acceptable for easy management).

Massimo

Hi Massimo,

Thanks for your response. So are you filtering out the transit and management subnets from ibgp after redistribute connected=yes? How is your radius creating the connected /32s for customers? You are using some tunnel? Or using radpool module in radius? And are all your tower routers pppoe NAS servers?

Thanks,
Dave

Thanks for your response. So are you filtering out the transit and management subnets from ibgp after redistribute connected=yes? How is your radius creating the connected /32s for customers? You are using some tunnel? Or using radpool module in radius? And are all your tower routers pppoe NAS servers?

Hi Dave,
the backbone is composed by routers with Loopback IP, running OSPF.
OSPF networks include loopbacks and point-to-point links (/30) only.
OSPF does not redistribute anything (redistribute-* = no). Of course, the loopbacks and PtP /30 are part of backbone and you don't have to filter them (actually, you couldn't even filter).

Every backbone router has a BGP session with a Router Reflector (a CHR machine in my case), itself is part of the backbone and visible through loopback IP.
Every router announces via BGP the connected routes (/routing bgp instance ... redistribute-connected=yes).
Connected routes (in my case) are the management IPs for radio links, and the customers subnets (mostly /32).

Only on the Route Reflector I have some Input filters in order to not duplicate the backbone networks. The most importants are:
Do not accept transit links (/30 already present in OSPF)
Do not accept loopback IPs (/32 already present in OSPF)

My radius is RadiusManager (based on freeradius). It can choose a free IP from a public IP pool (we have several subnets).
Every BTS router authenticate the PPPoE local user by sending the request to remote radius. When radius replies OK, the router installs the new /32 route and announces it via BGP.

We don't use any tunnel because we have a decentralized PPPoE system (yes, every tower router is pppoe NAS server with remote radius accounting).
Of course, if one tower serves lot of customers, you will have to put a more powerful router. e.g. we use from RB450G to CCR1009.

I know that some people follow different phylosophy (VPLS tunnel to centralized PPPoE server). Both solutions have advantages and drawbacks. I'm happy with this one.
It's just plain IPv4 routing. Very easy to troubleshoot using traceroute.

Ciao,
Massimo