...
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 but may sometimes be needed (e.g. temp. solution when two customers are migrating to single network infrastructure).
CE1 Router, cust-one
| Code Block | ||
|---|---|---|
| ||
/ip route add dst-address=10.4.4.0/24 gateway=10.1.1.2 |
...
CE2 Router, cust-one
| Code Block | ||
|---|---|---|
| ||
/ip route add dst-address=10.4.4.0/24 gateway=10.3.3.3 |
CE1 Router,
...
cust-two
| Code Block | ||
|---|---|---|
| ||
/ip address add address=10.4.4.5 interface=ether1 |
...
/ip route add dst-address=10.1.1.0/24 gateway=10.3.3.3 |
...
/ip route add dst-address=10.3.3.0/24 gateway=10.3.3.3 |
...
PE1 Router
| Code Block | ||
|---|---|---|
| ||
# replace the old VRF with this:
/ip route vrf add disabled=no routing-mark=cust-one route-distinguisher=1.1.1.1:111 \
|
...
export-route-targets=1.1.1.1:111 import-route-targets=1.1.1.1:111,2.2.2.2:222 interfaces=ether1 |
PE2 Router (Cisco)
| Code Block | ||
|---|---|---|
| ||
ip vrf cust-one |
...
rd 1.1.1.1:111 |
...
route-target export 1.1.1.1:111 |
...
route-target import 1.1.1.1:111 |
...
route-target import 2.2.2.2:222 exit |
...
ip vrf cust-two |
...
rd 2.2.2.2:222 |
...
route-target export 2.2.2.2:222 |
...
route-target import 1.1.1.1:111 |
...
route-target import 2.2.2.2:222 exit |
...
interface FastEthernet2/0 |
...
ip vrf forwarding cust-two |
...
ip address 10.4.4.3 255.255.255.0 router bgp 65000 |
...
address-family ipv4 vrf cust-two |
...
redistribute connected |
...
exit-address-family |
...
Variation: replace the Cisco with another MT
PE2 Mikrotik config
| Code Block | ||
|---|---|---|
| ||
/interface bridge add name=lobridge
/ip address
|
...
add address=10.2.2.3/24 interface=ether1
|
...
add address=10.3.3.3/24 interface=ether2
|
...
add address=10.4.4.3/24 interface=ether3
|
...
add address=10.5.5.3/32 interface=lobridge
/ip route vrf
|
...
add disabled=no routing-mark=cust-one route-distinguisher=1.1.1.1:111 \
|
...
export-route-targets=1.1.1.1:111 import-route-targets=1.1.1.1:111,2.2.2.2:222 \
|
...
interfaces=ether2
|
...
add disabled=no routing-mark=cust-two route-distinguisher=2.2.2.2:222 \
|
...
export-route-targets=2.2.2.2:222 import-route-targets=1.1.1.1:111,2.2.2.2:222 \
|
...
interfaces=ether3
/mpls ldp set enabled=yes transport-address=10.5.5.3
/mpls ldp interface add interface=ether1
/routing bgp instance set default as=65000
/routing bgp instance vrf add instance=default routing-mark=cust-one redistribute-connected=yes
/routing bgp instance vrf add instance=default routing-mark=cust-two redistribute-connected=yes
/routing bgp peer add remote-address=10.5.5.2 remote-as=65000 address-families=vpnv4 \
|
...
update-source=lobridge
|
...
# add route to the remote BGP peer's loopback address /ip route add dst-address=10.5.5.2/32 gateway=10.2.2.2 |
Results
The output of /ip route print now is interesting enough to deserve detailed observation.
| Code Block | ||
|---|---|---|
| ||
[admin@PE2] /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 ADb |
...
10.1.1.0/24 |
...
10.5.5.2 recurs... 20
|
...
1 ADC |
...
10.3.3.0/24 |
...
|
...
10.3.3.3 |
...
ether2 |
...
0
|
...
2 ADb |
...
10.4.4.0/24 20 3 ADb 10.1.1.0/24 10.5.5.2 |
...
recurs... 20 4 ADb 10.3.3.0/24 20 5 ADC 10.4.4.0/24 |
...
|
...
10.4.4.3 |
...
ether3 |
...
|
...
0
|
...
6 ADC |
...
10.2.2.0/24 |
...
10.2.2.3 |
...
|
...
ether1 |
...
|
...
0
|
...
7 A S |
...
10.5.5.2/32 |
...
|
...
10.2.2.2 reacha... 1
|
...
8 ADC |
...
10.5.5.3/32 |
...
10.5.5.3 |
...
|
...
lobridge |
...
|
...
0 |
The route 10.1.1.0/24 was received from 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 connected route in one table and as BGP route in another table. This has nothing to do with their being advertised via BGP. They are simply being "advertised" to local VPNv4 route table and locally reimported after that. Import and export route-targets determine in which tables they will end up.
This can be deduced from its attributes - they don't have the usual BGP properties. (Route 10.4.4.0/24.).)
| Code Block | ||
|---|---|---|
| ||
[admin@PE2] /ip route> print detail where routing-mark=cust-one
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
|
...
0 ADb |
...
dst-address=10.1.1.0/24 gateway=10.5.5.2 recursive via 10.2.2.2 ether1
|
...
distance=20 scope=40 target-scope=30 routing-mark=cust-one
|
...
bgp-local-pref=100 bgp-origin=incomplete
|
...
bgp-ext-communities="RT:1.1.1.1:111"
|
...
1 ADC |
...
dst-address=10.3.3.0/24 pref-src=10.3.3.3 gateway=ether2 distance=0 scope=10
|
...
routing-mark=cust-one
|
...
2 ADb |
...
dst-address=10.4.4.0/24 distance=20 scope=40 target-scope=10
|
...
routing-mark=cust-one bgp-ext-communities="RT:2.2.2.2:222" |
Static inter-VRF routes
In general it is recommended that all routes between VRF should be exchanged using BGP local import and export functionality. If that is not enough, static routes can be used to achieve this so-called route leaking.
...
The first way is to explicitly specify routing table in gateway field when adding route. This is only possible when leaking a route and gateway from the "main" routing table to a different routing table (VRF). Example:
| Code Block | ||
|---|---|---|
| ||
# add route to 5.5.5.0/24 in 'vrf1' routing table with gateway in the main routing table add dst-address=5.5.5.0/24 gateway=10.3.0.1@main routing-mark=vrf1 |
...
The second way is to explicitly specify interface in gateway field. The interface specified can belong to a VRF instance. Example:
| Code Block | ||
|---|---|---|
| ||
# add route to 5.5.5.0/24 in the main routing table with gateway at 'ether2' VRF interface add dst-address=5.5.5.0/24 gateway=10.3.0.1%ether2 routing-mark=main |
...
# add route to 5.5.5.0/24 in the main routing table with 'ptp-link-1' VRF interface as gateway add dst-address=5.5.5.0/24 gateway=ptp-link-1 routing-mark=main |
...
As can be observed, there are two variations possible - to specify gateway as ip_address%interface or to simply specify 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 address 1.2.3.4/24 on interface ether2 that is put in a VRF, there will be connected route to 1.2.3.0/24 in that VRF's routing table. It is acceptable to add static route 1.2.3.0/24 in a different routing table with interface-only gateway, even though ether2 is a broadcast interface:
| Code Block | ||
|---|---|---|
| ||
add dst-address=1.2.3.0/24 gateway=ether2 routing-mark=main |
References
RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)
...