forked from illumos/illumos-gate
-
Notifications
You must be signed in to change notification settings - Fork 111
/
overlay.c
2183 lines (2004 loc) · 74.2 KB
/
overlay.c
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
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
/*
* This file and its contents are supplied under the terms of the
* Common Development and Distribution License ("CDDL"), version 1.0.
* You may only use this file in accordance with the terms of version
* 1.0 of the CDDL.
*
* A full copy of the text of the CDDL should have accompanied this
* source. A copy of the CDDL is also available via the Internet at
* http://www.illumos.org/license/CDDL.
*/
/*
* Copyright 2016 Joyent, Inc.
* Copyright 2022 MNX Cloud, Inc.
*/
/*
* Overlay Devices
*
* Overlay devices provide a means for creating overlay networks, a means of
* multiplexing multiple logical, isolated, and discrete layer two and layer
* three networks on top of one physical network.
*
* In general, these overlay devices encapsulate the logic to answer two
* different questions:
*
* 1) How should I transform a packet to put it on the wire?
* 2) Where should I send a transformed packet?
*
* Each overlay device is presented to the user as a GLDv3 device. While the
* link itself cannot have an IP interface created on top of it, it allows for
* additional GLDv3 devices, such as a VNIC, to be created on top of it which
* can be plumbed up with IP interfaces.
*
*
* --------------------
* General Architecture
* --------------------
*
* The logical overlay device that a user sees in dladm(8) is a combination of
* two different components that work together. The first component is this
* kernel module, which is responsible for answering question one -- how should
* I transform a packet to put it on the wire.
*
* The second component is what we call the virtual ARP daemon, or varpd. It is
* a userland component that is responsible for answering the second question --
* Where should I send a transformed packet. Instances of the kernel overlay
* GLDv3 device ask varpd the question of where should a packet go.
*
* The split was done for a few reasons. Importantly, we wanted to keep the act
* of generating encapsulated packets in the kernel so as to ensure that the
* general data path was fast and also kept simple. On the flip side, while the
* question of where should something go may be simple, it may often be
* complicated and need to interface with several different external or
* distributed systems. In those cases, it's simpler to allow for the full
* flexibility of userland to be brought to bear to solve that problem and in
* general, the path isn't very common.
*
* The following is what makes up the logical overlay device that a user would
* create with dladm(8).
*
* Kernel Userland
* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
* . +--------+ +--------+ +--------+ . . .
* . | VNIC 0 | | VNIC 1 | | VNIC 2 | . . .
* . +--------+ +--------+ +--------+ . . .
* . | | | . . .
* . | | | . . .
* . +------------+-----------+ . . .
* . | . . /dev/overlay .
* . +--------------+ . . . +------------+ .
* . | | . . . | | .
* . | Overlay |======*=================| Virtual | .
* . | GLDv3 Device |========================| ARP Daemon | .
* . | | . . | | .
* . +--------------+ . . +------------+ .
* . | . . | .
* . | . . | .
* . +----------------+ . . +--------+ .
* . | Overlay | . . | varpd | .
* . | Encapsulation | . . | Lookup | .
* . | Plugin | . . | Plugin | .
* . +----------------+ . . +--------+ .
* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
*
*
* This image shows the two different components and where they live.
* Importantly, it also shows that both the kernel overlay device and the
* userland varpd both support plugins. The plugins actually implement the
* things that users care about and the APIs have been designed to try to
* minimize the amount of things that a module writer needs to worry about it.
*
* IDENTIFIERS
*
* Every overlay device is defined by a unique identifier which is the overlay
* identifier. Its purpose is similar to that of a VLAN identifier, it's a
* unique number that is used to differentiate between different entries on the
* wire.
*
* ENCAPSULATION
*
* An overlay encapsulation plugin is a kernel miscellaneous module whose
* purpose is to contain knowledge about how to transform packets to put them
* onto the wire and to take them off. An example of an encapsulation plugin is
* vxlan. It's also how support for things like nvgre or geneve would be brought
* into the system.
*
* Each encapsulation plugins defines a series of operation vectors and
* properties. For the full details on everything they should provide, please
* read uts/common/sys/overlay_plugin.h. The encapsulation plugin is responsible
* for telling the system what information is required to send a packet. For
* example, vxlan is defined to send everything over a UDP packet and therefore
* requires a port and an IP address, while nvgre on the other hand is its own
* IP type and therefore just requires an IP address. In addition, it also
* provides information about the kind of socket that should be created. This is
* used by the kernel multiplexor, more of that in the Kernel Components
* section.
*
* LOOKUPS
*
* The kernel communicates requests for lookups over the character device
* /dev/overlay. varpd is responsible for listening for requests on that device
* and answering them. The character device is specific to the target path and
* varpd.
*
* Much as the kernel overlay module handles the bulk of the scaffolding but
* leaves the important work to the encapsulation plugin, varpd provides a
* similar role and leaves the full brunt of lookups to a userland dynamic
* shared object which implements the logic of lookups.
*
* Each lookup plugin defines a series of operation vectors and properties. For
* the full details on everything that they should provide, please read
* lib/varpd/libvarpd/libvarpd_provider.h. Essentially, they are given a MAC
* address and asked to give an address on the physical network that it should
* be sent to. In addition, they handle questions related to how to handle
* things like broadcast and multicast traffic, etc.
*
* ----------
* Properties
* ----------
*
* A device from a dladm perspective has a unique set of properties that are
* combined from three different sources:
*
* 1) Generic properties that every overlay device has
* 2) Properties that are specific to the encapsulation plugin
* 3) Properties that are specific to the lookup plugin
*
* All of these are exposed in a single set of properties in dladm. Note that
* these are not necessarily traditional link properties. However, if something
* is both a traditional GLDv3 link property, say the MTU of a device, and a
* specific property here, than the driver ensures that all existing GLDv3
* specific means of manipulating it are used and wraps up its private property
* interfaces to ensure that works.
*
* Properties in the second and third category are prefixed with the name of
* their module. For example, the vxlan encapsulation module has a property
* called the 'listen_ip'. This property would show up in dladm as
* 'vxlan/listen_ip'. This allows different plugins to both use similar names
* for similar properties and to also have independent name spaces so that
* overlapping names do not conflict with anything else.
*
* While the kernel combines both sets one and two into a single coherent view,
* it does not do anything with respect to the properties that are owned by the
* lookup plugin -- those are owned wholly by varpd. Instead, libdladm is in
* charge of bridging these two worlds into one magical experience for the user.
* It carries the burden of knowing about both overlay specific and varpd
* specific properties. Importantly, we want to maintain this distinction. We
* don't want to treat the kernel as an arbitrary key/value store for varpd and
* we want the kernel to own its own data and not have to ask userland for
* information that it owns.
*
* Every property in the system has the following attributes:
*
* o A name
* o A type
* o A size
* o Permissions
* o Default value
* o Valid value ranges
* o A value
*
* Everything except for the value is obtained by callers through the propinfo
* callbacks and a property has a maximum size of OVERLAY_PROP_SIZEMAX,
* currently 256 bytes.
*
* The following are the supported types of properties:
*
* OVERLAY_PROP_T_INT
*
* A signed integer, its length is 8 bytes, corresponding to a
* int64_t.
*
* OVERLAY_PROP_T_UINT
*
* An unsigned integer, its length is 8 bytes, corresponding to a
* uint64_t.
*
* OVERLAY_PROP_T_IP
*
* A struct in6_addr, it has a fixed size.
*
* OVERLAY_PROP_T_STRING
*
* A null-terminated character string encoded in either ASCII or
* UTF-8. Note that the size of the string includes the null
* terminator.
*
* The next thing that we apply to a property is its permission. The permissions
* are put together by the bitwise or of the following flags and values.
*
* OVERLAY_PROP_PERM_REQ
*
* This indicates a required property. A property that is required
* must be set by a consumer before the device can be created. If a
* required property has a default property, this constraint is
* loosened because the default property defines the value.
*
* OVERLAY_PORP_PERM_READ
*
* This indicates that a property can be read. All properties will
* have this value set.
*
* OVERLAY_PROP_PERM_WRITE
*
* This indicates that a property can be written to and thus
* updated by userland. Properties that are only intended to
* display information, will not have OVERLAY_PROP_PERM_WRITE set.
*
* In addition, a few additional values are defined as a convenience to
* consumers. The first, OVERLAY_PROP_PERM_RW, is a combination of
* OVERLAY_PROP_PERM_READ and OVERLAY_PERM_PROP_WRITE. The second,
* OVERLAY_PROP_PERM_RRW, is a combination of OVERLAY_PROP_PERM_REQ,
* OVERLAY_PROP_PERM_READ, and OVERLAY_PROP_PERM_WRITE. The protection mode of a
* property should generally be a constant across its lifetime.
*
* A property may optionally have a default value. If it does have a default
* value, and that property is not set to be a different value, then the default
* value is inherited automatically. It also means that if the default value is
* acceptable, there is no need to set the value for a required property. For
* example, the vxlan module has the vxlan/listen_port property which is
* required, but has a default value of 4789 (the IANA assigned port). Because
* of that default value, there is no need for it to be set.
*
* Finally, a property may declare a list of valid values. These valid values
* are used for display purposes, they are not enforced by the broader system,
* but merely allow a means for the information to be communicated to the user
* through dladm(8). Like a default value, this is optional.
*
* The general scaffolding does not do very much with respect to the getting and
* setting of properties. That is really owned by the individual plugins
* themselves.
*
* -----------------------------
* Destinations and Plugin Types
* -----------------------------
*
* Both encapsulation and lookup plugins define the kinds of destinations that
* they know how to support. There are three different pieces of information
* that can be used to address to a destination currently, all of which is
* summarized in the type overlay_point_t. Any combination of these is
* supported.
*
* OVERLAY_PLUGIN_D_ETHERNET
*
* An Ethernet MAC address is required.
*
* OVERLAY_PLUGIN_D_IP
*
* An IP address is required. All IP addresses used by the overlay
* system are transmitted as IPv6 addresses. IPv4 addresses can be
* represented by using IPv4-mapped IPv6 addresses.
*
* OVERLAY_PLUGIN_D_PORT
*
* A TCP/UDP port is required.
*
* A kernel encapsulation plugin declares which of these that it requires, it's
* a static set. On the other hand, a userland lookup plugin can be built to
* support all of these or any combination thereof. It gets passed the required
* destination type, based on the kernel encapsulation method, and then it makes
* the determination as to whether or not it supports it. For example, the
* direct plugin can support either an IP or both an IP and a port, it simply
* doesn't display the direct/dest_port property in the cases where a port is
* not required to support this.
*
* The user lookup plugins have two different modes of operation which
* determines how they interact with the broader system and how look ups are
* performed. These types are:
*
* OVERLAY_TARGET_POINT
*
* A point to point plugin has a single static definition for where
* to send all traffic. Every packet in the system always gets sent
* to the exact same destination which is programmed into the
* kernel when the general device is activated.
*
* OVERLAY_TARGET_DYNAMIC
*
* A dynamic plugin does not have a single static definition.
* Instead, for each destination, the kernel makes an asynchronous
* request to varpd to determine where the packet should be routed,
* and if a specific destination is found, then that destination is
* cached in the overlay device's target cache.
*
* This distinction, while important for the general overlay device's operation,
* is not important to the encapsulation plugins. They don't need to know about
* any of these pieces. It's just a concern for varpd, the userland plugin, and
* the general overlay scaffolding.
*
* When an overlay device is set to OVERLAY_TARGET_POINT, then it does not
* maintain a target cache, and instead just keeps track of the destination and
* always sends encapsulated packets to that address. When the target type is of
* OVERLAY_TARGET_DYNAMIC, then the kernel maintains a cache of all such
* destinations. These destinations are kept around in an instance of a
* reference hash that is specific to the given overlay device. Entries in the
* cache can be invalidated and replaced by varpd and its lookup plugins.
*
* ----------------------------------
* Kernel Components and Architecture
* ----------------------------------
*
* There are multiple pieces inside the kernel that work together, there is the
* general overlay_dev_t structure, which is the logical GLDv3 device, but it
* itself has references to things like an instance of an encapsulation plugin,
* a pointer to a mux and a target cache. It can roughly be summarized in the
* following image:
*
* +------------------+
* | global |
* | overlay list |
* | overlay_dev_list |
* +------------------+
* |
* | +-----------------------+ +---------------+
* +->| GLDv3 Device |----------->| GLDv3 Device | -> ...
* | overlay_dev_t | | overlay_dev_t |
* | | +---------------+
* | |
* | mac_handle_t -----+---> GLDv3 handle to MAC
* | datalink_id_t -----+---> Datalink ID used by DLS
* | overlay_dev_flag_t ---+---> Device state
* | uint_t -----+---> Current device MTU
* | uint_t -----+---> In-progress RX operations
* | uint_t -----+---> In-progress TX operations
* | char[] -----+---> FMA degraded message
* | void * -----+---> plugin private data
* | overlay_target_t * ---+---------------------+
* | overlay_plugin_t * ---+---------+ |
* +-----------------------+ | |
* ^ | |
* +--------------------+ | | |
* | Kernel Socket | | | |
* | Multiplexor | | | |
* | overlay_mux_t | | | |
* | | | | |
* | avl_tree_t -+--+ | |
* | uint_t -+--> socket family | |
* | uint_t -+--> socket type | |
* | uint_t -+--> socket protocol | |
* | ksocket_t -+--> I/O socket | |
* | struct sockaddr * -+--> ksocket address | |
* | overlay_plugin_t --+--------+ | |
* +--------------------+ | | |
* | | |
* +-------------------------+ | | |
* | Encap Plugin |<--+-----------+ |
* | overlay_plugin_t | |
* | | |
* | char * ---+--> plugin name |
* | overlay_plugin_ops_t * -+--> plugin downcalls |
* | char ** (props) ---+--> property list |
* | uint_t ---+--> id length |
* | overlay_plugin_flags_t -+--> plugin flags |
* | overlay_plugin_dest_t --+--> destination type v
* +-------------------------+ +-------------------------+
* | Target Cache |
* | overlay_target_t |
* | |
* cache mode <--+- overlay_target_mode_t |
* dest type <--+- overlay_plugin_dest_t |
* cache flags <--+- overlay_target_flag_t |
* varpd id <--+- uint64_t |
* outstanding varpd reqs. <--+- uint_t |
* OVERLAY_TARGET_POINT state <--+- overlay_target_point_t |
* OVERLAY_TARGET_DYNAMIC state <-+---+- overlay_target_dyn_t |
* | +-------------------------+
* +-----------------------+
* |
* v
* +-------------------------------+ +------------------------+
* | Target Entry |-->| Target Entry |--> ...
* | overlay_target_entry_t | | overlay_target_entry_t |
* | | +------------------------+
* | |
* | overlay_target_entry_flags_t -+--> Entry flags
* | uint8_t[ETHERADDRL] ---+--> Target MAC address
* | overlay_target_point_t ---+--> Target underlay address
* | mblk_t * ---+--> outstanding mblk head
* | mblk_t * ---+--> outstanding mblk tail
* | size_t ---+--> outstanding mblk size
* +-------------------------------+
*
* The primary entries that we care about are the overlay_dev_t, which
* correspond to each overlay device that is created with dladm(8). Globally,
* these devices are maintained in a simple list_t which is protected with a
* lock. Hence, these include important information such as the mac_handle_t
* and a datalink_id_t which is used to interact with the broader MAC and DLS
* ecosystem. We also maintain additional information such as the current state,
* outstanding operations, the mtu, and importantly, the plugin's private data.
* This is the instance of an encapsulation plugin that gets created as part of
* creating an overlay device. Another aspect of this is that the overlay_dev_t
* also includes information with respect to FMA. For more information, see the
* FMA section.
*
* Each overlay_dev_t has a pointer to a plugin, a mux, and a target. The plugin
* is the encapsulation plugin. This allows the device to make downcalls into it
* based on doing things like getting and setting properties. Otherwise, the
* plugin itself is a fairly straightforward entity. They are maintained in an
* (not pictured above) list. The plugins themselves mostly maintain things like
* the static list of properties, what kind of destination they require, and the
* operations vector. A given module may contain more if necessary.
*
* The next piece of the puzzle is the mux, or a multiplexor. The mux itself
* maintains a ksocket and it is through the mux that we send and receive
* message blocks. The mux represents a socket type and address, as well as a
* plugin. Multiple overlay_dev_t devices may then share the same mux. For
* example, consider the case where you have different instances of vxlan all on
* the same underlay network. These would all logically share the same IP
* address and port that packets are sent and received on; however, what differs
* is the decapuslation ID.
*
* Each mux maintains a ksocket_t which is similar to a socket(3SOCKET). Unlike
* a socket, we enable a direct callback on the ksocket. This means that
* whenever a message block chain is received, rather than sitting there and
* getting a callback in a context and kicking that back out to a taskq. Instead
* data comes into the callback function overlay_mux_recv().
*
* The mux is given encapsulated packets (via overlay_m_tx, the GLDv3 tx
* function) to transmit. It receives encapsulated packets, decapsulates them to
* determine the overlay identifier, looks up the given device that matches that
* identifier, and then causes the broader MAC world to receive the packet with
* a call to mac_rx().
*
* Today, we don't do too much that's special with the ksocket; however, as
* hardware is gaining understanding for these encapsulation protocols, we'll
* probably want to think of better ways to get those capabilities passed down
* and potentially better ways to program receive filters so they get directly
* to us. Though, that's all fantasy future land.
*
* The next part of the puzzle is the target cache. The purpose of the target
* cache is to cache where we should send a packet on the underlay network,
* given its mac address. The target cache operates in two modes depending on
* whether the lookup module was declared to OVERLAY_TARGET_POINT or
* OVERLAY_TARGET_DYANMIC.
*
* In the case where the target cache has been programmed to be
* OVERLAY_TARGET_POINT, then we only maintain a single overlay_target_point_t
* which has the destination that we send everything, no matter the destination
* mac address.
*
* On the other hand, when we have an instance of OVERLAY_TARGET_DYNAMIC, things
* are much more interesting and as a result, more complicated. We primarily
* store lists of overlay_target_entry_t's which are stored in both an avl tree
* and a refhash_t. The primary look up path uses the refhash_t and the avl tree
* is only used for a few of the target ioctls used to dump data such that we
* can get a consistent iteration order for things like dladm show-overlay -t.
* The key that we use for the reference hashtable is based on the mac address
* in the cache and currently we just do a simple CRC32 to transform it into a
* hash.
*
* Each entry maintains a set of flags to indicate the current status of the
* request. The flags may indicate one of three states: that current cache entry
* is valid, that the current cache entry has been directed to drop all output,
* and that the current cache entry is invalid and may be being looked up. In
* the case where it's valid, we just take the destination address and run with
* it.
*
* If it's invalid and a lookup has not been made, then we start the process
* that prepares a query that will make its way up to varpd. The cache entry
* entry maintains a message block chain of outstanding message blocks and a
* size. These lists are populated only when we don't know the answer as to
* where should these be sent. The size entry is used to cap the amount of
* outstanding data that we don't know the answer to. If we exceed a cap on the
* amount of outstanding data (currently 1 Mb), then we'll drop any additional
* packets. Once we get an answer indicating a valid destination, we transmit
* any outstanding data to that place. For the full story on how we look that up
* will be discussed in the section on the Target Cache Lifecycle.
*
* ------------------------
* FMA and Degraded Devices
* ------------------------
*
* Every kernel overlay device keeps track of its FMA state. Today in FMA we
* cannot represent partitions between resources nor can we represent that a
* given minor node of a pseudo device has failed -- if we degrade the overlay
* device, then the entire dev_info_t is degraded. However, we still want to be
* able to indicate to administrators that things may go wrong.
*
* To this end, we've added a notion of a degraded state to every overlay
* device. This state is primarily dictated by userland and it can happen for
* various reasons. Generally, because a userland lookup plugin has been
* partitioned, or something has gone wrong such that there is no longer any
* userland lookup module for a device, then we'll mark it degraded.
*
* As long as any of our minor instances is degraded, then we'll fire off the
* FMA event to note that. Once the last degraded instance is no longer
* degraded, then we'll end up telling FMA that we're all clean.
*
* To help administrators get a better sense of which of the various minor
* devices is wrong, we store the odd_fmamsg[] character array. This character
* array can be fetched with doing a dladm show-overlay -f.
*
* Note, that it's important that we do not update the link status of the
* devices. We want to remain up as much as possible. By changing the link in a
* degraded state, this may end up making things worse. We may still actually
* have information in the target cache and if we mark the link down, that'll
* result in not being able to use it. The reason being that this'll mark all
* the downstream VNICs down which will go to IP and from there we end up
* dealing with sadness.
*
* -----------------------
* Target Cache Life Cycle
* -----------------------
*
* This section only applies when we have a lookup plugin of
* OVERLAY_TARGET_DYNAMIC. None of this applies to those of type
* OVERLAY_TARGET_POINT.
*
* While we got into the target cache in the general architecture section, it's
* worth going into more details as to how this actually works and showing some
* examples and state machines. Recall that a target cache entry basically has
* the following state transition diagram:
*
* Initial state
* . . . . . . first access . . . varpd lookup enqueued
* . . .
* . . .
* +-------+ . +----------+ .
* | No |------*---->| Invalid |-------*----+
* | Entry | | Entry | |
* +-------+ +----------+ |
* varpd ^ ^ varpd |
* invalidate | | drop |
* . . . * * . . v
* +-------+ | | +---------+
* | Entry |--->-----+ +----<----| Entry |
* | Valid |<----------*---------<----| Pending |->-+ varpd
* +-------+ . +---------+ * . . drop, but
* . varpd ^ | other queued
* . success | | entries
* +-----+
*
* When the table is first created, it is empty. As we attempt to lookup entries
* and we find there is no entry at all, we'll create a new table entry for it.
* At that point the entry is technically in an invalid state, that means that
* we have no valid data from varpd. In that case, we'll go ahead and queue the
* packet into the entry's pending chain, and queue a varpd lookup, setting the
* OVERLAY_ENTRY_F_PENDING flag in the progress.
*
* If additional mblk_t's come in for this entry, we end up appending them to
* the tail of the chain, if and only if, we don't exceed the threshold for the
* amount of space they can take up. An entry remains pending until we get a
* varpd reply. If varpd replies with a valid results, we move to the valid
* entry state, and remove the OVERLAY_ENTRY_F_PENDING flag and set it with one
* of OVERLAY_ENTRY_F_VALID or OVERLAY_ENTRY_F_DROP as appropriate.
*
* Once an entry is valid, it stays valid until user land tells us to invalidate
* it with an ioctl or replace it, OVERLAY_TARG_CACHE_REMOE and
* OVERLAY_TARG_CACHE_SET respectively.
*
* If the lookup fails with a call to drop the packet, then the next state is
* determined by the state of the queue. If the set of outstanding entries is
* empty, then we just transition back to the invalid state. If instead, the
* set of outstanding entries is not empty, then we'll queue another entry and
* stay in the same state, repeating this until the number of requests is
* drained.
*
* The following images describes the flow of a given lookup and where the
* overlay_target_entry_t is at any given time.
*
* +-------------------+
* | Invalid Entry | An entry starts off as an invalid entry
* | de:ad:be:ef:00:00 | and only exists in the target cache.
* +-------------------+
*
* ~~~~
*
* +---------------------+
* | Global list_t | A mblk_t comes in for an entry. We
* | overlay_target_list | append it to the overlay_target_list.
* +---------------------+
* |
* v
* +-------------------+ +-------------------+
* | Pending Entry |----->| Pending Entry |--->...
* | 42:5e:1a:10:d6:2d | | de:ad:be:ef:00:00 |
* +-------------------+ +-------------------+
*
* ~~~~
*
* +--------------------------+
* | /dev/overlay minor state | User land said that it would look up an
* | overlay_target_hdl_t | entry for us. We remove it from the
* +--------------------------+ global list and add it to the handle's
* | outstanding list.
* |
* v
* +-------------------+ +-------------------+
* | Pending Entry |----->| Pending Entry |
* | 90:b8:d0:79:02:dd | | de:ad:be:ef:00:00 |
* +-------------------+ +-------------------+
*
* ~~~~
*
* +-------------------+
* | Valid Entry | varpd returned an answer with
* | de:ad:be:ef:00:00 | OVERLAY_IOC_RESPOND and the target cache
* | 10.169.23.42:4789 | entry is now populated with a
* +-------------------+ destination and marked as valid
*
*
* The lookup mechanism is performed via a series of operations on the character
* pseudo-device /dev/overlay. The only thing that uses this device is the
* userland daemon varpd. /dev/overlay is a cloneable device, each open of it
* granting a new minor number which maintains its own state. We maintain this
* state so that way if an outstanding lookup was queued to something that
* crashed or closed its handle without responding, we can know about this and
* thus handle it appropriately.
*
* When a lookup is first created it's added to our global list of outstanding
* lookups. To service requests, userland is required to perform an ioctl to ask
* for a request. We will block it in the kernel a set amount of time waiting
* for a request. When we give a request to a given minor instance of the
* device, we remove it from the global list and append the request to the
* device's list of outstanding entries, for the reasons we discussed above.
* When a lookup comes in, we give user land a smaller amount of information
* specific to that packet, the overlay_targ_lookup_t. It includes a request id
* to identify this, and then the overlay id, the varpd id, the header and
* packet size, the source and destination mac address, the SAP, and any
* potential VLAN header.
*
* At that point, it stays in that outstanding list until one of two ioctls are
* returned: OVERLAY_TARG_RESPOND or OVERLAY_TARG_DROP. During this time,
* userland may also perform other operations. For example, it may use
* OVERLAY_TARG_PKT to get a copy of this packet so it can perform more in-depth
* analysis of what to do beyond what we gave it initially. This is useful for
* providing proxy arp and the like. Finally, there are two other ioctls that
* varpd can then do. The first is OVERLAY_TARG_INJECT which injects the
* non-jumbo frame packet up into that mac device and OVERLAY_TARG_RESEND which
* causes us to encapsulate and send out the packet they've given us.
*
*
* Finally, through the target cache, several ioctls are provided to allow for
* interrogation and management of the cache. They allow for individual entries
* to be retrieved, set, or have the entire table flushed. For the full set of
* ioctls here and what they do, take a look at uts/common/sys/overlay_target.h.
*
* ------------------
* Sample Packet Flow
* ------------------
*
* There's a lot of pieces here, hopefully an example of how this all fits
* together will help clarify and elucidate what's going on. We're going to
* first track an outgoing packet, eg. one that is sent from an IP interface on
* a VNIC on top of an overlay device, and then we'll look at what it means to
* respond to that.
*
*
* +----------------+ +--------------+ +------------------+
* | IP/DLS send |------->| MAC sends it |----------->| mblk_t reaches |
* | packet to MAC | | to the GLDv3 | | overlay GLDv3 tx |
* +----------------+ | VNIC device | | overlay_m_tx() |
* +--------------+ +------------------+
* |
* . lookup . cache |
* . drop . miss v
* +---------+ . +--------+ . +------------------+
* | freemsg |<-----*-------| varpd |<---*------| Lookup each mblk |
* | mblk_t | | lookup | | in the target |
* +---------+ | queued | | cache |
* ^ +--------+ +------------------+
* on send | | | cache
* error . . * *. . lookup * . . hit
* | | success v
* | | +------------------+
* +-----------------+ +--------------->| call plugin |
* | Send out | | ovpo_encap() to |
* | overlay_mux_t's |<----------------------------------| get encap mblk_t |
* | ksocket | +------------------+
* +-----------------+
*
* The receive end point looks a little different and looks more like:
*
* +------------------+ +----------------+ +-----------+
* | mblk_t comes off |---->| enter netstack |--->| delivered |---+
* | the physical | | IP stack | | to | * . . direct
* | device | +----------------+ | ksocket | | callback
* +------------------+ +-----------+ |
* . overlay id |
* . not found v
* +-----------+ . +-----------------+ +--------------------+
* | freemsg |<--*------| call plugin |<------| overlay_mux_recv() |
* | mblk_t | | ovpo_decap() to | +--------------------+
* +-----------+ | decap mblk_t |
* +-----------------+
* |
* * . . overlay id
* v found
* +--------+ +----------------+
* | adjust |----->| call mac_rx |
* | mblk_t | | on original |
* +--------+ | decaped packet |
* +----------------+
*
* ------------------
* Netstack Awareness
* ------------------
*
* In the above image we note that this enters a netstack. Today the only
* netstack that can be is the global zone as the overlay driver itself is not
* exactly netstack aware. What this really means is that varpd cannot run in a
* non-global zone and an overlay device cannot belong to a non-global zone.
* Non-global zones can still have a VNIC assigned to them that's been created
* over the overlay device the same way they would if it had been created over
* an etherstub or a physical device.
*
* The majority of the work to make it netstack aware is straightforward and the
* biggest thing is to create a netstack module that allows us to hook into
* netstack (and thus zone) creation and destruction. From there, we need to
* amend the target cache lookup routines that we discussed earlier to not have
* a global outstanding list and a global list of handles, but rather, one per
* netstack.
*
* For the mux, we'll need to open the ksocket in the context of the zone, we
* can likely do this with a properly composed credential, but we'll need to do
* some more work on that path. Finally, we'll want to make sure the dld ioctls
* are aware of the zoneid of the caller and we use that appropriately and store
* it in the overlay_dev_t.
*
* -----------
* GLDv3 Notes
* -----------
*
* The overlay driver implements a GLDv3 device. Parts of GLDv3 are more
* relevant and other parts are much less relevant for us. For example, the
* GLDv3 is used to toggle the device being put into and out of promiscuous
* mode, to program MAC addresses for unicast and multicast hardware filters.
* Today, an overlay device doesn't have a notion of promiscuous mode nor does
* it have a notion of unicast and multicast addresses programmed into the
* device. Instead, for the purposes of the hardware filter, we don't do
* anything and just always accept new addresses being added and removed.
*
* If the GLDv3 start function has not been called, then we will not use this
* device for I/O purposes. Any calls to transmit or receive should be dropped,
* though the GLDv3 guarantees us that transmit will not be called without
* calling start. Similarly, once stop is called, then no packets can be dealt
* with.
*
* Today we don't support the stat interfaces, though there's no good reason
* that we shouldn't assemble some of the stats based on what we have in the
* future.
*
* When it comes to link properties, many of the traditional link properties do
* not apply and many others MAC handles for us. For example, we don't need to
* implement anything for overlay_m_getprop() to deal with returning the MTU, as
* MAC never calls into us for that. As such, there isn't much of anything to
* support in terms of properties.
*
* Today, we don't support any notion of hardware capabilities. However, if
* future NIC hardware or other changes to the system cause it to make sense for
* us to emulate logical groups, then we should do that. However, we still do
* implement a capab function so that we can identify ourselves as an overlay
* device to the broader MAC framework. This is done mostly so that a device
* created on top of us can have fanout rings as we don't try to lie about a
* speed for our device.
*
* The other question is what should be done for a device's MTU and margin. We
* set our minimum supported MTU to be the minimum value that an IP network may
* be set to 576 -- which mimics what an etherstub does. On the flip side, we
* have our upper bound set to 8900. This value comes from the fact that a lot
* of jumbo networks use their maximum as 9000. As such, we want to reserve 100
* bytes, which isn't exactly the most accurate number, but it'll be good enough
* for now. Because of that, our default MTU off of these devices is 1400, as
* the default MTU for everything is usually 1500 or whatever the underlying
* device is at; however, this is a bit simpler than asking the netstack what
* are all the IP interfaces at. It also calls into question how PMTU and PMTU
* discovery should work here. The challenge, especially for
* OVERLAY_TARG_DYNAMIC is that the MTU to any of the places will vary and it's
* not clear that if you have a single bad entry that the overall MTU should be
* lowered. Instead, we should figure out a better way of determining these
* kinds of PMTU errors and appropriately alerting the administrator via FMA.
*
* Regarding margin, we allow a margin of up to VLAN_TAGSZ depending on whether
* or not the underlying encapsulation device supports VLAN tags. If it does,
* then we'll set the margin to allow for it, otherwise, we will not.
*/
#include <sys/conf.h>
#include <sys/errno.h>
#include <sys/stat.h>
#include <sys/ddi.h>
#include <sys/sunddi.h>
#include <sys/modctl.h>
#include <sys/policy.h>
#include <sys/stream.h>
#include <sys/strsubr.h>
#include <sys/strsun.h>
#include <sys/types.h>
#include <sys/kmem.h>
#include <sys/param.h>
#include <sys/sysmacros.h>
#include <sys/ddifm.h>
#include <sys/dls.h>
#include <sys/dld_ioc.h>
#include <sys/mac_provider.h>
#include <sys/mac_client_priv.h>
#include <sys/mac_ether.h>
#include <sys/vlan.h>
#include <sys/overlay_impl.h>
dev_info_t *overlay_dip;
static kmutex_t overlay_dev_lock;
static list_t overlay_dev_list;
static uint8_t overlay_macaddr[ETHERADDRL] =
{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
typedef enum overlay_dev_prop {
OVERLAY_DEV_P_MTU = 0,
OVERLAY_DEV_P_VNETID,
OVERLAY_DEV_P_ENCAP,
OVERLAY_DEV_P_VARPDID
} overlay_dev_prop_t;
#define OVERLAY_DEV_NPROPS 4
static const char *overlay_dev_props[] = {
"mtu",
"vnetid",
"encap",
"varpd/id"
};
#define OVERLAY_MTU_MIN 576
#define OVERLAY_MTU_DEF 1400
#define OVERLAY_MTU_MAX 8900
overlay_dev_t *
overlay_hold_by_dlid(datalink_id_t id)
{
overlay_dev_t *o;
mutex_enter(&overlay_dev_lock);
for (o = list_head(&overlay_dev_list); o != NULL;
o = list_next(&overlay_dev_list, o)) {
if (id == o->odd_linkid) {
mutex_enter(&o->odd_lock);
o->odd_ref++;
mutex_exit(&o->odd_lock);
mutex_exit(&overlay_dev_lock);
return (o);
}
}
mutex_exit(&overlay_dev_lock);
return (NULL);
}
void
overlay_hold_rele(overlay_dev_t *odd)
{
mutex_enter(&odd->odd_lock);
ASSERT(odd->odd_ref > 0);
odd->odd_ref--;
mutex_exit(&odd->odd_lock);
}
void
overlay_io_start(overlay_dev_t *odd, overlay_dev_flag_t flag)
{
ASSERT(flag == OVERLAY_F_IN_RX || flag == OVERLAY_F_IN_TX);
ASSERT(MUTEX_HELD(&odd->odd_lock));
if (flag & OVERLAY_F_IN_RX)
odd->odd_rxcount++;
if (flag & OVERLAY_F_IN_TX)
odd->odd_txcount++;
odd->odd_flags |= flag;
}
void
overlay_io_done(overlay_dev_t *odd, overlay_dev_flag_t flag)
{
boolean_t signal = B_FALSE;
ASSERT(flag == OVERLAY_F_IN_RX || flag == OVERLAY_F_IN_TX);
ASSERT(MUTEX_HELD(&odd->odd_lock));
if (flag & OVERLAY_F_IN_RX) {
ASSERT(odd->odd_rxcount > 0);
odd->odd_rxcount--;
if (odd->odd_rxcount == 0) {
signal = B_TRUE;
odd->odd_flags &= ~OVERLAY_F_IN_RX;
}
}
if (flag & OVERLAY_F_IN_TX) {
ASSERT(odd->odd_txcount > 0);
odd->odd_txcount--;
if (odd->odd_txcount == 0) {
signal = B_TRUE;
odd->odd_flags &= ~OVERLAY_F_IN_TX;
}
}
if (signal == B_TRUE)
cv_broadcast(&odd->odd_iowait);
}
static void
overlay_io_wait(overlay_dev_t *odd, overlay_dev_flag_t flag)
{
ASSERT((flag & ~OVERLAY_F_IOMASK) == 0);
ASSERT(MUTEX_HELD(&odd->odd_lock));
while (odd->odd_flags & flag) {
cv_wait(&odd->odd_iowait, &odd->odd_lock);
}
}
void
overlay_dev_iter(overlay_dev_iter_f func, void *arg)
{
overlay_dev_t *odd;
mutex_enter(&overlay_dev_lock);
for (odd = list_head(&overlay_dev_list); odd != NULL;
odd = list_next(&overlay_dev_list, odd)) {
if (func(odd, arg) != 0) {
mutex_exit(&overlay_dev_lock);
return;
}
}
mutex_exit(&overlay_dev_lock);
}
/* ARGSUSED */
static int
overlay_m_stat(void *arg, uint_t stat, uint64_t *val)
{
return (ENOTSUP);
}
static int
overlay_m_start(void *arg)
{
overlay_dev_t *odd = arg;
overlay_mux_t *mux;
int ret, domain, family, prot;
struct sockaddr_storage storage;
socklen_t slen;
mutex_enter(&odd->odd_lock);
if ((odd->odd_flags & OVERLAY_F_ACTIVATED) == 0) {
mutex_exit(&odd->odd_lock);
return (EAGAIN);
}
mutex_exit(&odd->odd_lock);
ret = odd->odd_plugin->ovp_ops->ovpo_socket(odd->odd_pvoid, &domain,
&family, &prot, (struct sockaddr *)&storage, &slen);
if (ret != 0)
return (ret);
mux = overlay_mux_open(odd->odd_plugin, domain, family, prot,
(struct sockaddr *)&storage, slen, &ret);
if (mux == NULL)
return (ret);
overlay_mux_add_dev(mux, odd);
odd->odd_mux = mux;
mutex_enter(&odd->odd_lock);
ASSERT(!(odd->odd_flags & OVERLAY_F_IN_MUX));
odd->odd_flags |= OVERLAY_F_IN_MUX;
mutex_exit(&odd->odd_lock);
return (0);
}
static void
overlay_m_stop(void *arg)
{
overlay_dev_t *odd = arg;
/*
* The MAC Perimeter is held here, so we don't have to worry about
* synchronizing this with respect to metadata operations.
*/
mutex_enter(&odd->odd_lock);