RIP
Introduction
StarOS uses the quagga open source software to provide RIP and OSPF. Documentation is available at www.quagga.net. The RIP documentation is incomplete. The quagga command set is similar to that of other RIP implementations, and any documentation you can find about RIP may be helpful. There is an abundance of Cisco documentation available on the Web. Ultimately, the quagga source code can be studied. The details that follow correspond to quagga version 0.98.5, from StarOS version 2.10.0 build 4693. Some of the details vary in other versions.
Be cautious that RIP is inclined to aggressively spread routing information to any routers or hosts that are using RIP. It can advertise routes for private addresses like 192.168.1.1 that you might have set up just for you own use in managing a router. If a customer's router or computer runs RIP, your router can learn and redistribute knowledge of its routes. RIP can result in routes being distributed against your wishes, and it can result in a significant amount of network traffic.
RIP is at its best in a small network with low connectivity. For example, 9 routers arranged in a single loop would foster only a modest amount of RIP traffic and would be able to tolerate the loss of any one link. By contrast, a grid or mesh of access points would provide an abundance of alternative paths and could generate a large amount of RIP activity. The maximum path-length that RIP supports is 15, so if your worst-case routing distance is more than 15, RIP cannot handle it.
A conservative approach is to run RIP only on backhaul interfaces that you use to interconnect your access points. You don't want to allow a customer to inject RIP traffic into your system.
The best guard against an overactive RIP is its filtering feature. Routes, sent or accepted, should be passed through a filter which only allows routes of your choice to be advertised. For example, suppose your network is organized so that the public addresses are of the form 222.22.*.*, the private address that you want to be able to route throughout your network are of the form 10.10.*.*, and you use 10.2.*.* for backhaul and management addresses. Then your RIP filters should allow routes within 10.10.0.0/16 and 222.22.0.0/16 to be advertised via RIP. Not only will this cut down the RIP traffic, but it will avert the prospect of multiple instances of 192.168.1.1 being accidentally advertised from random pieces of customers' equipment or your own equipment. You can provide static routes for 10.2.*.*. You should not provide static routes for RIP-routed addresses, if you expect failover behavior.
The default route 0.0.0.0/0 needs to be supported as well. Consider a public address such as 222.22.2.1. To get service, packets must be routed to it, and also packets from it must be able to reach arbitrary other addresses. So knowledge of a workable default route must reach the router that is connected to 222.22.22.1.
Management interface
Under StarOS, RIP is managed using a command-line interface accessed through a telnet-like connection. Initially, you access this through "routing->advanced" (v2) or "routing->dynamic" (v3). You must first "Enable" RIP and then "Configure" which brings you to the login phase of a session. Initially, the password is "1234" (regardless of what the router's main password is). Once you are logged in, you'll want to give the "enable" command which activates a mode in which you are allowed make changes.
After a few configuration changes (see below), you will be able to access the management interface directly using telnet, without logging in to the router. Just direct the telnet session to port 2602 at the router's address and log in as above.
You cannot experiment with the RIP configuration while leaving RIP disabled. Instead, you must first start RIP and then configure it. This means you must be careful if you go about configuring a router that is in service carrying customer traffic. Initially, the configuration is very liberal and will distribute all routes on all interfaces.
Command modes
The interface has several modes, using the prompt to indicate its current mode. This chart shows the prompt in each mode, the mode and command from which you enter the given mode, and the command you use to leave the mode:
MODE ENTERED BY LEFT BY ripd# ripd> enable ripd# disable ripd(config)# ripd# config terminal ripd(config)# exit ripd(config-router)# ripd(config)# router rip ripd(config-router)# exit
Commands
To see all the available commands in the current mode, use the "list" command. You will see a long list of possibilities. In typing commands, the TAB character generally serves to automatically complete the current word if there is a unique completion. Or you can just truncate keywords wherever there is a unique completion. The ? character in place of a command word will show you what word or words could be used at that point.
Important basic commands are "password" to change the password, "show running-config" which prints out the current configuration, "show ip rip" which shows routes, and "show ip rip status" which summarizes various rip-related information.
Lists
Many commands are used to manipulate lists. To add an item to a list, you just write out the whole item as a command. To delete an item, you write out the whole item prefixed with "no". The "list" command will disclose many examples of this. To reorder the items in a list, you must use a succession of deletions and additions.
Selecting interfaces for RIP
The "network" command in "(config-router)" mode determines which interfaces RIP runs on. It has two forms. The command "network IF", where IF is the name of an interface, says that RIP will run on that interface. Beware that if you misspell the name of the interface, as with "wlan1" instead of "wpci1", there will be no complaint, just a lack of effectiveness. Also beware that the naming within StarOS is different at the low levels (eth0, eth1,... wpci0, wpci1,...) than at the high levels (ether1, ether2,... wpci1, wpci2...). The rip configuration, like the system log, uses the low-level names. The command "network NETBLOCK", where NETBLOCK is a netblock like 10.10.0.0/16, says that RIP will run on any interface that supports any address in that netblock. You will probably want to use "no network 0.0.0.0/0" to erase the default which causes RIP to run on all interfaces.
Filtering the routes
There are two parts of filtering: defining filters as access lists or prefix lists, and associating filters with interfaces using the distribute-list command.
Access lists
An access list is used to allow or block a route being advertised. There are many possible forms, of which only the simplest are described here. A construction like this:
access-list myprivates permit 10.10.0.0/16
allows routes within a given netblock. This list is named "myprivates". If the keyword "exact-match" is appended, then routes using a proper subset of the given block are not affected, just routes that use the given netblock.
For example, to allow the public and private routes described above as well as the default route, this access list may be used:
access-list mine permit 222.22.0.0/16
access-list mine permit 10.10.0.0/16
access-list mine permit 0.0.0.0/0 exact-match
access-list mine deny any
The "exact-match" keyword is necessary for the default route, for otherwise it would match every route. The last item in the above list shows that "any" may be used in place of a netblock. That item is only reached if none of the earlier items is matched. Actually, it is unnecessary, because when matching falls off the end of the list due to nothing matching, "deny" is assumed.
Vty access list
You can define as many access lists as you like, referring to them by name. Initially, there is this access list guarding connections to the management interface:
access-list vtylist permit 127.0.0.1/32
access-list vtylist deny any
It allows only connections from within the StarOS management interface. If you wish to allow telnet connections from outside, choose the IP addresses you wish to allow to connect and modify the access list accordingly. For example, to allow connections from 222.22.0.1, these commands would suffice to insert the appropriate item into the list in the proper order:
no access-list vtylist deny any
access-list vtylist permit 222.22.0.1/32
access-list vtylist deny any
If you do this, you'll probably also want to change the password from the default 1234.
Prefix lists
Prefix lists offer more detailed descriptions of routes. Prefix lists are created under the "(config)" mode with commands of the form "ip prefix-list NAME seq STEP ACTION NETBLOCK MODIFIERS", where NAME is a name you assign to the list, ACTION is either "deny" or "permit", and the optional MODIFIERS are of the form "le N" or "ge N", where N is an integer between 0 and 32. The optional "seq STEP" construction, where STEP is a positive integer, is used to impose an order on the list so that you need not enter the items in the order in which they are to be scanned. If you omit the sequence numbers, 5, 10, 15,... are assigned.
A prefix list is used to either permit or deny a given netblock. The netblock is matched against each item in the list, in order, and when it matches, the ACTION determines the result. "Permit" means the given netblock passes the filter, and "deny" means it is blocked. The first step in matching is to see whether the subject netblock is a subset of the NETBLOCK given in the prefix-list item. If not, there is no match. If so, the MODIFIERS are consulted. They simply test the size of the given netblock. (See example below.) If all modifiers correctly describe the size of the given netblock, then it passes. If there are no modifiers, then the route must exactly match the given netblock and not be a proper subset. If no item in a prefix list is matched, then the result is "deny".
The following example shows how to allow all routes within 222.22.*.* or 10.10.*.*, and just the default route, using a prefix list named "mypre":
ip prefix-list mypre seq 5 permit 222.22.0.0/16 ge 17 ip prefix-list mypre seq 10 permit 222.22.0.0/16 ip prefix-list mypre seq 15 permit 10.10.0.0/16 ge 17 ip prefix-list mypre seq 20 permit 10.10.0.0/16 ip prefix-list mypre seq 25 permit 0.0.0.0/0 le 0
First note that the "seq" specifications could all be omitted since they are the same as the default assignments. Second, the slightly strange construction in the first two pairs must be explained. Quagga for some reason will not allow "222.22.0.0/16 ge 16". Thus, step 5 allows all routes of the form 222.22.*.*/N, where N is 17 or more, while step 10 allows the one route 222.22.0.0/16. Step 25 allows just the default route. It would also suffice to omit the "le 0" modifier, since that would demand an exact match.
Associating filters with interfaces
The "distribute-list" command in "(config-router)#" mode associates access or prefix lists with interfaces. For example, consider the following distribute-list commands:
distribute-list mine in wpci0 distribute-list prefix mypre in wpci1 distribute-list mine out
The first line associates an access list with incoming RIP advertisements on wpci0. The second line associates a prefix list with incoming RIP advertisements on wpci1. The third line associates an access list with outgoing advertisements on all interfaces.
Summary
By defining appropriate access or prefix lists and associating them with interfaces on which RIP is enabled, you can control the addresses (routes) that are disseminated within the RIP system. For example, suppose your backhaul uses eth0 and eth1 and the routable addresses that reach your customers are on wpci0 and wpci1. Then the following setup might be used:
ripd(config)# access-list mine permit 222.22.0.0/16 ripd(config)# access-list mine permit 10.10.0.0/16 ripd(config)# access-list mine permit 0.0.0.0/0 exact-match ripd(config)# router rip ripd(config-router)# distribute-list mine in ripd(config-router)# distribute-list mine out ripd(config-router)# network eth0 ripd(config-router)# network eth1
Favoring certain routes
You may wish to favor or disfavor the use of certain links. This is done by assigning weights to certain interfaces using offset lists. The command that applies an offset-list resembles the "distribute-list" command, as shown by these examples which discourage the use of wpci0 by giving it a weight of 4 rather than the default 1:
offset-list mine in 4 wpci0 offset-list mine out 4 wpci0
The list mentioned in an "offset-list" command must be an access list.
Injecting routes into RIP
The above commands control how RIP handles routes it comes to know of. The "redistribute" command controls which routes are made known to RIP in the first place. It has these basic possibilities:
redistribute connected redistribute static redistribute kernel
The first command tells RIP to advertise the addresses that are assigned to interfaces. The second one says to advertise all statically configured routes. The third says to adverise all routes in the routing table. Bear in mind that filters may limit which of these actually get disseminated to other computers running RIP.
Monitoring and debugging
These command will show your current configuration:
show running-config show ip rip status
The first one shows it in the form of commands you can type. The second is like an executive summary and is very informative.
This command will show all the routes that RIP has learned:
show ip rip
To debug RIP in operation, you first enable debugging with either or both of these commands:
(config)# debug rip events (config)# debug rip packet
Then you can turn on and off the delivery of debugging information to your session this way:
ripd# terminal monitor ripd# terminal no monitor
Saving your configuration
To save the configuration so that it is reloaded when the computer is rebooted, or when RIP is turned off and on, issue this command:
copy running-config startup-config