Difference between revisions of "OSPF"

From StarOS Community Wiki
Jump to navigation Jump to search
(Flesh this out with some operational experience, add some formatting.)
m (typo)
 
(2 intermediate revisions by one other user not shown)
Line 38: Line 38:
Here are the commands that would be run to set this up:
Here are the commands that would be run to set this up:


  hostname>en
  hostname>enable
  hostname#configure terminal
  hostname#configure terminal
  hostname(config)#password yourpassword
  hostname(config)#password yourpassword
Line 82: Line 82:
* OSPF is very sensitive to system clock changes.  If you have NTP enabled on StarOS routers pre-1.5.9b, you may see random OSPF neighbor association drops when the ntpdate synchronizes the clock to the NTP server every day.  When that happens, OSPF drops all the routes it learned from that neighbor and had to relearn them. Whether this will happen depends on the "drift" of the clock on the particular board.<br />  The XSCALE-METRO boards seem to have the most drift (about 7 minutes per 24 hour period) and will have OSPF issues every 24 hours if NTP is enabled.  XSCALE-WP188 board clocks also have just enough drift to cause problems, sometimes.  To determine if your router has a problem with this, look for ntpdate entries in the system log.  If the system log shows ntpdate stepping the clock by more than a couple of seconds, disable NTP on those boards or update StarOS to 1.5.9b or later.<br />  Quagga's OSPFd, which is used on StarOS, does not care how much the clocks differ between neighbors so long as it hears the hello packets within the configured interval.  That statement may be generally true of any OSPF implementation.  I've not done the due diligence to state that.
* OSPF is very sensitive to system clock changes.  If you have NTP enabled on StarOS routers pre-1.5.9b, you may see random OSPF neighbor association drops when the ntpdate synchronizes the clock to the NTP server every day.  When that happens, OSPF drops all the routes it learned from that neighbor and had to relearn them. Whether this will happen depends on the "drift" of the clock on the particular board.<br />  The XSCALE-METRO boards seem to have the most drift (about 7 minutes per 24 hour period) and will have OSPF issues every 24 hours if NTP is enabled.  XSCALE-WP188 board clocks also have just enough drift to cause problems, sometimes.  To determine if your router has a problem with this, look for ntpdate entries in the system log.  If the system log shows ntpdate stepping the clock by more than a couple of seconds, disable NTP on those boards or update StarOS to 1.5.9b or later.<br />  Quagga's OSPFd, which is used on StarOS, does not care how much the clocks differ between neighbors so long as it hears the hello packets within the configured interval.  That statement may be generally true of any OSPF implementation.  I've not done the due diligence to state that.


* According to StarOS forum posts, OSPF has not been terribly reliable across StarOS wireless interfaces when the OSPF network type is left at the default of <code>broadcast</code>.  Try <code>ip ospf network point-to-point</code>, <code>ip ospf network point-to-multipoint</code>, or <code>ip ospf network non-broadcast</code> on wireless links.  You may need to specify the neighbors in the <code>router ospf</code> section when using these other network types, <code>neighbor 10.10.2.3</code>.  The Mikrotik wiki suggests that the OSPF network type of "point-to-multipoint" is to be preferred for wireless interfaces in general.  Not enough operational experience has been professed on the forums to say for certain.
* With the lack of a hardware realtime clock on most StarOS hardware, you can run into problems when you have OSPF MD5 authentication enabled on a network interface and the staros box is power cycled.  The clock will revert to it's default from 1969 and other devices on the network will refuse to talk to the power cycled device if it boots before the association timeout timer expires on the other boxes.  Probably an anti-replay attack safeguard of the MD5 auth mechanism, but I don't know for certain.  I would recommend not running OSPF with MD5 authentication on interfaces which are not directly accessible by customer hardware.  This problem manifests as one or more routers on the network segment showing a neighbor state of 2-way  for the router which has been rebooted.  Quite often, the router which was rebooted shows a neighbor state of full with all of it's neighbors.
 
* For best results, always specify an ip ospf router-id  on each box using an IP address unique to that box.  Duplicate route-ids cause routes injected by one or more of the routers with the duplicate router-id to be ignored.  On StarOS boxes with two ethernet interfaces, of which only one is being utilized, I have most commonly seen the 192.168.2.1 from the second ethernet interface be automagically chosen by multiple routers.  We've seen a ping to an IP on the problem router respond for 1 to 2 seconds after a restart of OSPF, then the route goes away and the pings fail again.
 
