Website hosting mac, affordable, php5, plesk - linux experts blog

larger the priority number, the less likely the router will be elected the designated router. Give your most powerful router the lowest priority number. A designated router is used to reduce the size of the link-state database and thus the complexity of calculating the Dijkstra graph of the area. The designated router treats all other routers in the area as neighbors, but all other routers treat only the designated router as a neighbor. To understand how this reduces the size of the link-state database, think of a network of five routers. Without a designated router, all five routers advertise four neighbors, for a total of 20 neighbors in the database. With a designated router, only that router advertises four neighbors. The other four routers advertise one neighbor for a total of eight neighbors in the database. The larger the network, the more important it is to use a designated router. The router ospf statement enables the OSPF protocol. In Listing 7.13, the router ospf statement contains two clauses. The ospf router-id clause defines the router identifier used for OSPF advertisements. Normally, this is set to the primary address of one of the interfaces used for OSPF. On this sample router, only one network interface is being used for OSPF, so the address of that interface is used as the router identifier. The network clause identifies the network over which OSPF routes will be exchanged. In the ospfd.conf file, the network on the network clause is always defined by an IP-address/network-mask pair. The network clause also identifies the area of which the network is part. Remember that OSPF divides the autonomous system into areas, and every OSPF router must connect to some area. As mentioned earlier, the area that interconnects all other areas within the routing domain is called the backbone area. The number assigned to the backbone area is 0. Therefore, the network clause in Listing 7.13 specifies that this router is connected to the backbone area. A simple OSPF configuration, such as the one shown in Listing 7.13, should be adequate for any Linux system that needs to run OSPF. Much of the configuration information will come from the network designer who defines your routing hierarchy. The area you connect to, the type of authentication used, the authentication password, and the priority number of your system are all design decisions that will be made before your network even begins to run OSPF. As a final example of configuring the Zebra suite, we configure the router that attaches the OSPF network to the outside world via BGP. Running bgpd The zebra.conf file and the ospfd.conf file used on the BGP router are almost identical to the files shown in Listings 7.11 and 7.13, as the following cat commands show: [root]# cat /etc/zebra/zebra.conf hostname externalgw password BILL&ted enable password 4138doc log file /var/log/zebra.log ! interface eth0 ip address 172.16.1.5/24 multicast ! interface eth1 ip address 26.10.105.4/8 ! 216
Note: If you are looking for cheap and reliable provider to host and run your servlet application check Vision servlet hosting services

In addition to the ripd.conf file shown in Listing 7.9, the host needs a zebra.conf file. The zebra.conf file we created for our sample host is shown in Listing 7.10. Listing 7.10: A zebra.conf File for a Linux Host hostname grebe password lOOK!c? log file /var/log/zebra.log ! interface eth0 ip address 172.16.60.2/24 multicast ! This file is simpler than the zebra.conf file shown in Listing 7.5. It defines the hostname used by this host and the path to the log file, but it defines only one vtysh password. This password allows interactive queries of the routing configuration, but it does not allow the configuration to be changed. The interface command in Listing 7.10 defines the interface over which this host listens to RIPv2 updates. The RIPv2 updates that this host uses to build its routing configuration come from the routers on the subnet. In the next section, we look at the sample configuration of such a router. Running ospfd In this section, a router is configured to send RIPv2 packets on one subnet the one that it shares with the sample host configured in Listing 7.9 and OSPF link-state advertisements on another subnet that it shares with other routers. For this configuration, we create a zebra.conf file to configure the routing manager, a ripd.conf file to configure the RIPv2 protocol daemon, and an ospfd.conf file to configure the OSPF protocol daemon. The zebra.conf file is almost identical to the one shown in Listing 7.5. Listing 7.11: A zebra.conf File for a RIP/OSPF Router hostname subnet60gw password Wats?Watt? enable password CHLLlns log file /var/log/zebra.log ! interface eth0 ip address 172.16.60.1/24 multicast ! interface eth1 ip address 172.16.1.9/24 ! The zebra.conf file in Listing 7.11 contains everything that was found in Listing 7.5, except for the static route. All of this was explained earlier, so there is no need to explain it again here. The ripd.conf file used for this configuration is shown in Listing 7.12. Listing 7.12: A ripd.conf File for a RIP/OSPF Router 214
Note: If you are looking for cheap and reliable provider to host and run your servlet application check Vision servlet hosting services

