Difference between revisions of "Manual:Virtual Routing and Forwarding"

From MikroTik Wiki
Jump to: navigation, search
Line 1: Line 1:
''Preliminary version - will be expanded!''
+
''Packages required: '''routing-test''', '''mpls-test'''''
  
== Description ==
+
= Description =
  
New '''routing-test''' package in version 3.x allows to create multiple Virtual Routing and Forwarding instances on a single router. This is useful for BGP based MPLS VPNs. Unlike MPLS BGP VPLS, which is OSI Layer 2 technology, BGP VPNs works in Layer 3 and as such exchanges IP prefixes between routers. VRFs solves the problem of overlapping IP prefixes, and provides the required privacy (via separated routing for different VPNs).
+
RouterOS 3.x allows to create multiple Virtual Routing and Forwarding instances on a single router. This is useful for BGP based MPLS VPNs. Unlike MPLS BGP VPLS, which is OSI Layer 2 technology, BGP VPNs works in Layer 3 and as such exchanges IP prefixes between routers. VRFs solves the problem of overlapping IP prefixes, and provides the required privacy (via separated routing for different VPNs).
  
 
To create a VRF, configure it under '''/ip route vrf'''. You can now add routes to that VRF - simply specify '''routing-mark''' attribute. Connected routes from interfaces belonging to a VRF will be installed in right routing table automatically.
 
To create a VRF, configure it under '''/ip route vrf'''. You can now add routes to that VRF - simply specify '''routing-mark''' attribute. Connected routes from interfaces belonging to a VRF will be installed in right routing table automatically.
Line 14: Line 14:
 
Active multiprotocol BGP routes are installed in a separate routing table, which can be observed at '''/routing bgp vpnv4-route'''. These so called VPNv4 routes has prefix that consists of '''route-distinguisher''' and an IPv4 route prefix. This way you can have overlapping IPv4 prefixes distributed in BGP. '''route-distinguisher''' can be configured under '''/ip route vrf'''. Usually there will be one-to-one correspondence between route-distinguishers and VRFs, but that's not a mandatory requirement.
 
Active multiprotocol BGP routes are installed in a separate routing table, which can be observed at '''/routing bgp vpnv4-route'''. These so called VPNv4 routes has prefix that consists of '''route-distinguisher''' and an IPv4 route prefix. This way you can have overlapping IPv4 prefixes distributed in BGP. '''route-distinguisher''' can be configured under '''/ip route vrf'''. Usually there will be one-to-one correspondence between route-distinguishers and VRFs, but that's not a mandatory requirement.
  
Please note that a VPNv4 route will be distributed only if it has a valid MPLS label. You need to install '''mpls''' or '''mpls-test''' package and configure valid label range (default is OK) for this to work.
+
Please note that a VPNv4 route will be distributed only if it has a valid MPLS label. You need to install '''mpls''' or '''mpls-test''' package and configure valid label range for this to work. (The label range is configured by default.)
  
== An example with Cisco ==
+
= Examples =
  
In this example we create two VPNs for cust-one and cust-two, and exchange all routes between them.
+
== The simplest MPLS VPN setup ==
  
[[Image:VRF.png]]
+
[[Image:l3vpn-simple.png]]
  
=== Configuration  ===
+
In this example rudimentary MPLS backbone (consisting of PE1 and PE2 routers) is created and configured to forward traffic between CE1 and CE2
 +
routers that belong to ''cust-one'' VPN.
  
'''Mikrotik''':
+
=== CE1 Router ===
  
Addresses are like this:
+
  /ip address add address=10.1.1.1/24 interface=ether1
  [admin@MikroTik] > /ip address p
+
# use static routing
Flags: X - disabled, I - invalid, D - dynamic
+
/ip route add dst-address=10.3.3.0/24 gateway=10.1.1.2
  #  ADDRESS            NETWORK        BROADCAST      INTERFACE
 
  0  10.0.0.131/24     10.0.0.0        10.0.0.255      ether1
 
  1  1.1.1.1/24         1.1.1.0        1.1.1.255      ether2
 
  
