summaryrefslogtreecommitdiffstats
path: root/doc/user/sharp.rst
blob: 3e73a599edec56833c4d44d6639e0f996cdc7f81 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
.. _sharp:

*****
SHARP
*****

:abbr:`SHARP (Super Happy Advanced Routing Process)` is a daemon that provides
miscellaneous functionality used for testing FRR and creating proof-of-concept
labs.

.. _starting-sharp:

Starting SHARP
==============

Default configuration file for *sharpd* is :file:`sharpd.conf`.  The typical
location of :file:`sharpd.conf` is |INSTALL_PREFIX_ETC|/sharpd.conf.

If the user is using integrated config, then :file:`sharpd.conf` need not be
present and the :file:`frr.conf` is read instead.

.. program:: sharpd

:abbr:`SHARP` supports all the common FRR daemon start options which are
documented elsewhere.

.. _using-sharp:

Using SHARP
===========

All sharp commands are under the enable node and preceded by the ``sharp``
keyword. At present, no sharp commands will be preserved in the config.

.. clicmd:: sharp install routes A.B.C.D <nexthop <E.F.G.H|X:X::X:X>|nexthop-group NAME> (1-1000000) [instance (0-255)] [repeat (2-1000)] [opaque WORD]

   Install up to 1,000,000 (one million) /32 routes starting at ``A.B.C.D``
   with specified nexthop ``E.F.G.H`` or ``X:X::X:X``. The nexthop is
   a ``NEXTHOP_TYPE_IPV4`` or ``NEXTHOP_TYPE_IPV6`` and must be reachable
   to be installed into the kernel. Alternatively a nexthop-group NAME
   can be specified and used as the nexthops.  The routes are installed into
   zebra as ``ZEBRA_ROUTE_SHARP`` and can be used as part of a normal route
   redistribution. Route installation time is noted in the debug
   log. When zebra successfully installs a route into the kernel and SHARP
   receives success notifications for all routes this is logged as well.
   Instance (0-255) if specified causes the routes to be installed in a different
   instance. If repeat is used then we will install/uninstall the routes the
   number of times specified.  If the keyword opaque is specified then the
   next word is sent down to zebra as part of the route installation.

.. clicmd:: sharp remove routes A.B.C.D (1-1000000)

   Remove up to 1,000,000 (one million) /32 routes starting at ``A.B.C.D``. The
   routes are removed from zebra. Route deletion start is noted in the debug
   log and when all routes have been successfully deleted the debug log will be
   updated with this information as well.

.. clicmd:: sharp data route

   Allow end user doing route install and deletion to get timing information
   from the vty or vtysh instead of having to read the log file.  This command
   is informational only and you should look at sharp_vty.c for explanation
   of the output as that it may change.

.. clicmd:: sharp label <ipv4|ipv6> vrf NAME label (0-1000000)

   Install a label into the kernel that causes the specified vrf NAME table to
   be used for pop and forward operations when the specified label is seen.

.. clicmd:: sharp watch <nexthop <A.B.C.D|X:X::X:X>|import <A.B.C.D/M:X:X::X:X/M> [connected]

   Instruct zebra to monitor and notify sharp when the specified nexthop is
   changed. The notification from zebra is written into the debug log.
   The nexthop or import choice chooses the type of nexthop we are asking
   zebra to watch for us.  This choice affects zebra's decision on what
   matches.  Connected tells zebra whether or not that we want the route
   matched against to be a static or connected route for the nexthop keyword,
   for the import keyword connected means exact match.  The no form of
   the command obviously turns this watching off.

.. clicmd:: sharp data nexthop

   Allow end user to dump associated data with the nexthop tracking that
   may have been turned on.

.. clicmd:: sharp watch [vrf NAME] redistribute ROUTETYPE

   Allow end user to monitor redistributed routes of ROUTETYPE
   origin.

.. clicmd:: sharp lsp [update] (0-100000) nexthop-group NAME [prefix A.B.C.D/M TYPE [instance (0-255)]]

   Install an LSP using the specified in-label, with nexthops as
   listed in nexthop-group ``NAME``. If ``update`` is included, the
   update path is used. The LSP is installed as type ZEBRA_LSP_SHARP.
   If ``prefix`` is specified, an existing route with type ``TYPE``
   (and optional ``instance`` id) will be updated to use the LSP.

.. clicmd:: sharp remove lsp (0-100000) nexthop-group NAME [prefix A.B.C.D/M TYPE [instance (0-255)]]

   Remove a SHARPD LSP that uses the specified in-label, where the
   nexthops are specified in nexthop-group ``NAME``. If ``prefix`` is
   specified, remove label bindings from the route of type ``TYPE``
   also.