with the name zebra.conf.sav. The vtysh interface is a tool intended to simplify a complex configuration problem. In general, however, Linux routers do not have highly complex configurations; and the configurations, once set, do not change frequently. Additionally, a small configuration file must be created before vtysh can be used, and the final configuration files are often not much larger than the minimal ones that must be created by hand. For these reasons, you may find vtysh more useful as a tool for examining the router configuration than as a tool for modifying the configuration. Personally, I like vtysh; but if you prefer, you can build Zebra configuration files with your favorite text editor. It’s up to you. The following sections show a few reasonable Linux Zebra configurations. We configure a host to run RIPv2, an interior router to run RIPv2 and OSPF, and an exterior router to run OSPF and BGP. Running ripd Routing protocols are not limited to routers. It is possible to need a routing protocol on a Linux host. Suppose that you have a host on a network in which routing updates are distributed via RIPv2. This system is not a router, but because it is on a network segment with more than one router, you decide to configure it to listen to the RIPv2 updates that the routers are broadcasting. Listing 7.9 shows a possible ripd.conf file for this host. Listing 7.9: A Sample ripd.conf File ! Enable RIPV2, but don’t send updates ! Check that packets are authentic interface eth0 ip rip authentication string EZdozIt ! router rip passive-interface eth0 ! The RIPv2 configuration is very simple. The command router rip enables RIP. By default, Zebra uses RIPv2, which is capable of handling address masks and is compatible with RIP version 1. To force Zebra to use RIP version 1, a version 1 clause could be used with the router rip command, but using RIP version 1 is generally ill advised. The passive-interface clause is used because this host listens to routing updates, but does not send routing updates. This is equivalent to the -q option mentioned earlier for the routed command. passive-interface is used on hosts that listen for updated; routers that actively participate in the routing exchange use the network clause. The network clause uses the interface name to identify the interface over which routing updates are exchanged; for example, network eth0. Alternatively, it can use an IP address to identify the systems with which routing updates are exchanged. The IP address is defined with an address mask. For example, network 172.16.60.0/24 would exchange routing updates with any system on subnet 172.16.60.0. We will see the network clause in action when we configure an interior router. The interface statement is used to configure the network interface for RIP. In Listing 7.9, a RIPv2 authentication mode is set for the interface. In this example, a simple clear text password is used. Clear text passwords are used to help the router avoid accepting updates from misconfigured systems; it is not a security method. Stronger update authentication is available in the form of MD5 authentication. 213
Note: If you are looking for inexpensive but high quality provider to host and run your jsp application check Astra jsp hosting services

Listing 7.8: Reconfiguring zebra.conf through the vtysh Interface junko.foobirds.org# configure terminal junko.foobirds.org(config)# hostname junko junko(config)# log file /var/log/zebra.log junko(config)# interface eth0 junko(config-if)# ip address 172.16.20.3/24 junko(config-if)# multicast junko(config-if)# exit junko(config)# exit junko# write file Configuration saved to /etc/zebra/zebra.conf junko# exit Connection closed by foreign host. [root]# cat /etc/zebra/zebra.conf ! ! Zebra configuration saved from vty ! 2002/05/28 15:22:17 ! hostname junko password Wats?Watt? enable password CHLLlns log file /var/log/zebra.log ! interface lo ! interface eth0 ip address 172.16.20.3/24 multicast ! line vty ! Listing 7.8 picks up where Listing 7.6 ended. We are still in enable mode, and all of the vtysh commands in Listing 7.8, except for the exit commands, can be entered only in enable mode. The configure terminal command tells the system that configuration commands will be entered from the vtysh interface. As each configuration command is entered, vtysh checks it for syntax errors, which is one of the best reasons for entering configuration commands through the vtysh interface. The commands hostname, interface, ip address, and multicast (shown in Listing 7.8) are basic configuration commands found in the zebra.conf file. In fact, all of these commands were discussed earlier when we looked at the zebra.conf example in Listing 7.5. Notice how the vtysh command prompt changes to indicate the different modes of operation. Listing 7.6 shows that the prompt for standard mode, called view mode, is a dollar sign ($), and that the prompt for enable mode is a hash mark (#). When the session enters configuration mode in Listing 7.8, the prompt indicates this with a (config) string. Furthermore, the prompt string changes to indicate what is being configured. For example, the string (config-if)indicates that an interface is being configured. Also notice that each time an exit command is entered, vtysh exits the current mode until the final exit command ends the session. The new configuration is stored in the zebra.conf file by the write file command. The final exit command in Listing 7.8 ends the session that began in Listing 7.6. A cat of the zebra.conf file shows that it has changed substantially from the zebra.conf file that was displayed at the start of Listing 7.6. The original zebra.conf file is not gone, however. vtysh saves the previous configuration file with a .sav extension when it writes the new file. The old zebra.conf file is now stored in /etc/zebra 212
Note: If you are looking for inexpensive but high quality provider to host and run your jsp application check Astra jsp hosting services

