sun.com | docs.sun.com |  | How To Buy | My Sun | Worldwide Sites |

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Maintenance Commands | cgtp(7D)

- NAME
- SYNOPSIS
- DESCRIPTION
- INTERFACE LEVEL
- FILES
- ATTRIBUTES
- SEE ALSO

## NAME

> cgtp - CGTP virtual device driver

## SYNOPSIS

> `/dev/cgtp`

## DESCRIPTION

> The Carrier Grade Transport Protocol (CGTP) driver is a multi-threaded, loadable, clonable, STREAMS virtual device driver, compatible with the connectionless Data Link Provider Interface, `dlpi`(7p). CGTP is not related to any particular hardware and is purely virtual. Delivered with the Foundation Services, CGTP provides a single point of convergence for redundant incoming data flows. CGTP IP addresses are defined on each cluster node.

> The CGTP does not send and receive data, but is instead normally used to indirectly accumulate incoming CGTP traffic from underlying redundant interfaces through internal IP routing. It supports most of the normal functions of a `DLPI` Ethernet device, the major exception being data transfer. All data packets (`DL_UNITDATA_REQ`) are rejected with an error of `network down`.

## INTERFACE LEVEL

> The cloning character-special device `/dev/cgtp` is used to register the Foundation Services cluster node's CGTP IP addresses.

> The `cgtp` driver is a "style 2" Data Link Service provider. All messages of the `M_PROTO` and `M_PCPROTO` types are interpreted as `DLPI` primitives. Valid `DLPI` primitives are defined in the `sys/dlpi.h` file. For more information, see the `dlpi`(7p) man page. Send an explicit `DL_ATTACH_REQ` message to associate the opened stream with a particular device (`ppa`). As CGTP is purely a virtual driver, parameter configuration using `DL_INFO_REQ` is unnecessary.

> The `ppa` ID is interpreted as an unsigned long data type and indicates the corresponding device instance (unit) number. An error (`DL_ERROR_ACK`) is returned by the driver if the `ppa` field value does not correspond to a valid device instance number for this system. The device is initialized on first attach and deinitialized (stopped) at last detach.

> The values returned by the driver in the `DL_INFO_ACK` primitive in response to the `DL_INFO_REQ` from the user are as follows:

> - The maximum service data unit (SDU) is 1500 (`ETHERMTU` - defined in `sys/ethernet.h` ).

> - The minimum SDU is 0.

> - The `dlsap` address length is 8.

> - The MAC type is `DL_ETHER`. MAC address is fixed to `0:0:0:0:0:0`.

> - The `sap` length value is -2, meaning that the physical address component is followed immediately by a 2-byte `sap` component within the `DLSAP` address.

> - No optional quality of service (`QOS`) support is included at present, so the `QOS` fields are 0.

> - The provider style is `DL_STYLE`.

> - The version is `DL_VERSION_2`.

> - The broadcast address value is the Ethernet or IEEE broadcast address (`0xFFFFFF`).

> Once in the ``DL_ATTACHED`` state, the user must send a `DL_BIND_REQ` to associate a particular `SAP` (Service Access Pointer) with the stream. The `cgtp` driver interprets the `sap` field within the `DL_BIND_REQ` as an Ethernet "type". Therefore, valid values for the `sap` field are in the [0-0xFFFF] range. Only one Ethernet type can be bound to the stream at any time.

> The `cgtp` driver `DLSAP` address format consists of the 6-byte physical (Ethernet) address component followed immediately by the 2-byte `sap` (type) component producing an 8-byte `DLSAP` address. Applications must not hardcode to this particular implementation-specific `DLSAP` address format, but instead use information returned in the `DL_INFO_ACK` primitive to compose and decompose `DLSAP` addresses. The `sap` length, full `DLSAP` length, and `sap` or physical ordering are included within `DL_INFO_ACK`. The physical address length can be computed by subtracting the `sap` length from the full `DLSAP` address length or by issuing the `DL_PHYS_ADDR_REQ` to obtain the current physical address associated with the stream.

> The `DL_ENABMULTI_REQ` and `DL_DISABMULTI_REQ` primitives enable or disable reception of individual multicast group addresses. A set of multicast addresses can be iteratively created and modified on a per-stream basis using these primitives. These primitives are accepted by the driver in any state following `DL_ATTACHED`.

> The `DL_PHYS_ADDR_REQ` primitive returns the 6-octet Ethernet address currently associated (attached) to the stream in the `DL_PHYS_ADDR_ACK` primitive. This primitive is valid only in states following a successful `DL_ATTACH_REQ`.

> The `DL_SET_PHYS_ADDR_REQ` primitive does not change the 6-octet Ethernet address currently associated (attached) to this stream.

> After the `cgtp` virtual driver is installed, the administrator must configure the IP address with the address mask.

> For example:

> >     example% ifconfig cgtp0 plumb
> >     example% ifconfig cgtp0 10.128.3.4/24 broadcast 10.128.3.255 up
> >     example% ifconfig cgtp0
> >     cgtp0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu \
> >     1500 index 2
> >     inet 10.128.3.4 netmask ffffff00 broadcast 10.128.3.255
> >     ether 0:0:0:0:0:0

> Aliasing is permitted on the `cgtp` driver. Configuring the `cgtp` virtual driver is not sufficient to access full CGTP functionalities. CGTP configuration must be done at the same time as CGTP routes configuration using the `route` command. In particular, there is a need to configure specific routes for broadcasts and multicasts by using the `route` command.

> For instructions on how to manually install and configure CGTP on cluster nodes, see the Netra High Availability Suite Foundation Services 2.1 6/03 Custom Installation Guide. For instructions on how to manually install and configure CGTP on a standalone nodes, see the Netra High Availability Suite Foundation Services 2.1 6/03 Standalone CGTP Guide.

> CGTP never actually sends or receives data. Instead, the CGTP configuration must be done at the same time as configuration of no more than two physical interfaces of any type that are responsible for redundancy.

> When the `cgtp0` virtual physical interface and the two physical interfaces are properly configured, and all the necessary routes are correctly configured on the cluster, data will be sent and received through the redundant interfaces. At the emitter, `cgtp` is used (if specified by `route` command) to specify the source address of the CGTP IP packets. Packets are then transmitted on the physical interfaces. At the receiver, incoming CGTP packets are received by redundant interfaces, the duplicates are filtered out at the IP level, and the remaining packets converge in the `cgtp` stream to be presented to upper applications (after an optional reassembly).

> Note – The use of IPv6 is not supported for use with CGTP.

> ### Manually Configuring CGTP using Logical Interfaces

> > Logical interfaces can be configured only after the creation and configuration of physical interfaces. Two logical interfaces are configured on each node.

> > Additional logical interfaces can be created on a specified CGTP interface, provided the CGTP interface and the logical interfaces share the same subnet address. This means the primary CGTP address and the logical (or aliased) addresses must only differ by their host ID. Routes to the aliased interfaces can accordingly be set up on the other cluster nodes.

## FILES

> `/dev/cgtp` cgtp special character device.

## ATTRIBUTES

> See `attributes`(5) for descriptions of the following attributes:

> ATTRIBUTE TYPE | ATTRIBUTE VALUE
> --- | ---
> Architecture | SPARC
> Availability | SUNWnhtp8, SUNWnhtu8 for Solaris 8 2/02
> | SUNWnhtp9, SUNWnhtu9 for Solaris 9
> Interface Stability | Evolving

## SEE ALSO

> `dlpi`(7p)

Netra HAS FS 2.1 | Go To Top | Last Changed September 2004

Company Info | Contact | Copyright 2004 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.