OSPF Backbone area -> Another Area -> Multiple PPPoE servers

gius64 · Fri Jan 08, 2016 5:04 am

Hello everyone,
I'm trying to convert my bridged network to routed.

I currently have one gateway to the internet and one radius server for accounting, and multiple access points on each tower.
I'm using access points as PPPoE servers to be as close as possible to end users.

I would like to keep this configuration in a routed environment, but I'm having some issues.

If I simply add access points to OSPF, and enable redistribute connected I have the area flooded by single /32 routes to clients.
I don't want that, since I'm using larger subnets for users.

It seems the only way to summarize is to have the PPPoE server as an Area Border Router, but I don't have all Access Points directly connected to backbone.

I thought to try anyway, and... it worked!

But:
1) Each access point is obviously seen as an Area Border Router by the router connected to it. Is that bad?
2) Each access point mantains a LSDB with the routes from the area. Is that bad?

I made a diagram to better explain what I did...

scheme.jpg

Do you think it's a good way or do you think it can cause issue in the future?
How can I achieve a better design?

Thank you

Fri Jan 08, 2016 9:02 am

Each pppoe server needs to be in separate STUB area, and route aggregation (area ranges) on it. Also, you need to make sure that dynamic pppoe interfaces are not OSPF interfaces network ( specify ones you need and then "all" with passive flag)

gius64 · Fri Jan 08, 2016 2:15 pm

Each pppoe server needs to be in separate STUB area, and route aggregation (area ranges) on it. Also, you need to make sure that dynamic pppoe interfaces are not OSPF interfaces network ( specify ones you need and then "all" with passive flag)

Thank you very much for your answer

So if I make a stub area for PPPoE server inside another area that isn't connected to the backbone it's not a problem?

Making a stub area the routes from the PPPoE server doesn't get distributed to its neighbor... Is there something I have to do?

I have both private and public IP addresses, so I would like to distribute both.
Public IP addresses are /32: a single /24 class can be used for 253 addresses along all the network (1 Address is used on the gateway).

Fri Jan 08, 2016 3:08 pm

all areas need to be connected to Backbone area - use virtual links to do so.
http://wiki.mikrotik.com/index.php?titl ... rtual_Link

gius64 · Fri Jan 08, 2016 3:12 pm

What happens if I don't use virtual links?
It seems to be working

What you suggest as a good OSPF design for my network diagram?

EDIT:
Not using virtual links, some routers doesn't have the correct route to the PPPoE class, and trying to reach these classes from them make an infinite loop

Some users said using virtual links should be an emergency solution and you shouldn't use virtual links by design... So... How can I design my network?

About virtual links on the internet....

We discuss OSPF virtual links last because they should be used as your last option. The Cisco design guide warns that the use of virtual links is an indication of poor design, and, for the most part, this is correct. Virtual links are used to extend Area 0 across another area. They also can be thought of as tunnels for LSAs. They are deployed in cases when areas become partitioned or an area does not border Area 0.

Fri Jan 08, 2016 5:17 pm

It's generally considered to be bad practice to use virtual links - apparently they let you do things that break OSPF design paradigm and cause the troubleshooting of LSAs and other things to become more difficult....

I would recommend against redistributing connected routes - in fact, redistributing routes by default is a very bad habit to get into. Routing protocols all treat redistributed routes differently than they treat routes that are "native" to the protocol.

Redistributing routes is definitely something that is normal and has its place, but most newbies to dynamic routing tend to just tell the router to go grab everything it knows, dump it into the protocol, and announce everything. ("Kill them all and let God sort it out") The destinations of redistributed routes are considered to be "outside" your network, and the ASBR that injects a route is considered to be a gateway to the destination, with some unknown amount of distance to cover after leaving the local network.

Instead of redistributing every /32 into your routing, you should try injecting aggregated routes (pools) into OSPF at each AP.

Of course this means that in general, each user's IP address should be taken from that specific AP's pool of addresses. If you run out, then allocate another block to the AP and assign more customers from the new block. If you have a few customers that are exceptions to the block, then advertise those specific /32s into OSPF

