The configuration file for end systems is simple, usually containing only two configuration statements.

1. The following sample configuration file emulates routed, runs RIP, and only sends updates if there is more than one interface up and IP forwarding is enabled in the kernel:

   # rip yes ; #

   
   Note that RIP will not run if UDP checksums are disabled in the kernel.

2. The following sample runs RIP in quiet mode; it only listens to packets, no matter how many interfaces are configured:

   # rip yes ; { nobroadcast ; } ; #

3. The following sample is suitable for any system that runs RIP and has only one network interface:

   # # do not time-out the network interface # interface 136.66.12.2 passive ; # # enable rip # rip yes ; #

   
   The passive keyword prevents GATED from changing the preference of the route to this interface if it is believed to be down due to lack of received routing information. The interface passive statement identifies a router with a guest host on an Ethernet.
   In the previous example, the route is through the directly attached network interface. Normally when GATED thinks an interface is down, it removes it from the routing database to prevent a gateway from announcing that it can route data through a nonoperational interface.
   If the host has only one interface, it should not be removed from the routing database even if the interface is down (the interface 136.66.12.2 passive statement in the sample). RIP is enabled with the rip yes statement. This statement is not required as it is the default, but the explicit statement in the GATED.CONF file serves to document the configuration to prevent future confusion.

The following sample enables both an interior (RIP) and an exterior (EGP) protocol and sets certain protocol-specific parameters:

# generate a default route if an EGP neighbor is acquired # options gendefault ; # # define the autonomous system number for EGP # autonomoussystem 303 ; # # enable RIP # rip yes ; # # enable EGP with hello interval 1 1/2 minute, poll # interval 10 minutes, neighbors 26.6.0.103 and 26.20.0.72 # egp yes { packetsize 24488 ; group minhello 1:30 minpoll 10:00 { neighbor 26.6.0.103 ; neighbor 26.20.0.72 ; } ; } ; # # announce 136.66 to AS 183 # export proto egp as 183 { proto direct { 136.66 metric 0 ; } ; } ; # # announce default through RIP with a metric of 3 # export proto rip interface 136.66.12.1 { proto default { announce 0.0.0.0 metric 3 ; } ; } ;

The AS number 303 is defined early because it is a definition statement and must occur before the first protocol statement. EGP is enabled by the yes keyword in the EGP statement. This statement also defines the following EGP parameters:

• Packetsize parameter, which defines the initial size of update packets accepted.
• Group clause, which sets parameters for all of the EGP neighbors in the group.
• Minhello and minpoll, which set the protocol timers.

The first export statement directs GATED to use EGP to advertise the network (136.66.0.0) to the Internet. This is the address of the network, not of a gateway. The second export statement is used to announce the default route to subnet 136.66.12.0 with a metric of 3.

B.18.2 Sample BGP and OSPF Configuration

The following sample implements the transformation of distance metrics between the internal (OSPF) and external (BGP) protocols. Autonomous system 1019, of which GATED is a member, contains network 19.0.0.0. The GATED machine has several interfaces into this autonomous system. The GATED daemon is using BGP to peer with AS 2021, neighbor 21.5.1.21.

# # # # # # # # # # # # # # # # # # # interfaces {options all passive; }; autonomoussystem 1019; routerid 19.1.1.18; rip no; hello no; egp no; bgp yes { preference 50 ; group type External peeras 2021 { peer 21.5.1.21 ; } ; group type IGP peeras 1019 { peer 19.1.1.19 ; } ; } ; ospf yes { area 0.0.0.2 { authtype none; networks { 119.0.0.0 mask 255.0.0.0 ; } ; interface 119.2.128.18 cost 1 { retransmitinterval 5; transitdelay 1; priority 1; hello interval 10; routerdeadinterval 40; } ; interface 119.4.128.18 cost 1 { retransmitinterval 5; transitdelay 1; priority 1; hellointerval 60; routerdeadinterval 180; } ; } ; backbone { authype none; interface 19.1.1.19 cost 1 { retransmitinterval 5; transitdelay 1; priority 1; hellointerval 60; routerdeadinterval 180; } ; } ; } ; export proto ospfase type 1 { proto bgp as 2021 { ALL metric 1; }; proto direct { ALL metric 1; }; } ; export proto bgp as 2021 { proto direct { ALL metric 1; } ; proto ospfase { ALL metric 1; } ; } ;

In this example, two autonomous systems (one internal, one external) are directly connected through a router that is attached to a backbone speaking OSPF. The AS number 1019 is defined early as it is a definition statement that occurs again in the first protocol statement, which enables BGP. The first export statement directs GATED to advertise routes from the internal group AS 1019. The group AS 1019 is running OSPF as its interior gateway protocol and is running BGP as its exterior routing protocol to route information to the external group AS 2021.