* According to StarOS forum posts, OSPF has not been terribly reliable across StarOS wireless interfaces when the OSPF network type is left at the default of <code>broadcast</code>.  Try <code>ip ospf network point-to-point</code>, <code>ip ospf network point-to-multipoint</code>, or <code>ip ospf network non-broadcast</code> on wireless links.  You may need to specify the neighbors in the <code>router ospf</code> section when using these other network types, <code>neighbor 10.10.2.3</code>.  The Mikrotik wiki suggests that the OSPF network type of "point-to-multipoint" is to be preferred for wireless interfaces in general.  Not enough operational experience has been professed on the StarOS forums to say for certain which works best with StarOS.


* When you Activate Changes in StarOS, StarOS restarts the Quagga daemons.  That can cause a short interruption in service while the daemons restart and relearn all of the routes, including the default if you don't have a static default route configured in StarOS.   
* When you Activate Changes in StarOS, StarOS restarts the Quagga daemons.  That can cause a short interruption in service while the daemons restart and relearn all of the routes, including the default if you don't have a static default route configured in StarOS.   

Latest revision as of 05:06, 2 June 2011

OSPF stands for Open Shortest Path First. On StarOS, this is implemented through the use of the Quagga routing daemon. Essentially, the daemon runs on two routers and they use the broadcast addresses to announce routes between routers. This is an excellent way to dynamically distribute routes across a complex routed network. Some effort may be required to achieve a stable OSPF configuration for wireless networks.

OSPF configuration uses a configuration prompt that works in a very similar manner to a Cisco router configuration. Once logged in, you have to use the enable command to get into a privileged mode which will allow for modification of the configuration. Each line in the configuration file is enabled by simply typing the command. Disabling interfaces or commands is accomplished by putting the word "no" in front of the command.

When the configuration is completed, use the write memory command to copy the configuration to memory. "memory" is long term storage in this context. If you do not write the config to memory, OSPF will not retain the configuration. When you exit the OSPF daemon's interface, be certain to use File --> Save changes in StarOS. The Quagga daemon configuration files are not actually saved to permanent storage in StarOS until you do so. Also, be careful of the "Factory Settings" button in the StarOS GUI. At the time this article is being written, StarOS does not ask if you are certain. It will simply wipe out your configuration.

Here is an example of a simple OSPF configuration:


Current configuration:
!
hostname ospftest-ap
password yourpassword
!
!
!
interface eth0
!
interface wpci0
!
interface wpcm0
!
router ospf
  ospf router-id 10.1.1.1
  redistribute connected
  redistribute static
  network 10.0.0.0/8 area 0.0.0.0
!
access-list vtylist permit 127.0.0.1/32
access-list vtylist permit 10.0.0.0/8
access-list vtylist deny any
!
line vty
  access-class vtylist
!
end

Here are the commands that would be run to set this up:

hostname>enable
hostname#configure terminal
hostname(config)#password yourpassword
hostname(config)#hostname ospftest-ap
ospftest-ap(config)#router ospf
ospftest-ap(config-router)#ospf router-id 10.1.1.1
ospftest-ap(config-router)#redistribute connected
ospftest-ap(config-router)#redistribute static
ospftest-ap(config-router)#network 10.0.0.0/8 area 0
ospftest-ap(config-router)#exit
ospftest-ap(config)#no access-list vtylist deny any
ospftest-ap(config)#access-list vtylist permit 10.0.0.0/8
ospftest-ap(config)#access-list vtylist deny any
ospftest-ap(config)#exit
ospftest-ap#write memory
ospftest-ap#show running-config


In general, you can type a non-ambiguous prefix of a command without having to type the entire word. So conf t works just as well as configure terminal. Also, sh run works the same as show running-config.

You can type the question mark ? to see what options are available at that point in a command. While learning, type ? on the command line any time you are uncertain of what you can do. For instance, try show ip ospf ?.

Common commands to use for troubleshooting OSPF include the show ip ospf neighbor [detail], show ip ospf interface, and show ip ospf routes commands.

ospftest-ap# sh ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface           RXmtL RqstL DBsmL
10.0.1.7          1   Full/Backup     00:00:35    10.8.1.1        wpci0:10.8.1.2      0     0     0
10.8.3.2          1   Full/DR         00:00:34    10.8.3.2        wpcm0:10.8.3.1      0     0     0
ospftest-ap#

