diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/developer/mgmtd-dev.rst | 13 | ||||
| -rw-r--r-- | doc/developer/packaging-redhat.rst | 15 | ||||
| -rw-r--r-- | doc/developer/sbfd.rst | 143 | ||||
| -rw-r--r-- | doc/developer/subdir.am | 1 | ||||
| -rw-r--r-- | doc/user/bgp.rst | 19 | ||||
| -rw-r--r-- | doc/user/sbfd.rst | 316 | ||||
| -rw-r--r-- | doc/user/static.rst | 63 | ||||
| -rw-r--r-- | doc/user/subdir.am | 1 | ||||
| -rw-r--r-- | doc/user/zebra.rst | 2 |
9 files changed, 562 insertions, 11 deletions
diff --git a/doc/developer/mgmtd-dev.rst b/doc/developer/mgmtd-dev.rst index 4c56cadb28..6cbd617f8c 100644 --- a/doc/developer/mgmtd-dev.rst +++ b/doc/developer/mgmtd-dev.rst @@ -160,14 +160,19 @@ Back-End Interface: should be destroyed with a call to `mgmt_be_client_destroy` and to be safe NULL out the global `mgmt_be_client` variable. -#. In ``mgmtd/mgmt_be_adapter.c`` add xpath prefix mappings to a one or both - mapping arrays (``be_client_config_xpaths`` and ``be_client_oper_xpaths``) to - direct ``mgmtd`` to send config and oper-state requests to your daemon. NOTE: - make sure to include library supported xpaths prefixes as well (e.g., +#. In ``mgmtd/mgmt_be_adapter.c`` add xpath prefix mappings to a each of the + mapping arrays (``be_client_config_xpaths``, ``be_client_oper_xpaths``, and + ``be_client_rpc_xpaths``) to direct ``mgmtd`` to send config, oper-state, and + RPC requests to your daemon. + + NOTE: make sure to include library supported xpaths prefixes as well (e.g., "/frr-interface:lib"). A good way to figure these paths out are to look in each of the YANG modules that the daemon uses and include each of their paths in the array. +#. In ``python/xref2vtysh.py`` add ``VTYSH_xxxD`` (for client xxx) to + ``lib/mgmt_be_client.c`` entry in the ``daemon_falgs`` dictionary. + Add YANG and CLI into MGMTD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/doc/developer/packaging-redhat.rst b/doc/developer/packaging-redhat.rst index 8037873461..277de5d16f 100644 --- a/doc/developer/packaging-redhat.rst +++ b/doc/developer/packaging-redhat.rst @@ -3,7 +3,7 @@ Packaging Red Hat ================= -Tested on CentOS 6, CentOS 7, CentOS 8 and Fedora 24. +Tested on CentOS 6, CentOS 7, Rocky 8 and Fedora 24. 1. On CentOS 6, refer to :ref:`building-centos6` for details on installing sufficiently up-to-date package versions to enable building FRR. @@ -18,14 +18,14 @@ Tested on CentOS 6, CentOS 7, CentOS 8 and Fedora 24. yum install rpm-build net-snmp-devel pam-devel libcap-devel - For CentOS 7 and CentOS 8, the package will be built using python3 + For CentOS 7 and Rocky 8, the package will be built using python3 and requires additional python3 packages:: yum install python3-devel python3-sphinx .. note:: - For CentOS 8 you need to install ``platform-python-devel`` package + For Rocky 8 you need to install ``platform-python-devel`` package to provide ``/usr/bin/pathfix.py``:: yum install platform-python-devel @@ -33,7 +33,7 @@ Tested on CentOS 6, CentOS 7, CentOS 8 and Fedora 24. If ``yum`` is not present on your system, use ``dnf`` instead. - You should enable ``PowerTools`` repo if using CentOS 8 which + You should enable ``PowerTools`` repo if using Rocky 8 which is disabled by default. 4. Checkout FRR:: @@ -88,11 +88,18 @@ Tested on CentOS 6, CentOS 7, CentOS 8 and Fedora 24. %{!?with_watchfrr: %global with_watchfrr 1 } %{!?with_pathd: %global with_pathd 1 } %{!?with_grpc: %global with_grpc 0 } + %{!?with_rpki: %global with_rpki 1 } + %{!?with_docs: %global with_docs 1 } 8. Build the RPM:: rpmbuild --define "_topdir `pwd`/rpmbuild" -ba rpmbuild/SPECS/frr.spec + To override :file:`rpm/SPECS/frr.spec` defaults on the rpmbuild + commandline with: + + rpmbuild --define 'variable value' + If building with RPKI, then download and install the additional RPKI packages from https://ci1.netdef.org/browse/RPKI-RTRLIB/latestSuccessful/artifact diff --git a/doc/developer/sbfd.rst b/doc/developer/sbfd.rst new file mode 100644 index 0000000000..66a3b48dba --- /dev/null +++ b/doc/developer/sbfd.rst @@ -0,0 +1,143 @@ +.. _sbfd: + +**** +SBFD +**** + +:abbr:`SBFD (Seamless Bidirectional Forwarding Detection)` is: + + Seamless Bidirectional Forwarding Detection, a simplified mechanism for using BFD with a large + proportion of negotiation aspects eliminated, thus providing benefits + such as quick provisioning, as well as improved control and + flexibility for network nodes initiating path monitoring. + + -- :rfc:`7880` + +It is described and extended by the following RFCs: + +* :rfc:`7880` +* :rfc:`7881` + +.. _sbfd-sate-machine: + +SBFD state machine +================== + +SBFD takes the same data packet format as BFD, but with a much simpler state machine. +According to RFC7880, SBFD has a stateless SBFDReflector and a stateful SBFDInitiator with the state machine as below: + +:: + + +--+ + ADMIN DOWN, | | + TIMER | V + +------+ UP +------+ + | |-------------------->| |----+ + | DOWN | | UP | | UP + | |<--------------------| |<---+ + +------+ ADMIN DOWN, +------+ + TIMER + + Figure 1: SBFDInitiator Finite State Machine + +.. _sbfd-extention: + +SBFD extension - SRv6 encapsulation +=================================== + +SBFDInitiator periodically send packets to monitor the connection to SBFDReflector. We set up an SBFD connection between the source and the destination node of a path, +with the source node serving as Initiator and the destination node as Reflector. The communicated SBFD packets should also follow every exact hop in the path, +from the source to the destination, which could be achieved by segment routing. This requirement extends the node verification to the path verification. + +.. _sbfd-implement: + +implementation +=============== + +Some considerations when implementing sbfd. + + + +.. _sbfd-implement-coexist: + +SBFD Co-exist with BFD +-------------------------- + +Both SBFD and Classical BFD have their unique discriminator, SBFD can co-exist with BFD since they sharing a same discriminator pool in bfdd. +Also in bfdd SBFD and BFD can share most code logic, SBFD packet and BFD packet are demultiplexed by different discriminators. + + +.. _sbfd-implement-bfdname: + +SBFD name +--------- + +We introduced a bfd-name for every sbfd session. A unique bfd-name can be used to identify a sbfd session quickly. This is quite useful in our Srv6 deployment for path protection case. +A bfd-name is always associated with a TE path, for example if we use the sbfd session to protect the path A-B-D, we would assign the name 'path-a-b-d' or 'a-b-d' to the session. + +Meanwhile bfdd will notify the sbfd status to the Pathd, we should add the bfd-name field in PTM bfd notify message ZEBRA_BFD_DEST_REPLAY: + +:: + + * Message format: + * - header: command, vrf + * - l: interface index + * - c: family + * - AF_INET: + * - 4 bytes: ipv4 + * - AF_INET6: + * - 16 bytes: ipv6 + * - c: prefix length + * - l: bfd status + * - c: family + * - AF_INET: + * - 4 bytes: ipv4 + * - AF_INET6: + * - 16 bytes: ipv6 + * - c: prefix length + * - c: cbit + * - c: bfd name len <---- new field + * - Xbytes: bfd name <---- new field + * + * Commands: ZEBRA_BFD_DEST_REPLAY + * + * q(64), l(32), w(16), c(8) + + + +.. _sbfd-implement-port: + +SBFD UDP port +------------- + +According to RFC7881, SBFD Control packet dst port should be 7784, src port can be any but NOT 7784. In our implementation, the UDP ports in packet are set as: + + +:: + + UDP(sport=4784, dport=7784)/BFD() or UDP(sport=3784, dport=7784)/BFD() + +if "multihop" is specified for sbfd initiator we choose the 4784 as the source port, so the reflected packet will take 4784 as the dst port, this is a local BFD_MULTI_HOP_PORT so the reflected packet can be handled by the existing bfd_recv_cb function. +if "multihop" is not specified for sbfd initiator we choose the 3784 as the source port, this is a local BFD_DEFDESTPORT so the reflected packet can be handled by the existing bfd_recv_cb function. + + +For echo SBFD with SRv6 encapsulation case, we re-use the BFD Echo port, the UDP ports in packet are set as: + +:: + + UDP(sport=3785, dport=3785)/BFD() + + +we choose the 3785 as the source port, so the echo back packet will take 3785 as the dst port, this is a local BFD_DEF_ECHO_PORT so the packet can be handled by the existing bfd_recv_cb function. + + +.. _sbfd-not-implemented: + +Todo list for SBFD +------------------ + + Currently some features are not yet implemented for SBFD, will add it in future: + 1) SBFD in IPv4 only packet + 2) The ADMIN DOWN logic + 3) SBFD echo function in a initiator session + 4) SBFD over MPLS diff --git a/doc/developer/subdir.am b/doc/developer/subdir.am index bdf93a05c1..9f6986cd33 100644 --- a/doc/developer/subdir.am +++ b/doc/developer/subdir.am @@ -83,6 +83,7 @@ dev_RSTFILES = \ doc/developer/northbound/transactional-cli.rst \ doc/developer/northbound/yang-module-translator.rst \ doc/developer/northbound/yang-tools.rst \ + doc/developer/sbfd.rst \ # end EXTRA_DIST += \ diff --git a/doc/user/bgp.rst b/doc/user/bgp.rst index 3bf21a6ef5..a1dd799392 100644 --- a/doc/user/bgp.rst +++ b/doc/user/bgp.rst @@ -282,7 +282,9 @@ internal or external. interface and address information. In that case default router ID value is selected as the largest IP Address of the interfaces. When `router zebra` is not enabled *bgpd* can't get interface information so `router-id` is set to - 0.0.0.0. So please set router-id by hand. + 0.0.0.0, which is invalid and BGP session can't be established. + + So please set router-id by manually. .. _bgp-multiple-autonomous-systems: @@ -1951,6 +1953,15 @@ Configuring Peers are not supporting this capability or supporting BGP Capabilities Negotiation RFC 2842. +.. clicmd:: neighbor PEER capability link-local + + Send the Link-Local Next Hop capability in the BGP OPEN message to the neighbor. + This is useful in data center environments where point-to-point (unnumbered) links + are utilized. This capability standardizes the operation of BGP over a + point-to-point links using link-local IPv6 addressing only. + + Enabled by default for the ``datacenter`` profile. + .. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> accept-own Enable handling of self-originated VPN routes containing ``accept-own`` community. @@ -2693,6 +2704,12 @@ The following commands can be used in route maps: happen only when BGP updates have completely same communities value specified in the community list. +.. clicmd:: match community-limit (0-65535) + + This command matches BGP updates that use community list, and with a community + list count less or equal than the defined limit. Setting community-limit to 0 + will only match BGP updates with no community. + .. clicmd:: set community <none|COMMUNITY> additive This command sets the community value in BGP updates. If the attribute is diff --git a/doc/user/sbfd.rst b/doc/user/sbfd.rst new file mode 100644 index 0000000000..d26bffe07b --- /dev/null +++ b/doc/user/sbfd.rst @@ -0,0 +1,316 @@ +.. _sbfd: + +**** +SBFD +**** + +:abbr:`SBFD (Seamless Bidirectional Forwarding Detection)` is: + + Seamless Bidirectional Forwarding Detection, a simplified mechanism for using BFD with a large + proportion of negotiation aspects eliminated, thus providing benefits + such as quick provisioning, as well as improved control and + flexibility for network nodes initiating path monitoring. + + -- :rfc:`7880` + +It is described and extended by the following RFCs: + +* :rfc:`7880` +* :rfc:`7881` + +.. _sbfd-sate-machine: + +SBFD state machine +================== + +SBFD takes the same data packet format as BFD, but with a much simpler state machine. +According to RFC7880, SBFD has a stateless SBFDReflector and a stateful SBFDInitiator with the state machine as below: + +:: + + +--+ + ADMIN DOWN, | | + TIMER | V + +------+ UP +------+ + | |-------------------->| |----+ + | DOWN | | UP | | UP + | |<--------------------| |<---+ + +------+ ADMIN DOWN, +------+ + TIMER + + Figure 1: SBFDInitiator Finite State Machine + +* If SBFDInitiator doesn't receive the response packet in time, session is DOWN. +* If SBFDInitiator receives the response packet in time: reponse state is ADMINDOWN, session goes DOWN; reponse state is UP, session goes UP. + +.. note:: + + SBFDReflector is stateless, it just transmit a packet in response to a received S-BFD packet having a valid S-BFD Discriminator in the Your Discriminator field. + + +.. _sbfd-extention: + +SBFD extension - SRv6 encapsulation +=================================== + +SBFDInitiator periodically send packets to monitor the connection to SBFDReflector. We set up an SBFD connection between the source and the destination node of a path, +with the source node serving as Initiator and the destination node as Reflector. The communicated SBFD packets should also follow every exact hop in the path, +from the source to the destination, which could be achieved by segment routing. This requirement extends the node verification to the path verification. +In the following example, we set up a sbfd session to monitor the path A-B-D (all nodes in the topo are SRv6 ready, which can decap and forward SRv6 packets). + +:: + + +------------C-----------+ + / \ + A---------------B---------------D + ^ ^ ^ + | | | + End: 100::A End: 100::B End: 100::D + Loopback: 200::A Loopback: 200::D + BFD Discrim: 123 BFD Discrim: 456 + + +A is the SBFDInitiator, and D is the SBFDReflector, A will trasmit the SBFD packet to B as the format: + +:: + + IPv6(src="200::A", dst="100::B", nh=43)/IPv6ExtHdrSegmentRouting(addresses=["100::D"], nh=41, segleft=1)/IPv6(src="200::A", dst="200::D")/UDP(dport=7784)/BFD(my_dis=123, your_disc=456, state=UP) + + +Upon receiving the packet, B will take the Srv6 End action since the dst ip 100::B is the End address, B will the shift the dst address according to Srv6 spec, then trasmit the SBFD packet to D as the format: + +:: + + IPv6(src="200::A", dst="100::D", nh=41)/IPv6(src="200::A", dst="200::D")/UDP(dport=7784)/BFD(my_dis=123, your_disc=456, state=UP) + + +After D receive the packet, It will decap the outer IPv6 header since the dst ip 100::D is the End address, the decapped packet is: + +:: + + IPv6(src="200::A", dst="200::D")/UDP(dport=7784)/BFD(my_dis=123, your_disc=456, state=UP) + + +This packet will be routed to kernel stack of D since its dst is 200::D. Then the SBFDReflector service on D will get the packet and Reflect it. The response packet will be: + +:: + + IPv6(src="200::D", dst="200::A")/UDP(sport=7784)/BFD(my_dis=456, your_disc=123, state=UP) + + +This packet will be routed in the topo according to the dst ip 200::A, it will go back to A by D-B-A or D-C-A in this case. + + + + In this example, Command used to configure the SBFDInitiator on A is: + +.. clicmd:: peer 200::D bfd-mode sbfd-init bfd-name a-b-d multihop local-address 200::A remote-discr 456 srv6-source-ipv6 200::A srv6-encap-data 100::B 100::D + + + Command used to configure the SBFDReflector on D is: + +.. clicmd:: sbfd reflector source-address 200::D discriminator 456 + + +.. _sbfd-echo: + +Echo SBFD with SRv6 encapsulation +================================= + +The SBFD Initiator-Reflector mode requires the configuration on both source and destination nodes. It can not work if the remote node has no SBD feature supported, especial on some third-party devices. +The Echo SBFD can solve this kind of deployment issue since it only requires the configuration on source node. This is also known as One-Arm BFD Echo or unaffiliated BFD Echo. +For example, we use Echo SBFD session to protect Srv6 path: A-B-D + +:: + + +------------C-----------+ + / \ + A---------------B---------------D + ^ ^ ^ + | | | + End: 100::A End: 100::B End: 100::D + Loopback: 200::A Loopback: 200::D + BFD Discrim: 123 + + +A is also the SBFDInitiator, and B, C, D is Srv6 ready nodes, A will trasmit the SBFD packet to B as the format: + +:: + + IPv6(src="200::A", dst="100::B", nh=43)/IPv6ExtHdrSegmentRouting(addresses=["100::D"], nh=41, segleft=1)/IPv6(src="200::A", dst="200::A")/UDP(dport=3785)/BFD(my_dis=123, your_disc=123, state=UP) + + +Upon receiving the packet, B will take the Srv6 End action since the dst ip 100::B is the End address, B will the shift the dst address according to Srv6 spec, then trasmit the SBFD packet to D as the format: + +:: + + IPv6(src="200::A", dst="100::D", nh=41)/IPv6(src="200::A", dst="200::A")/UDP(dport=3785)/BFD(my_dis=123, your_disc=123, state=UP) + + +After D receive the packet, It will decap the outer IPv6 header since the dst ip 100::D is the End address, the decapped packet is: + +:: + + IPv6(src="200::A", dst="200::A")/UDP(dport=3785)/BFD(my_dis=123, your_disc=123, state=UP) + + +This packet will be routed in the topo according to the dst ip 200::A, it will go back to A by D-B-A or D-C-A in this case. + + + + In this example, Command used to configure the SBFDInitiator on A is: + +.. clicmd:: peer 200::A bfd-mode sbfd-echo bfd-name a-b-d local-address 200::A srv6-source-ipv6 200::A srv6-encap-data 100::B 100::D + + + no configuration needed on D. + + +.. _sbfd-normal: + +normal SBFD with no SRv6 encapsulation +====================================== + +We can also configure a SBFD Initiator-Reflector session based on simple IPv6/IPv4 packet, no Srv6 involved in this case. + +:: + + +------------C-----------+ + / \ + A---------------B---------------D + ^ ^ ^ + | | | + Loopback: 200::A Loopback: 200::D + BFD Discrim: 123 BFD Discrim: 456 + + + +A is the SBFDInitiator, and D is the SBFDReflector, A will trasmit the SBFD packet to B or C as the format: + +:: + + IPv6(src="200::A", dst="200::D")/UDP(dport=7784)/BFD(my_dis=123, your_disc=456, state=UP) + + +Upon receiving the packet, B/C will route the packet to D according to the dst ip 200::D. + +After D receive the packet, packet will be sent to kernel stack of D since its dst is 200::D. Then the SBFDReflector service on D will get the packet and reflect it. The response packet will be: + +:: + + IPv6(src="200::D", dst="200::A")/UDP(sport=7784)/BFD(my_dis=456, your_disc=123, state=UP) + + +This packet will be routed in the topo according to the dst ip 200::A, it will go back to A by D-B-A or D-C-A in this case. + + + In this example, Command used to configure the SBFDInitiator on A is: + +.. clicmd:: peer 200::D bfd-mode sbfd-init bfd-name a-d local-address 200::A remote-discr 456 + + + Command used to configure the SBFDReflector on D is: + +.. clicmd:: sbfd reflector source-address 200::D discriminator 456 + + +.. note:: + + Currently some features are not yet implemented: + 1) SBFD in IPv4 only packet + 2) The ADMIN DOWN logic + 3) SBFD echo function in a initiator session + 4) SBFD over MPLS + + +.. _sbfd-show: + +show command +============ + +The exsiting bfd show command is also appliable to SBFD sessions, for example: +This command will show all the BFD and SBFD sessions in the bfdd: + +.. clicmd:: show bfd peers + + +:: + + BFD Peers: + peer 200::D bfd-mode sbfd-init bfd-name a-d multihop local-address 200::A vrf default remote-discr 456 + ID: 1421669725 + Remote ID: 456 + Active mode + Minimum TTL: 254 + Status: up + Uptime: 5 hour(s), 48 minute(s), 39 second(s) + Diagnostics: ok + Remote diagnostics: ok + Peer Type: sbfd initiator + Local timers: + Detect-multiplier: 3 + Receive interval: 300ms + Transmission interval: 1000ms + Echo receive interval: 50ms + Echo transmission interval: disabled + Remote timers: + Detect-multiplier: - + Receive interval: - + Transmission interval: - + Echo receive interval: - + +This command will show all the BFD and SBFD session packet counters: + +.. clicmd:: show bfd peers counters + +:: + + BFD Peers: + peer 200::A bfd-mode sbfd-echo bfd-name a-b-d local-address 200::A vrf default srv6-source-ipv6 200::A srv6-encap-data 100::B 100::D + Control packet input: 0 packets + Control packet output: 0 packets + Echo packet input: 23807 packets + Echo packet output: 23807 packets + Session up events: 1 + Session down events: 0 + Zebra notifications: 1 + Tx fail packet: 0 + + peer 200::D bfd-mode sbfd-init bfd-name a-d local-address 200::A vrf default remote-discr 456 + Control packet input: 25289 packets + Control packet output: 51812 packets + Echo packet input: 0 packets + Echo packet output: 0 packets + Session up events: 5 + Session down events: 4 + Zebra notifications: 9 + Tx fail packet: 0 + + +we also implemented a new show command to display BFD sessions with a bfd-name, the bfd-name is the key to search the sessioon. + +.. clicmd:: show bfd bfd-name a-b-d + +:: + + BFD Peers: + peer 200::A bfd-mode sbfd-echo bfd-name a-b-d local-address 200::A vrf default srv6-source-ipv6 200::A srv6-encap-data 100::B 100::D + ID: 123 + Remote ID: 123 + Active mode + Status: up + Uptime: 5 hour(s), 39 minute(s), 34 second(s) + Diagnostics: ok + Remote diagnostics: ok + Peer Type: echo + Local timers: + Detect-multiplier: 3 + Receive interval: 300ms + Transmission interval: 300ms + Echo receive interval: 300ms + Echo transmission interval: 1000ms + Remote timers: + Detect-multiplier: - + Receive interval: - + Transmission interval: - + Echo receive interval: - diff --git a/doc/user/static.rst b/doc/user/static.rst index 922c71a073..0ce6e2107e 100644 --- a/doc/user/static.rst +++ b/doc/user/static.rst @@ -176,3 +176,66 @@ multiple segments instructions. router# show ipv6 route [..] S>* 2005::/64 [1/0] is directly connected, ens3, seg6 2001:db8:aaaa::7,2002::4,2002::3,2002::2, weight 1, 00:00:06 + +STATIC also supports steering of IPv4 traffic over an SRv6 SID list, as shown in the example below. + +.. code-block:: frr + + ip route A.B.C.D <A.B.C.D|nexthop> segments U:U::U:U/Y:Y::Y:Y/Z:Z::Z:Z + +:: + + router(config)# ip route 10.0.0.0/24 sr0 segments fcbb:bbbb:1:2:3:fe00:: + + router# show ip route + [..] + S>* 10.0.0.0/24 [1/0] is directly connected, sr0, seg6 fcbb:bbbb:1:2:3:fe00::, weight 1, 00:00:06 + +SRv6 Static SIDs Commands +========================= + +.. clicmd:: segment-routing + + Move from configure mode to segment-routing node. + +.. clicmd:: srv6 + + Move from segment-routing node to srv6 node. + +.. clicmd:: static-sids + + Move from srv6 node to static-sids node. In this static-sids node, user can + configure static SRv6 SIDs. + +.. clicmd:: sid X:X::X:X/M locator NAME behavior <uN|uDT4|uDT6|uDT46> [vrf VRF] + + Specify the locator sid manually. Configuring a local sid in a purely static mode + by specifying the sid value would generate a unique SID. + This feature will support the configuration of static SRv6 decapsulation on the system. + + It supports four parameter options, corresponding to the following functions: + uN, uDT4, uDT6, uDT46 + + When configuring the local sid, if the action is set to 'uN', no vrf should be set. + While for any other action, it is necessary to specify a specific vrf. + +:: + + router# configure terminal + router(config)# segment-routing + router(config-sr)# srv6 + router(config-srv6)# static-sids + router(config-srv6-sids)# sid fcbb:bbbb:1:fe01::/64 locator LOC1 behavior uDT6 vrf Vrf1 + router(config-srv6-sids)# sid fcbb:bbbb:1:fe02::/64 locator LOC1 behavior uDT4 vrf Vrf1 + router(config-srv6-sids)# sid fcbb:bbbb:1:fe03::/64 locator LOC1 behavior uDT46 vrf Vrf2 + + router(config-srv6-locator)# show run + ... + segment-routing + srv6 + static-sids + sid fcbb:bbbb:1:fe01::/64 locator LOC1 behavior uDT6 vrf Vrf1 + sid fcbb:bbbb:1:fe02::/64 locator LOC1 behavior uDT4 vrf Vrf1 + sid fcbb:bbbb:1:fe03::/64 locator LOC1 behavior uDT46 vrf Vrf2 + ! + ...
\ No newline at end of file diff --git a/doc/user/subdir.am b/doc/user/subdir.am index 395ce305fe..e4e12788e7 100644 --- a/doc/user/subdir.am +++ b/doc/user/subdir.am @@ -55,6 +55,7 @@ user_RSTFILES = \ doc/user/watchfrr.rst \ doc/user/wecmp_linkbw.rst \ doc/user/mgmtd.rst \ + doc/user/sbfd.rst \ # end EXTRA_DIST += \ diff --git a/doc/user/zebra.rst b/doc/user/zebra.rst index ef3a619853..f700d36086 100644 --- a/doc/user/zebra.rst +++ b/doc/user/zebra.rst @@ -1133,10 +1133,8 @@ kernel. - any, - babel, - bgp, - - connected, - eigrp, - isis, - - kernel, - nhrp, - openfabric, - ospf, |