Routes to two local Ethernets in AS 1019, identified as 119.2.128.18 and 119.4.128.18 (119.0.0.0 mask 255.0.0.0), are advertised along with the OSPF backbone (19.1.1.19). The parameters for AS path, path origin, and transitive optional attributes, including transmission intervals, are defined. The second export statement announces the default route to AS 2021 with a metric of 1.

B.19 Sample Interior Gateway Configurations

Gateway configurations are more complicated than a simple host configuration as gateways have multiple interfaces and may run multiple protocols. This section contains sample files for the following gateway configurations:

• RIP only (subnet to backbone). Section B.19.1
• RIP with default announcement. Section B.19.2
• RIP and OSPF. Section B.19.3

The following sample connects two networks within an autonomous system. You can use this configuration file for any gateway that uses only RIP and that connects a single subnet to a larger network.

# # enable rip # rip yes ; # # using rip, announce subnet 3 through interface 136.66.1.2 # export proto rip interface 136.66.1.2 { proto direct { announce 136.66.3.0 metric 0 ; } ; } ; # # using rip, announce all routes learned from interface 136.66.1.2 # export proto rip interface 136.66.3.1 { proto rip interface 136.66.1.2 { announce all ; } ; } ;

In this sample, the first export statement tells GATED to announce, through the RIP protocol and interface 136.66.1.2, a direct route to subnet 136.66.3.0. The second export statement announces to subnet 3 all routes learned from the interface 136.66.1.2, including subnet routes and any routes to the rest of the world, as well as default routes.

The first export statement is not required because by default GATED announces every network that is directly connected to the gateway. The export statement was explicitly entered for two reasons: to document the intended structure and to avoid relying on defaults that might be changed in future releases.

In any export statement, the main proto clause and the main interface clause may define the protocol and interface through which the routes are advertised. Subsidiary proto and interface clauses define the protocols and the interfaces from which the routes must be learned.

B.19.2 Sample RIP with Default Announcement

In the following sample, the gateway announces a default route to the backbone and announces all of the individual subnet routes to the outside world:

# # enable rip # rip yes ; # # using rip, announce all local subnets through 136.66.12.3 # export proto rip interface 136.66.12.3 metric 3 { proto rip interface 136.66.1.5 { announce all ; } ; }; # # using rip, announce default to the local backbone through 136.66.1.5 # export proto rip interface 136.66.3.1 { proto rip interface 136.66.12.3 { announce 0.0.0.0 ; } ; } ;

The first export statement explicitly directs GATED to announce all of the routes it learns from interface 136.66.1.5 out through interface 136.66.12.3. The explicit announce all is not required. The metric value is specified in the main statement and applies to every route announced through this protocol and interface. When the metric is specified in the export clause, it only applies to the routes specified in that clause. In the previous sample, metric 3 applies to every route announced over interface 136.66.12.3 through RIP.

B.19.3 Sample RIP and OSPF Configuration

The following sample enables both RIP and OSPF protocols and can be used for testing RIP and OSPF:

#options noinstall ; interfaces { interface le0 passive ; } ; autonomoussystem 283 ; snmp yes ; rip yes { broadcast ; defaultmetric 5 ; interface le version 2 multicast ; } ; ospf yes { traceoptions 1sabuild protocol ; monauthkey "ZZZZZZZZ" ; backbone { authtype simple ; interface all { priority 2 ; } ; interface le { authkey "YYYYYYYY" ; } ; } ; } ; static { default gateway 132.236.200.200 preference 140 retain ; }

In the RIP case, version 2 multicast packets are generated on all Ethernet interfaces (for example, le0, le1, and so on). This is a safe way to test RIP, because the production gateways on this network do not support RIP version 2. In the OSPF case, all interfaces are configured to be Priority 2, so the Proteon routers (Priority 0) become designated routers. A simple password is specified "YYYYYYYY" for authentication of all Ethernet interfaces. (The only kind of interfaces in this configuration.)

B.20 For More Information

For more information about GATED, see the following UNIX manual reference pages: gated(8), gated.control(4), gated.proto(4), and gated_intro(7).

The TCP/IP Services TELNET implementation supports IBM 3270 terminal emulation. The default translation tables for DIGITAL/IBM-terminal compatibility satisfy most users' needs.

To modify the translation tables, use the file TCPIP$EXAMPLES:TN3270DEF.MAR.

C.1 Macros for Modifying the Translation Tables

If the standard translation table does not suit your needs, you can modify it by specifying macros in the file TN3270DEF.MAR. You should copy TN3270DEF.MAR from TCPIP$EXAMPLES into your current default directory and edit it with any editor supported by your system.

Use the macros described to make any changes you need in the translation tables. You can specify three macros. The arguments for all three macros are:

eb	The EBCDIC code for the character you want to translate.
as	The DMCS code for the character you are translating to. (You can specify the actual DMCS display character instead of the code, if you want to. To do this, enter a single quotation mark before you type the character, for example, '!, 'A, 'g, and so on.)

The macros are:

1. EB2AS eb, as
   The EB2AS macro lets you change an entry in the EBCDIC-to-DMCS table without affecting the DMCS-to-EBCDIC table. For example:
   EB2AS 5A, '!
   In this example, the EBCDIC hexadecimal code 5A is translated to the DMCS exclamation point (hexadecimal code 21). The macro does not affect the translation of a DMCS exclamation point to its EBCDIC equivalent.
2. AS2EB as, eb
   The AS2EB macro lets you change an entry in the DMCS-to-EBCDIC table without affecting the EBCDIC-DMCS table.
   For example:
   AS2EB '[, 5F
   In this example, the DMCS open bracket character (hexadecimal code 5B) is translated to the EBCDIC hexadecimal code 5F. The macro does not affect the translation of the EBCDIC code 5F to DMCS.
3. REVTRA eb, as
   The REVTRA macro combines the functions of the EB2AS and AS2EB macros, enabling you to change the same translation in both the DMCS-to-EBCDIC and EBCDIC-to-DMCS tables.
   For example:
   REVTRA 4A, A2
   In this example, the macro changes the EBCDIC-to-DMCS translation table so that the EBCDIC character represented by the hexadecimal code 4A translates to a DMCS cent sign (hexadecimal code A2.) The DMCS-to-EBCDIC translation table is also changed so that a DMCS cent sign translates to the EBCDIC character represented by the hexadecimal code 4A.

   NOTE If you use the REVTRA macro, you must give new translations to the codes used as arguments to the macro. You can do this with the EB2AS and AS2EB macros.

Before you edit the file TCPIP$EXAMPLES:TN3270DEF.MAR, save the original by copying it from TCPIP$EXAMPLES to your current default directory.

Edit the file using any editor your system supports. When you have changed the file to your satisfaction, perform the following steps:

1. Assemble the file you just edited:

   $ MACRO/OBJECT TN3270DEF

   
   When you assemble the template file, you create an object file containing two 256-byte translation tables labeled $AS2EB:: and $EB2AS::. This object file can be linked to a user application program.

2. Link the template file to create the translation table, enter:

   $ LINK/SYSTEM/HEADER TN3270DEF

3. Copy the resulting image to an accessible area, enter:

   $ COPY TN3270DEF.EXE SYS$LIBRARY:TN3270DEF.TBL

   Note The .EXE file is renamed to .TBL in this final step.

This section gives two examples of modifying translation tables. Example 1 shows how to translate the ASCII left bracket to the EBCDIC cent sign. Example 2 shows how to modify the standard translation tables to the translation tables used by the TN3270 Terminal Emulator.

Example 1

The following code segment translates the ASCII left bracket, hexadecimal code 5B, to the EBCDIC cent sign, hexadecimal code 4A. The change causes the EBCDIC cent sign to be translated into the ASCII cent sign, hex A2. When the REVTRA macro is used, it leaves the ASCII left bracket unmapped, and a second macro, AS2EB, is used to map the ASCII left bracket to the EBCDIC SUB character, hex code 3F.

DMFILL = 26. ; This argument causes all the EBCDIC ; characters that normally map to an ASCII ; backslash in the standard table to map ; to an ASCII SUB character, code 26 ; decimal, 1A hexadecimal. REVTRA 4A,A2 ; Map the EBCDIC cent character (4A) ; to/from the ASCII cent character (A2). AS2EB 5B,3F ; Map the ASCII "[" (5B) to the EBCDIC ; SUB character (3F). ; ; The preceding macro could also be written in the following way: ; AS2EB '[,3F

Example 2

This example shows the macros used to modify the standard translation tables to the translation tables used by IBM 3270TE. Table C-1 describes the required changes.

DMFILL = 26. REVTRA 4A,A2 ; Map the EBCDIC cent character (4A) ; to/from the ASCII cent character (A2). ; Because this macro leaves ASCII "[" (5B) ; still mapped to the EBCDIC cent character ; (4A) , it must be remapped. REVTRA 4F,7C ; Map the EBCDIC "|" (4F) to/from ; the ASCII "|" (7C). REVTRA 6A,A1 ; Map EBCDIC "dashed vbar" (6A) to/from ASCII ; inverted ! (A1). REVTRA 5A,'! ; Map EBCDIC "!" (5A) to/from ASCII "!" (21). AS2EB '],3F ; Map ASCII "]" (5D) to the EBCDIC SUB ; character (3F). AS2EB 5B,3F ; Map the ASCII "[" (5B) to the EBCDIC ; SUB character (3F).

The changes that are described modify a version of the ANSI standard X3.26 1970 EBCDIC-to-ASCII translation table. Table C-1 shows these modifications:

Table C-1 Modifications to Translation Tables

DMCS Character	Hexadecimal Code	EBCDIC Character	Hexadecimal Code
¢	A2	¢	4A
|	7C	|	4F
!	21	!	5A
¡ 1	A1	dashed vbar	6A
[	5B	2
]	5D	2