! end Listing 7.6 starts our sample vtysh session. We begin by displaying the current zebra.conf file. A minimal zebra.conf file must exist before zebra can be configured through the vtysh interface. The minimal configuration file must contain the passwords required for vtysh access. The first password is required to start the vtysh session. The second password is required to enter enable mode. You must be in enable mode to view or modify the configuration. In addition to requiring a minimal configuration, the daemon must be up and running before it can be configured from the vtysh interface, as illustrated by the service zebra start command shown in Listing 7.6. The vtysh interface is invoked by making a telnet connection to the running daemon. Notice in Listing 7.6, we telnet to the zebra port on the local host. For this to work, the port number must be defined in the /etc/services file. If the zebra port is not defined on your system, you must telnet to port 2601. The port numbers from the services file on our sample system are shown in Listing 7.7. Listing 7.7: The Port Numbers Used by the Zebra Suite $ tail -8 /etc/services # Local services zebrasrv 2600/tcp # zebra service zebra 2601/tcp # zebra vty ripd 2602/tcp # RIPd vty ripngd 2603/tcp # RIPngd vty ospfd 2604/tcp # OSPFd vty bgpd 2605/tcp # BGPd vty ospf6d 2606/tcp # OSPF6d vty Every routing daemon has its own port number. Before any of these can be configured by vtysh, a minimal configuration file containing the necessary passwords must be created for the daemon, and the daemon must be up and running. For example, to use the vtysh interface with ripd, you must first create a minimal ripd.conf file and start ripd. The first two steps shown in Listing 7.6 apply to all of the daemons. After connecting to the zebra routing manager in Listing 7.6, the first password is entered in response to the Password: prompt. This password starts the vtysh session. The enable command is entered to invoke enable mode. We again receive a password prompt, but this time it is for the password defined by the enable password command in the zebra.conf configuration file. After that password is entered, enable mode commands can be used. The first enable mode command in Listing 7.6 is write terminal, which displays the current configuration on the terminal screen. Notice that this configuration is different from the two-line configuration shown in response to the cat command. The write terminal command displays the configuration that is being used, which includes various defaults. Notice that all of the interfaces on the system, lo and eth0, are used by default. Also note the line vty command. This command appears in the configuration file when the configuration can be modified from the vtysh interface, which is the default. Having examined the existing configuration, we are ready to customize it to our needs. Listing 7.8 is a continuation of the session shown in Listing 7.6. 211
Note: If you are looking for inexpensive but high quality provider to host and run your jsp application check Astra jsp hosting services

multicasting protocol, such as RIPv2, on this interface. The second interface command is much like the first, except that it does not set the multicast flag. The log file command defines the file into which zebra should write its logging information. In Listing 7.5, the log is written to /var/log/zebra.log. Alternatives to logging to a specific file are to use the log stdout command to log to standard output or the log syslog command to log through syslogd. The last command in Listing 7.5 defines a static route. Although static routes may be distributed by protocols configured in other files, such as ripd.conf, the static routes are defined in the zebra.conf file. The keywords ip route are followed by the destination of the route and then the router used to reach that destination. In Listing 7.5, the destination is network number 172.16.50.0. A 24-bit address mask is being used to match addresses to the destination. The gateway for the route is 172.16.1.50. Of course, this is just an example. You probably won’t use static routes when you run routing protocols. Two lines in the zebra.conf file shown in Listing 7.5 define passwords for the vtysh interface. This file should therefore be readable only by administrators. Before going on to the configuration of individual routing protocols, let’s look at how these passwords are put to use for the vtysh interface. Using vtysh The vtysh tool provides an interactive interface into the zebra routing manager and each routing daemon. vtysh allows you to examine and modify the configuration of each program in the Zebra suite. Listing 7.6 shows a vtysh session in which the current zebra configuration is examined. In a later example, this configuration will be modified with vtysh. Listing 7.6: Examining zebra.conf through the vtysh Interface [root]# cat /etc/zebra/zebra.conf password Wats?Watt? enable password CHLLlns [root]# service zebra start Starting zebra: [ OK ] [root]# telnet localhost zebra Trying 127.0.0.1… Connected to localhost. Escape character is ‘^]’. Hello, this is zebra (version 0.91a). Copyright 1996-2001 Kunihiro Ishiguro. User Access Verification Password: Wats?Watt? junko.foobirds.org> enable Password: CHLLlns junko.foobirds.org# write terminal Current configuration: ! password Wats?Watt? enable password CHLLlns ! interface lo ! interface eth0 ! line vty 210
Note: If you are looking for cheap and reliable provider to host and run your servlet application check Vision servlet hosting services

