IPv6 + OSPFv3 + PPPoE

RouterOS General
1

Hi all!!

We have two PPPoE servers runing IPv4 and OSPFv2 (area 1 and area 2 in stub type).

These CCR’s are connected to another CCR wich is connected to the backbone area. This CCR is a ABR (it’s connected to backbone, area 1 and 2) and I do the summarization from PPPoE routers.

I can do it because on IPv4, pppoe clients routes are DAC (dynamic, active and connected), so they’re considered inter-area LSAs

I’m trying to replicate this IPv4 “model” to IPv6 but I’m facing one problem.

PPPoE on IPv6 creates DAS routes (dynamic, active and STATIC) for each pppoe user, in OSPFv3 static routes are advertised as external routes.

Because OSPFv3 can summarize only inter-area networks (to my knowledge) how can I avoid to advertising all IPv6 prefixes (56, 60 and 64)) instead of advertising the /48 prefixes?

I’ll apreciate any sugestions!!

BGP not advertising routes
2

The IPv6 routes are created as static routes because you’re routing a block of prefixes to the connected customer, vs. applying a specific routable IPv4 address directly onto the session itself.

If your ASBR were a Cisco router, I’d say to use the summary-address command in the OSPF configuration.

Interior vs Exterior route sumarization:
The difference between summary-address and area range is not immediately obvious, but it makes sense when you think about how OSPF works.
ABR routers will take LSAs from one area and flood them into other areas as sumary net links. (I think this is LSA type 3, but don’t quote me on that)
Area range tells the router not to translate LSAs falling within that range. Instead, what it does is whenever there is any route available (and I think it needn’t even be an OSPF route) within that range, instead of translating the individual LSAs into type (3?) LSAs, the ABR will generate an aggregated summary prefix (type 3?) that covers the entire range and announce only that aggregate prefix.
This works for normal interior-to-ospf routes, but not for external routes (type 5 & 7) which are treated differently.

External routes are pretty much just forwarded throughout OSPF except in stub,totally stubby areas and NSSA areas. They reference the originating router as well as either an unchanging (E2) metric or a metric that includes the path cost to reach the originating ASBR (E1). In both cases, these aren’t treated as part of interior OSPF routing, so they don’t get aggregated as part of an area’s IP range. They’re considered to be “beyond” the area and not “within” the area.

In Cisco, you can configure the summary-address directive on an ASBR. This works like the area range, but only applies to the routes being injected by that very ASBR. (i.e. it won’t aggregate sub-prefixes originated by other ASBR routers). Whenever at least one sub prefix is to be injected by the ASBR, it will instead create a null route for the summary prefix, and then announce that summary prefix as an external route, suppressing the injection of the actual sub prefixes.

ROS doesn’t have this functionality built in, AFAIK.

However, you can configure this behavior using a blackhole type route + a route filter on the OSPF process itself.

Create a static blackhole route for the /48 you wish to aggregate.
/ipv6 route add type=blackhole dst-address=2001:db8:cafe::/48

Create a route filter for OSPF-in which looks like this:
prefix=2001:db8:cafe::/48 prefix-length=49-128 action=discard

You now have the same behavior. Realize that this must be done at each ASBR itself, and it can only aggregate prefixes it directly originates. If some other router in the topology injects an external route which is a longer prefix within this /48, that longer prefix will not be aggregated by the “home router” and it cannot be filtered out of OSPF globally. Each other router /could/ have this same filter to ignore /49-128 external prefixes, but that doesn’t make sense.

In fact, if you have another router whose /48 is 2001:db8:ba5e::/48 but also acts as a backup router for ::cafe::/48, then if two customers from cafe connect to ba5e, their /56 prefixes will be injected into ospfv3 by the ba5e router, and your network will thus know to reach these customers on the backup router. (I think the cafe router might possibly ignore the /56 prefixes due to the filter, but I haven’t tested this particular scenario in IPv6 in ROS, so ymmv)

3

ZeroByte when I was writing this post I was thinking the same thing you wrote here.

I’ll try your sugestion in my lab and I’ll let you know the results.

Thanks again!

4

Hi all again!

There is no blackhole route type for ipv6 (only unicast and unreachable) and there is no ospf filter on ROS 6.38.7.

I think there is no workrround for this “problem”.

Thanks!

5

Use type unreachable. It gets the job done just as well, and is nice enough to send !H to the original sender so the applications can time out faster.
You should set that up regardless of the inability to filter prefixes.
Actually, though, so long as you don’t attach any prefixes from your /48 pool to any interfaces, you could simply put 2001:db8:p001::/48 onto your loopback as an IPv6 address, which would make the 48 go into routing as normal. Add the loopback interface to your ospfv3 instance, then create unreachable routes for 2001:db8:p001:1000::/49 and 2001:db8:p001::/49

All PPPoE sessions will receive their (e.g.) /56 blocks from that 48 and the more specific /56 should win.

As for route filters not working in 6 - another instance of Mikrotik saying “meh” about IPv6. I was surprised because I know the filter rules themselves support IPv6 prefixes - no problem there. I just never noticed that there was no filter selection for the OSPFv3 instance. Oh well.

EDIT:
I did this in GNS3 just now, and here’s the routing table on my test router.
(I haven’t lit a second router to demonstrate OSPFv3 doign it right, but I’m pretty certain this will yield the intended results.)

Also - I noticed that ROS will not let you put whatever::/48 onto one interface and then whatver:subprefix::1/64 onto some other interface. That doesn’t bother me as technically it would be bad practice to do things like that in real deployments anyway… well, it lets you add it, but whichever you add second (the /64 or the /48) will get the ‘I’ flag until you actually delete the conflicting address. (disabling does not cause the new one to become valid)

6