.. clicmd:: sharp send opaque type (1-255) (1-1000)

   Send opaque ZAPI messages with subtype ``type``. Sharpd will send
   a stream of messages if the count is greater than one.

.. clicmd:: sharp send opaque unicast type (1-255) PROTOCOL [{instance (0-1000) | session (1-1000)}] (1-1000)

   Send unicast opaque ZAPI messages with subtype ``type``. The
   protocol, instance, and session_id identify a single target zapi
   client. Sharpd will send a stream of messages if the count is
   greater than one.

.. clicmd:: sharp send opaque <reg | unreg> PROTOCOL [{instance (0-1000) | session (1-1000)}] type (1-1000)

   Send opaque ZAPI registration and unregistration messages for a
   single subtype. The messages must specify a protocol daemon by
   name, and can include optional zapi ``instance`` and ``session``
   values.

.. clicmd:: sharp create session (1-1024)

   Create an additional zapi client session for testing, using the
   specified session id.

.. clicmd:: sharp remove session (1-1024)

   Remove a test zapi client session that was created with the
   specified session id.

.. clicmd:: sharp neigh discover [vrf NAME] <A.B.C.D|X:X::X:X> IFNAME

   Send an ARP/NDP request to trigger the addition of a neighbor in the ARP
   table.

.. clicmd:: sharp import-te

   Import Traffic Engineering Database produced by OSPF or IS-IS.

.. clicmd:: show sharp ted [verbose|json]

.. clicmd:: show sharp ted [<vertex [A.B.C.D]|edge [A.B.C.D]|subnet [A.B.C.D/M]>] [verbose|json]

   Show imported Traffic Engineering Data Base

.. clicmd:: show sharp cspf source <A.B.C.D|X:X:X:X> destination <A.B.C.D|X:X:X:X> <metric|te-metric|delay> (0-16777215) [rsv-bw (0-7) BANDWIDTH]

   Show the result of a call to the Constraint Shortest Path First (CSPF)
   algorithm that allows to compute a path between a source and a
   destination under various constraints. Standard Metric, TE Metric, Delay
   and Bandwidth are supported constraints. Prior to use this function, it is
   necessary to import a Traffic Engineering Database with `sharp import-te`
   command (see above).

.. clicmd:: sharp install seg6-routes [vrf NAME] <A.B.C.D|X:X::X:X> nexthop-seg6 X:X::X:X encap X:X::X:X (1-1000000)

   This command installs a route for SRv6 Transit behavior (on Linux it is
   known as seg6 route). The count, destination, vrf, etc. have the same
   meaning as in the ``sharp install routes`` command.  With this command,
   sharpd will request zebra to configure seg6 route via ZEBRA_ROUTE_ADD
   ZAPI. As in the following example.

::

   router# sharp install seg6-routes 1::A nexthop-seg6 2001::2 encap A:: 1
   router# sharp install seg6-routes 1::B nexthop-seg6 2001::2 encap B:: 1

   router# show ipv6 route
   D>* 1::A/128 [150/0] via 2001::2, dum0, seg6 a::, weight 1, 00:00:01
   D>* 1::B/128 [150/0] via 2001::2, dum0, seg6 b::, weight 1, 00:00:01

   bash# ip -6 route list
   1::A  encap seg6 mode encap segs 1 [ a:: ] via 2001::2 dev dum0 proto 194 metric 20 pref medium
   1::B  encap seg6 mode encap segs 1 [ b:: ] via 2001::2 dev dum0 proto 194 metric 20 pref medium

.. clicmd:: sharp install seg6local-routes [vrf NAME] X:X::X:X nexthop-seg6local NAME ACTION ARGS.. (1-1000000)

   This command installs a route for SRv6 Endpoint behavior (on Linux it is
   known as seg6local route). The count, destination, vrf, etc. have the same
   meaning as in the ``sharp install routes`` command.  With this command,
   sharpd will request zebra to configure seg6local route via ZEBRA_ROUTE_ADD
   ZAPI. As in the following example.

   There are many End Functions defined in SRv6, which have been standardized
   in RFC 8986. The current implementation supports End, End.X, End.T, End.DX4,
   End.DT6 and End.DT46, which can be configured as follows.

