L3VRF configuration¶
There are a list of necessary elements to know when making an L3VRF configuration.
Basic elements for configuration¶
When making an L3VRF configuration, a unique routing table table-id must be assigned to the L3VRF.
The configuration below creates an L3VRF named l3vrf1
inside VRF main
.
vsr running config# / vrf main l3vrf l3vrf1 table-id 10
Conversely, it is possible to suppress L3VRF configuration as below:
vsr running config# del / vrf main l3vrf l3vrf1
Note that the l3vrf name cannot be default
, as this keyword is reserved in each
VRF to reference the default L3VRF, which stands for the default routing
table of the VRF (table main
, table-id 254).
Also, the L3VRF name must not conflict with another interface name in the same
VRF and must be chosen wisely. Moreover, the chosen table-id
value cannot be
254
as it conflicts with the main
routing table.
The following table summarizes the possible values as well as forbidden values for l3vrf name and table-id:
Parameter |
Allowed values |
Forbidden values (reserved by the system) |
---|---|---|
l3vrf name |
string between 1 and 15 alphanumeric characters except Forbidden values |
‘all’, ‘default’ |
table identifier |
any 32 bit unsigned integer except Forbidden values |
‘0’, ‘253’, ‘254’, ‘255’ |
To create a routing domain with L3VRF, just bind interfaces to a given L3VRF as below:
vsr running config# / vrf main l3vrf l3vrf1 table-id 10
vsr running config# / vrf main l3vrf l3vrf1 interface physical eth1 port pci-b0s4
vsr running config# / vrf main l3vrf l3vrf1 interface physical eth1 ipv4 address 10.100.0.1/24
vsr running config# / vrf main l3vrf l3vrf1 interface physical eth1 ipv6 address fd00:100::1/64
A check can be done about routing table associated to L3VRF l3vrf1
by issuing one
of the two proposed commands:
To display the routes in a specific L3VRF, use the following command:
vsr> show ipv4-routes l3vrf l3vrf1
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, N - NHRP, T - Table
> - selected route, * - FIB route, r - rejected, b - backup
L3VRF l3vrf1:
K>* 0.0.0.0/0 [255/8192] unreachable (ICMP unreachable), 00:00:01
C>* 10.100.0.0/24 is directly connected, eth1, 00:00:01
2 routes displayed.
Note that the keyword VRF
in the output stands for the L3VRF name, not the
VRF name (which is main
).
As you can see, the connected route for the eth0
interface address is in the
l3vrf1
routing table, instead of the main
table.
You can also reference the L3VRF routing table table-id instead:
vsr> show ipv4-routes table 10
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, N - NHRP, T - Table
> - selected route, * - FIB route, r - rejected, b - backup
L3VRF l3vrf1:
K>* 0.0.0.0/0 [255/8192] unreachable (ICMP unreachable), 00:00:03
C>* 10.100.0.0/24 is directly connected, eth1, 00:00:03
2 routes displayed.
Note that when specifying the table-id, the route output does not care about L3VRFs, it considers the routing table as an ordinary routing table.
To dump the IPv6 routes, the following command can be used:
vsr> show ipv6-routes l3vrf l3vrf1
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
> - selected route, * - FIB route, r - rejected, b - backup
L3VRF l3vrf1:
K>* ::/0 [255/8192] unreachable (ICMP unreachable), 00:00:04
C>* fd00:100::/64 is directly connected, eth1, 00:00:02
C>* fe80::/64 is directly connected, eth1, 00:00:03
3 routes displayed.
vsr> show ipv6-routes table 10
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
> - selected route, * - FIB route, r - rejected, b - backup
L3VRF l3vrf1:
K>* ::/0 [255/8192] unreachable (ICMP unreachable), 00:00:05
C>* fd00:100::/64 is directly connected, eth1, 00:00:03
C>* fe80::/64 is directly connected, eth1, 00:00:04
3 routes displayed.
As explained in the L3VRF overview.
routing tables are parsed according to the PBR rules,
creating L3VRFs automatically adds an intermediate rule of priority 1000, so that if an inbound interface is bound to an L3VRF, route lookups for packets coming from that interface are performed in a the L3VRF routing table (instead of the
main
table),a default unreachable route is added at the end of each L3VRF routing table, in order to avoid resuming route lookup in the default L3VRF if no route was found.
If the user prefers that packets be silently dropped instead of triggering an ICMP unreachable message when no route is found in the L3VRF table, it is possible to override the default behaviour by adding blackhole routes in an L3VRF routing table, as follows:
vsr running config# / vrf main l3vrf l3vrf1 routing static ipv4-route 0.0.0.0/0 next-hop blackhole distance 254
vsr running config# / vrf main l3vrf l3vrf1 routing static ipv6-route ::/0 next-hop blackhole distance 254
The resulting routes can be checked.
vsr> show ipv4-routes l3vrf l3vrf1
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, N - NHRP, T - Table
> - selected route, * - FIB route, r - rejected, b - backup
L3VRF l3vrf1:
S>* 0.0.0.0/0 [254/0] unreachable (blackhole), weight 1, 00:00:01
K * 0.0.0.0/0 [255/8192] unreachable (ICMP unreachable), 00:00:08
C>* 10.100.0.0/24 is directly connected, eth1, 00:00:08
2 routes displayed.
vsr> show ipv6-routes l3vrf l3vrf1
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
> - selected route, * - FIB route, r - rejected, b - backup
L3VRF l3vrf1:
S>* ::/0 [254/0] unreachable (blackhole), weight 1, 00:00:02
K * ::/0 [255/8192] unreachable (ICMP unreachable), 00:00:09
C>* fd00:100::/64 is directly connected, eth1, 00:00:07
C>* fe80::/64 is directly connected, eth1, 00:00:08
3 routes displayed.
To establish a forwarding scenario in a given L3VRF, a second interface is added in the L3VRF. Also, optional routing configuration can be done. Below configuration gives an example of static routing entry targeting an IP located behind a bridge interface.
The whole configuration is depicted below:
rt1
vsr running config# / vrf main l3vrf l3vrf1 table-id 10
vsr running config# / vrf main l3vrf l3vrf1 interface physical eth1 port pci-b0s4
vsr running config# / vrf main l3vrf l3vrf1 interface physical eth1 ipv4 address 10.100.0.1/24
vsr running config# / vrf main l3vrf l3vrf1 interface physical eth1 ipv6 address 10:100::1/64
vsr running config# / vrf main l3vrf l3vrf1 interface bridge bridge ipv4 address 10.125.0.1/24
vsr running config# / vrf main l3vrf l3vrf1 interface bridge bridge ipv6 address 10:125::1/64
vsr running config# / vrf main l3vrf l3vrf1 interface bridge bridge link-interface eth2
vsr running config# / vrf main l3vrf l3vrf1 interface bridge bridge link-interface eth3
vsr running config# / vrf main l3vrf l3vrf1 routing static ipv4-route 10.200.0.0/24 next-hop 10.125.0.2
vsr running config# / vrf main l3vrf l3vrf1 routing static ipv6-route 10:200::/64 next-hop 10:125::2
vsr running config# / vrf main interface physical eth2 port pci-b0s5
vsr running config# / vrf main interface physical eth3 port pci-b0s6
Below dump shows the routing entries an incoming packet will face when coming from
either bridge
or eth0
interface.
vsr> show ipv4-routes l3vrf l3vrf1
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, N - NHRP, T - Table
> - selected route, * - FIB route, r - rejected, b - backup
L3VRF l3vrf1:
K>* 0.0.0.0/0 [255/8192] unreachable (ICMP unreachable), 00:00:03
C>* 10.100.0.0/24 is directly connected, eth1, 00:00:03
C>* 10.125.0.0/24 is directly connected, bridge, 00:00:03
S>* 10.200.0.0/24 [1/0] via 10.125.0.2, bridge, weight 1, 00:00:02
4 routes displayed.
vsr> show ipv6-routes l3vrf l3vrf1
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
> - selected route, * - FIB route, r - rejected, b - backup
L3VRF l3vrf1:
K>* ::/0 [255/8192] unreachable (ICMP unreachable), 00:00:04
C>* 10:100::/64 is directly connected, eth1, 00:00:02
C>* 10:125::/64 is directly connected, bridge, 00:00:03
S>* 10:200::/64 [1/0] via 10:125::2, bridge, weight 1, 00:00:03
C * fe80::/64 is directly connected, bridge, 00:00:02
C>* fe80::/64 is directly connected, eth1, 00:00:03
5 routes displayed.
Note
L3VRF operates at layer 3 level. This implies that only interfaces with
incoming traffic handled at routing level are eligible to be assigned in an L3VRF.
The eth1
interface is attached to a bridge interface and incoming traffic coming from
that interface is bridged, not routed. In other words, it is not possible for
a given interface to be at the same time slave from a bridge interface, and be assigned
an L3VRF. Similarly, the same constraint applies to interfaces belonging to a bonding
interface. For instance, below configuration is not possible:
vsr running config# / vrf main l3vrf l3vrf1 interface vxlan vxl1 vni 100
vsr running config# / vrf main l3vrf l3vrf1 interface vxlan vxl1 ipv4 address 10.126.0.1/24
vsr running config# / vrf main l3vrf l3vrf1 interface bridge bridge link-interface vxl1
vsr running config#! validate
ERROR: Ext plugin "extra-conditions - unique-values, version 1": Duplicate value 'vxl1' found in /vrouter:config/vrf[name='main']/l3vrf[name='l3vrf1']/vrouter-interface:interface/vrouter-bridge:bridge[name='bridge']/link-interface[slave='vxl1']/slave.
ERROR: Ext plugin "extra-conditions - unique-values, version 1": An interface in a l3vrf can not be part of a bridge or a lag port.
Invalid configuration.
vsr running config#! del / vrf main l3vrf l3vrf1 interface vxlan
vsr running config# / vrf main interface vxlan vxl1 vni 100
vsr running config# / vrf main interface vxlan vxl1 ipv4 address 10.126.0.1/24
This chapter introduced how to configure L3VRF and use basic operations. Further chapters will explain how to use specific services with L3VRF.
Routing services with L3VRF¶
The following routing services can be configured within a L3VRF domain, and are listed below:
See also
Configuring L3VRF static routing, see Configuring L3VRF Static routing.
Configuring L3VRF static routing leak, see Configuring L3VRF Static routing leak.
Using OSPF routing instances in L3VRF routing domains, see L3VRF OSPF.
Creating BGP routing instances in L3VRF routing domains, see L3VRF BGP.
Using L3VPN technology with BGP and L3VRF, see BGP L3VPN.
Using EVPN technology with BGP and L3VRF, see BGP EVPN Routing mode.
Impact on IP packet filtering and traffic control¶
There is a switching in the routing process before and after routing: at ingress, the interface information attached to the packet contains the L3VRF instance name, and not the original received interface. Similarly, at egress, the interface information attached contains the L3VRF instance name, and not the output one. The interface information is handled by services such as IP packet filtering. Those services are impacted.
The below figure explains the routing process differences for a given packet in an L3VRF
domain or in the default
L3VRF. The term chain
mentioned in the drawing is used to
mention the possible entry points for adding firewall service. The dotted line depicts
the various chains
that can be used on each L3VRF.
The first drawing depicts the processing of forwarded traffic.
Below figure explains the routing process differences for local traffic handling, in
a given L3VRF and in the default
L3VRF.
When configuring and defining an input
or a forward
rule with inbound-interface
keyword, the behaviour slightly changes depending on the configured chain.
When a rule is created in prerouting
chain, then the user can choose to select in
inbound-interface
keyword either the incoming original interface or the L3VRF
instance name. This is also the case at egress for postrouting
and output
chains
(for the outbound-interface
keyword) where the user can use either the original
interface name or the L3VRF instance name.
However, input
and forward
chain, if used to filter traffic across an L3VRF domain,
will work only with the inbound-interface
keyword set to the L3VRF instance name.
Below example illustrates that only rule 2
is able to match forwarded traffic across
the given L3VRF domain. This is not the case if the user wants to filter traffic on
default
L3VRF: in that case, rule 1
would be sufficient assuming that eth0
sits
on default
L3VRF.
vsr running config# / vrf main l3vrf l3vrf1 table-id 10
vsr running config# / vrf main l3vrf l3vrf1 interface physical eth1 port pci-b0s4
vsr running config# / vrf main l3vrf l3vrf1 interface physical eth1 ipv4 address 10.100.0.1/24
vsr running config# / vrf main l3vrf l3vrf1 interface physical eth2 port pci-b0s5
vsr running config# / vrf main l3vrf l3vrf1 interface physical eth2 ipv4 address 10.125.0.1/24
vsr running config# / vrf main l3vrf l3vrf1 routing static ipv4-route 10.200.0.0/24 next-hop 10.125.0.2
vsr running config# / vrf main firewall ipv4 filter forward rule 1 inbound-interface eth0 action accept
vsr running config# / vrf main firewall ipv4 filter forward rule 2 inbound-interface l3vrf1 action accept
vsr running config# / vrf main firewall ipv4 filter forward rule 5 action drop
Impact on IP PBR¶
Chapter PBR shows examples of how to select traffic and redirect
this traffic to a specific routing table. Within a given L3VRF domain, it is possible to
redirect traffic to an alternate routing table. The configuration below gives an example on
how to redirect traffic with the inbound-interface
keyword.
vsr running config# / vrf main l3vrf l3vrf1 table-id 10
vsr running config# / vrf main l3vrf l3vrf1 interface physical eth1 port pci-b0s4
vsr running config# / vrf main l3vrf l3vrf1 interface physical eth1 ipv4 address 10.100.0.1/24
vsr running config# / vrf main l3vrf l3vrf1 interface physical eth2 port pci-b0s5
vsr running config# / vrf main l3vrf l3vrf1 interface physical eth2 ipv4 address 10.125.0.1/24
vsr running config# / vrf main routing policy-based-routing ipv4-rule 5 match inbound-interface l3vrf1 action lookup 40
Note that it is not possible to add a PBR rule whose action is to lookup in a
routing table owned by an L3VRF instance. Hence, table-id
value in a l3vrf
should not conflict with the lookup table used by policy based routing.