Suppose AP1 assigns IP addresses from 10.1.1.0/26 and AP2 assigns them from 10.1.1.64/26
On AP1, create a route type=blackhole dst=10.1.1.0/26 tag=100 and on AP2, create a route type=blackhole dst=10.1.1.64/26 tag=100
On these APs you would then redistribute static in-filter=static2ospf

For route filter static2ospf, make the first rule match tag=100 action=accept
and make the last rule be action=discard

This gives you complete control over which static routes are injected into OSPF and which are just private routes for this router. If you want a static route to go into OSPF, set the tag to 100....

Finally, make sure that you only create OSPF networks for the active interfaces that you want forming adjacencies. Also add networks for any other local ethernet networks that you want to appear in your routing table, but As macguyver suggested, make sure that interfaces are configured as passive where you don't want adjacencies to form.

Fri Jan 08, 2016 5:33 pm

Another (possibly simpler) way to do this, using areas, is to use the backbone area everywhere, and make each AP into an ABR by definining a new area for each AP. When you do this, define an area range similar to my previous explanation:

Assume that ether1 is the uplink to your network and is connected to network 10.0.0.0/24 as area 0 (backbone).

/routing ospf area
add area-id=0.0.0.1 default-cost=1 inject-summary-lsas=no name=users type=stub
/routing ospf area range
add area=users range=10.1.1.0/26
/routing ospf interface
add network-type=broadcast passive=yes
add interface=ether1 network-type=broadcast
/routing ospf network
add area=users network=10.1.1.0/26
add area=backbone network=10.0.0.0/24

This will cause the AP to announce (as a native-to-ospf destination, yay) 10.1.1.0/26 if it has even one user connected whose IP is in that range. It won't announce any individual routes it knows which fall inside this range.

If you have any users whose IP is an exception to the pool, create another network entry for area users.
e.g.:
/routing ospf network add area=users network=10.1.3.204/32
You won't need to define an area range for this /32 because area range is only used to aggregate your routes into blocks. If you had two "exception" users whose IPs were contiguous, you could create a /31 area range to aggregate them if you wanted to, though.....

Note that if these "exception" users' IPs are part of a range being announced by some other AP, the user will work just fine because the more specific route will be in your routing table to bring traffic to the correct AP. As long as each AP's "users" area has a unique area id (which isn't an IP address, it's just a number) then you won't get any problems with aggregation.

Note that even if you do this (I think it's a better solution for your scale) then you should still configure the redistribute static in-filter=static2ospf method I mentioned in my previous post. There are times you need to redistribute static routes into OSPF, and it's nice to have a filter in place so that you can control which routes are injected.

Fri Jan 08, 2016 6:05 pm

Here's how your network diagram would look:

Drawing3.png

There are some cons to using the ABR method:
1)
It puts a bit more load onto the APs because they're ABRs and must contain the Link State DB for both the backbone area and for the "users" area they're connected to.... but this isn't so bad because the users areas don't have any neighbors in them, and the backbone area is pretty clean because it doesn't get any LSAs for any user links.

2)
It doesn't let you partition your primary network into areas. This isn't a problem unless you start to get thousands and thousands of routes and need to do more route aggregation in a large scale.

Remember that OSPF must look like a sunflower: the black center with the seeds is area 0, and every other area attaches directly to the center, and has no connection to any other area except through area 0, so if you ever would need to break your primary network into areas, you would need to convert the APs into ASBRs as with my earlier suggestion, and use NSSA areas... but that's way far future stuff, so I recommend using the ABR range method for now because it's easy to understand.

gius64 · Fri Jan 08, 2016 6:11 pm

ZeroByte, you gave me very clear answers! Thank you very much for your time, I appreciate it!

If I understood what you're saying, you suggest me to have all routers and access points in backbone area, so Access Points can become ABR.

I have about 60 different routers, and each one has from 1 to 6 access points (in some case even more), so I would have about 250 different routers accross all the network.
I use different routers in each tower (RB750, RB750r2, RB2011, CCR1009)... A smaller router mean a smaller amount of traffic to route. CCR1009 are only on big backbone place (that collect traffic from other places and send it to the main gateway).

