❓ what's the best solution for OSPF and PPPoE service

Hi friends :wink:
I’m now using a CCR1036 for my centralized PPPoE Service and using EoIP and static routes for all of my networks .
EoIP have a performance issue and always have problem with frame size .

Because of this I must convert my network from EoIP/StaticRoute to MPLS/VPLS/OSPF .
Diagram2.png
The most important things is this two :

  1. What’s the best way for OSPF routing and IP address assigning for R1 to Rx (for example if the routes are in range of 172.16.1.0/24 + )
  2. If the central PPPoE server router join the OSPF network , because of each pppoe session make a dynamic route then all of this routes will spread over the network .

if is possible make me a simple configuration for my network .
Thanks

EDIT :
My loop-back address range is must be 172.16.255.0/24 .
All of my point to point links between routers have /30 and /29 block size from 172.16.0.0/24 and 172.16.1.0/24 , this two is my network . (/29 for wireless links & /30 for direct Ethernet)

Please include more specific details (loopback IPs, point to point IPs, what IPs the PPPoE customers will receive, etc.)

If you’re using VPLS to replace EoIP, then your IP assignment / routing at the concentrator will not change. You’re just using VPLS to carry the PPPoE frames instead of EoIP.

The main thing to consider in this case is that your network nodes all need to have /32 loopback IPs injected into OSPF, and your VPLS sessions should be built to/from these addresses as the endpoints, and finally, these loopback IPs should be visible everywhere - i.e. don’t let them be aggregated into area ranges / summary prefixes.

In fact, the IP scheme of your transport network will not even come into play as far as your customers are concerned. They’ll see your concentrator as their first hop.

loopback address range is must be in 172.16.255.0/24 .
All of my point to point links between routers have /30 and /29 block size from 172.16.0.0/24 and 172.16.1.0/24 , this two is my network . (/29 for wireless links & /30 for direct Ethernet)

The important thing that is I don’t know how can I include just my network range to trough OSPF and not any other like PPPoE sessions from routing over OSFP .(I don’t see a example of this .)
I’m using the local IP of PPPoE profiles with 1.1.1.1 and the remote is public IP pool (146.146.46.0/22 , 155.155.55.0/24 , 179.179.79.0/22 and … )

OK, here is what I would recommend:

On your routers:

/routing ospf interface
add network-type=broadcast passive=yes
add authentication=md5 authentication-key=somesecretkey interface=someptpinterface network-type=broadcast
add authentication=md5 authentication-key=somesecretkey interface=someotherptpinterface network-type=broadcast
/routing ospf network
add area=backbone comment=“Loopback IP” network=someloopbackip
add area=backbone comment=“Point to Point connection to Router X” network=someptpsubnet/30
add area=backbone comment=“Point to Point connection to Router Y” network=someptpsubnet/30

On your core PPPoE router, the same thing, but also, do this for advertising your PPPoE customer subnet:

/routing ospf area add area-id=0.0.0.1 name=pppoe-area type=stub
/routing ospf network add area=pppoe-area network=somepppoecustomersubnet/23
/routing ospf area range add area=pppoe-area range=somepppoecustomersubnet/23 cost=default advertise=yes

On the other routers they will only get this ‘area range’ route rather than all the individual routes. The individual routes will only appear on your concentrator.

Thank you @mducharme .
PPPoE clients are internet users and they just use outbound of core router wan internet .

  1. With this type of PPPoE Users , do I need to add ospf area range too ?
  2. I must add all of my /30 networks each by each or can I add a /24 of all ? (network of point to point between routers)
  3. after prepare the OSPF I must remove my static routes ?

Best to add all /30’s individually rather than a /24 for all. You could do the /24 for all but it is the ‘lazy way’.

The area range prevents advertising to the OSPF Backbone the individual customer IPs. Even if you are doing masquerade, your customers will have individual private IP addresses, you need to summarize this pool with an area range, then the other routers will get the area range instead of individual routes for each PPPoE customer.

More detail below:

