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.
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.