Inviting everyone in the networking community to review the TRILL design document. Solaris Bridging and TRILL are deliverables of the RBridges project. TRILL builds on the functionality provided by Solaris Bridging. TRILL design document is available at:
http://www.opensolaris.org/os/project/rbridges/files/trilldesign.pdf I am also including the text in-line below. I am setting the timer for review feedback to expire on July 9th. If you need more time for review then please let me know. Thanks, Rishi ------- OpenSolaris TRILL 1. Introduction TRILL (Transparent Interconnection of Lots of Links) is a new protocol under active development at the IETF for layer-2 bridging. Devices implementing the new protocol are called RBridges (Routing Bridges) as they share features from layer-3 routers and layer-2 bridges. RBridges are an improvement over IEEE 802.1D Bridges in various ways, including the use of a new tunneling protocol called "TRILL" to transport packets on pairwise shortest paths between RBridges and utilizing a TTL field in the TRILL header to avoid temporary forwarding loops. TRILL utilizes the IS-IS link state routing protocol to compute pairwise shortest paths between RBridges. IEEE 802.1D Bridges however use the spanning tree protocol (STP) to compute a forwarding path that concentrates traffic to selected links in the spanning tree. 802.1D Bridges are also prone to temporary forwarding loops due to mis-configuration or loss of STP messages and cannot be prevented as the Ethernet header has no hop count (TTL) field. Both 802.1D Bridges and RBridges are compatible and can function together on the same network to ensure a number of physical links appear as a single network to layer-3 protocols such as IP. In the following document we describe the design of the TRILL protocol implementation in OpenSolaris. There are two components in the TRILL protocol implementation: the IS-IS routing protocol extensions for TRILL used in computing the layer-2 link-state database and the TRILL kernel module for the transmission, receipt and forwarding of TRILL packets. In the following document TRILL refers to the protocol, RBridge refers to the bridge instance using the TRILL protocol for forwarding and we explicitly mention 802.1D or the spanning tree protocol (STP) when referring to regular 802.1D Bridges. TRILL protocol details are covered in the IETF TRILL documents [TRILL] and are suggested reading. As the TRILL design is built on the support for Bridging in Solaris prior reading of the Solaris Bridging design document [BRIDGE] is also recommended. TRILL utilizes an extended IS-IS link-state routing protocol to calculate the optimal forwarding paths between RBridges. The IS-IS link-state routing protocol instance used by TRILL is similar in operation to the IS-IS protocol for layer-3 routing. "TRILL IS-IS" is used to denote the extensions to the IS-IS protocol introduced for TRILL. The open-source Quagga routing protocol suite includes support for the IS-IS layer-3 routing protocol (isisd). We have added support for layer-2 TRILL IS-IS in the Quagga protocol suite and further describe the changes in section 3. The TRILL kernel module provides an AF_TRILL socket interface to enable the TRILL IS-IS daemon (trilld) to control and configure TRILL forwarding. The AF_TRILL socket support is implemented via a Volo kernel socket module. The TRILL kernel module utilizes the bridging support in OpenSolaris for the transmission and receipt of both TRILL control packets and TRILL forwarded data packets. TRILL is provided as an alternative to STP when configuring a bridge instance on OpenSolaris. Users create RBridge instances by creating bridges using the dladm command and choosing the "trill" protection option. 2. Background In this section we briefly describe the TRILL protocol. RBridges use TRILL to tunnel Ethernet packets between RBridges. End-nodes do not participate in TRILL. Ethernet packets forwarded via TRILL are encapsulated with a TRILL header. The first RBridge that encapsulates an Ethernet frame for tunneling across links is called an "ingress" RBridge. The last RBridge that decapsulates the TRILL frame for delivery of the packet on the remote link is called an "egress" RBridge. All RBridges participating in the TRILL protocol have a 16-bit unique ID called the nickname. The ingress RBridge determines the optimal forwarding path of the packet and sets the ingress and egress RBridge nicks in the TRILL header of the packet. In case of multiple-destination frames the ingress RBridge sets the multiple-destination frame flag in the TRILL header and the egress RBridge is set to match the distribution tree (DT) root nick chosen for the forwarding paths of the packet (distribution trees are further described in section 2.3). On receiving TRILL encapsulated packets RBridges act like routers and use the "egress" nickname to determine the next-hop RBridge and forward the packet. If the "egress" nick is self then RBridges decapsulate the TRILL packet and transmit the native Ethernet frame on the local link. TRILL relies on an extended version of the IS-IS link-state routing protocol to create pair-wise shortest paths between RBridges. We provide a short overview of the IS-IS link-state routing protocol below: 2.1 IS-IS IS-IS is a link-state routing protocol. Each IS-IS router sends probe packets periodically to discover the state of adjacent routers (neighbors) and distributes (floods) the link-state identifying the adjacent routers with all other IS-IS routers. The former packets are called Hello PDUs and the latter are called LSP PDUs. Each IS-IS router uses the link-state information from all IS-IS routers to construct a map (aka the link-state database) describing the connections between all routers. Once the map is constructed each IS-IS router independently uses the map to compute the shortest-path routes and update the routing table. IS-IS uses CSNP/PSNP PDUs (complete/partial sequence number packets) to efficiently synchronize the link-state databases between all routers. Each LSP is assigned a sequence number and includes checksum allowing IS-IS routers to quickly determine and update any link-state changes with other routers. On a network with more than one IS-IS router a designated IS router (DIS) is elected to reduce number of adjacencies reported in link-state advertisements from routers on the same link. Instead the shared network is considered a pseudonode and the DIS advertises the pseudonode with connections to the adjacent IS-IS routers, all including the DIS report a single adjacency with the pseudonode. 2.2. TRILL IS-IS IS-IS link-state routing protocol was chosen by TRILL for layer-2 routing of TRILL packets due to the following reasons: unlike OSPF IS-IS utilizes Type-Length-Value (TLV) encoding for protocol data and is not specific for use with IP or any one particular layer-3 protocol. TLVs are easily extensible and new types can be introduced with-out impacting existing consumers. TRILL introduces new IS-IS extensions in the form of new IS-IS TLVs for both Hello PDUs and LSP PDUs to advertise additional TRILL specific state information such as : 16-bit nicknames used to identify RBridges, TRILL flags, enabled VLANs, distribution tree roots and appointed forwarders etc. Nicknames are included in LSP PDUs along with a priority of use field value. TRILL IS-IS routers detect nickname conflicts and based on priority and system ID (in case of identical priority) select and advertise a new nickname. TRILL IS-IS routers also exchange appointed-forwarder (AF) status on the local link. On a link with more than one RBridge an RBridge is chosen as the appointed forwarder per VLAN. Only the appointed forwarder encapsulates and decapsulates Ethernet traffic from a particular VLAN on the local link. An AF can be assigned for more than one VLAN. The AF status of a RBridge for a set of VLAN IDs is included in both Hello and LSP PDUs. The TRILL AF assignment is done by the DIS router on the link by using the set of enabled VLAN IDs each router advertises on the link. 2.3. TRILL Distribution Trees TRILL IS-IS routers utilize the link-state database to compute pair-wise optimal paths between RBridges. These optimal paths between RBridges are used to forward a known unicast frame i.e. the "egress" RBridge for forwarding the Ethernet frame is known. But for multiple-destination frames (unknown destination, broadcast and multicast frames) TRILL utilizes distribution trees for optimal forwarding of the packet to all other RBridges. A distribution tree is the result of a Shortest-Path-First (SPF) computation over all known RBridges from the TRILL IS-IS link-state database with a particular RBridge as root. RBridges use multiple DTs with different RBridges as root to allow for multi-path forwarding (avoids concentration of TRILL frames to a select number of links) and allows RBridges to choose a DT closer/identical to the "ingress" RBridge to reduce out-of-delivery packets. RBridges advertise their choice of DT roots in TRILL IS-IS link-state advertisements. All RBridges create and maintain multiple DTs with a number of RBridges as roots. RBridges at a minimum should create all DTs that were advertised as in use by other RBridges. OpenSolaris IS-IS TRILL creates all possible DTs. 2.4. TRILL forwarding During forwarding of TRILL frames RBridges run a set of checks on the TRILL packet to ensure subsequent forwarding of the packet is optimal and safe (no loops). For known unicast frames RBridges lookup the next-hop RBridge from the "egress" nick and decrement the hop-count (discard if it is zero) before forwarding the packet. If the packet was addressed to self and the RBridge is the appointed forwarder of the VLAN ID in the packet then the decapsulated packet is delivered on the local link (where the source address of the packet was learnt). For multiple-destination frames RBridges lookup the distribution tree from the tree root specified in the "egress" nick field of the TRILL header. RBridges verify the packet was received on the path in the DT and also verify the DT was chosen by the "ingress" RBridge (DT roots selection is advertised as part of the link-state advertisement). If the RBridge is the appointed VLAN forwarder of the VLAN ID in the packet then a copy of the decapsulated frame is delivered locally. The hop-count is checked and decremented before forwarding the frame to any next-hop RBridges found from the DT. RBridges check whether the VLAN ID in the Ethernet frame has an appointed VLAN forwarder down a particular path in the DT before forwarding the frame to optimize forwarding and avoid unnecessary traffic (called VLAN pruning). 3. Quagga TRILL IS-IS (trilld) TRILL support has been added to the Quagga protocol suite by modifying the Quagga IS-IS routing protocol (isisd) daemon. isisd has been modified to either run layer-3 link-state routing or TRILL IS-IS routing at layer-2 but not both in the same instance. The reason a single isisd instance cannot participate in both TRILL IS-IS and layer-3 IS-IS as both compute different link-state databases and have the following differences: * TRILL IS-IS uses an all-zero area address and uses a new All IS-IS RBridges multicast address as the destination address for protocol traffic. * TRILL IS-IS utilizes new TLV types for TRILL specific extensions in IS-IS. * TRILL IS-IS output is different from layer-2 IS-IS routing information and interacts with the kernel module using a new AF_TRILL socket interface on OpenSolaris. * There are no separate IS-IS area levels in TRILL IS-IS. * TRILL IS-IS does not use 48-bit IS-IS system IDs and instead uses 16-bit nicknames. TRILL IS-IS extensions cover nickname selection, conflict detection and resolution. * TRILL IS-IS uses SPF to create distribution trees from the layer-2 link-state database. Distribution trees are used in forwarding multi-destination frames (f.e. broadcast and multicast packets). Much of the protocol operation however is similar in both TRILL IS-IS and layer-3 IS-IS. Hello PDUs are used to discover neighbors and LSP/CSNP PDUs are used to exchange link-state information. The following changes were introduced to isisd to add support for TRILL IS-IS: * TRILL is a compile-time configuration option. A new trilld binary is built from the isisd source when TRILL support is configured. * A new IO backend for TRILL and OpenSolaris is introduced. When TRILL is selected at compile time the resulting binary (trilld) uses AF_TRILL sockets for send/receive of TRILL IS-IS packets and also to share the forwarding control information with the kernel using ioctls on an AF_TRILL socket. * Added support for TRILL IS-IS extensions. TRILL IS-IS extensions include new TLVs in IS-IS Hello and LSP PDUs. Extensions cover nickname announcement, nickname priority of use, VLAN forwarder flags, TRILL flags, TRILL protocol versioning etc. 4. TRILL requirements: TRILL has the following requirements from the stack to support layer-2 forwarding: R1: Raw transmit and receipt of TRILL packets. TRILL encapsulates forwarded packets with a TRILL header and requires receipt of TRILL encapsulated traffic from the interfaces running TRILL. In addition TRILL kernel module sends and receives TRILL IS-IS control traffic. R2: Ability to turn on promiscuous mode. RBridges that are appointed forwarders (AF) forward traffic on the local link by listening for all traffic in promiscuous mode. R3: Hook into the transmit path in the stack. RBridges that are appointed forwarders (AF) encapsulate packets on the transmit path of one of the TRILL interfaces to forward traffic across links. R4: Hook into the receive path in the stack. RBridges that are AF decapsulate packets on the receive path if the TRILL packet received is addressed to self or when the packet destination is unknown a de-capsulated copy is delivered locally. If the destination is another RBridge then TRILL does not decapsulate the TRILL header and instead forwards the packet to the destination RBridge. R5: Local MAC address learning. RBridges needs to listen for all local traffic (R2) and learn MAC addresses that appear on the local link. TRILL utilizes this information to determine whether a packet's destination is local or if the packet needs to be forwarded across local link(s). R6: RBridges interact with 802.1D Bridges and MUST listen for BPDUs. RBridges must listen for topology changes and must transmit BPDUs on change in AF status. RBridges never forward or encapsulate BPDUs. Due to the above requirements and the design of bridging support in Solaris [BRIDGE] TRILL has been implemented in the stack on top of the bridging functionality in Solaris. Implementing TRILL over the bridging functionality in Solaris offers the following advantages: * Leverage existing bridging hooks in the MAC layer for transmit and receipt of TRILL traffic. Bridging has implemented low-level hooks in the send and receive paths that can be leveraged by TRILL rather than create additional hooks. [R1, R3, R4] * Bridging turns on promiscuous mode to receive all traffic on the local link. TRILL has a similar requirement. [R2] * Access to bridge forwarding table. Bridging maintains a table of known MAC address entries with each entry including the local interface the MAC address was seen. TRILL extends the table by including RBridge nicknames. By looking up entries in the forwarding table TRILL can determine whether: a) the received packet is for local delivery if the destination address of the packet was found in the table or b) packet should be forwarded to another RBridge (from the nickname in the matched entry) or c) if no entry is found then treat the destination as unknown and forward it to all other RBridges. Bridging updates the forwarding table entries with nicknames when receiving de-capsulated TRILL traffic from another RBridge. [R5] There are some disadvantages with the use of bridging module by TRILL: * TRILL requires a bridging instance to be configured before TRILL can function. The bridging daemon (bridged) needs to run and setup bridging to allow I/O for TRILL over the interfaces used by TRILL even though STP isn't running. * TRILL administration is tied to bridging. TRILL is introduced as an alternative to the default STP protection option when configuring bridge instances. Though they are tied together by introducing TRILL as a protection option the administration is simple and no additional commands/steps are needed for setup when upgrading to TRILL from STP. * RBridges created in this model cannot function as interior RBridge nodes with no ability to encapsulate/decapsulate traffic and only forward TRILL packets. In future an option can be provided to turn off bridge promiscuous mode and limit TRILL to forwarding of TRILL traffic only. The following block diagram describes the various components in the design of the TRILL implementation on Solaris. The architecture of the various RBridges components are also described in [RBA]. _____________ ___________ | trilld | | bridged | |TRILL IS-IS| ----------- .......... |(AF_TRILL) | .. .. . Apps . ------------- || || .......... ^^ ^^ || || ^^ ^^ || || || || || || --------------------------------------------------------------- || || || || || || || || .. .. || || __VV____^^__ _______________________VV___VV__ | | | ________ | | TRILL |<---------->| | | MAC | |__________| | | BRIDGE | <------> layer | | |________| | |______________________________| ^^ ^^ ^^ || || || (promiscuous mode) VV VV VV _____ _____ _____ |NIC| |NIC| |NIC| ----- ----- ----- 5. TRILL 5.1 TRILL IS-IS setup A bridging instance in the stack is created when users configure a bridge via dladm(1M) along with the list of bridged interfaces. A SMF service (svc:/network/bridge:<bridge name>) is created to manage the bridging daemon (bridged). When users choose TRILL protection for the new bridge another SMF service (svc:/network/routing/trill:<bridge name>) is created to manage the TRILL IS-IS daemon (trilld). The TRILL IS-IS client (trilld) sets up registration with the bridge instance to enable I/O for TRILL control traffic and TRILL forwarding in the stack. During the registration with the bridging instance TRILL registers the callback functions to be called for packet transmit and receipt paths. Before TRILL can operate successfully TRILL registration with bridging must succeed. TRILL clients invoke the AF_TRILL socket ioctl TRILL_NEWBRIDGE to perform the registration setup with bridging. 5.2 TRILL data structures The TRILL module supports multiple RBridge instances running on the system. Each RBridge instance runs on a unique set of data links on the system. Like 802.1D Bridges on Solaris, RBridges operate on the same data link types. RBridges run on physical data links, link aggregations and simulated network interfaces (simnet) but not on VNICs nor on VLANs. RBridge instances are tracked in "trill_inst_t". Each "trill_inst_t" must be registered with an existing bridge instance ("bridge_inst_t") on the system. If a corresponding bridge instance (look up by bridge name) isn't found then the TRILL instance isn't created. The "ti_binst" variable in "trill_inst_t" holds a reference to the bridge instance "bridge_inst_t". Each TRILL instance structure includes the following: * "ti_bridgename" holds the name of the bridge instance. It is used for lookup of TRILL instances by bridge name and also to register with the underlying bridge instance. "ti_binst" holds the reference to the bridge instance. * RBridge node database ("ti_nodes") is an array of "trill_node_t" references for all possible RBridge nodes (RBRIDGE_NICKNAME_MAX: 65535). The array is populated with "trill_node_t" structures for each RBridge known in the entire campus and identified by its unique 16-bit integer nick. Each RBridge node "trill_node_t" holds RBridge nickname information in a "trill_nickinfo_t" structure and for adjacent neighboring RBridges the socket interface ("trill_sock_t") to reach the node. One of the RBridge nodes is for the running RBridge itself and the nickname information structure ("trill_nickinfo_t") holds the forwarding information with the running RBridge as the root of a distribution tree (DT). * RBridge nickname information ("trill_nickinfo_t") is used to hold all the forwarding information for a particular RBridge node. The forwarding information describes a distribution tree (DT) with the RBridge node as the root of the tree. It holds a variable size list of the running RBridge's adjacent RBridge nicks (next-hop information) present on the DT, a variable size list of distribution tree roots chosen by the particular RBridge and fixed size VLAN filter lists (for filtering forwarded packets by VLAN ID). * RBridge nickname and the distribution tree root. The distribution tree nickname identifies the distribution tree to use for forwarding multi-destination frames. * The list of AF_TRILL sockets ("ti_socklist") bound to the RBridge instance. We accept TRILL control packets and many ioctls modifying the TRILL IS-IS link-state only from the list of bound AF_TRILL sockets bound to the RBridge instance. * "ti_refs" and "ti_rwlock" control lifetime and protect concurrent access to the instance structure respectively. Each AF_TRILL socket takes a reference on the TRILL instance structure. The last reference release unregisters the TRILL instance from the bridge instance and de-allocates the TRILL instance. The "ti_rwlock" protects concurrent access to the instance structure by the AF_TRILL socket threads. * "ti_instnode" is the list node member for the static "trill_inst_list" global in the TRILL module. "trill_inst_list" holds all the TRILL instances and "trill_inst_rwlock" protects concurrent access to the list. Each AF_TRILL socket is tracked in a "trill_sock_t" structure. The socket holds the socket state, socket address information (of type sockaddr_dl), a reference to the underlying bridged interface "bridge_link_t", a reference to the bounded TRILL instance ("ts_tip"), Volo structures, statistics and flags. A refcount ("ts_refs") is used to track references to the socket structure from other data structures (RBridge nick nodes). A list node ("ts_socklistnode") for the socket list per instance ("ti_socklist") noted above. 5.3 AF_TRILL sockets AF_TRILL sockets are implemented using a new Volo socket module. AF_TRILL socket family only supports datagram type sockets and the supported protocol value is zero. Prior to running the TRILL protocol on the socket or controlling the TRILL forwarding state callers must issue the TRILL_NEWBRIDGE ioctl to associate the socket with a TRILL instance. During the TRILL_NEWBRIDGE ioctl call the TRILL kernel module sets up the required TRILL instance structures and also registers the TRILL instance with the underlying bridge instance. If the TRILL_NEWBRIDGE ioctl doesn't succeed then the caller cannot proceed to do a bind() or issue many of the ioctls on the socket. Callers must do a bind() on the AF_TRILL socket to associate the socket with an underlying interface that was configured to be a part of the bridge instance. Callers must pass the datalink ID (datalink_id_t) of the interface as the bind() parameter inside a "sockaddr_dl" address structure. Only a single AF_TRILL socket can bind to a bridged interface. In other words only a single AF_TRILL client can send TRILL IS-IS control traffic on a interface. This does not preclude a privileged user-space application from doing a raw DLPI send/receive of TRILL IS-IS traffic on the interface (however such actions are not supported). The list of ioctls available on the AF_TRILL socket interface for TRILL IS-IS clients are noted below. Callers must have the PRIV_SYS_NET_CONFIG privilege for any of the ioctls below to succeed. Constants and definitions required for TRILL clients are introduced in a new header file: <net/trill.h>. TRILL_SETNICK Sets the nickname of the running RBridge instance (arg:trill_node_t) TRILL_GETNICK Returns the nickname of the running RBridge instance (return arg: uint16_t) TRILL_ADDNICK Add a new RBridge node (arg:trill_node_t) TRILL_DELNICK Delete a RBridge node (arg:uint16_t) TRILL_DELALL Delete all RBridge nodes TRILL_HWADDR Retrieve the MAC address of the interface bound to the socket (return arg: ETHERADDRL bytes) TRILL_TREEROOT Nickname of the RBridge tree root (arg:uint16_t) TRILL_NEWBRIDGE Create/lookup TRILL instance for the socket (arg: char[MAXLINKNAMELEN]) TRILL_VLANFWDER Set VLAN forwarder information (arg: uint8_t[TRILL_VLANS_ARRSIZE]) TRILL_DESIGVLAN Set the designated VLAN for the interface bound to the socket (arg: uint16_t) TRILL_LISTNICK Retrieve RBridge nicknames (return arg:trill_listnick_t) TRILL_GETBRIDGE Get a reference to the passed bridge instance (return arg: char[MAXLINKNAMELEN]) TRILL_PORTFLUSH Discard bridge forwarding entries with the passed VLAN (arg:uint16_t) TRILL_NICKFLUSH Discard TRILL forwarding entries with the passed VLAN (arg:uint16_t) TRILL_GETMTU Retrieve the MTU of the interface bound to the socket (return arg:uint_t). Transmit and receipt of IS-IS TRILL traffic is via send() and receive() system calls. Clients can invoke recvfrom() on the AF_TRILL socket to receive sender MAC address and the VLAN TCI of the received packet in a sockaddr_dl structure. TRILL IS-IS daemon (trilld) utilizes the AF_TRILL socket interface to run the TRILL IS-IS protocol over the list of bridged interfaces. Periodically the daemon updates RBridge(s) node information and forwarding information with the TRILL kernel module from the computed layer-2 link-state database. 5.4 TRILL kernel module In this section we describe the data and control paths in the TRILL kernel module. The control path describes the flow of TRILL IS-IS packets. TRILL packets received off the wire are received by the bridging module and passed to TRILL via the "trill_recv_pkt_cb" entry point. The bridging module passes the "trill_sock_t" that is bound to the interface the packet was received on as well. "trill_recv_pkt_cb" checks the ethertype and destination address fields in the Ethernet header to determine if it is a TRILL data packet or a TRILL IS-IS control packet. TRILL IS-IS packets are passed to "trill_ctrl_input" which in turn pushes the packet upstream to the AF_TRILL socket. TRILL data packets are received in the TRILL kernel module via two entry points. The "trill_recv_pkt_cb" called by bridging for TRILL packets received off the wire and "trill_encap_pkt_cb" called by bridging for forwarding Ethernet packets using TRILL. TRILL data packets received off the wire are handled by "trill_recv". "trill_recv" checks for a valid TRILL header and determines the forwarding action for the packet. If the received packet is a multi-destination frame then forwarding checks (valid adjacency check and the reverse path forwarding check) are performed before accepting the frame. The accepted multi-destination frame is de-capsulated and delivered locally before forwarding the frame to the next-hop RBridge. The next-hop RBridge is determined by looking up the distribution tree with the egress RBridge in the packet header as the root. Before forwarding to the next-hop the hop count in the packet header is decremented and the packet is discarded if the hop count reaches zero. If the received packet is a known-destination frame then the RBridge checks the egress nickname specified in the TRILL header of the packet. If the egress nick is self then the packet is delivered locally. Otherwise the egress nick is looked up in the RBridge nodes table and the destination interface to forward the packet to reach the next-hop RBridge is determined. The hop count in the header is updated like with multi-destination frames and the packet is forwarded. Local delivery of de-capsulated TRILL packets is handled by "trill_recv_local". "trill_recv_local" passes the packet to bridging via the "bridge_trill_decaps" function. "bridge_trill_decaps" performs MAC address learning: updates forwarding entries with the source MAC address and the ingress nickname and pushes the de-capsulated frame to the upper MAC layer for any local system receive of the packet. 6. libdladm configuration TRILL IS-IS daemon (trilld) uses libdladm to access bridge instance configuration. trilld determines the data links that are part of the RBridge instance from libdladm and also retrieves link properties such as the default VLAN tag of the link using libdladm. In addition trilld stores the nickname (for re-use) using new libdladm methods dladm_bridge_{get,set}_nick. The nick is stored in SMF as part of the SMF service configuration for the calling TRILL IS-IS service. 7. trilld debugging support trilld (unlike isisd) does not use a static configuration file and instead relies on libdladm. However trilld does accept a static configuration file allowing users to override and configure settings that aid in debugging. Some of the command-line arguments for trilld are: * -A, --vty_addr and -P, --vty_port: VTY address and port numbers for the VTY interface (CLI) to the TRILL daemon (trilld). Unless the port number is specified trilld does not provide this CLI interface. In addition a password must be specified in a configuration file (via the --config_file option noted below). We describe some of the commands available for users to run via the VTY control interface below. * -f, --config_file: pass a configuration file to trilld. Options allowed in the configuration file are described below. * -i, --pid_file: file name to store the process identifier. * Bridge instance name: the last argument specifies the bridge instance. The bridge instance name specifies the underlying bridge instance on the system used by TRILL. 7.1 trilld config file options Users can specify the following options in the configuration file for trilld: * hostname <hostname> : Specifies the hostname for the RBridge instance. Used in VTY command output to refer to the system running the RBridge instance. * password <password> : authentication password for the VTY interface. * log file <filename> : file name to log trilld messages. * debug isis <event-name> : turns on debugging output for IS-IS protocol events in trilld. Events include adj-packets, checksum-errors, local-updates, spf-events, events etc. * debug trill events : turns on debugging output for TRILL IS-IS protocol extension events in trilld. 7.2 trilld VTY interface commands Users can use the VTY interface to check the running state of trilld, can turn on debugging and write the modified configuration to file. Some of the available commands in the VTY interface are: * show isis database {detail} : shows the IS-IS link-state database including LSP IDs, LSP sequence number, checksum etc. * show isis neighbors {detail} : shows IS-IS neighbor information including the destination interface to reach the neighbor, system ID, DIS or appointed forwarder (AF) status etc. * show isis hostname : shows the system ID and the associated host name of all the known RBridges. * show isis topology : shows the distribution tree paths with all other RBridge nodes as root. * show trill forwarding : shows the distribution tree paths with the running RBridge node as root. * show trill adjacencies : shows the adjacencies of the running RBridge on all other RBridge distribution trees. * show trill circuits : shows the interfaces configured for the running RBridge instance along with interface information such as the designated VLAN, PVID, VLAN forwarder IDs and enabled VLANs. * show trill nickname database : shows all known RBridge nicknames along with the associated hostname, priority of use and VLAN forwarder flag information. References: [BRIDGE] Solaris Bridging design document: http://hg.opensolaris.org/sc/src/rbridges/rbridges-doc/bridging-design.pdf [RBA] RBridges architecture documents: PSARC/2007/596 RBridges: Routing Bridges PSARC/2008/055 Solaris Bridging PSARC/2009/344 Bridging Updates RBridges architecture image at: http://hg.opensolaris.org/sc/src/rbridges/rbridges-doc/rbridges-arch.png [TRILL] IETF TRILL documents: http://www.ietf.org/rfc/rfc5556.txt http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-protocol-12.txt http://tools.ietf.org/id/draft-eastlake-trill-rbridge-isis-02.txt _______________________________________________ networking-discuss mailing list [email protected]