and info documentation files, and quick reference man pages. Second, most of these commands never appear in a Linux router configuration. The best way to learn about Zebra configuration is to look at some reasonable examples. The zebra.conf File The zebra routing manager is required if you want to use any of the Zebra routing daemons. zebra maintains the kernel routing table, maintains the network interface list, defines the static routes, and manages the sharing of information between the different routing protocols. zebra is configured by the zebra.conf file. Listing 7.5 shows a sample zebra.conf file for a Linux system using two Ethernet interfaces: Listing 7.5: Sample zebra.conf File ! The hostname of this router hostname subnet60gw ! The password required for vtysh access password Wats?Watt? ! The password required for privileged vtysh commands enable password CHLLlns ! The first network interface interface eth0 ip address 172.16.60.1/24 multicast ! The second network interface interface eth1 ip address 172.16.1.9/24 ! The path to the log file log file /var/log/zebra.log ! A sample static route ip route 172.16.50.0/24 172.16.1.50 ! Comments in the various Zebra configuration files begin with an exclamation mark (!). The comments in Listing 7.5 explain the commands that follow them. The sample file in Listing 7.5 is larger and more complex than most. It was made that way to provide a full range of examples, but it is worthwhile to remember that your zebra.conf file will probably be smaller. The hostname command defines the hostname of the router. This is the name that will be used in routing protocol exchanges that use router names. zebra.conf files often start with this command. Next come two commands that define passwords. The password command is necessary if you plan to use the vtysh interface. If this password is not defined, the vtysh interface is disabled for zebra. The second password provides greater configuration control to the vtysh interface. Without the password defined by the enable password command, the vtysh interface can only be used to query zebra for information. With this second password, the zebra configuration can be controlled from the interface. We look at vtysh in more detail later. The first interface command defines the configuration of eth0. The command contains two clauses: ip address, which defines the address of the interface; and multicast, which turns on the multicasting flag for the interface. The multicast flag might be used if you planned to use a 209
Note: If you are looking for cheap and reliable provider to host and run your servlet application check Vision servlet hosting services

configuration. For example, a Red Hat Linux host running only RIPv2 might use the following commands to ensure that routing restarts after a system shutdown: [root]# chkconfig –level 35 zebra on [root]# chkconfig –level 35 ripd on On the other hand, a Red Hat system acting as an external router might use the following: [root]# chkconfig –level 35 zebra on [root]# chkconfig –level 35 ospfd on [root]# chkconfig –level 35 bgpd on If your system does not include startup scripts, the routing manager and the daemons can be started directly, either from the command prompt or from the rc.local script, using the following commands: [root]# zebra -d [root]# ospfd -d [root]# bgpd -d The -d option causes the selected program to run as a daemon. Another commonly used option is -f, which defines the path to the program’s configuration file. Of course, our sample Red Hat system does include startup files in the Zebra RPM to ensure that Zebra starts every time the system reboots. Invoke the startup scripts directly to start the routing manager and the routing daemons immediately. For example: [root]# service zebra start Starting zebra: [ OK ] [root]# service ospfd start Starting ospfd: [ OK ] [root]# service bgpd start Starting bgpd: [ OK ] These commands show the zebra routing manager, the OSPF daemon, and the BGP daemon starting successfully. This happens only after zebra, ospfd, and bgpd are configured because the Red Hat startup scripts check that the configuration files exist before running the programs. Before you start the daemons, create the required configuration files. Zebra Configuration Files Each program in the Zebra suite has its own configuration file. By default, the configuration files are located in the /usr/local/etc directory. On our sample Red Hat system, they are located in the / etc/zebra directory. Each file has a name in the format program.conf, where program is the name of the program being configured. For example, zebra.conf, ospfd.conf, and ripd.conf are all standard configuration filenames. Of course, you can name the configuration file anything you want and place it anywhere on the system because the file can be identified to the program using the -f command-line option when the program is run. However, it is best to stick with standard names, so that others can easily find the files when performing maintenance. Because the routing manager and the various protocols are configured separately, and because modern routing protocols can be very complex, there are hundreds of configuration commands available for Zebra. The “Command Index” section of the HTML documentation that comes with Zebra lists them all. We do not repeat that list here, for a couple of reasons. First, the laundry list of commands is already provided in the online Zebra documentation Zebra provides excellent HTML 208
Note: If you are looking for cheap and reliable provider to host and run your servlet application check Vision servlet hosting services

