Difference between revisions of "Manual:Virtual Routing and Forwarding"
|Line 25:||Line 25:|
In this example rudimentary MPLS backbone (consisting of two Provider
In this example rudimentary MPLS backbone (consisting of two Provider Edge (PE) routers PE1 and PE2) is created and configured to forward traffic between Edge (CE) routers CE1 and CE2
routers that belong to ''cust-one'' VPN.
routers that belong to ''cust-one'' VPN.
Revision as of 12:27, 22 October 2009
Packages required: routing-test, mpls-test
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 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).
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 the right routing table automatically.
Technically VRFs are based on policy routing. There is exactly one policy route table for each active VRF. The existing policy routing support in MT RouterOS is not changed; but on the other hand, it is not possible to have policy routing within a VRF. The main differences between VRF tables and simple policy routing are:
- Routes in VRF tables resolve next-hops in their own route table by default, while policy routes always use the main route table. Read-only route attribute gateway-table displays information about which table is used for a particular route (default is main).
- Route lookup is different. For policy routing: after route lookup has been done in policy-route table, and no route was found, route lookup proceeds to the main route table. For VRFs: if lookup is done, and no route is found in VRF route table, the lookup fails with "network unreachable" error. (You can still override this behavior with custom route lookup rules, as they have precedence.)
You can use multi-protocol BGP with VPNv4 address family to distribute routes from VRF route tables - not only to other routers, but also to different routing tables in the router itself. First configure the route distinguisher for a VRF. It can be done under /ip route vrf. Usually there will be one-to-one correspondence between route distinguishers and VRFs, but that's not a mandatory requirement. Route installation in VRF tables is controlled by BGP extended communities attribute. Configure import and export lists under /ip route vrf, import-route-targets and export-route-targets. Export route target list for a VRF should contained at least the route distinguisher for that VRF. Then configure a list of VRFs for each BGP instance that will participate in VRF routing.
Once list of VRFs for BGP instance, route distinguisher and export route targets has been configured, some active VPNv4 address family routes may be created, depending on BGP redistribution settings. They are installed in a separate route table and, if present, visible under /routing bgp vpnv4-route. These so called VPNv4 routes have prefix that consists of a route distinguisher and an IPv4 network prefix. This way you can have overlapping IPv4 prefixes distributed in BGP.
Please note that a VPNv4 route will be distributed only if it has a valid MPLS label. You need to install mpls-test package and configure valid label range for this to work. (Default configuration has valid label range.)
The simplest MPLS VPN setup
In this example rudimentary MPLS backbone (consisting of two Provider Edge (PE) routers PE1 and PE2) is created and configured to forward traffic between Customer Edge (CE) routers CE1 and CE2 routers that belong to cust-one VPN.
/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
/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
/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=184.108.40.206:111 \ export-route-targets=220.127.116.11:111 import-route-targets=18.104.22.168: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 /routing bgp instance vrf add instance=default routing-mark=cust-one redistribute-connected=yes /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 22.214.171.124:111 route-target export 126.96.36.199:111 route-target import 188.8.131.52: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
Check that VPNv4 route redistribution is working:
[admin@PE1] > /routing bgp vpnv4-route print detail Flags: L - label present 0 L route-distinguisher=184.108.40.206: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:220.127.116.11:111" 1 L route-distinguisher=18.104.22.168:111 dst-address=10.1.1.0/24 interface=ether1 in-label=16 bgp-ext-communities="RT:22.214.171.124: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:126.96.36.199: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: 188.8.131.52: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 (changes only)
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
# replace the old VRF with this: /ip route vrf add disabled=no routing-mark=cust-one route-distinguisher=184.108.40.206:111 \ export-route-targets=220.127.116.11:111 import-route-targets=18.104.22.168:111,22.214.171.124:222 interfaces=ether1
PE2 Router (Cisco)
ip vrf cust-one rd 126.96.36.199:111 route-target export 188.8.131.52:111 route-target import 184.108.40.206:111 route-target import 220.127.116.11:222 exit ip vrf cust-two rd 18.104.22.168:222 route-target export 22.214.171.124:222 route-target import 126.96.36.199:111 route-target import 188.8.131.52: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=184.108.40.206:111 \ export-route-targets=220.127.116.11:111 import-route-targets=18.104.22.168:111,22.214.171.124:222 \ interfaces=ether2 add disabled=no routing-mark=cust-two route-distinguisher=126.96.36.199:222 \ export-route-targets=188.8.131.52:222 import-route-targets=184.108.40.206:111,220.127.116.11: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
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 deduced from its 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:18.104.22.168: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:22.214.171.124:222"
MPLS Fundamentals, chapter 7, Luc De Ghein, Cisco Press 2006