MikroTik

Hello Everyone, after kurking for a while its good to be here.

So basically i am labbing my setup on v7 before moving production to it.

i can post exports but it is the typical mpls ldp , with ospf for igp and ibgp between PEs and RR router

The thing is when create a bgp-vpls tunnel from PE1 to PE2 the tunnels form with the peer being the route reflector! and it doesn't even show up in route reflector or has the Bgp signaled flag.

i tried lots of thing but it seems the route reflector insnt reflecting correctly the l2vpn without assigning itself as the originator. am not sure if anyone can help.. manual vpls works normally no issues there

now regarding L3vpns i am not able to make it work without setting the default originate for the ebp on PE1 with CE1 i dont want default originate i want the routes to be distributed as is from the vfr table but that doesn't happen it only works with default originate or i dont see any routes distributed on CE1

i wanna migrate v7 asap as i really like the work done its great with latest Bfd update.

are those known bugs with 7.10 or am just doing something wrong although it was working on v6
Ps: all networks internal and external are running on VLans not the actual interfaces and ibpg is running on loopbacks advertised by ospf

Is the RR router running v7.10 as well?

Afaik there have been a few issues with carrying L2VPN information over BGP for services like VPLS in v7 and only works in v6, so your RR needs to run v6.

hello croissante,

thing is when create a bgp-vpls tunnel from PE1 to PE2 the tunnels form with the peer being the route reflector! and it doesn't even show up in route reflector or has the Bgp signaled flag.

can we take a look at your sample output here?

along with these 2 part samples

tried lots of thing but it seems the route reflector insnt reflecting correctly the l2vpn without assigning itself as the originator. am not sure if anyone can help.. manual vpls works normally no issues there

now regarding L3vpns i am not able to make it work without setting the default originate for the ebp on PE1 with CE1 i dont want default originate i want the routes to be distributed as is from the vfr table but that doesn't happen it only works with default originate or i dont see any routes distributed on CE1

I have observed the same behavior with BGP VPLS using a Cisco IOS 12 as Route Reflector.

I generated a ticket [SUP-83173] with the problem, which was closed as solved by Support. However the problem persists. The only way I've found to fix the issue is by removing the following command from the route reflector:

hello croissante,

thing is when create a bgp-vpls tunnel from PE1 to PE2 the tunnels form with the peer being the route reflector! and it doesn't even show up in route reflector or has the Bgp signaled flag.

can we take a look at your sample output here?

this is PEs bgp

/routing bgp connection
add address-families=ip,l2vpn,vpnv4 as=66000 connect=yes disabled=no listen=\
yes local.address=192.0.0.2 .role=ibgp name=to-rr nexthop-choice=\
force-self output.network=pip .redistribute=bgp remote.address=\
192.0.0.1/32 .as=66000 router-id=192.0.0.2 routing-table=main

RR BGP
add address-families=ip,l2vpn,vpnv4 as=66000 connect=yes disabled=no listen=\
yes local.address=192.0.0.1 .role=ibgp-rr name=to-pe2 \
output.filter-chain=int .network=internet remote.address=192.0.0.2/32 \
.as=66000 router-id=192.0.0.1 routing-table=main

the output filter is just to change default gateway without using default originate.

PEs vpls

add disabled=no export-route-targets=201:201 import-route-targets=201:201 \
name=PE2-PE3 rd=201:201 site-id=1 vrf=main


below is the VPLS that formed the peer is 192.0.0.1 instead of the PE2(192.168.0.2), and it just says RD instead of RDB

2 RD name="vpls3" mtu=1500 mac-address=02:59:BC:26:B0:32 arp-timeout=auto
peer=192.0.0.1 pw-type=vpls pw-l2mtu=1500 pw-control-word=enabled
bgp-vpls=PE2-PE3 bgp-vpls-prfx="veId=2,veBlockOffset=0&201:201"

along with these 2 part samples

tried lots of thing but it seems the route reflector insnt reflecting correctly the l2vpn without assigning itself as the originator. am not sure if anyone can help.. manual vpls works normally no issues there

now regarding L3vpns i am not able to make it work without setting the default originate for the ebp on PE1 with CE1 i dont want default originate i want the routes to be distributed as is from the vfr table but that doesn't happen it only works with default originate or i dont see any routes distributed on CE1

l3vpn bgp PE config

add as=66000 connect=yes disabled=no listen=yes local.address=192.168.65.1 \
.role=ebgp name=baristawan nexthop-choice=force-self output.redistribute=\
connected,static,bgp,vpn,bgp-mpls-vpn remote.address=192.168.65.2/32 .as=\
66100 router-id=192.0.0.3 routing-table=vrf1 vrf=vrf1