bgpd bgpd provides the BGP routing protocol. vtysh Because each routing protocol and the zebra routing manager are all configured in separate files, configuration can be complex. vtysh is a virtual terminal interface designed for maintaining the router configuration. ripngd ripngd provides the RIPng routing protocol for use on IPv6 networks. ospf6d ospf6d provides the OSPFv6 routing protocol for use on IPv6 networks. This modular architecture is inherently extensible. A new routing protocol can be added by creating a new daemon for the protocol and designing that daemon to interface with the zebra routing manager. Additionally, implementation of the protocol daemon is simplified because zebra handles the internal functions for the new daemon. The new software needs to handle only the external protocol functions. Installing Zebra The Zebra suite is available on the Web at http://www.gnu.org/ and via FTP from ftp://ftp.zebra.org/. A beta-testers’ website is available at http://www.zebra.org/. At the time of writing, the Zebra software is in beta release. If you prefer to use mature software, see the information on gated later in this chapter. However, for the type of routing applications that should reasonably be undertaken by a Linux system, the beta release of Zebra is more than adequate. The Zebra software suite is include in some Linux distributions, and can be installed during the initial system installation. Our sample Red Hat Linux system is an example of a distribution that includes Zebra. If it is not already installed, it can be installed on the Red Hat system using the rpm command. Figure 7.3 show a gnorpm query of the Zebra RPM. Figure 7.3: Contents of the Zebra RPM Zebra does not start at boot time, even if installed from the RPM, unless you configure your system to start it. The Zebra RPM includes a separate startup script for the routing manager and each of the routing protocol daemons. Start only those daemons needed to support your routing 207
Note: If you are looking for good and quality webspace to host and run your java application check Actions java hosting services

The first line in our example creates an active default route. This default route is used during the RIP startup period, but after RIP is up and running, this default router is expected to be an active participant in the routing protocol. If you use a default route when running a routing protocol, use an active default route. A static default route can defeat the purpose of a dynamic routing protocol by not allowing the protocol to update the route when network conditions change. The second line creates a static route to subnet 172.16.50.0 through router 172.16.55.36. Because this is a passive route, 172.16.55.36 does not need to run RIP. The only reason to create such a route would be that 17216.55.36 does not run RIP. routed is adequate for some small networks. It requires no installation and very little configuration. However, it is antiquated software that is not suitable for many networks. In particular, it does not support classless IP addresses. If you use classless IP addresses, run a modern routing protocol that supports address masks. Some Linux distributions no longer provide routed, preferring to rely on more modern routing software. Linux offers two different software packages that provide modern routing protocols. The gateway daemon (gated) is a routing software package found on many Unix systems. Zebra is a routing software package from GNU. These packages provide Linux systems with access to interior and exterior routing protocols that normally run only on dedicated routing hardware, such as Cisco routers. Routing with Zebra Zebra is a routing software package that provides support for RIP, RIPv2, OSPF, and BGP. In addition, Zebra provides support for IPv6 routing with both the RIPng protocol and the OSPFv6 protocol. There are internal and external aspects to routing software. On the external side, routing software runs a protocol to exchange routing information with external routers. On the internal side, routing software processes the information learned from the protocol, selects the best routes, and updates the kernel routing table. This internal process increases in complexity when running multiple protocols because it is possible for a router to receive routes to the same destination from different routing protocols. Each protocol uses its own metric for selecting the best route. If each protocol independently updated the routing table, chaos could ensue. To support multiple protocols, and in particular exterior routing protocols, Zebra provides a way to compare incompatible metrics and select the best route. It does this using a value it calls distance, which is an arbitrary number from 1 to 255. The higher the distance number of the protocol that provides the route, the less preferred the route. Each protocol has a default distance value assigned to it, which you can override in the configuration. Zebra uses a modular architecture, with separate programs handling different routing tasks. At this writing, the Zebra suite includes the following key programs: zebra zebra is the routing manager. It updates the kernel routing table with the routes received from the various routing protocols. All protocols update the table through the zebra routing manager. ripd ripd provides the RIP and RIPv2 routing protocols. ospfd ospfd provides the OSPF routing protocol. 206
Note: If you are looking for good and quality webspace to host and run your java application check Actions java hosting services