Add default route:
+
=== CE2 Router ===
/ip route add gateway=10.0.0.1
 
  
Configure VRFs:
+
  /ip address add address=10.3.3.4/24 interface=ether1
  /ip route vrf add interfaces=ether2 route-distinguisher=1.1.1.1:111 export-route-targets=1.1.1.1:111 \
+
  /ip route add dst-address=10.1.1.0/24 gateway=10.3.3.3
    import-route-targets=1.1.1.1:111,2.2.2.2:222 routing-mark=cust-one
 
 
 
  /ip route vrf add interfaces=ether3 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 routing-mark=cust-two
 
  
Configure VPNv4 redistribution and multiprotocol BGP:
 
/routing bgp instance set default as=64550 redistribute-connected=yes vrf=cust-one,cust-two
 
/routing bgp peer add remote-address=10.0.11.202 remote-as=64550 instance=default address-families=vpnv4
 
  
'''Cisco''': (note that VRF names are not important, they are the same on both MT and Cisco only by convention)
+
=== PE1 Router ===
interface FastEthernet0/0
 
  ip address 10.0.11.202 255.255.255.0
 
 
 
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 Tunnel1
 
  ip vrf forwarding cust-one
 
  ip address 2.2.2.2 255.255.255.0
 
  tunnel source 10.0.11.202
 
  tunnel destination X.X.X.X
 
 
 
interface Tunnel2
 
  ip vrf forwarding cust-two
 
  ip address 3.3.3.3 255.255.255.0
 
  tunnel source 10.0.11.202
 
  tunnel destination Y.Y.Y.Y
 
 
 
router bgp 64550
 
  neighbor 10.0.0.131 remote-as 64550
 
  address-family vpnv4
 
  neighbor 10.0.0.131 activate
 
  neighbor 10.0.0.131 send-community both
 
  exit-address-family
 
  address-family ipv4 vrf cust-one
 
  redistribute connected
 
  exit-address-family
 
  address-family ipv4 vrf cust-two
 
  redistribute connected
 
  exit-address-family
 
  
 +
/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 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 interfaces=ether1
 +
/mpls ldp set enabled=yes transport-address=10.5.5.2
 +
/mpls ldp interface add interface=ether2
 +
/routing bgp instance set default as=65000 redistribute-connected=yes vrf=cust-one
 +
/routing bgp peer add remote-address=10.5.5.3 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.3/32 gateway=10.2.2.3
 +
 +
=== PE2 Router (Cisco) ===
 +
<pre>
 +
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
 +
exit
 +
 +
interface Loopback0
 +
ip address 10.5.5.3 255.255.255.255
 +
 +
mpls ldp router-id Loopback0 force
 +
mpls label protocol ldp
 +
 +
interface FastEthernet0/0
 +
ip address 10.2.2.3 255.255.255.0
 +
mpls ip
 +
 +
interface FastEthernet1/0
 +
ip vrf forwarding cust-one
 +
ip address 10.3.3.3 255.255.255.0
 +
 +
router bgp 65000
 +
neighbor 10.5.5.2 remote-as 65000
 +
neighbor 10.5.5.2 update-source Loopback0
 +
address-family vpnv4
 +
  neighbor 10.5.5.2 activate
 +
  neighbor 10.5.5.2 send-community both
 +
  exit-address-family
 +
address-family ipv4 vrf cust-one
 +
  redistribute connected
 +
  exit-address-family
 +
 +
ip route 10.5.5.2 255.255.255.255 10.2.2.2
 +
</pre>
 
=== Results ===
 
=== Results ===
  
==== Cisco ====
+
Check that VPNv4 route redistribution is working:
 +
<pre>
 +
[admin@PE1] > /routing bgp vpnv4-route print detail
 +
Flags: L - label present
 +
0 L route-distinguisher=1.1.1.1:111 dst-address=10.3.3.0/24 gateway=10.5.5.3
 +
    interface=ether2 in-label=17 out-label=17 bgp-local-pref=100 bgp-med=0
 +
    bgp-origin=incomplete bgp-ext-communities="RT:1.1.1.1:111"
 +
 
 +
1 L route-distinguisher=1.1.1.1:111 dst-address=10.1.1.0/24 interface=ether1
 +
    in-label=16 bgp-ext-communities="RT:1.1.1.1:111"
 +
</pre>
 +