Can a single backbone area be a problem for memory usage (especially on RB750 where I have only 32MB)?
Can a single backbone area be a problem for convergence time in case of a wireless link down (I have a ring network for backbone)?

Thank you very much for your time, you gave me the best answers I ever received in the forum

Fri Jan 08, 2016 6:29 pm

If I understood what you're saying, you suggest me to have all routers and access points in backbone area, so Access Points can become ABR.

I have about 60 different routers, and each one has from 1 to 6 access points (in some case even more), so I would have about 250 different routers accross all the network.

Well, in this case, you would make the site's CCR router into the ABR and use an NSSA area pointing to the access points. Do your route aggregation (area ranges) in the CCR and be sure to inject default route into the NSSA. If all users for that site (regardless of AP) are in just a few easily-aggregated ranges, then your backbone are will be nice and tidy. The access points should be just fine to send all /32s into the area because only the local routers in the NSSA will be exchanging LSAs whenever a user goes online or drops offline.... and the only route from the rest of the network would be the default GW from the ABR.....

One thing to be very very careful of, in this scenario: If area 0.0.0.3 has area range 10.3.0.0/24, but there's a user connected to some other area, but with an IP from this range, then nothing inside this area would be able to communicate with that other user.

Can a single backbone area be a problem for memory usage (especially on RB750 where I have only 32MB)?

Yep. Definitely - but aggregating routes helps with this a LOT. (and you really can't aggregate exterior routes, which is why just doing "redistribute connected" is bad - having a large network full of External2 /32 prefixes would be a nightmare.)

Can a single backbone area be a problem for convergence time in case of a wireless link down (I have a ring network for backbone)?

Well, yeah, but it wouldn't be so bad if all of your users were covered by sumary prefixes, because the number of links to re-compute would be greatly reduced.

Thank you very much for your time

You're welcome!

gius64 · Fri Jan 08, 2016 6:56 pm

If I understood what you're saying, you suggest me to have all routers and access points in backbone area, so Access Points can become ABR.

I have about 60 different routers, and each one has from 1 to 6 access points (in some case even more), so I would have about 250 different routers accross all the network.
Well, in this case, you would make the site's CCR router into the ABR and use an NSSA area pointing to the access points. Do your route aggregation (area ranges) in the CCR and be sure to inject default route into the NSSA. If all users for that site (regardless of AP) are in just a few easily-aggregated ranges, then your backbone are will be nice and tidy. The access points should be just fine to send all /32s into the area because only the local routers in the NSSA will be exchanging LSAs whenever a user goes online or drops offline.... and the only route from the rest of the network would be the default GW from the ABR.....

One thing to be very very careful of, in this scenario: If area 0.0.0.3 has area range 10.3.0.0/24, but there's a user connected to some other area, but with an IP from this range, then nothing inside this area would be able to communicate with that other user.

Each range (for example 10.3.0.0/24) is only for one AP, so I shouldn't have this issue.
My problem is I also have other links in each area, like you saw in my diagram, and each link has its router and its access points, so having such configuration would mean that in the area I will have /32 from each users because I would summarize them only on the ABR, and we're talking of about 300-400 routes (I have very unbalanced area: some 300-400 users, other 30-40) which will be distributed also on other APs of that NSSA area... I think it can be a problem, can't it?

Can a single backbone area be a problem for memory usage (especially on RB750 where I have only 32MB)?
Yep. Definitely - but aggregating routes helps with this a LOT. (and you really can't aggregate exterior routes, which is why just doing "redistribute connected" is bad - having a large network full of External2 /32 prefixes would be a nightmare.)

How can I calculate how much memory an LSDB will require?
If I choose to use a single backbone area I want to be sure that smaller routers won't crash when I'll remove all bridges at the end of the transition...

Can a single backbone area be a problem for convergence time in case of a wireless link down (I have a ring network for backbone)?
Well, yeah, but it wouldn't be so bad if all of your users were covered by sumary prefixes, because the number of links to re-compute would be greatly reduced.

We're talking of about 200 Access Points and 50 routers accross all the network... And I would like to build a scalable network design as I'm reengineering all the network and I can make the best choices!

Fri Jan 08, 2016 7:05 pm

We're talking of about 200 Access Points and 50 routers accross all the network... And I would like to build a scalable network design as I'm reengineering all the network and I can make the best choices!

You should use areas.

So here's the updated diagram.....

Drawing3.png

You can use area type=stub if you don't plan on injecting any external routes whatsoever.

NSSA will let you inject routes into OSPF, and they'll get translated into type5 LSA by the ABR.

For this configuration, on the APs, you could be lazy and set network=0.0.0.0/0 area=nssa_area_name
so long as you have default interface = passive, this shouldn't cause a lot of issues, and it will keep your routes properly aggregate-able....

NOTE: If you put a route into the table by a redistribute statement, then the ABR won't aggregate that route, even if it is inside of an area range you defined.

If you're worried about overwhelming the AP's brains - you could leave them as bridges and put a local PPPoE concentrator at each tower site to handle the actual sessions and routing.... or have multiple PPPoE boxes acting as access concentrators, and leave the APs doing nothing but pure wireless. Give them simple static IP addresses in a management network at the site, which gets announced by the ABR or the concentrator(s).

gius64 · Fri Jan 08, 2016 7:20 pm

You're spending so much time for me, I have no words for your kindness

So you suggest to keep in the backbone area all routers and an NSSA area for each group of access points?
In this way I should keep routes very clear and I can make a virtually infinite number of derivation from each router!

I should also be able to give redundancy to each router as they will be all in the backbone area!

How much routes do you think an RB750 with 32MB of RAM can manage?
I have 4 RB750, 21 RB750r2 (64MB RAM), 4 RB2011i (64MB RAM), 22 RB2011Ui (128MB RAM), and 9 CCR1009 (2GB RAM).

With this situation in the backbone area I will have about 200 summary routes from access points and some routes from routers to reach them.

I think this is the perfect solution for my network and I think it will help lots of people!

PS.: What are you using to design diagrams? They're very clear!

If you're worried about overwhelming the AP's brains - you could leave them as bridges and put a local PPPoE concentrator at each tower site to handle the actual sessions and routing.... or have multiple PPPoE boxes acting as access concentrators, and leave the APs doing nothing but pure wireless. Give them simple static IP addresses in a management network at the site, which gets announced by the ABR or the concentrator(s).

In a single NSSA area I shouldn't have more than 200 users, I have all AP with RB922UAGS-5HPacD or RB912UAG-5HPnD with 128 or 64MB RAM, I think it shouldn't be an issue as they aren't very CPU/RAM stressed. What do you think about that?

gius64 · Fri Jan 08, 2016 7:29 pm

I was thinking: What's the difference between:
1) having a group of access points in NSSA areas
2) having each access point in a stub area summarized by the access points?