Sets default interface type to passive, so that you do not send hello packets to customers, important for security! The only interfaces that should not be passive are interfaces where you want to form neighbor relationships with other routers.

add authentication=md5 authentication-key=somesecretkey interface=someptpinterface network-type=broadcast
add authentication=md5 authentication-key=somesecretkey interface=someotherptpinterface network-type=broadcast

This ‘overrides’ the passive default for these two PtP interfaces connecting to your router, so that you can form neighbor with other routers over ptp interfaces, plus also adds security, so that a hacker cannot unplug your router and plug in their own and get an OSPF neighbor relationship forming, if they do not have the ospf auth key

/routing ospf network
add area=backbone comment=“Loopback IP” network=someloopbackip
add area=backbone comment=“Point to Point connection to Router X” network=someptpsubnet/30
add area=backbone comment=“Point to Point connection to Router Y” network=someptpsubnet/30

Those advertise the loopbacks and ptp subnets

On your core PPPoE router, the same thing, but also, do this for advertising your PPPoE customer subnet:

/routing ospf area add area-id=0.0.0.1 name=pppoe-area type=stub

That creates a second OSPF area for your PPPoE customers only

/routing ospf network add area=pppoe-area network=somepppoecustomersubnet/23

That advertises the PPPoE customer IPs, which would normally create a route for every PPPoE customer, EXCEPT then you add the following below:

/routing ospf area range add area=pppoe-area range=somepppoecustomersubnet/23 cost=default advertise=yes

That does the magic - the PPPoE area is summarized to the backbone as a single route rather than one per customer IP. You still get hundreds of OSPF routes but only on your core router itself, the other routers just get the area range.

1 Like

Yes after all that is working, you can safely remove your static routes, except the default route you should keep as a static route.

Loopback network must be my /24 class in my situation ? or /32 of routerid ?

add area=backbone comment="Loopback IP" network=someloopbackip

No, the individual /32 for that router. On each router you have to individually advertise the loopback IP. Best to set that loopback IP as the OSPF router ID as well.

EDIT: The /24 would work too but it is the ‘lazy way’, again better to advertise the individual route on each device rather than risk advertising something extra that you did not intend.

@ mducharme , one thing will remain about the security .
when we specify the OSPF interfaces with a security , always a dynamic passive interface with loopback interface will remain as none security ,
Is this make the OSPF insecure ?

Mducharme’s answers are spot-on, but I’d like to add one detail that I haven’t seen addresses in this discussion.

If you don’t define a network in OSPF on the core router which covers any of the local/net addresses of your PPPoE sessions, then none of those interfaces will be activated with OSPF, and therefore none of them will be advertised as links in OSPF (interior routes). If you’re still seeing them in OSPF, that means you have redistribute static / redistribute connected active on that router. This is a very common beginner’s habit to just turn those on and dump everything into OSPF that way. It’s a bad habit to get into and it’s not easily understood just why it’s bad.

In general, I’d recommend as best practices that you never use redistribute connected unless it’s just unavoidable for some reason (I can’t imagine many such scenarios), and don’t redistribute static routes except at the very edge of your OSPF domain - on access routers mostly - and in those routers, use a filter that allows you to explicitly label routes for redistribution or not.

In ROS, this would mean using the ospf-out filter. In Cisco, I like to use tags to flag routes that I want redistributed into OSPF. If I’m running a process OSPF 100, then I have a route-map which matches static routes with tag 100 so only those tagged routes get injected into OSPF 100.

In conclusion - if your core router has no redistribute connected, and no redistribute static, then you should have no trouble keeping the PPPoE sessions out of OSPF. In fact, when using MPLS, it’s even more important that your OSPF follow best practices and use native OSPF routes as much as possible vs. using a lot of redistributed E1 / E2 routes.

No. OSPF only forms adjacencies with directly-connected neighbors, and you do not have anything attached to a loopback interface, so no adjacencies can form there. Passive just means that the router doesn’t send hellos or listen to them. Since there is nothing else on a loopback bridge, there’s no way for any adjacency to form anyway, so there’s no danger in it being active. (unless you bridge that loop interface to something, but you shouldn’t do that anyway)