::

   router# sharp install seg6local-routes 1::1 nexthop-seg6local dum0 End 1
   router# sharp install seg6local-routes 1::2 nexthop-seg6local dum0 End_X 2001::1 1
   router# sharp install seg6local-routes 1::3 nexthop-seg6local dum0 End_T 10 1
   router# sharp install seg6local-routes 1::4 nexthop-seg6local dum0 End_DX4 10.0.0.1 1
   router# sharp install seg6local-routes 1::5 nexthop-seg6local dum0 End_DT6 10 1
   router# sharp install seg6local-routes 1::6 nexthop-seg6local dum0 End_DT46 10 1

   router# show ipv6 route
   D>* 1::1/128 [150/0] is directly connected, dum0, seg6local End USP, weight 1, 00:00:05
   D>* 1::2/128 [150/0] is directly connected, dum0, seg6local End.X nh6 2001::1, weight 1, 00:00:05
   D>* 1::3/128 [150/0] is directly connected, dum0, seg6local End.T table 10, weight 1, 00:00:05
   D>* 1::4/128 [150/0] is directly connected, dum0, seg6local End.DX4 nh4 10.0.0.1, weight 1, 00:00:05
   D>* 1::5/128 [150/0] is directly connected, dum0, seg6local End.DT6 table 10, weight 1, 00:00:05
   D>* 1::6/128 [150/0] is directly connected, dum0, seg6local End.DT46 table 10, weight 1, 00:00:05

   bash# ip -6 route
   1::1  encap seg6local action End dev dum0 proto 194 metric 20 pref medium
   1::2  encap seg6local action End.X nh6 2001::1 dev dum0 proto 194 metric 20 pref medium
   1::3  encap seg6local action End.T table 10 dev dum0 proto 194 metric 20 pref medium
   1::4  encap seg6local action End.DX4 nh4 10.0.0.1 dev dum0 proto 194 metric 20 pref medium
   1::5  encap seg6local action End.DT6 table 10 dev dum0 proto 194 metric 20 pref medium
   1::6  encap seg6local action End.DT46 table 10 dev dum0 proto 194 metric 20 pref medium

.. clicmd:: show sharp segment-routing srv6

   This command shows us what SRv6 locator chunk, sharp is holding as zclient.
   An SRv6 locator is defined for each SRv6 router, and a single locator may
   be shared by multiple protocols.

   In the FRRouting implementation, the Locator chunk get request is executed
   by a routing protocol daemon such as sharpd or bgpd, And then Zebra
   allocates a Locator Chunk, which is a subset of the Locator Prefix, and
   notifies the requesting protocol daemon of this information.

   This command example shows how the locator chunk of sharpd itself is
   allocated.

::

   router# show segment-routing srv6 locator
   Locator:
   Name                 ID            2 2001:db8:2:2::/64        Up

   router# show sharp segment-routing srv6
   Locator loc1 has 1 prefix chunks
     2001:db8:1:1::/64

.. clicmd:: sharp srv6-manager get-locator-chunk

   This command requests the SRv6 locator to allocate a locator chunk via ZAPI.
   This chunk can be owned by the protocol daemon, and the chunk obtained by
   sharpd will not be used by the SRv6 mechanism of another routing protocol.

   Since this request is made asynchronously, it can be issued before the SRv6
   locator is configured on the zebra side, and as soon as it is ready on the
   zebra side, sharpd can check the allocated locator chunk via zapi.

::

   router# show segment-routing srv6 locator loc1 detail
   Name: loc1
   Prefix: 2001:db8:1:1::/64
   Chunks:
   - prefix: 2001:db8:1:1::/64, owner: system

   router# show sharp segment-routing srv6
   (nothing)

   router# sharp srv6-manager get-locator-chunk loc1

   router# show segment-routing srv6 locator loc1 detail
   Name: loc1
   Prefix: 2001:db8:1:1::/64
   Chunks:
   - prefix: 2001:db8:1:1::/64, owner: sharp

   router# show sharp segment-routing srv6
   Locator loc1 has 1 prefix chunks
     2001:db8:1:1::/64

.. clicmd:: sharp srv6-manager release-locator-chunk

   This command releases a locator chunk that has already been allocated by
   ZAPI. The freed chunk will have its owner returned to the system and will
   be available to another protocol daemon.

::

   router# show segment-routing srv6 locator loc1 detail
   Name: loc1
   Prefix: 2001:db8:1:1::/64
   Chunks:
   - prefix: 2001:db8:1:1::/64, owner: sharp

   router# show sharp segment-routing srv6
   Locator loc1 has 1 prefix chunks
     2001:db8:1:1::/64

   router# sharp srv6-manager release-locator-chunk loc1

   router# show segment-routing srv6 locator loc1 detail
   Name: loc1
   Prefix: 2001:db8:1:1::/64
   Chunks:
   - prefix: 2001:db8:1:1::/64, owner: system

   router# show sharp segment-routing srv6
   (nothing)

.. clicmd:: sharp interface IFNAME protodown

   Set an interface protodown.