Using NSSA area each ABR must have two LSDB, one for NSSA area and one for Backbone

Fri Jan 08, 2016 7:42 pm

So you suggest to keep in the backbone area all routers and an NSSA area for each group of access points?
In this way I should keep routes very clear and I can make a virtually infinite number of derivation from each router!

I should also be able to give redundancy to each router as they will be all in the backbone area!

Exactly. Imagine another yellow lightning bolt between the top ABR and the bottom-right ABR. Done!

How much routes do you think an RB750 with 32MB of RAM can manage?
I have 4 RB750, 21 RB750r2 (64MB RAM), 4 RB2011i (64MB RAM), 22 RB2011Ui (128MB RAM), and 9 CCR1009 (2GB RAM).

I'm not sure how many routes they can handle - you could always lab it up and see how much RAM you have with an empty routing table and how much with a whole bunch of OSPF routes. The bigger concern, though is how much CPU drain an unstable topology can cause in your routers.... if links are flapping a lot, then all routers have to keep re-computing their routing table....

With the NSSA in place, the routing table at any given AP shouldn't be so huge - and topology changes only affect their local area routers. If a user in area 3 connects and disconnects over and over, the routers in area 1 don't have to keep re-computing their routing table.

PS.: What are you using to design diagrams? They're very clear!

Thanks - and I'm using Visio. I've been doing them for quite a while, so I've gotten used to slapping out a quickie diagram that's focused in on the details I want to convey.