I agree, generally avoid ‘redistribute connected’ or ‘redistribute static’ unless needed on a router. Better to advertise as a regular LSA by listing it in ‘networks’ instead of an external LSA. You should list all individual subnets you want to advertise in OSPF in ‘networks’ rather than doing it via redistribution. By making ‘passive’ the default you can advertise these in ‘networks’ as regular LSAs without opening up potential security issues.

There is no security issue having passive interfaces without an authentication key. An authentication key should be used to add security on non-passive interfaces. Passive interfaces are already inherently secure due to the fact that an OSPF neighbor / adjacency cannot form on such an interface, and have no need for this security feature.

1. If I understand correctly , when using redistribute connected & redistribute static as “no” , then no need to specify the PPPoE pool as network stub at CoreRouter ? and this make no any different of security from adding it or not . ?

2. The last thing about the individually subnets in OSPF networks , If we comeback to the first diagram , all of routers in the path between R1 to R11 must have their /30 subnets in their OSPF networks list . but the question is the routers is not in the path need it too ? (for example : R4 need subnet of R10 to R11 too)

In your case this is correct, since your PPPoE concentrator is also the only core router. If you ever split these functions, as is more common, you would have to set up the stub area.

2. > The last thing about the individually subnets in OSPF networks , If we comeback to the first diagram , all of routers in the path between R1 to R11 must have their /30 subnets in their OSPF networks list . but > the question is > the routers is not in the path need it too ? (for example : R4 need subnet of R10 to R11 too)

You only add to ‘networks’ the locally connected networks to that router that should be advertised. The router needs to have an IP on that subnet as well in order for the network to actually get advertised. There is no need to add networks not locally on that router, since it will not have any effect if the router doesn’t have an IP on that network.

Missed the last part - it makes no difference in security b/c by making the interfaces default to ‘passive’, if you advertise it, your PPPoE interfaces will appear as passive interfaces in OSPF (on the core router only) and your customers will not receive hello packets and will not be able to establish OSPF adjacency, so there is no security issue. If your config was missing the line to make the default interface type passive, there would be a potential security issue.

1. Double check about the networks :slight_smile: , if the example subnets like below :

R1 to R2 --> 172.16.1.0/30
R2 to R3 --> 172.16.1.4/30
R3 to R4 --> 172.16.1.8/30

then OSPF networks except the loopback IP , will be :
in R1

network=172.16.1.0/30

in R2

network=172.16.1.0/30
network=172.16.1.4/30

in R3

network=172.16.1.4/30
network=172.16.1.8/30

Is it correct ?

2. Authentication on all of OSPF network must be same or just the direct connected interfaces ?

3. Is there any performance issue on enabling the security of OSPF interfaces ?

Yes, I believe so

2. > Authentication on all of OSPF network must be same or just the direct connected interfaces ?

Each /30 can use its own password if you like. We use the same password for all. You only need auth on interfaces that connect to other OSPF routers (non-passive) where you want to form adjacency.

3. > Is there any performance issue on enabling the security of OSPF interfaces ?

No

At this example , what’s the best MTU settings when I don’t using VLAN ?
When just using MPLS / VPLS tunnels for extend PPPoE servers and want a 1500 L3 MTU for PPPoE Clients.

Do I need to change L2MTU of ethernet interfaces ?
Whats the best MTU of PPPoE servers ?
Whats the best MTU of MPLS interface ?
Do I need to change MTU of VPLS tunnels ?

Not usually, the default is normally 1598 or 1600 or around there, and that is more than enough. As long as it is above your MPLS MTU with room for a VLAN tag on top possibly, that should be enough.

Set MTU and MRU to 1500 for PPPoE server, that will enable RFC4638 support as long as the PPPoE client is set for 1500 MTU similarly and supports RFC4638.

We use 1550, enough for VPLS plus PPPoE overhead with room to spare

Yes, change ‘advertised L2MTU’ for VPLS tunnels to 1508 so that RFC4638 will work.