...
RouterOS allows to create multiple Virtual Routing and Forwarding instances on a single router. This is useful for BGP-based MPLS VPNs. Unlike BGP VPLS, which is OSI Layer 2 technology, BGP VRF VPNs work in Layer 3 and as such exchange IP prefixes between routers. VRFs solve the problem of overlapping IP prefixes , and provide the required privacy (via separated routing for different VPNs).
...
VRF table is created in/ip vrf menu. After the VRF config is created routing table mapping is added (a dynamic table with the same name is created). Each active VRF will always have a mapped routing table.
...
As can be observed, there are two variations possible - to specify gateway as ip_address%interface or to simply specify an interface. The first should be used for broadcast interfaces in most cases. The second should be used for point-to-point interfaces, and also for broadcast interfaces, if the route is a connected route in some VRF. For example, if you have an address 1.2.3.4/24 on interface ether2 that is put in a VRF, there will be a connected route to 1.2.3.0/24 in that VRF's routing table. It is acceptable to add a static route 1.2.3.0/24 in a different routing table with an interface-only gateway, even though ether2 is a broadcast interface:
...
| Code Block | ||
|---|---|---|
| ||
/interface bridge add name=lobridge
/ip address add address=10.1.1.2/24 interface=ether1
/ip address add address=10.2.2.2/24 interface=ether2
/ip address add address=10.5.5.2/32 interface=lobridge
/ip vrf add name=cust-one interfaces=ether1
/mpls ldp add enabled=yes transport-address=10.5.5.2 lsr-id=10.5.5.2
/mpls ldp interface add interface=ether2
/routing bgp template set default as=65000
/routing bgp vpn
add vrf=cust-one redistribute=connected \
route-distinguisher=1.1.1.1:111 \
import-route-targets=1.1.1.1:111 \
export-route-targets=1.1.1.1:111 \
label-allocation-policy=per-vrf
/routing bgp connection
add template=default remote.address=10.5.5.3 address-families=vpnv4 local.address=10.5.5.2
# add route to the remote BGP peer's loopback address
/ip route add dst-address=10.5.5.3/32 gateway=10.2.2.3 |
...
Check that the 10.3.3.0 is installed in IP routes, in the cust-one route table:
| Code Block | ||
|---|---|---|
| ||
[admin@PE1] > /ip route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 ADC 10.1.1.0/24 10.1.1.2 ether1 0 1 ADb 10.3.3.0/24 10.5.5.3 recursi... 20 2 ADC 10.2.2.0/24 10.2.2.2 ether2 0 3 ADC 10.5.5.2/32 10.5.5.2 lobridge 0 4 A S 10.5.5.3/32 10.2.2.3 reachab... 1 |
Let's take a closer look at IP routes in cust-one VRF. The 10.1.1.0/24 IP prefix is a connected route that belongs to an interface that was configured to belong to cust-one VRF. The 10.3.3.0/24 IP prefix was advertised via BGP as a VPNv4 route from PE2 and is imported in this VRF routing table, because our configured import-route-targets matched the BGP extended communities attribute it was advertised with.
...
As opposed to the simplest setup, in this example, we have two customers: cust-one and cust-two.
We configure two VPNs for thenthem, cust-one and cust-two respectively, and exchange all routes between them. (This is also called "route leaking").
Note that this could be not the most typical setup, because routes are usually not exchanged between different customers. In contrast, by default, it should not be possible to gain access from one VRF site to a different VRF site in another VPN. (This is the "Private" aspect of VPNs.) Separate routing is a way to provide privacy; , and it is also required to solve the problem of overlapping IP network prefixes. Route exchange is in direct conflict with these two requirement requirements but may sometimes be needed (e.g. temp. solution when two customers are migrating to a single network infrastructure).
...
The route 10.1.1.0/24 was received from a remote BGP peer and is installed in both VRF routing tables.
The routes 10.3.3.0/24 and 10.4.4.0/24 are also installed in both VRF routing tables. Each is as a connected route in one table and as a BGP route in another table. This has nothing to do with their being advertised via BGP. They are simply being "advertised" to the local VPNv4 route table and locally reimported after that. Import and export route-targets determine in which tables they will end up.
...
Leaking routes between VRFs
Currently, there are is no mechanism to leak routes from one VRF instance to an other another within the same router.
As a workaround, it is possible to create a tunnel between two locally configure loopback addresses and assign each tunnel endpoint to its own VRF. Then it is possible tun to run either dynamic routing protocols or set up static routes to leak between both VRFs.
Downside The downside of this approach is that tunnel must be created between between each VRF where routes should be leaked (create a full mesh), which significantly complicates configuration even if there is are just several VRFs, not to mention more complicated setups.
...