In a single NSSA area I shouldn't have more than 200 users, I have all AP with RB922UAGS-5HPacD or RB912UAG-5HPnD with 128 or 64MB RAM, I think it shouldn't be an issue as they aren't very CPU/RAM stressed. What do you think about that?

It should be okay. Remember - if you inject routes by redistributing static/connected, then your summaries aren't going to work, so be sure to make your APs do something simple like network=0.0.0.0/0 area=nssa_area_name, and have passive as the default interface type.

Fri Jan 08, 2016 7:49 pm

I was thinking: What's the difference between:
1) having a group of access points in NSSA areas
2) having each access point in a stub area summarized by the access points?

Using NSSA area each ABR must have two LSDB, one for NSSA area and one for Backbone

The area type isn't the difference here - you could use a stub area, but that would prevent you from being able to redistribute any static routes you need into OSPF. (stub doesn't allow type 5 LSA (external) and NSSA uses LSA type 7 which gets converted into a type 5 as it enters the backbone area).

The thing that IS the difference is that area 0 gets all information. If each AP is an ABR, (whether the users interfaces are in a stub or nssa area is irrelevant) then that means that they MUST have an interface in area 0, which means that they get the whole enchilada.... and in fact it's worse because they get the area 0 (which, granted, isn't too huge if you're aggregating your routes, but you'd have at least X sumary routes, where X is the number of APs in your network) and they also have their own stub/nssa area to contend with as an additional table to manage. changes in either table force the router to re-compute the routing table.

