417N/A# The contents of this file are subject to the terms of the
417N/A# Common Development and Distribution License (the "License").
417N/A# You may not use this file except in compliance with the License.
417N/A# See the License for the specific language governing permissions
417N/A# and limitations under the License.
417N/A# When distributing Covered Code, include this CDDL HEADER in each
417N/A# If applicable, add the following below this CDDL HEADER, with the
417N/A# fields enclosed by brackets "[]" replaced with your own identifying
417N/A# information: Portions Copyright [yyyy] [name of copyright owner]
5003N/A# Copyright (c) 2006, 2015, Oracle
and/or its affiliates. All rights reserved.
417N/A SOLARIS' OFFERING OF OPENSOURCE QUAGGA SOFTWARE
417N/A ************************************************
417N/AQuagga(version 0.99.4) in Solaris is comprised of the following packages:
417N/A - Provides the Quagga daemons and the quaggaadm utility.
417N/A The daemons installed by this package are:
417N/A ripd, ripngd, ospfd, ospf6d, bgpd, and zebra(the routing manager daemon)
417N/A This package has dependencies on SUNWquaggar and SUNWquagga-libs
417N/A file and SMF manifests for Quagga daemons.
417N/A - Provides Quagga-specific dynamic libraries used by the Quagga daemons.
417N/A - Provides header files, archive libraries and libtool files required for
417N/A building code using the Quagga libraries. Note that these interfaces are
417N/A External to Solaris and come without API stability guarantees. See also the
5003N/A attributes (7) manual page.
417N/A - Provides the sources from which this release of the SUNWquagga packages
417N/A were built. You may need to install either the Workshop compilers or gcc
417N/A to compile the source. In order to compile Quagga's vtysh utility, you
417N/A will need Readline libraries, which are freely available on the web.
417N/ALocation of Installed Files and Directories
417N/A===========================================
417N/AModules of Quagga Location
417N/A-------------------------------------------------------------
417N/ADaemon binaries(zebra,ospfd, ospf6d, ripd,
417N/AUpgrading from SUNWzebra
417N/A========================
417N/APreviously, the Zebra routing protocol suite was delivered as part of the
417N/ASFW consolidation. This has now been replaced with Quagga, and Zebra
417N/Arouting configuration can be migrated easily, either explicitly by running
5003N/A"routeadm -u" (see routeadm (8)), or by rebooting the system. The
417N/Aappropriate configuration files for the daemons used will be migrated to
417N/AQuagga, and the equivalent Quagga SMF services will be enabled.
417N/AIncompatibilities of Quagga
417N/A============================
5003N/AYou may use
in.routed(8) on other systems on your network, but you must not
417N/AQuagga. Quagga is incompatible with the Solaris IP Multipathing
5003N/A(
in.mpathd(8)) feature. Do not enable IPMP on a system running Quagga. If
417N/Ayou have a machine set up with IPMP and wish to run Quagga on it, please
417N/ASolaris 10 System Administrator Collection >>
417N/A System Administration Guide: IP Services >>
417N/A Part VI IP Network Multipathing (IPMP) >>
417N/A 30. Administering IPMP (Task))
417N/AIFF_NORTEXCH Interface Flag Support
417N/A====================================
417N/ACurrently Quagga is not aware of the IFF_NORTEXCH interface flag, so if
417N/Ayou're trying to fence off interfaces from the intrusion of unwanted routing
417N/Aprotocols, make sure you don't configure those interfaces in Quagga.
417N/ASupport Level of Quagga Software
417N/A================================
417N/AThe contents of SUNWquaggar, SUNWquagga-daemons are provided with full Level
417N/A1 support in accordance with your current software support agreement. This
417N/Asupport includes Sun's global 24/7 sustaining model.
417N/AConfiguring a Multi-homed Host as a Router Using Quagga
417N/A==========================================================
417N/A Sample configuration files have been provided in that directory.
417N/A routeadm -e ipv4-forwarding
417N/A Disable IPMP if machine is set up with it. To do this, you will
417N/A have to undo all the things you had done to configure IPMP
417N/A on your system. Please see :
417N/A Product Categories>> Solaris >> Solaris 10
417N/A Solaris 10 System Administration Guide:IP services, Chapter 30
417N/A for configurations details of IPMP.
417N/A Also it is important to note that each daemon is invoked with
417N/A arguments to disable remote Telnet access to the daemons as it is a
417N/A security risk. Please do not edit these configuration parameters that
417N/A comprise part of the daemon-args property for each service.
417N/A Pick the appropriate SMF service for the routing daemon that
417N/A you wish to start. To enable a Quagga daemon service, type the following
417N/A # routeadm -s routing-svcs="<routing daemon svc>" -e ipv4-routing -u
417N/A # svcadm enable <routing daemon svc>
417N/A Example: To enable the ospfd daemon, type the command:
417N/A # routeadm -s routing-svcs=ospf:quagga -e ipv4-routing -u
417N/A To enable the ospf6d daemon, type the command:
417N/A # routeadm -s routing-svcs=ospf6:quagga -e ipv6-routing -u
417N/AEditing the Daemon Arguments
417N/A----------------------------
417N/AYou can change the arguments used to invoke the Quagga routing
417N/Adaemons by modifying the service properties (listed by
417N/Arunning "routeadm -l <routing daemon svc>"). For example,
417N/Asets an alternate configuration file.
417N/AMonitoring, Debugging and Reconfiguring Quagga Daemons Interactively
417N/A====================================================================
417N/AQuagga provides a Telnet UI so that the user can access the daemons in
417N/Areal-time. This interface is disabled by default for all daemons, but can
417N/Abe enabled by changing the daemon-args property of Quagga services to a suitable
417N/Avalue, such as "-A 127.0.0.1":
417N/A # routeadm -m ospf:quagga vty_address="127.0.0.1"
417N/AThis user interface allows one to connect to each daemon, monitor the
417N/Adaemon, tag debugging parameters, and reconfigure the parameters of the
417N/Arunning daemon. We have provided this facility with a wrapper utility called
417N/Aquaggaadm (formerly zebraadm).
417N/ATo access a particular daemon type
417N/A*****WARNING*****WARNING****WARNING********
417N/ABy default, if the daemon-args are not set so as to restrict access, Quagga
417N/Aallows a user to remotely access the daemons via the Telnet UI. We STRONGLY
417N/ARECOMMEND AGAINST remote Telnet access of the daemons, as it leaves the
417N/Asystem vulnerable to security holes. To avoid leaving your system
417N/Avulnerable, all daemons must be invoked with "-A 127.0.0.1" option, as shown
417N/Ain the example above where routeadm is used to modify the 'daemon-args'
417N/A*****WARNING*****WARNING****WARNING********
417N/ADisabling Quagga Daemons on a System
417N/A====================================
417N/AIf you have enabled Quagga routing daemons as discussed above, and now wish
417N/Ato disable them, this can be done generally with:
417N/A # routeadm -d ipv4-routing -u
417N/A # routeadm -d ipv6-routing -u
417N/Aas appropriate. One may also disable just specific daemons with:
417N/A # svcadm disable <daemon service>
417N/AHigh-Availability Networking for Hosts with Quagga
417N/A==================================================
417N/AThe OSPF-MP (OSPF Multi-Pathing) feature is a layer 3 solution to achieve
417N/Anetwork connectivity redundancy on servers. It uses the popular technique of
417N/Aadvertising loopback-hosted virtual addresses using a routing protocol, in
417N/Athis case the OSPF routing protocol.
417N/AThe OSPF-MP feature is meant to be enabled on multihomed servers to
417N/Aimplement an HA solution based on the OSPF protocol. Note that the server's
417N/Ainterfaces *do not require forwarding to be enabled* for the functioning of
417N/Athis feature. The feature does require, though, that
417N/Aip_strict_dst_multihoming not be enabled. The OSPF-MP feature can be
417N/Aachieved by configuring Quagga appropriately on a server.
417N/A | loopback virtual addresses:
417N/A | lo0:1, lo0:2.... lo0:n
417N/A ---------------------------------------
417N/A | server with OSPF-MP feature enabled |
417N/A ---------------------------------------
417N/A ====== subnet A ===== subnet B
417N/A ----------------------------------
417N/A ----------------------------------
417N/ASetting up a Multi-Homed Host with OSPF-MP
417N/A==========================================
417N/A #ifconfig lo0:1 inet plumb 172.16.3.91/32 up
417N/A To have these loopback aliases plumb up across boots, create the
417N/A file would have the following entry:
417N/A 172.16.3.91 netmask 255.255.255.255 up
417N/A2. Copy over the OSPF-MP sample configuration files:
417N/A3 Edit the zebra and ospfd configuration files appropriately
417N/A4. Disable forwarding on your server.
417N/A routeadm -d ipv4-forwarding
417N/A5. Disable IPMP if machine is set up with it. To do this you will
417N/A have to undo all the things you had done to configure IPMP on your
417N/A Product Categories>> Solaris >> Solaris 10
417N/A Solaris 10 System Administration Guide:IP services, Chapter 30
417N/A for configuration details of IPMP.
417N/A6. Enable the OSPF-MP service at boot time, type the following
417N/A # routeadm -s routing-svcs=ospf:quagga -e ipv4-routing -u
417N/A7. Verify that the loopback hosted addresses are being correctly
417N/A advertised by OSPF on the server, use the following snoop command:
417N/A snoop -d <device> -rv ospf
417N/AFollowing is the snoop output on a server that is enabled with OSPF-MP, and
417N/Ais configured with the loopback alias of the example case above:
417N/AETHER: ----- Ether Header -----
417N/AETHER: Packet 8 arrived at 16:23:57.00008
417N/AETHER: Packet size = 82 bytes
417N/AETHER: Destination = 1:0:5e:0:0:5, (multicast)
417N/AETHER: Source = 0:d0:b7:b9:ac:b2,
417N/AETHER: Ethertype = 0800 (IP)
417N/AIP: ----- IP Header -----
417N/AIP: Header length = 20 bytes
417N/AIP: Type of service = 0xc0
417N/AIP: xxx. .... = 6 (precedence)
417N/AIP: ...0 .... = normal delay
417N/AIP: .... 0... = normal throughput
417N/AIP: .... .0.. = normal reliability
417N/AIP: .... ..0. = not ECN capable transport
417N/AIP: .... ...0 = no ECN congestion experienced
417N/AIP: Total length = 68 bytes
417N/AIP: Identification = 41685
417N/AIP: .0.. .... = may fragment
417N/AIP: ..0. .... = last fragment
417N/AIP: Fragment offset = 0 bytes
417N/AIP: Protocol = 89 (OSPF)
417N/AIP: Header checksum = 2ac5
417N/AIP: Source address = 10.1.1.1, 10.1.1.1
417N/AIP: Destination address = 224.0.0.5, 224.0.0.5
417N/AOSPF: ----- OSPF Header -----
417N/AOSPF: Router ID = 10.1.2.1
417N/AOSPF HELLO: ----- Hello Packet -----
417N/AOSPF HELLO: Mask = 255.255.255.0
417N/AOSPF HELLO: Hello interval = 10
417N/AOSPF HELLO: Priority = 1
417N/AOSPF HELLO: Dead interval = 40
417N/AOSPF HELLO: Designated Router = 10.1.1.2
417N/AOSPF HELLO: Backup Designated Router = 10.1.1.1
417N/AOSPF HELLO: Neighbor: 172.16.3.91
417N/AExample configuration case on a server with OSPF-MP feature
417N/A-----------------------------------------------------------
417N/AGiven a server with the following ifconfig output:
417N/Alo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
417N/A inet 127.0.0.1 netmask ff000000
417N/Alo0:1: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
417N/A inet 172.16.3.91 netmask ffffffff
417N/Ahme1: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu
417N/A1500 index 3 inet 10.10.48.91
417N/Anetmask ffffff00 broadcast 10.10.48.255 ether 8:0:20:d9:53:71
417N/Aqfe0: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu 1500 index 4 inet 10.11.48.91
417N/Anetmask ffffff00 broadcast 10.11.48.255 ether 0:3:ba:17:4d:47
417N/AIts ospfd and zebra config files for OSPF-MP would be the following:
417N/A! Zebra configuration saved from vty
417N/A! Zebra configuration saved from vty
417N/A ospf router-id 10.10.48.91
417N/A network 10.10.48.0/24 area 1
417N/A network 10.11.48.0/24 area 1
417N/ATroubleshooting the OSPF-MP Feature
417N/A===================================
417N/AUse the following monitoring and debugging commands on a running
417N/AMonitoring Commands for the ospfd Daemon
417N/A----------------------------------------
417N/A show ip ospf interface [INTERFACE]
417N/ADebug Commands for the ospfd Daemon
417N/A-----------------------------------
417N/A debug ospf ism (status|events|timers)
417N/A debug ospf lsa (generate|flooding|refresh)
417N/A debug ospf nsm (status|events|timers)
417N/A debug ospf packet (hello|dd|ls-request|ls-update|ls-ack|all)
417N/A debug ospf packet (hello|dd|ls-request|ls-update|ls-ack|all) (send|recv)
417N/A debug ospf packet (hello|dd|ls-request|ls-update|ls-ack|all)
417N/A debug ospf zebra (interface|redistribute)
417N/ASimilarly, use the following monitoring and debugging commands on a running
417N/AMonitor Commands for the zebra Daemon
417N/A--------------------------------------
417N/A show interface [IFNAME]
417N/ADebug Commands for the zebra Daemon
417N/A-----------------------------------
417N/A debug zebra packet (recv|send)
417N/A debug zebra packet (recv|send) detail
417N/AFine-tuning the OSPF-MP Feature by Customizing the OSPF Timers
417N/A==============================================================
417N/AUse specific interface level configuration subcommands of Telnet UI
417N/Ato fine-tune the timers of OSPF daemon. To get to the interface level
417N/Aconfiguration mode, type:
417N/A <hostname>#configure terminal
417N/A <hostname>(config)# interface <interface name>
417N/AThe appropriate subcommands to customize the timers are:
417N/A ip ospf dead-interval <1-65535>
417N/A ip ospf hello-interval <1-65535>
417N/A ip ospf retransmit-interval <3-65535>
417N/A ip ospf transmit-delay <1-65535>
417N/AYou can have these new parameters committed to the configuration file by
417N/A <hostname>(config-if)# write file
417N/AFor further details of the above commands, please see the Quagga