Check that the 10.3.3.0 is installed in IP routes, in cust-one route table:
 +
 
 +
[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
  
'''VPNv4 routing table:'''
+
Let's take 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 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.
 +
<pre>
 +
[admin@PE1] /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 ADC  dst-address=10.1.1.0/24 pref-src=10.1.1.2 gateway=ether1 distance=0 scope=10
 +
        routing-mark=cust-one
  
  C7200#show ip bgp vpnv4 all
+
  1 ADb  dst-address=10.3.3.0/24 gateway=10.5.5.3 recursive via 10.2.2.3 ether2
BGP table version is 20, local router ID is 10.0.11.202
+
        distance=20 scope=40 target-scope=30 routing-mark=cust-one
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
+
        bgp-local-pref=100 bgp-origin=incomplete
              r RIB-failure, S Stale
+
        bgp-ext-communities="RT:1.1.1.1:111"
Origin codes: i - IGP, e - EGP, ? - incomplete
+
</pre>
    Network          Next Hop            Metric LocPrf Weight Path
+
The same for Cisco:
Route Distinguisher: 1.1.1.1:111 (default for vrf cust-one)
+
<pre>
*>i1.1.1.0/24      10.0.0.131                    100      0 ?
+
PE2#show ip bgp vpnv4 all
*> 2.2.2.0/24      0.0.0.0                  0        32768 ?
+
BGP table version is 5, local router ID is 10.5.5.3
*> 3.3.3.0/24      0.0.0.0                  0        32768 ?
+
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
Route Distinguisher: 2.2.2.2:222 (default for vrf cust-two)
+
              r RIB-failure, S Stale
*>i1.1.1.0/24      10.0.0.131                    100      0 ?
+
Origin codes: i - IGP, e - EGP, ? - incomplete
*> 2.2.2.0/24      0.0.0.0                  0        32768 ?
 
*> 3.3.3.0/24      0.0.0.0                  0        32768 ?
 
  
'''Routing table for customer one:'''
+
  Network          Next Hop            Metric LocPrf Weight Path
 +
Route Distinguisher: 1.1.1.1:111 (default for vrf cust-one)
 +
*>i10.1.1.0/24      10.5.5.2                      100      0 ?
 +
*> 10.3.3.0/24      0.0.0.0                  0        32768 ?
  
C7200#show ip route vrf cust-one
+
PE2#show ip route vrf cust-one
Routing Table: cust-one
+
 
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
+
Routing Table: cust-one
 +
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
 
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
Line 122: Line 153:
 
       ia - IS-IS inter area, * - candidate default, U - per-user static route
 
       ia - IS-IS inter area, * - candidate default, U - per-user static route
 
       o - ODR, P - periodic downloaded static route
 
       o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
 
    1.0.0.0/24 is subnetted, 1 subnets
 
B      1.1.1.0 [200/0] via 10.0.0.131, 00:02:51
 
    2.0.0.0/24 is subnetted, 1 subnets
 
C      2.2.2.0 is directly connected, Tunnel1
 
    3.0.0.0/24 is subnetted, 1 subnets
 
B      3.3.3.0 is directly connected, 00:01:20, Tunnel2
 
  
==== Mikrotik ====
+
Gateway of last resort is not set
  
'''VPNv4 routing table:'''
+
    10.0.0.0/24 is subnetted, 1 subnets
[admin@MikroTik] > vpnv4-route print detail
+
B       10.1.1.0 [200/0] via 10.5.5.2, 00:05:33
Flags: N - no label
+
    10.0.0.0/24 is subnetted, 1 subnets
  0   route-distinguisher=1.1.1.1:111 dst-address=2.2.2.0/24 gateway=10.0.11.202
+
C      10.3.3.0 is directly connected, FastEthernet1/0
       interface=ether1 in-label=17 out-label=16 bgp-local-pref=100 bgp-med=0
+
</pre>
      bgp-origin=incomplete bgp-ext-communities="RT:1.1.1.1:111"
+
You should be able to ping from CE1 to CE2 and vice versa.
&nbsp;
 
  1  route-distinguisher=2.2.2.2:222 dst-address=3.3.3.0/24 gateway=10.0.11.202
 
      interface=ether1 in-label=18 out-label=17 bgp-local-pref=100 bgp-med=0
 
      bgp-origin=incomplete bgp-ext-communities="RT:2.2.2.2:222"
 
&nbsp;
 
  2  route-distinguisher=1.1.1.1:111 dst-address=1.1.1.0/24 interface=ether2
 
      in-label=16 bgp-ext-communities="RT:1.1.1.1:111"
 
  
'''All IP routing tables:'''
+
[admin@CE1] > /ping 10.3.3.4
 +
10.3.3.4 64 byte ping: ttl=62 time=18 ms
 +
10.3.3.4 64 byte ping: ttl=62 time=13 ms
 +
10.3.3.4 64 byte ping: ttl=62 time=13 ms
 +
10.3.3.4 64 byte ping: ttl=62 time=14 ms
 +
4 packets transmitted, 4 packets received, 0% packet loss
 +
round-trip min/avg/max = 13/14.5/18 ms
  
[admin@MikroTik] > /ip route p detail
+
== A more complicated setup ==
Flags: X - disabled, A - active, D - dynamic,
+
 
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
+
[[Image:l3vpn-two-customers.png]]
B - blackhole, U - unreachable, P - prohibit
+
 
  &nbsp;
+
As opposed to the simplest setup, in this example we have two customers: cust-one and cust-two.
  # ---------------------- routes for customer 1 --------------------------
+
 
  # a connected route that is bound to a particular VRF
+
We configure two VPNs for then, cust-one and cust-two respectively, and exchange all routes between them.
  0 ADC  dst-address=1.1.1.0/24 pref-src=1.1.1.1 interface=ether2 distance=0 scope=10
+
 
        routing-mark=cust-one
+
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).
  &nbsp;