If the APs are just interior routers, then they only have to worry about the routing table of their immediate area, and they won't even have routes from other regions of the network. You could do a hybrid where you don't worry about area range aggregation so much, and you do your aggregation on your ASBR routers (ap's) - this will be the cleanest within an area, but dirtier in the backbone.

gius64 · Fri Jan 08, 2016 8:07 pm

That makes perfectly sense!
I'll try this way!

Thank you very much!

gius64 · Sun Jan 10, 2016 1:11 pm

I'm implementing the solution we discussed on my routers and I have one question and one problem!

Question:
If in the access points I set 0.0.0.0/0 as network, also the loopback interface is included in the routes. Is that ok?

Problem:
The default route is flapping: after 10-20 minutes it disappear from access points in the NSSA area if the main router is a CCR1009. I don't have this problem on other routers (RB2011 and hEX) and only on 2 of 3 CCR1009 I configured as routed.

A workaround is add a static route to 0.0.0.0/0 on the devices attached but I would like to solve that!
I sent a mail to MikroTik support with supout.rif files, but I would like to know if anyone had this issue.

I found some thread of RouterOS 5.6... But my CCR are updated to 6.33.3 or 6.32.3

Mon Jan 11, 2016 5:39 pm

Question:
If in the access points I set 0.0.0.0/0 as network, also the loopback interface is included in the routes. Is that ok?

Actually, you want every last router's loopback in your OSPF. You want to make sure that each router is using its loopback IP as the routerid. These are part of best practice. In fact, if you're ever considering MPLS, I've read that best practice is to make sure that your loopback IP addresses don't get aggregated.

Problem:
The default route is flapping: after 10-20 minutes it disappear from access points in the NSSA area if the main router is a CCR1009.

That sounds pretty abnormal. I think contacting support was the best thing to do in this case.

gius64 · Mon Jan 11, 2016 5:48 pm

Your answers are very helpful!
Do you own a WISP?

Oh, so I should include loopback address in every router?
I'm considering MPLS TE for load balancing!

About route flapping they answered, but I had to insist to convince them it's not a configuration issue...
The strange thing is I configured more than 15 routers as you suggested me, and I have this issue only on CCR1009 even if the configuration is exactly the same of all other routers!
I hope they'll work on that because it's abnormal!

Mon Jan 11, 2016 6:09 pm

Your answers are very helpful!
Do you own a WISP?

Oh, so I should include loopback address in every router?
I'm considering MPLS TE for load balancing!

About route flapping they answered, but I had to insist to convince them it's not a configuration issue...
The strange thing is I configured more than 15 routers as you suggested me, and I have this issue only on CCR1009 even if the configuration is exactly the same of all other routers!
I hope they'll work on that because it's abnormal!

No - but I've been a network engineer for quite a while, and OSPF design is something you need to be fluent in.

Just for the sake of thoroughness - have you tried replacing your CCR1009 with another router, just to rule out something peculiar about this corner of your network? (could there be packet loss on the backhaul, causing the 1009 to temporarily lose connectivity, for instance?) If another device works perfectly in the exact same spot plugged into the very same equipment, then that'd be pretty convincing.

gius64 · Mon Jan 11, 2016 6:18 pm

Good point, but I don't think it's related to loss of connectivity: at the moment I have static routes to 0.0.0.0/0 on the CCR1009 because they are still bridged.
Default routes simply disappear from access point attached after exactly 30 minutes (I tried to replicate), and if I make a change on any OSPF instance parameter, they come back and disappear after 30 minutes...
Very strange, and only on CCR1009 and CCR1036 (main gateway)!

amt · Thu Sep 28, 2017 4:19 pm

/routing ospf area
add area-id=0.0.0.1 default-cost=1 inject-summary-lsas=no name=users type=stub
/routing ospf area range
add area=users range=10.1.1.0/26
/routing ospf interface
add network-type=broadcast passive=yes
add interface=ether1 network-type=broadcast
/routing ospf network
add area=users network=10.1.1.0/26
add area=backbone network=10.0.0.0/24

this is old topic I know but I saw it and I doubt about my config that I use for pppoe connection's on pppoeserver's.
I set inject-summary-lsas as yes and ospf interface network type as default for passive interface. did I make mistake at here ?
here is what I use;


/routing ospf interface
add authentication=simple authentication-key=somesecret interface=ether1 network-type=broadcast priority=1
add network-type=default passive=yes
/routing ospf area
add area-id=0.0.0.20 default-cost=1 inject-summary-lsas=yes name=pppoe1 type=stub
/routing ospf area range
add area=pppoe1 range=172.16.0.0/23
/routing ospf network
add area=backbone network=10.10.0.128/30
add area=backbone network=10.255.255.20/32
add area=pppoe1 network=172.16.0.0/23

thanks

Thu Sep 28, 2017 4:53 pm

inject-summary-lsas is only going to affect what prefixes are sent to peers inside the area, and since the area has no peers (all interfaces in it are passive) then it doesn't matter.
This command dictates whether your internal OSPF topology prefixes should be sent into an area from the backbone area.

When set to no on a stub area, then the routers inside the area pretty much only receive a default gateway prefix from the ABR, and nothing else from outside the area.
When set to yes, then all of the natural (non-external) OSPF routes will be sent into the area.
STUB areas don't allow type 5 LSAs, so this will prevent the E1 and E2 routes propagating from your backbone into a stub area. (and of course it also eliminates the possibility of any ASBR existing in the stub area - i.e. any router in a stub area cannot redistribute routes into OSPF)

NSSA areas are like stubs that send out their own redistributed routes, but ignore the ones from the rest of the network.
They do this by using the type 7 LSA for redistributed routes instead of type 5. The ABR will translate the NSSA type 7 LSAs into type 5 as they enter area 0, and the rest of your network won't know the difference.

amt · Thu Sep 28, 2017 10:56 pm

Thanks a lot ZeroByte,
I will set inject-summary-lsas to no and one more thing for ospf interface network-type, what should it be ? Broadcast or default for where passive=yes

Thu Sep 28, 2017 11:31 pm

Thanks a lot ZeroByte,
I will set inject-summary-lsas to no and one more thing for ospf interface network-type, what should it be ? Broadcast or default for where passive=yes

Neither parameter matters on a passive interface, which pretty much only serves one function: to - to properly originate routing information. The other parameters pretty much handle the behavior when forming adjacencies, except for cost which does have potential effects on routing.

amt · Fri Sep 29, 2017 9:20 pm

thanks for your help again zerobyte..... thanks a lot

OSPF Backbone area -> Another Area -> Multiple PPPoE servers

OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Re: OSPF Backbone area -> Another Area -> Multiple PPPoE servers

Who is online