❓ MPLS + VPLS + PPPOE Central (DataTransfer Problem on 3rd hops)

RouterOS General
21

If all traffic goes through the core router anyway, you could simply advertise everything except the PPPOE subnet.

Failing that, either a) set up second area for pppoe, can be a stub, then summarize pppoe super net to backbone with area range, and then advertise pppoe subnet normally through networks - other routers will get one route only, or b) do not advertise the pppoe subnet through networks, and instead enable refistribute connected in OSPF, then create a route filter to filter the /32s for pppoe while leaving the main subnet advertised as external lsa, with b you don’t need second area but if you ever add the pppoe to OSPF networks they will be advertised individually bypassing the filter.

I would do ‘a’

22

I asked regarding this, have worked with ligowaves in the past and even I noticed some oddities, overall they were truly L2 transparent.

Rest of the tests ViRENG is reporting here were done connecting routers straight, no switches nor anything in-between (that’s why I asked).

The “funny” thing, is all VPLS tunnels were reported running on both ends, but despite that, R1-R3 communication seemed to be botched; R1 → R3 worked, but R3 → R1 didn’t, in other words R1 Rx on R1-R3 wasn’t working, counters were 0.

The suggestions I provided regarding MTU were blind shooting in order to determine if the problem was MTU related (there have been some MTU fixes lately), which it wasn’t.

I agree that OSPF, specially when deployed following best practices is much more preferable than static routing. I completely second the stub area/summarizing suggestion on the PPPoE. In fact, is the first time I have deployed MPLS/VPLS without using OSPF as apart from a scenario like this one, or a lab, static routing can quickly get out of hand.

However, even though MPLS is twice as better in combination with OSPF, strictly speaking it doesn’t need OSPF if proper static routes are provided.

Yes, but MPLS fits between L2 and L3 (commonly referred as L2.5). Even having ping through default route, As R1-R3 don’t have directly connected routes, we need to resort to route recursivity in order to have loopback’s specific routing entries on each router routing table.

Labbed it, everything is the same, but for R1, where ether2 is used instead of ether1 (needed the PoE):
MPLS no OSPF Diagram.png
Devices:
R1: mAP2n, 6.39.2, FW 3.24 (ether2 was used instead of ether1 on R1).
R2: RB951-2n 6.39.2, FW 3.24
R3: RB941-2n, 6.39.2 FW 3.36

R1:

/interface bridge
add name=loopback

/interface ethernet
set [ find default-name=ether2 ] l2mtu=1600 master-port=ether1

/ip address
add address=172.16.1.1/24 interface=ether2 network=172.16.1.0
add address=172.16.0.1 interface=loopback network=172.16.0.1

/ip route
add distance=1 dst-address=172.16.0.2/32 gateway=172.16.1.2
add distance=1 dst-address=172.16.0.3/32 gateway=172.16.2.2 target-scope=30
add distance=1 dst-address=172.16.2.0/24 gateway=172.16.1.2

/mpls ldp
set enabled=yes lsr-id=172.16.0.1 transport-address=172.16.0.1

/mpls ldp interface
add interface=ether2

/interface vpls
add advertised-l2mtu=1508 disabled=no l2mtu=1508 mac-address=02:E7:AA:E2:75:39 name=R1-R2 remote-peer=172.16.0.2 vpls-id=1:2
add advertised-l2mtu=1508 disabled=no l2mtu=1508 mac-address=02:68:1A:BD:D1:AD name=R1-R3 remote-peer=172.16.0.3 vpls-id=1:3

/interface pppoe-server server
add disabled=no interface=R1-R3 service-name=PPPoE_R1-R3
add disabled=no interface=R1-R2 service-name=PPPoE-R1-R2

/system identity
set name=R1

R2:

/interface bridge
add name=loopback

/interface ethernet
set [ find default-name=ether2 ] l2mtu=1600

/interface vpls
add advertised-l2mtu=1508 disabled=no l2mtu=1508 mac-address=02:9D:3D:58:0D:7D name=R2-R1 remote-peer=172.16.0.1 vpls-id=1:2

/ip address
add address=172.16.1.2/24 interface=ether1 network=172.16.1.0
add address=172.16.2.1/24 interface=ether2 network=172.16.2.0
add address=172.16.0.2 interface=loopback network=172.16.0.2

/ip route
add distance=1 gateway=172.16.1.1
add distance=1 dst-address=172.16.0.1/32 gateway=172.16.1.1
add distance=1 dst-address=172.16.0.3/32 gateway=172.16.2.2

/mpls ldp
set enabled=yes lsr-id=172.16.0.2 transport-address=172.16.0.2

/mpls ldp interface
add interface=ether1
add interface=ether2

/system identity
set name=R2

R3:

/interface bridge
add name=loopback

/interface ethernet
set [ find default-name=ether1 ] l2mtu=1600

/interface vpls
add advertised-l2mtu=1508 disabled=no l2mtu=1508 mac-address=02:14:C3:2D:63:5B name=R3-R1 remote-peer=172.16.0.1 vpls-id=1:3

/ip address
add address=172.16.2.2/24 interface=ether1 network=172.16.2.0
add address=172.16.0.3 interface=loopback network=172.16.0.3

/ip route
add distance=1 gateway=172.16.2.1
add distance=1 dst-address=172.16.0.1/32 gateway=172.16.1.1 target-scope=30
add distance=1 dst-address=172.16.0.2/32 gateway=172.16.2.1

/mpls ldp
set enabled=yes lsr-id=172.16.0.3 transport-address=172.16.0.3

/mpls ldp interface
add interface=ether1

/system identity
set name=R3

Both tunnels work in both ways, and each pppoe server instance is seen from R3 and R2 when scanning.

23

Yes, he can use static routes to the loopbacks as long as they are individual /32’s, but this is silly in my opinion, it is much better (and you agree) to set up a stub area (which is not hard to do at all) and get OSPF working and be done with it.

24

I know, but it was a simple scenario, and the OP wanted to know what was the problem specifically with his setup; I simply didn’t want to provide a “solution” to a problem by adding a third player (OSPF) and more complexity; simple problem = simple solution.

OSPF in not experienced hands can quickly become a really complex problem for them to troubleshoot… IMHO even if best practices dictate specific approaches, is almost always better a solution tailored to the user level so that he feels confident with his network, even it not being the most widely used.

25

pukkita,

Why only configure eth2 in terms of l2-mtu, and not both eth1 and eth2? Is the L2-mtu stuff only required when the VPLS terminates on the interface? I was under the impression it would be of importance anywhere on the MPLS path?

Just asking :slight_smile:

26

On RB951-2n (R2) ether1 default L2MTU is 1600, that’s why only ether2 appear in the export.

Yes, L2MTU is crucial on all interfaces involved in MPLS/VPLS.

27

Ah yes, of course. Thanks!

28

Thanks a lot @pukkita and @mducharme

With distinction of OSPF and PPPoE routes , I’m going to first solution for making the network with OSPF and because of different with this topic subject I make another with that .
if is possible see & check it too :wink: :

what’s the best solution for OSPF and PPPoE service :
http://forum.mikrotik.com/t/whats-the-best-solution-for-ospf-and-pppoe-service/110550/1