+
 
  # this route is received from Cisco and imported to customer's 1 VRF
+
=== CE1 Router (''cust-one'') ===
  1 ADb  dst-address=2.2.2.0/24 gateway=10.0.11.202 interface=ether1 gateway-table=main
+
/ip route add dst-address=10.4.4.0/24 gateway=10.1.1.2
        gateway-state=recursive distance=20 scope=40 target-scope=30
+
 
        routing-mark=cust-one bgp-local-pref=100 bgp-med=0 bgp-origin=incomplete
+
=== CE2 Router (''cust-one'') ===
        bgp-ext-communities="RT:1.1.1.1:111"
+
/ip route add dst-address=10.4.4.0/24 gateway=10.3.3.3
   &nbsp;
+
 
   # from Cisco
+
=== CE1 Router (''cust-two'')  ===
   2 ADb  dst-address=3.3.3.0/24 gateway=10.0.11.202 interface=ether1 gateway-table=main
+
/ip address add address=10.4.4.5 interface=ether1
        gateway-state=recursive distance=20 scope=40 target-scope=30
+
/ip route add dst-address=10.1.1.0/24 gateway=10.3.3.3
        routing-mark=cust-one bgp-local-pref=100 bgp-med=0 bgp-origin=incomplete
+
/ip route add dst-address=10.3.3.0/24 gateway=10.3.3.3
        bgp-ext-communities="RT:2.2.2.2:222"
+
 
  &nbsp;
+
=== PE1 Router ===  
   # ---------------------- routes for customer 2 --------------------------
+
 
  # "locally" reimported via bgp to a different table
+
# replace the old VRF with this:
  3 ADb  dst-address=1.1.1.0/24 distance=20 routing-mark=cust-two
+
/ip route vrf add disabled=no routing-mark=cust-one route-distinguisher=1.1.1.1:111 \
        bgp-ext-communities="RT: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
  &nbsp;
+
 
  # from Cisco and imported to customer's 2 VRF
+
=== PE2 Router (Cisco) ===
  4 ADb dst-address=2.2.2.0/24 gateway=10.0.11.202 interface=ether1 gateway-table=main
+
<pre>
        gateway-state=recursive distance=20 scope=40 target-scope=30
+
ip vrf cust-one
        routing-mark=cust-two bgp-local-pref=100 bgp-med=0 bgp-origin=incomplete
+
rd 1.1.1.1:111
        bgp-ext-communities="RT:1.1.1.1:111"
+
route-target export 1.1.1.1:111
  &nbsp;
+
route-target import 1.1.1.1:111
  # from Cisco