This shows all neighbors to an OSPF router. The "Full" designation indicates that routes are being exchanged between this router and the neighbor routers. If you see the "Init" state continuously, there may be a configuration issue on one of the routers. Check your MTU and hello intervals on both sides of the link.

The "show ip ospf routes" command will show all of the routes that this OSPF router has in its routing table.

Caveats:

  • Certain via-rhine network cards will not broadcast network traffic, and have problems with the standard OSPF configuration. You will have to set up a unicast network broadcast to adjacent routers and vice versa if you are using these cards. (Does this mean "ip ospf network non-broadcast"? If so, can we say so explicitly?)
  • The broadcast traffic for OSPF will go out using the first IP address configuration on an interface.
  • OSPF traffic will not propagate between every two different routers on a Point-to-MultiPoint (PTMP) wireless connection with Intercell relay turned off. You may need to configure the the "ip ospf network point-to-multipoint" on interfaces connected to PTMP wireless or frame-relay networks. All hosts should be able to build an adjacency with the AP end of the link, but not with each other. OSPF will see multiple point-to-point neighbors on such links. However, normal traffic between routers connected in that fashion won't be able to go through other routers on the same AP. But it could be useful for the usual situation in which customers want to talk to resources not connected to the same AP. Confused yet?
  • OSPF is very sensitive to system clock changes. If you have NTP enabled on StarOS routers pre-1.5.9b, you may see random OSPF neighbor association drops when the ntpdate synchronizes the clock to the NTP server every day. When that happens, OSPF drops all the routes it learned from that neighbor and had to relearn them. Whether this will happen depends on the "drift" of the clock on the particular board.
    The XSCALE-METRO boards seem to have the most drift (about 7 minutes per 24 hour period) and will have OSPF issues every 24 hours if NTP is enabled. XSCALE-WP188 board clocks also have just enough drift to cause problems, sometimes. To determine if your router has a problem with this, look for ntpdate entries in the system log. If the system log shows ntpdate stepping the clock by more than a couple of seconds, disable NTP on those boards or update StarOS to 1.5.9b or later.
    Quagga's OSPFd, which is used on StarOS, does not care how much the clocks differ between neighbors so long as it hears the hello packets within the configured interval. That statement may be generally true of any OSPF implementation. I've not done the due diligence to state that.
  • With the lack of a hardware realtime clock on most StarOS hardware, you can run into problems when you have OSPF MD5 authentication enabled on a network interface and the staros box is power cycled. The clock will revert to it's default from 1969 and other devices on the network will refuse to talk to the power cycled device if it boots before the association timeout timer expires on the other boxes. Probably an anti-replay attack safeguard of the MD5 auth mechanism, but I don't know for certain. I would recommend not running OSPF with MD5 authentication on interfaces which are not directly accessible by customer hardware. This problem manifests as one or more routers on the network segment showing a neighbor state of 2-way for the router which has been rebooted. Quite often, the router which was rebooted shows a neighbor state of full with all of it's neighbors.
  • For best results, always specify an ip ospf router-id on each box using an IP address unique to that box. Duplicate route-ids cause routes injected by one or more of the routers with the duplicate router-id to be ignored. On StarOS boxes with two ethernet interfaces, of which only one is being utilized, I have most commonly seen the 192.168.2.1 from the second ethernet interface be automagically chosen by multiple routers. We've seen a ping to an IP on the problem router respond for 1 to 2 seconds after a restart of OSPF, then the route goes away and the pings fail again.
  • According to StarOS forum posts, OSPF has not been terribly reliable across StarOS wireless interfaces when the OSPF network type is left at the default of broadcast. Try ip ospf network point-to-point, ip ospf network point-to-multipoint, or ip ospf network non-broadcast on wireless links. You may need to specify the neighbors in the router ospf section when using these other network types, neighbor 10.10.2.3. The Mikrotik wiki suggests that the OSPF network type of "point-to-multipoint" is to be preferred for wireless interfaces in general. Not enough operational experience has been professed on the StarOS forums to say for certain which works best with StarOS.
  • When you Activate Changes in StarOS, StarOS restarts the Quagga daemons. That can cause a short interruption in service while the daemons restart and relearn all of the routes, including the default if you don't have a static default route configured in StarOS.
  • If you do have a static default route configured in StarOS, traffic to the Internet cannot fail over to a different path in cases where you do have redundant paths available. It may be worth investigating setting a low priority default route in the Zebra configuration telnet 127.0.0.1 2601 from the system console shell.

See Also: