Hello forum,

i have two subnets, let's say two /23, announced via BGP with my IP carrier provider. Obviously i have an ASN, and BGP is correctly in place on the 1st routerboard.
A second routerboard is housed in a different datacenter with the same IP carrier provider.
The question is: can i announce on both RBs the same subnets? Is there any best practice or caveat to do that?
My goal is to have PPPoE sessions moving from one concentrator to another, without splitting the subnets between the two RBs.

Thanks in advance.

You can do it, but there are some considerations.

If you're not prioritizing the advertisements (or don't trust that they'll work as expected when you do) you'll need a connection between the two DCs to ensure that when outbound traffic leaves from one and returns from another, it completes its connection. Connection tracking for this will also need to be turned off because you have the potential for asymmetric paths.

If you configure the BGP advertisements and your PPPoE delays so that the traffic always has a symmetric path through one DC and only fails over to the other, you can get away without the cross-connect, but it's not 100% and it's purely a failover configuration.

Personally, I would split the networks... but if that's not on the table, consider the first option above.

You can do it, but there are some considerations.

If you're not prioritizing the advertisements (or don't trust that they'll work as expected when you do) you'll need a connection between the two DCs to ensure that when outbound traffic leaves from one and returns from another, it completes its connection. Connection tracking for this will also need to be turned off because you have the potential for asymmetric paths.

I have a /30 in place between the 2 RB. I can have a L2 connection between the two routers, if needed.

If you configure the BGP advertisements and your PPPoE delays so that the traffic always has a symmetric path through one DC and only fails over to the other, you can get away without the cross-connect, but it's not 100% and it's purely a failover configuration.

Personally, I would split the networks... but if that's not on the table, consider the first option above.

I can split the network, rewriting the IP pool on the radius, but is not so simple because the assignment in the past was very very random . I'll try to be more specific: part of the network will be collected in PPPoE by the new 2nd RB, and those that will be collected on the 2nd router for sure will never see the 1st old router. Kinda of migrating network step by step on the 2nd RB as long as i migrate all the backhauls.
My first idea was OSPF in place between the 2 RB/DC, so every router know exactly where is who, from the POV of PPPoE IP address.
Then announce the networks on both router, and start to migrate the bachauls and the PPPoE servers.
But hm reading you there are many things involved, and a guideline to start learning and studying howto, will be very appreciated.

TY in advance.

What you're doing isn't really an uncommon configuration. Typically, that setup will run OSPF between the DCs and then iBGP over that with each DC running eBGP out to the provider. If you're using the same provider at both locations, you can use MED to suggest that the new router should be the primary destination for your prefixes. Put a delay for the PPPoE responses on the old router and you can be fairly sure most will go to the new one. PPPoE sessions and return Internet traffic that doesn't will still get where it needs to go using the transit link between the two routers at that point.

Top. I'll try.
No need to use PPPoE delay, every tower will go on one and only one PPPoE AC.

TY for now.

No need to use PPPoE delay, every tower will go on one and only one PPPoE AC.

The PPPoE delay isn’t necessary, but helps to direct sessions to the device you want to use as the primary router. If they terminate on the secondary unit and some traffic uses the cross-connect, it’s not a big deal (depending on the bandwidth of that cross-connect) but isn’t optimal routing either.