+
route-target import 2.2.2.2:222
  5 ADb  dst-address=3.3.3.0/24 gateway=10.0.11.202 interface=ether1 gateway-table=main
+
exit
        gateway-state=recursive distance=20 scope=40 target-scope=30
+
 
        routing-mark=cust-two bgp-local-pref=100 bgp-med=0 bgp-origin=incomplete
+
ip vrf cust-two
        bgp-ext-communities="RT:2.2.2.2:222"
+
rd 2.2.2.2:222
  &nbsp;
+
route-target export 2.2.2.2:222
  # ------------------------- "main" table ------------------------------
+
route-target import 1.1.1.1:111
  6 A S dst-address=0.0.0.0/0 gateway=10.0.0.1 interface=ether1 gateway-table=main
+
route-target import 2.2.2.2:222
        gateway-state=reachable distance=1 scope=30 target-scope=10
+
exit
  &nbsp;
+
 
  7 ADC dst-address=10.0.0.0/24 pref-src=10.0.0.131 interface=ether1 distance=0
+
interface FastEthernet2/0
        scope=10
+
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
 +
</pre>
 +
== Variation: replace the Cisco with another MT ==
 +
 
 +
=== PE2 Mikrotik config ===
 +
/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 redistribute-connected=yes vrf=cust-one,cust-two
 +
/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.
 +
<pre>
 +
