2006-06-27 09:52:03 +02:00
|
|
|
# Canonical Zserv route types information registry for Quagga.
|
|
|
|
|
#
|
|
|
|
|
# Used to construct route_types.c and route_types.h
|
|
|
|
|
#
|
|
|
|
|
# comma-seperated fields of either 2 fields (help strings) or 7 fields.
|
|
|
|
|
# White space before and after the comma seperators is stripped.
|
|
|
|
|
# Lines /beginning/ with # are comments.
|
|
|
|
|
#
|
|
|
|
|
####
|
2018-04-13 15:39:23 +02:00
|
|
|
# 9 field line has format:
|
|
|
|
|
# ZServ route type, canonical name, daemon, route char, ipv4, ipv6, redist, short desc, Restrictions
|
2006-06-27 09:52:03 +02:00
|
|
|
#
|
|
|
|
|
# Zserv route type: Corresponding with zebra.h. Key field.
|
|
|
|
|
# canonical name: Typically derived from the route type definition.
|
|
|
|
|
# Used in 'redistribute' commands in daemons.
|
|
|
|
|
# Key field.
|
|
|
|
|
# daemon: The daemon which may originates this route type
|
|
|
|
|
# for redistribution to other daemons.
|
|
|
|
|
# NULL if not applicable.
|
|
|
|
|
# M:N definitions of type:daemon are allowed.
|
|
|
|
|
# Used to construct vty command strings.
|
|
|
|
|
# route char: Single character to denote the route, if applicable.
|
|
|
|
|
# Used to denote route type where space is tight,
|
|
|
|
|
# e.g. 'show ip route' / 'show ipv6 route'.
|
|
|
|
|
# 'X' is reserved as the 'not needed' placeholder.
|
|
|
|
|
# ipv4: IPv4 capable? yes/no, or 1/0.
|
|
|
|
|
# ipv6: IPv6 capable? ditto.
|
2018-04-13 15:39:23 +02:00
|
|
|
# redist: Allow this protocol to be used in redistribution statements
|
2006-06-27 09:52:03 +02:00
|
|
|
# short desc: Very brief description. Used in header of
|
|
|
|
|
# 'show ip route'. May be specified as NULL
|
|
|
|
|
# if the canonical name suffices.
|
2018-04-13 15:39:23 +02:00
|
|
|
# Restriction: If this cannot be used with the listed protocol for redistribution events
|
2006-06-27 09:52:03 +02:00
|
|
|
#
|
|
|
|
|
# Key fields obviously must be a unique ASCII alpha-numeric word.
|
|
|
|
|
# Lower-case is required, brevity is optional but highly desirable.
|
|
|
|
|
#
|
|
|
|
|
####
|
|
|
|
|
# 2 field format:
|
|
|
|
|
#
|
|
|
|
|
# Zserv route type, Long description
|
|
|
|
|
#
|
|
|
|
|
# Long description: Full description, but should try fit on a line.
|
|
|
|
|
####
|
2017-06-07 21:47:35 +02:00
|
|
|
#
|
2018-03-09 16:44:56 +01:00
|
|
|
# If you add a new routing protocol here, make sure you also update
|
2017-06-07 21:47:35 +02:00
|
|
|
# meta_queue_map in zebra_rib.c
|
|
|
|
|
#
|
2018-04-13 15:39:23 +02:00
|
|
|
## type cname daemon C 4 6 Redist short help Restrictions
|
|
|
|
|
ZEBRA_ROUTE_SYSTEM, system, NULL, 'X', 0, 0, 0, "Reserved"
|
|
|
|
|
ZEBRA_ROUTE_KERNEL, kernel, zebra, 'K', 1, 1, 1, "kernel route"
|
|
|
|
|
ZEBRA_ROUTE_CONNECT, connected, zebra, 'C', 1, 1, 1, "connected"
|
|
|
|
|
ZEBRA_ROUTE_STATIC, static, zebra, 'S', 1, 1, 1, "static"
|
|
|
|
|
ZEBRA_ROUTE_RIP, rip, ripd, 'R', 1, 0, 1, "RIP"
|
|
|
|
|
ZEBRA_ROUTE_RIPNG, ripng, ripngd, 'R', 0, 1, 1, "RIPng"
|
|
|
|
|
ZEBRA_ROUTE_OSPF, ospf, ospfd, 'O', 1, 0, 1, "OSPF"
|
|
|
|
|
ZEBRA_ROUTE_OSPF6, ospf6, ospf6d, 'O', 0, 1, 1, "OSPFv3"
|
|
|
|
|
ZEBRA_ROUTE_ISIS, isis, isisd, 'I', 1, 1, 1, "IS-IS"
|
|
|
|
|
ZEBRA_ROUTE_BGP, bgp, bgpd, 'B', 1, 1, 1, "BGP"
|
|
|
|
|
ZEBRA_ROUTE_PIM, pim, pimd, 'P', 0, 0, 0, "PIM"
|
|
|
|
|
ZEBRA_ROUTE_EIGRP, eigrp, eigrpd, 'E', 1, 0, 1, "EIGRP"
|
|
|
|
|
ZEBRA_ROUTE_NHRP, nhrp, nhrpd, 'N', 1, 1, 1, "NHRP"
|
2006-06-27 09:52:03 +02:00
|
|
|
# HSLS and OLSR both are AFI independent (so: 1, 1), however
|
|
|
|
|
# we want to disable for them for general Quagga distribution.
|
|
|
|
|
# This at least makes it trivial for users of these protocols
|
|
|
|
|
# to 'switch on' redist support (direct numeric entry remaining
|
|
|
|
|
# possible).
|
2018-04-13 15:39:23 +02:00
|
|
|
ZEBRA_ROUTE_HSLS, hsls, hslsd, 'H', 0, 0, 0, "HSLS"
|
|
|
|
|
ZEBRA_ROUTE_OLSR, olsr, olsrd, 'o', 0, 0, 0, "OLSR"
|
|
|
|
|
ZEBRA_ROUTE_TABLE, table, zebra, 'T', 1, 1, 1, "Table"
|
|
|
|
|
ZEBRA_ROUTE_LDP, ldp, ldpd, 'L', 0, 0, 0, "LDP"
|
bgpd: add L3/L2VPN Virtual Network Control feature
This feature adds an L3 & L2 VPN application that makes use of the VPN
and Encap SAFIs. This code is currently used to support IETF NVO3 style
operation. In NVO3 terminology it provides the Network Virtualization
Authority (NVA) and the ability to import/export IP prefixes and MAC
addresses from Network Virtualization Edges (NVEs). The code supports
per-NVE tables.
The NVE-NVA protocol used to communicate routing and Ethernet / Layer 2
(L2) forwarding information between NVAs and NVEs is referred to as the
Remote Forwarder Protocol (RFP). OpenFlow is an example RFP. For
general background on NVO3 and RFP concepts see [1]. For information on
Openflow see [2].
RFPs are integrated with BGP via the RF API contained in the new "rfapi"
BGP sub-directory. Currently, only a simple example RFP is included in
Quagga. Developers may use this example as a starting point to integrate
Quagga with an RFP of their choosing, e.g., OpenFlow. The RFAPI code
also supports the ability import/export of routing information between
VNC and customer edge routers (CEs) operating within a virtual
network. Import/export may take place between BGP views or to the
default zebera VRF.
BGP, with IP VPNs and Tunnel Encapsulation, is used to distribute VPN
information between NVAs. BGP based IP VPN support is defined in
RFC4364, BGP/MPLS IP Virtual Private Networks (VPNs), and RFC4659,
BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN . Use
of both the Encapsulation Subsequent Address Family Identifier (SAFI)
and the Tunnel Encapsulation Attribute, RFC5512, The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP Tunnel
Encapsulation Attribute, are supported. MAC address distribution does
not follow any standard BGB encoding, although it was inspired by the
early IETF EVPN concepts.
The feature is conditionally compiled and disabled by default.
Use the --enable-bgp-vnc configure option to enable.
The majority of this code was authored by G. Paul Ziemba
<paulz@labn.net>.
[1] http://tools.ietf.org/html/draft-ietf-nvo3-nve-nva-cp-req
[2] https://www.opennetworking.org/sdn-resources/technical-library
Now includes changes needed to merge with cmaster-next.
2016-05-07 20:18:56 +02:00
|
|
|
#vnc when sent to zebra
|
2018-04-13 15:39:23 +02:00
|
|
|
ZEBRA_ROUTE_VNC, vnc, NULL, 'v', 1, 1, 1, "VNC"
|
bgpd: add L3/L2VPN Virtual Network Control feature
This feature adds an L3 & L2 VPN application that makes use of the VPN
and Encap SAFIs. This code is currently used to support IETF NVO3 style
operation. In NVO3 terminology it provides the Network Virtualization
Authority (NVA) and the ability to import/export IP prefixes and MAC
addresses from Network Virtualization Edges (NVEs). The code supports
per-NVE tables.
The NVE-NVA protocol used to communicate routing and Ethernet / Layer 2
(L2) forwarding information between NVAs and NVEs is referred to as the
Remote Forwarder Protocol (RFP). OpenFlow is an example RFP. For
general background on NVO3 and RFP concepts see [1]. For information on
Openflow see [2].
RFPs are integrated with BGP via the RF API contained in the new "rfapi"
BGP sub-directory. Currently, only a simple example RFP is included in
Quagga. Developers may use this example as a starting point to integrate
Quagga with an RFP of their choosing, e.g., OpenFlow. The RFAPI code
also supports the ability import/export of routing information between
VNC and customer edge routers (CEs) operating within a virtual
network. Import/export may take place between BGP views or to the
default zebera VRF.
BGP, with IP VPNs and Tunnel Encapsulation, is used to distribute VPN
information between NVAs. BGP based IP VPN support is defined in
RFC4364, BGP/MPLS IP Virtual Private Networks (VPNs), and RFC4659,
BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN . Use
of both the Encapsulation Subsequent Address Family Identifier (SAFI)
and the Tunnel Encapsulation Attribute, RFC5512, The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP Tunnel
Encapsulation Attribute, are supported. MAC address distribution does
not follow any standard BGB encoding, although it was inspired by the
early IETF EVPN concepts.
The feature is conditionally compiled and disabled by default.
Use the --enable-bgp-vnc configure option to enable.
The majority of this code was authored by G. Paul Ziemba
<paulz@labn.net>.
[1] http://tools.ietf.org/html/draft-ietf-nvo3-nve-nva-cp-req
[2] https://www.opennetworking.org/sdn-resources/technical-library
Now includes changes needed to merge with cmaster-next.
2016-05-07 20:18:56 +02:00
|
|
|
# vnc when sent to bgp
|
2018-04-13 15:39:23 +02:00
|
|
|
ZEBRA_ROUTE_VNC_DIRECT, vnc-direct,NULL, 'V', 1, 1, 1, "VNC-Direct", bgpd
|
2016-11-04 17:47:36 +01:00
|
|
|
# vnc when sent to bgp (resolve NVE mode)
|
2018-04-13 15:39:23 +02:00
|
|
|
ZEBRA_ROUTE_VNC_DIRECT_RH, vnc-rn, NULL, 'V', 0, 0, 0, "VNC-RN"
|
bgpd: add L3/L2VPN Virtual Network Control feature
This feature adds an L3 & L2 VPN application that makes use of the VPN
and Encap SAFIs. This code is currently used to support IETF NVO3 style
operation. In NVO3 terminology it provides the Network Virtualization
Authority (NVA) and the ability to import/export IP prefixes and MAC
addresses from Network Virtualization Edges (NVEs). The code supports
per-NVE tables.
The NVE-NVA protocol used to communicate routing and Ethernet / Layer 2
(L2) forwarding information between NVAs and NVEs is referred to as the
Remote Forwarder Protocol (RFP). OpenFlow is an example RFP. For
general background on NVO3 and RFP concepts see [1]. For information on
Openflow see [2].
RFPs are integrated with BGP via the RF API contained in the new "rfapi"
BGP sub-directory. Currently, only a simple example RFP is included in
Quagga. Developers may use this example as a starting point to integrate
Quagga with an RFP of their choosing, e.g., OpenFlow. The RFAPI code
also supports the ability import/export of routing information between
VNC and customer edge routers (CEs) operating within a virtual
network. Import/export may take place between BGP views or to the
default zebera VRF.
BGP, with IP VPNs and Tunnel Encapsulation, is used to distribute VPN
information between NVAs. BGP based IP VPN support is defined in
RFC4364, BGP/MPLS IP Virtual Private Networks (VPNs), and RFC4659,
BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN . Use
of both the Encapsulation Subsequent Address Family Identifier (SAFI)
and the Tunnel Encapsulation Attribute, RFC5512, The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP Tunnel
Encapsulation Attribute, are supported. MAC address distribution does
not follow any standard BGB encoding, although it was inspired by the
early IETF EVPN concepts.
The feature is conditionally compiled and disabled by default.
Use the --enable-bgp-vnc configure option to enable.
The majority of this code was authored by G. Paul Ziemba
<paulz@labn.net>.
[1] http://tools.ietf.org/html/draft-ietf-nvo3-nve-nva-cp-req
[2] https://www.opennetworking.org/sdn-resources/technical-library
Now includes changes needed to merge with cmaster-next.
2016-05-07 20:18:56 +02:00
|
|
|
# bgp unicast -> vnc
|
2018-04-13 15:39:23 +02:00
|
|
|
ZEBRA_ROUTE_BGP_DIRECT, bgp-direct, NULL, 'b', 0, 0, 0, "BGP-Direct"
|
bgpd: add L3/L2VPN Virtual Network Control feature
This feature adds an L3 & L2 VPN application that makes use of the VPN
and Encap SAFIs. This code is currently used to support IETF NVO3 style
operation. In NVO3 terminology it provides the Network Virtualization
Authority (NVA) and the ability to import/export IP prefixes and MAC
addresses from Network Virtualization Edges (NVEs). The code supports
per-NVE tables.
The NVE-NVA protocol used to communicate routing and Ethernet / Layer 2
(L2) forwarding information between NVAs and NVEs is referred to as the
Remote Forwarder Protocol (RFP). OpenFlow is an example RFP. For
general background on NVO3 and RFP concepts see [1]. For information on
Openflow see [2].
RFPs are integrated with BGP via the RF API contained in the new "rfapi"
BGP sub-directory. Currently, only a simple example RFP is included in
Quagga. Developers may use this example as a starting point to integrate
Quagga with an RFP of their choosing, e.g., OpenFlow. The RFAPI code
also supports the ability import/export of routing information between
VNC and customer edge routers (CEs) operating within a virtual
network. Import/export may take place between BGP views or to the
default zebera VRF.
BGP, with IP VPNs and Tunnel Encapsulation, is used to distribute VPN
information between NVAs. BGP based IP VPN support is defined in
RFC4364, BGP/MPLS IP Virtual Private Networks (VPNs), and RFC4659,
BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN . Use
of both the Encapsulation Subsequent Address Family Identifier (SAFI)
and the Tunnel Encapsulation Attribute, RFC5512, The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP Tunnel
Encapsulation Attribute, are supported. MAC address distribution does
not follow any standard BGB encoding, although it was inspired by the
early IETF EVPN concepts.
The feature is conditionally compiled and disabled by default.
Use the --enable-bgp-vnc configure option to enable.
The majority of this code was authored by G. Paul Ziemba
<paulz@labn.net>.
[1] http://tools.ietf.org/html/draft-ietf-nvo3-nve-nva-cp-req
[2] https://www.opennetworking.org/sdn-resources/technical-library
Now includes changes needed to merge with cmaster-next.
2016-05-07 20:18:56 +02:00
|
|
|
# bgp unicast -> vnc
|
2018-04-13 15:39:23 +02:00
|
|
|
ZEBRA_ROUTE_BGP_DIRECT_EXT, bgp-direct-to-nve-groups, NULL, 'e', 0, 0, 0, "BGP2VNC"
|
|
|
|
|
ZEBRA_ROUTE_BABEL, babel, babeld, 'A', 1, 1, 1, "Babel"
|
|
|
|
|
ZEBRA_ROUTE_SHARP, sharp, sharpd, 'D', 1, 1, 1, "SHARP"
|
|
|
|
|
ZEBRA_ROUTE_PBR, pbr, pbrd, 'F', 1, 1, 0, "PBR"
|
2018-06-27 18:40:50 +02:00
|
|
|
ZEBRA_ROUTE_BFD, bfd, bfdd, '-', 0, 0, 0, "BFD"
|
2018-03-22 15:01:08 +01:00
|
|
|
ZEBRA_ROUTE_OPENFABRIC, openfabric, fabricd, 'f', 1, 1, 1, "OpenFabric"
|
2019-04-22 20:03:30 +02:00
|
|
|
ZEBRA_ROUTE_VRRP, vrrp, vrrpd, '-', 0, 0, 0, "VRRP"
|
2018-04-13 15:39:23 +02:00
|
|
|
ZEBRA_ROUTE_ALL, wildcard, none, '-', 0, 0, 0, "-"
|
2006-06-27 09:52:03 +02:00
|
|
|
|
2017-05-13 20:59:41 +02:00
|
|
|
|
2006-06-27 09:52:03 +02:00
|
|
|
## help strings
|
|
|
|
|
ZEBRA_ROUTE_SYSTEM, "Reserved route type, for internal use only"
|
|
|
|
|
ZEBRA_ROUTE_KERNEL, "Kernel routes (not installed via the zebra RIB)"
|
|
|
|
|
ZEBRA_ROUTE_CONNECT,"Connected routes (directly attached subnet or host)"
|
|
|
|
|
ZEBRA_ROUTE_STATIC, "Statically configured routes"
|
|
|
|
|
ZEBRA_ROUTE_RIP, "Routing Information Protocol (RIP)"
|
|
|
|
|
ZEBRA_ROUTE_RIPNG, "Routing Information Protocol next-generation (IPv6) (RIPng)"
|
|
|
|
|
ZEBRA_ROUTE_OSPF, "Open Shortest Path First (OSPFv2)"
|
|
|
|
|
ZEBRA_ROUTE_OSPF6, "Open Shortest Path First (IPv6) (OSPFv3)"
|
|
|
|
|
ZEBRA_ROUTE_ISIS, "Intermediate System to Intermediate System (IS-IS)"
|
|
|
|
|
ZEBRA_ROUTE_BGP, "Border Gateway Protocol (BGP)"
|
2015-02-04 07:01:14 +01:00
|
|
|
ZEBRA_ROUTE_PIM, "Protocol Independent Multicast (PIM)"
|
2017-03-09 05:07:46 +01:00
|
|
|
ZEBRA_ROUTE_EIGRP, "Enhanced Interior Gateway Routing Protocol (EIGRP)"
|
2017-01-19 16:27:01 +01:00
|
|
|
ZEBRA_ROUTE_NHRP, "Next Hop Resolution Protocol (NHRP)"
|
2006-06-27 09:52:03 +02:00
|
|
|
ZEBRA_ROUTE_HSLS, "Hazy-Sighted Link State Protocol (HSLS)"
|
bgpd: add L3/L2VPN Virtual Network Control feature
This feature adds an L3 & L2 VPN application that makes use of the VPN
and Encap SAFIs. This code is currently used to support IETF NVO3 style
operation. In NVO3 terminology it provides the Network Virtualization
Authority (NVA) and the ability to import/export IP prefixes and MAC
addresses from Network Virtualization Edges (NVEs). The code supports
per-NVE tables.
The NVE-NVA protocol used to communicate routing and Ethernet / Layer 2
(L2) forwarding information between NVAs and NVEs is referred to as the
Remote Forwarder Protocol (RFP). OpenFlow is an example RFP. For
general background on NVO3 and RFP concepts see [1]. For information on
Openflow see [2].
RFPs are integrated with BGP via the RF API contained in the new "rfapi"
BGP sub-directory. Currently, only a simple example RFP is included in
Quagga. Developers may use this example as a starting point to integrate
Quagga with an RFP of their choosing, e.g., OpenFlow. The RFAPI code
also supports the ability import/export of routing information between
VNC and customer edge routers (CEs) operating within a virtual
network. Import/export may take place between BGP views or to the
default zebera VRF.
BGP, with IP VPNs and Tunnel Encapsulation, is used to distribute VPN
information between NVAs. BGP based IP VPN support is defined in
RFC4364, BGP/MPLS IP Virtual Private Networks (VPNs), and RFC4659,
BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN . Use
of both the Encapsulation Subsequent Address Family Identifier (SAFI)
and the Tunnel Encapsulation Attribute, RFC5512, The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP Tunnel
Encapsulation Attribute, are supported. MAC address distribution does
not follow any standard BGB encoding, although it was inspired by the
early IETF EVPN concepts.
The feature is conditionally compiled and disabled by default.
Use the --enable-bgp-vnc configure option to enable.
The majority of this code was authored by G. Paul Ziemba
<paulz@labn.net>.
[1] http://tools.ietf.org/html/draft-ietf-nvo3-nve-nva-cp-req
[2] https://www.opennetworking.org/sdn-resources/technical-library
Now includes changes needed to merge with cmaster-next.
2016-05-07 20:18:56 +02:00
|
|
|
ZEBRA_ROUTE_VNC, "Virtual Network Control (VNC)"
|
2006-06-27 09:52:03 +02:00
|
|
|
ZEBRA_ROUTE_OLSR, "Optimised Link State Routing (OLSR)"
|
2015-05-20 03:03:42 +02:00
|
|
|
ZEBRA_ROUTE_TABLE, "Non-main Kernel Routing Table"
|
2016-03-01 19:31:28 +01:00
|
|
|
ZEBRA_ROUTE_LDP, "Label Distribution Protocol (LDP)"
|
2016-11-04 17:47:36 +01:00
|
|
|
ZEBRA_ROUTE_VNC_DIRECT, "VNC direct (not via zebra) routes"
|
2017-05-13 20:59:41 +02:00
|
|
|
ZEBRA_ROUTE_BABEL, "Babel routing protocol (Babel)"
|
2017-11-10 18:55:16 +01:00
|
|
|
ZEBRA_ROUTE_SHARP, "Super Happy Advanced Routing Protocol (sharpd)"
|
pbrd: Add PBR to FRR
This is an implementation of PBR for FRR.
This implemenation uses a combination of rules and
tables to determine how packets will flow.
PBR introduces a new concept of 'nexthop-groups' to
specify a group of nexthops that will be used for
ecmp. Nexthop-groups are specified on the cli via:
nexthop-group DONNA
nexthop 192.168.208.1
nexthop 192.168.209.1
nexthop 192.168.210.1
!
PBR sees the nexthop-group and installs these as a default
route with these nexthops starting at table 10000
robot# show pbr nexthop-groups
Nexthop-Group: DONNA Table: 10001 Valid: 1 Installed: 1
Valid: 1 nexthop 192.168.209.1
Valid: 1 nexthop 192.168.210.1
Valid: 1 nexthop 192.168.208.1
I have also introduced the ability to specify a table
in a 'show ip route table XXX' to see the specified tables.
robot# show ip route table 10001
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, P - PIM, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR,
> - selected route, * - FIB route
F>* 0.0.0.0/0 [0/0] via 192.168.208.1, enp0s8, 00:14:25
* via 192.168.209.1, enp0s9, 00:14:25
* via 192.168.210.1, enp0s10, 00:14:25
PBR tracks PBR-MAPS via the pbr-map command:
!
pbr-map EVA seq 10
match src-ip 4.3.4.0/24
set nexthop-group DONNA
!
pbr-map EVA seq 20
match dst-ip 4.3.5.0/24
set nexthop-group DONNA
!
pbr-maps can have 'match src-ip <prefix>' and 'match dst-ip <prefix>'
to affect decisions about incoming packets. Additionally if you
only have one nexthop to use for a pbr-map you do not need
to setup a nexthop-group and can specify 'set nexthop XXXX'.
To apply the pbr-map to an incoming interface you do this:
interface enp0s10
pbr-policy EVA
!
When a pbr-map is applied to interfaces it can be installed
into the kernel as a rule:
[sharpd@robot frr1]$ ip rule show
0: from all lookup local
309: from 4.3.4.0/24 iif enp0s10 lookup 10001
319: from all to 4.3.5.0/24 iif enp0s10 lookup 10001
1000: from all lookup [l3mdev-table]
32766: from all lookup main
32767: from all lookup default
[sharpd@robot frr1]$ ip route show table 10001
default proto pbr metric 20
nexthop via 192.168.208.1 dev enp0s8 weight 1
nexthop via 192.168.209.1 dev enp0s9 weight 1
nexthop via 192.168.210.1 dev enp0s10 weight 1
The linux kernel now will use the rules and tables to properly
apply these policies.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
2018-01-23 19:11:36 +01:00
|
|
|
ZEBRA_ROUTE_PBR, "Policy Based Routing (PBR)"
|
2018-06-27 18:40:50 +02:00
|
|
|
ZEBRA_ROUTE_BFD, "Bidirectional Fowarding Detection (BFD)"
|
2018-03-22 15:01:08 +01:00
|
|
|
ZEBRA_ROUTE_OPENFABRIC, "OpenFabric Routing Protocol"
|