/ip/route> pri where routing-table=vrf1
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, b - BGP, y - BGP-MPLS-VPN; + - ECMP
Columns: DST-ADDRESS, GATEWAY, DISTANCE
DST-ADDRESS GATEWAY DISTANCE
DAy+ 20.20.10.0/29 192.0.0.2 200
DAb 192.168.40.0/24 192.168.65.2@vrf1 20
DAc 192.168.65.0/24 vlan201-ce1@vrf1 0
DAy+ 192.168.91.0/24 192.0.0.2 200

this output confirms VPN is working perfectly fine both PEs can see the routes now the customer have this prefix only from bgp, if i use default originate on the PE it works normally.

DAb 20.20.10.0/29 192.168.65.1 20

your RR needs to run v6.

hmm i will try that thx

I have observed the same behavior with BGP VPLS using a Cisco IOS 12 as Route Reflector.

I generated a ticket [SUP-83173] with the problem, which was closed as solved by Support. However the problem persists. The only way I've found to fix the issue is by removing the following command from the route reflector:

Code: Select all

neighbor x.x.x.x send-community extended

i am not using communities at all so nothing to remove here

Is the RR router running v7.10 as well?

Afaik there have been a few issues with carrying L2VPN information over BGP for services like VPLS in v7 and only works in v6, so your RR needs to run v6.

Well i tried a V6 RR and it worked nornally.
which begs the question why did mikrotik put all these features as green in the table on the wiki when in fact they are not i wasted way too much time trying combinations.

Hi Croissante,

I'm running BGP signalled VPLS with RR and basically the tunnels are running. BUT, there is a known bug: when using RR instead of a full BGP mash, the traffic in the tunnels is not always routed. Mikrotik support is investigating the problem.

As I read trough your post, I can suggest you to check your roting filters for that line:

Hi Croissante,

I'm running BGP signalled VPLS with RR and basically the tunnels are running. BUT, there is a known bug: when using RR instead of a full BGP mash, the traffic in the tunnels is not always routed. Mikrotik support is investigating the problem.

As I read trough your post, I can suggest you to check your roting filters for that line:

Code: Select all

if ( afi l2vpn ) { accept;} 

thx for your input, will check that

regarding l3vpn do u have any idea why only the prefix
DAy+ 20.20.10.0/29 192.0.0.2 200 is advertised to ce1 and not this one
DAy+ 192.168.91.0/24 192.0.0.2 200

Please can you share you input and output routing filters, from PE and CE?

Hi Everyone,

Quick update/question on this topic.
We have successfully configured BGP Signaled VPLS (L2VPN) and BGP VPN (L3VPN) on a GNS Project where we are developing a OSPF / IBGP Service Provider network. We are using RouterOS 7.13 (Latest Stable version 7.13)
OSPF is used to distribute loopbacks and PtP's between routers, and then we have iBGP sessions between each router and the route reflectors (we have 2x RRs)

What we have noticed is that the L3VPN is working 100%, i.e. we can route traffic between any number of sites that use the same Import/Export Route Targets in the BGP VPN config.

However, with L2VPN the layer2 bridging between sites only works when we have the BGP VPLS configured and active on one of the Route Reflectors. According to Mikrotik documentation the Route Reflectors does not need to be part of the BGP VPLS, and that makes sense, because we don't need the Layer2 bridging on the RRs.

To give some more background.
The dynamic VPLS tunnels are coming up at all sites, even without the route reflectors being part of the BGP VPLS, however no Layer2 traffic is passing through the tunnels. The moment we make the Route Reflector part of the BGP VPLS (i.e. see config below) then Layer2 traffic is being passed between the sites.

We have two concerns here.
1. With this issue Layer 2 traffic is bridged at the Route Reflectors resulting in suboptimal traffic routing. Layer2 Traffic should be bridged directly between sites.
2. We are forced to make the Layer2 traffic available on the Route Reflectors

I am suspecting this is a Mikrotik RouterOS bug, however would love some input from the community experts before submitting this to Mikrotik Support.

Below my config used for the BGP VPLS, we can safely assume that IBGP config is done correctly, i.e. IBGP sessions are working, and we have l2vpn AFI enabled.

/routing bgp vpls
add bridge=bridge1 disabled=no export-route-targets=111:10 import-route-targets=111:10 name=test1 \
pw-control-word=default pw-type=vpls rd=111:10 site-id=99

Maybe just one more comment, to further clarify.

If we create the VPLS tunnel manually by specifying the remote peer and VPLS: ID, then direct communication between sites works just fine. So, the issue is definitely with the BGP VPLS dynamic tunnels.

Yes, it is a known route reflector issue, will be fixed in the future.

Thanks for confirming this @mrz.

Is there any indication from Mikrotik developers which release version this issue will be fixed?

7.14.3 in PE
7.14.1 in RR
still same situation

I've prepared the diagram , about what happening while VPLS is working.

ROS 7.15 released

Anybody tried to check this issue in new version ?

I haven't seen anything related to this topic in the changelog of this new version.

I haven't seen anything related to this topic in the changelog of this new version.

me too
Dear Mikrotik team, did you confirm this issue for fixing ? or not yet ?