[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
 +
</pre>
 +
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 observed from it's attributes - they don't have the usual BGP properties. (Route 10.4.4.0/24.)
 +
<pre>
 +
[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"
 +
</pre>
  
== References ==
+
= References =
 
[http://www.ietf.org/rfc/rfc4364.txt RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)]
 
[http://www.ietf.org/rfc/rfc4364.txt RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)]
  

Revision as of 17:06, 9 April 2009

Packages required: routing-test, mpls-test

Description

RouterOS 3.x allows to create multiple Virtual Routing and Forwarding instances on a single router. This is useful for BGP based MPLS VPNs. Unlike MPLS BGP VPLS, which is OSI Layer 2 technology, BGP VPNs works in Layer 3 and as such exchanges IP prefixes between routers. VRFs solves the problem of overlapping IP prefixes, and provides the required privacy (via separated routing for different VPNs).

To create a VRF, configure it under /ip route vrf. You can now add routes to that VRF - simply specify routing-mark attribute. Connected routes from interfaces belonging to a VRF will be installed in right routing table automatically.

Technically VRFs are based on policy routing. There is exactly one policy routing table for each active VRF. Note that existing policy routing support will not be changed, but you will not be able to have policy routing within a VRF. The main difference between VRF tables and simple policy routing is that routes in VRF tables resolve nexthops in their own routing table by default, while policy routes always use main routing table. Read-only route attribute gateway-table displays information about which table is used for a particular route (default is main).

The real fun begins when you start to configure BGP. You can use multiprotocol BGP to distribute those routes - not only to other routers, but also to different routing tables in the router itself. Route installation in VRF tables is controlled by BGP extended communities attribute. Configure import and export lists under /ip route vrf, import-route-target and export-route-target. Export route target list for a VRF should contained at least the route distinguisher for that VRF.

Active multiprotocol BGP routes are installed in a separate routing table, which can be observed at /routing bgp vpnv4-route. These so called VPNv4 routes has prefix that consists of route-distinguisher and an IPv4 route prefix. This way you can have overlapping IPv4 prefixes distributed in BGP. route-distinguisher can be configured under /ip route vrf. Usually there will be one-to-one correspondence between route-distinguishers and VRFs, but that's not a mandatory requirement.

Please note that a VPNv4 route will be distributed only if it has a valid MPLS label. You need to install mpls or mpls-test package and configure valid label range for this to work. (The label range is configured by default.)

Examples

The simplest MPLS VPN setup

L3vpn-simple.png

In this example rudimentary MPLS backbone (consisting of PE1 and PE2 routers) is created and configured to forward traffic between CE1 and CE2 routers that belong to cust-one VPN.

CE1 Router

/ip address add address=10.1.1.1/24 interface=ether1
# use static routing
/ip route add dst-address=10.3.3.0/24 gateway=10.1.1.2

CE2 Router

/ip address add address=10.3.3.4/24 interface=ether1
/ip route add dst-address=10.1.1.0/24 gateway=10.3.3.3


PE1 Router

/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 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 interfaces=ether1
/mpls ldp set enabled=yes transport-address=10.5.5.2
/mpls ldp interface add interface=ether2
/routing bgp instance set default as=65000 redistribute-connected=yes vrf=cust-one
/routing bgp peer add remote-address=10.5.5.3 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.3/32 gateway=10.2.2.3

PE2 Router (Cisco)

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
 exit

interface Loopback0
 ip address 10.5.5.3 255.255.255.255

mpls ldp router-id Loopback0 force
mpls label protocol ldp

interface FastEthernet0/0
 ip address 10.2.2.3 255.255.255.0
 mpls ip

interface FastEthernet1/0
 ip vrf forwarding cust-one
 ip address 10.3.3.3 255.255.255.0

router bgp 65000
 neighbor 10.5.5.2 remote-as 65000
 neighbor 10.5.5.2 update-source Loopback0
 address-family vpnv4
  neighbor 10.5.5.2 activate
  neighbor 10.5.5.2 send-community both
  exit-address-family
 address-family ipv4 vrf cust-one
  redistribute connected
  exit-address-family

ip route 10.5.5.2 255.255.255.255 10.2.2.2

Results

Check that VPNv4 route redistribution is working:

[admin@PE1] > /routing bgp vpnv4-route print detail
Flags: L - label present
 0 L route-distinguisher=1.1.1.1:111 dst-address=10.3.3.0/24 gateway=10.5.5.3
     interface=ether2 in-label=17 out-label=17 bgp-local-pref=100 bgp-med=0
     bgp-origin=incomplete bgp-ext-communities="RT:1.1.1.1:111"

 1 L route-distinguisher=1.1.1.1:111 dst-address=10.1.1.0/24 interface=ether1
     in-label=16 bgp-ext-communities="RT:1.1.1.1:111"

Check that the 10.3.3.0 is installed in IP routes, in cust-one route table:

[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 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 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.

[admin@PE1] /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 ADC  dst-address=10.1.1.0/24 pref-src=10.1.1.2 gateway=ether1 distance=0 scope=10
        routing-mark=cust-one

 1 ADb  dst-address=10.3.3.0/24 gateway=10.5.5.3 recursive via 10.2.2.3 ether2
        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"

The same for Cisco:

PE2#show ip bgp vpnv4 all
BGP table version is 5, local router ID is 10.5.5.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1.1.1.1:111 (default for vrf cust-one)
*>i10.1.1.0/24      10.5.5.2                      100      0 ?
*> 10.3.3.0/24      0.0.0.0                  0         32768 ?

PE2#show ip route vrf cust-one

Routing Table: cust-one
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 1 subnets
B       10.1.1.0 [200/0] via 10.5.5.2, 00:05:33
     10.0.0.0/24 is subnetted, 1 subnets
C       10.3.3.0 is directly connected, FastEthernet1/0

You should be able to ping from CE1 to CE2 and vice versa.

[admin@CE1] > /ping 10.3.3.4
10.3.3.4 64 byte ping: ttl=62 time=18 ms
10.3.3.4 64 byte ping: ttl=62 time=13 ms
10.3.3.4 64 byte ping: ttl=62 time=13 ms
10.3.3.4 64 byte ping: ttl=62 time=14 ms
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 13/14.5/18 ms

A more complicated setup

L3vpn-two-customers.png

As opposed to the simplest setup, in this example we have two customers: cust-one and cust-two.

We configure two VPNs for then, cust-one and cust-two respectively, and exchange all routes between them.

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)

/ip route add dst-address=10.4.4.0/24 gateway=10.1.1.2

CE2 Router (cust-one)

/ip route add dst-address=10.4.4.0/24 gateway=10.3.3.3

CE1 Router (cust-two)

/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

# 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)

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

/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 redistribute-connected=yes vrf=cust-one,cust-two
/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.

[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 observed from it's attributes - they don't have the usual BGP properties. (Route 10.4.4.0/24.)

[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"

References

RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)

MPLS Fundamentals, chapter 7, Luc De Ghein, Cisco Press 2006