The file specified in "File Name" contains all routing entries,
which are in the format of ``subtype == BGP4MP_ENTRY``.
-@example
-Constants:::
-
- /* type value */
- #define MSG_PROTOCOL_BGP4MP 16
- #define MSG_PROTOCOL_BGP4MP_ET 17
- /* subtype value */
- #define BGP4MP_STATE_CHANGE 0
- #define BGP4MP_MESSAGE 1
- #define BGP4MP_ENTRY 2
- #define BGP4MP_SNAPSHOT 3
+::
+ Constants:
+
+ /* type value */
+ #define MSG_PROTOCOL_BGP4MP 16
+ #define MSG_PROTOCOL_BGP4MP_ET 17
+ /* subtype value */
+ #define BGP4MP_STATE_CHANGE 0
+ #define BGP4MP_MESSAGE 1
+ #define BGP4MP_ENTRY 2
+ #define BGP4MP_SNAPSHOT 3
****
:abbr:`ISIS (Intermediate System to Intermediate System)` is a routing protocol
-which is described in @cite{ISO10589, RFC1195, RFC5308}. ISIS is an
+which is described in :t:`ISO10589`, :rfc:`1195`, :rfc:`5308`. ISIS is an
:abbr:`IGP (Interior Gateway Protocol)`. Compared with :abbr:`RIP`,
-:abbr:`ISIS` can provide scalable network support and faster
-convergence times like :abbr:`OSPF`. ISIS is widely used in large networks such as
-:abbr:`ISP (Internet Service Provider)` and carrier backbone networks.
+:abbr:`ISIS` can provide scalable network support and faster convergence times
+like :abbr:`OSPF`. ISIS is widely used in large networks such as :abbr:`ISP
+(Internet Service Provider)` and carrier backbone networks.
.. _Configuring_isisd:
:abbr:`OSPF` is, mostly, a link-state routing protocol. In contrast
to :term:`distance-vector` protocols, such as :abbr:`RIP` or
-:abbr:`BGP`, where routers describe available :term:`paths` (i.e@. routes)
+:abbr:`BGP`, where routers describe available :term:`paths` (i.e. routes)
to each other, in :term:`link-state` protocols routers instead
describe the state of their links to their immediate neighbouring
routers.
process called :term:`flooding`. Each router thus builds up an
:abbr:`LSDB (Link State Database)` of all the link-state messages. From
this collection of LSAs in the LSDB, each router can then calculate the
-shortest path to any other router, based on some common metric, by
-using an algorithm such as @url{http://www.cs.utexas.edu/users/EWD/,
-Edgser Dijkstra}'s :abbr:`SPF (Shortest Path First)`.
+shortest path to any other router, based on some common metric, by using an
+algorithm such as `Edgar Djikstra's <http://www.cs.utexas.edu/users/EWD/>`_
+:abbr:`SPF (Shortest Path First)` algorithm.
.. index:: Link-state routing protocol advantages
flooding.
This section aims to give a distilled, but accurate, description of the
-more important workings of :abbr:`OSPF`@ which an administrator may need
-to know to be able best configure and trouble-shoot :abbr:`OSPF`@.
+more important workings of :abbr:`OSPF` which an administrator may need
+to know to be able best configure and trouble-shoot :abbr:`OSPF`.
OSPF Mechanisms
---------------
*External Routes*
- Routes entirely external to :abbr:`OSPF`@. Routers originating such
+ Routes entirely external to :abbr:`OSPF`. Routers originating such
routes are known as :abbr:`ASBR (Autonomous-System Border Router)`
routers.
Note that only summaries and external routes are passed between areas.
As these describe *paths*, rather than any router link-states,
- routing between areas hence is by :term:`distance-vector`, @strong{not}
+ routing between areas hence is by :term:`distance-vector`, **not**
link-state.
:ref:`OSPF_Areas`.
OSPF LSAs
---------
-:abbr:`LSA`s are the core object in OSPF@. Everything else in OSPF
+:abbr:`LSA`s are the core object in OSPF. Everything else in OSPF
revolves around detecting what to describe in LSAs, when to update
them, how to flood them throughout a network and how to calculate
routes from them.
* Type
Different types of :abbr:`LSA`s describe different things in
- :abbr:`OSPF`@. Types include:
+ :abbr:`OSPF`. Types include:
* Router LSA
* Network LSA
The ID of the LSA, which is typically derived in some way from the
information the LSA describes, e.g. a Router LSA uses the Router ID as
the LSA ID, a Network LSA will have the IP address of the :abbr:`DR`
- as its LSA ID@.
+ as its LSA ID.
The combination of the Type, ID and Advertising Router ID must uniquely
- identify the :abbr:`LSA`@. There can however be multiple instances of
+ identify the :abbr:`LSA`. There can however be multiple instances of
an LSA with the same Type, LSA ID and Advertising Router ID, see
:ref:`OSPF_LSA_sequence_number,,LSA_Sequence_Number`.
Routers may deliberately flood LSAs with the age artificially set to
3600 to indicate an LSA is no longer valid. This is called
- :term:`flushing` of an LSA@.
+ :term:`flushing` of an LSA.
It is not abnormal to see stale LSAs in the LSDB, this can occur where
a router has shutdown without flushing its LSA(s), e.g. where it has
These values depend on the Link Type:
- @multitable @columnfractions .18 .32 .32
- @headitem Link Type @tab Link ID @tab Link Data
-
- * Transit
- @tab Link IP address of the :abbr:`DR`
- @tab Interface IP address
-
- * Point-to-Point
- @tab Router ID of the remote router
- @tab Local interface IP address,
- or the :abbr:`ifindex (MIB-II interface index)`
- for unnumbered links
-
- * Stub
- @tab IP address
- @tab Subnet Mask
-
- @end multitable
+ +----------------+-----------------------------------+------------------------------------------+
+ | Link Type | Link ID | Link Data |
+ +================+===================================+==========================================+
+ | Transit | Link IP address of the :abbr:`DR` | Interface IP address |
+ +----------------+-----------------------------------+------------------------------------------+
+ | Point-to-Point | Router ID of the remote router | Local interface IP address, or the |
+ | | | :abbr:`ifindex (MIB-II interface index)` |
+ | | | for unnumbered links |
+ +----------------+-----------------------------------+------------------------------------------+
+ | Stub | IP address | Subnet Mask |
+ +----------------+-----------------------------------+------------------------------------------+
Links on a router may be listed multiple times in the Router LSA, e.g.
a :abbr:`PtP` interface on which OSPF is enabled must *always*
* Network LSA
- On multi-access links (e.g. ethernets, certain kinds of ATM and X@.25
- configurations), routers elect a :abbr:`DR`@. The :abbr:`DR` is
+ On multi-access links (e.g. ethernets, certain kinds of ATM and X.25
+ configurations), routers elect a :abbr:`DR`. The :abbr:`DR` is
responsible for originating a Network :abbr:`LSA`, which helps reduce
the information needed to describe multi-access networks with multiple
routers attached. The :abbr:`DR` also acts as a hub for the flooding of
Each router fully-adjacent with the :abbr:`DR` is listed in the LSA,
by their Router-ID. This allows the corresponding Router :abbr:`LSA`s to be
- easily retrieved from the :abbr:`LSDB`@.
+ easily retrieved from the :abbr:`LSDB`.
Summary of Link State LSAs:
-@multitable @columnfractions .18 .32 .40
-@headitem LSA Type @tab LSA ID Describes @tab LSA Data Describes
-
-* Router LSA
-@tab The Router ID
-@tab The :abbr:`OSPF` enabled links of the router, within
-a specific link-state area.
-
-* Network LSA
-@tab The IP address of the :abbr:`DR` for the network
-@tab The Subnet Mask of the network, and the Router IDs of all routers
-on the network.
-@end multitable
++-------------+----------------------------+--------------------------------------------+
+| LSA Type | LSA ID | LSA Data Describes |
++=============+============================+============================================+
+| Router LSA | Router ID | The :abbr:`OSPF` enabled links of the |
+| | | router, within a specific link-state area. |
++-------------+----------------------------+--------------------------------------------+
+| Network LSA | The IP address of the | The subet mask of the network and the |
+| | :abbr:`DR` for the network | Router IDs of all routers on the network |
++-------------+----------------------------+--------------------------------------------+
With an LSDB composed of just these two types of :abbr:`LSA`, it is
possible to construct a directed graph of the connectivity between all
Note that from one LSA, you can find the other. E.g. Given the
Network-LSA you have a list of Router IDs on that network, from which
you can then look up, in the local :abbr:`LSDB`, the matching Router
-LSA@. From that Router-LSA you may (potentially) find links to other
+LSA. From that Router-LSA you may (potentially) find links to other
Transit networks and Routers IDs which can be used to lookup the
-corresponding Router or Network LSA@. And in that fashion, one can find
-all the Routers and Networks reachable from that starting :abbr:`LSA`@.
+corresponding Router or Network LSA. And in that fashion, one can find
+all the Routers and Networks reachable from that starting :abbr:`LSA`.
Given the Router LSA instead, you have the IP address of the
:abbr:`DR` of any attached transit links. Network LSAs will have that IP
From just the above two :abbr:`LSA`s, one can already see the
following partial topology:
-::
+::
- --------------------- Network: ......
+ ------------------------ Network: ......
| Designated Router IP: 192.168.1.3
|
IP: 192.168.1.3
External, or "Type 5", :abbr:`LSA`s describe routing information which is
entirely external to :abbr:`OSPF`, and is "injected" into
-:abbr:`OSPF`@. Such routing information may have come from another
+:abbr:`OSPF`. Such routing information may have come from another
routing protocol, such as RIP or BGP, they may represent static routes
or they may represent a default route.
hence are unaffected by this setting (:ref:`OSPF_virtual-link`).
More information regarding the behaviour controlled by this command can
- be found in @cite{RFC 3509, Alternative Implementations of OSPF Area
- Border Routers}, and @cite{draft-ietf-ospf-shortcut-abr-02.txt}.
+ be found in :rfc:`3509`, and :t:`draft-ietf-ospf-shortcut-abr-02.txt`.
Quote: "Though the definition of the :abbr:`ABR (Area Border Router)`
in the OSPF specification does not require a router with multiple
to verify received BGP updates without suffering from cryptographic
complexity.
-The RPKI/RTR protocol is defined in @cite{RFC6810, The Resource Public Key
-Infrastructure (RPKI) to Router Protocol}, and the validation scheme in
-:rfc:`6811`. The current version of Prefix
-Origin Validation in FRR implements both RFCs.
+The RPKI/RTR protocol is defined in :rfc:`6810` and the validation scheme in
+:rfc:`6811`. The current version of Prefix Origin Validation in FRR implements
+both RFCs.
For a more detailed but still easy-to-read background, we suggest the
following two articles:
{Route Map Command} {no match rpki {notfound|invalid|valid}} {}
Create a clause for a route map to match prefixes with the specified RPKI state.
- @strong{Note} that the matching of invalid prefixes requires that invalid
+ **Note** that the matching of invalid prefixes requires that invalid
prefixes are considered for best path selection, i.e., @command{bgp
bestpath prefix-validate disallow-invalid} is not enabled.
{Command} {no agentx} {}
- @include snmptrap.texi
-
+.. include:: snmptrap.rst
The BGP4 mib will send traps on peer up/down events. These should be
visible in your snmp logs with a message similar to:
-.. clicmd:: snmpd[13733]: Got trap from peer on fd 14
+::
+
+ snmpd[13733]: Got trap from peer on fd 14
To react on these traps they should be handled by a trapsink. Configure
your trapsink by adding the following lines to :file:`/etc/snmpd/snmpd.conf`:
::
- # send traps to the snmptrapd on localhost
- trapsink localhost
+ # send traps to the snmptrapd on localhost
+ trapsink localhost
This will send all traps to an snmptrapd running on localhost. You can
::
- traphandle .1.3.6.1.4.1.3317.1.2.2 /etc/snmp/snmptrap_handle.sh
+ traphandle .1.3.6.1.4.1.3317.1.2.2 /etc/snmp/snmptrap_handle.sh
This will use the bash script :file:`/etc/snmp/snmptrap_handle.sh` to handle
is below. You can of course do all sorts of things when handling traps,
like sound a siren, have your display flash, etc., be creative ;).
-@verbatim
-#!/bin/bash
-
-# routers name
-ROUTER=`hostname -s`
-
-#email address use to sent out notification
-EMAILADDR="john@doe.com"
-#email address used (allongside above) where warnings should be sent
-EMAILADDR_WARN="sms-john@doe.com"
-
-# type of notification
-TYPE="Notice"
-
-# local snmp community for getting AS belonging to peer
-COMMUNITY="<community>"
-
-# if a peer address is in $WARN_PEERS a warning should be sent
-WARN_PEERS="192.0.2.1"
-
-# get stdin
-INPUT=`cat -`
-
-# get some vars from stdin
-uptime=`echo $INPUT | cut -d' ' -f5`
-peer=`echo $INPUT | cut -d' ' -f8 | sed -e 's/SNMPv2-SMI::mib-2.15.3.1.14.//g'`
-peerstate=`echo $INPUT | cut -d' ' -f13`
-errorcode=`echo $INPUT | cut -d' ' -f9 | sed -e 's/\\"//g'`
-suberrorcode=`echo $INPUT | cut -d' ' -f10 | sed -e 's/\\"//g'`
-remoteas=`snmpget -v2c -c $COMMUNITY localhost SNMPv2-SMI::mib-2.15.3.1.9.$peer | cut -d' ' -f4`
-
-WHOISINFO=`whois -h whois.ripe.net " -r AS$remoteas" | egrep '(as-name|descr)'`
-asname=`echo "$WHOISINFO" | grep "^as-name:" | sed -e 's/^as-name://g' -e 's/ //g' -e 's/^ //g' | uniq`
-asdescr=`echo "$WHOISINFO" | grep "^descr:" | sed -e 's/^descr://g' -e 's/ //g' -e 's/^ //g' | uniq`
-
-# if peer address is in $WARN_PEER, the email should also
-# be sent to $EMAILADDR_WARN
-for ip in $WARN_PEERS; do
-if [ "x$ip" == "x$peer" ]; then
-EMAILADDR="$EMAILADDR,$EMAILADDR_WARN"
-TYPE="WARNING"
-break
-fi
-done
-
-# convert peer state
-case "$peerstate" in
-1) peerstate="Idle" ;;
-2) peerstate="Connect" ;;
-3) peerstate="Active" ;;
-4) peerstate="Opensent" ;;
-5) peerstate="Openconfirm" ;;
-6) peerstate="Established" ;;
-*) peerstate="Unknown" ;;
-esac
-
-# get textual messages for errors
-case "$errorcode" in
-00)
-error="No error"
-suberror=""
-;;
-01)
-error="Message Header Error"
-case "$suberrorcode" in
-01) suberror="Connection Not Synchronized" ;;
-02) suberror="Bad Message Length" ;;
-03) suberror="Bad Message Type" ;;
-*) suberror="Unknown" ;;
-esac
-;;
-02)
-error="OPEN Message Error"
-case "$suberrorcode" in
-01) suberror="Unsupported Version Number" ;;
-02) suberror="Bad Peer AS" ;;
-03) suberror="Bad BGP Identifier" ;;
-04) suberror="Unsupported Optional Parameter" ;;
-05) suberror="Authentication Failure" ;;
-06) suberror="Unacceptable Hold Time" ;;
-*) suberror="Unknown" ;;
-esac
-;;
-03)
-error="UPDATE Message Error"
-case "$suberrorcode" in
-01) suberror="Malformed Attribute List" ;;
-02) suberror="Unrecognized Well-known Attribute" ;;
-03) suberror="Missing Well-known Attribute" ;;
-04) suberror="Attribute Flags Error" ;;
-05) suberror="Attribute Length Error" ;;
-06) suberror="Invalid ORIGIN Attribute" ;;
-07) suberror="AS Routing Loop" ;;
-08) suberror="Invalid NEXT_HOP Attribute" ;;
-09) suberror="Optional Attribute Error" ;;
-10) suberror="Invalid Network Field" ;;
-11) suberror="Malformed AS_PATH" ;;
-*) suberror="Unknown" ;;
-esac
-;;
-04)
-error="Hold Timer Expired"
-suberror=""
-;;
-05)
-error="Finite State Machine Error"
-suberror=""
-;;
-06)
-error="Cease"
-case "$suberrorcode" in
-01) suberror="Maximum Number of Prefixes Reached" ;;
-02) suberror="Administratively Shutdown" ;;
-03) suberror="Peer Unconfigured" ;;
-04) suberror="Administratively Reset" ;;
-05) suberror="Connection Rejected" ;;
-06) suberror="Other Configuration Change" ;;
-07) suberror="Connection collision resolution" ;;
-08) suberror="Out of Resource" ;;
-09) suberror="MAX" ;;
-*) suberror="Unknown" ;;
-esac
-;;
-*)
-error="Unknown"
-suberror=""
-;;
-esac
-
-# create textual message from errorcodes
-if [ "x$suberror" == "x" ]; then
-NOTIFY="$errorcode ($error)"
-else
-NOTIFY="$errorcode/$suberrorcode ($error/$suberror)"
-fi
-
-# form a decent subject
-SUBJECT="$TYPE: $ROUTER [bgp] $peer is $peerstate: $NOTIFY"
-# create the email body
-MAIL=`cat << EOF
-BGP notification on router $ROUTER.
-
-Peer: $peer
-AS: $remoteas
-New state: $peerstate
-Notification: $NOTIFY
-
-Info:
-$asname
-$asdescr
-
-Snmpd uptime: $uptime
-EOF`
-
-# mail the notification
-echo "$MAIL" | mail -s "$SUBJECT" $EMAILADDR
-@end verbatim
+::
+ #!/bin/bash
+
+ # routers name
+ ROUTER=`hostname -s`
+
+ #email address use to sent out notification
+ EMAILADDR="john@doe.com"
+ #email address used (allongside above) where warnings should be sent
+ EMAILADDR_WARN="sms-john@doe.com"
+
+ # type of notification
+ TYPE="Notice"
+
+ # local snmp community for getting AS belonging to peer
+ COMMUNITY="<community>"
+
+ # if a peer address is in $WARN_PEERS a warning should be sent
+ WARN_PEERS="192.0.2.1"
+
+ # get stdin
+ INPUT=`cat -`
+
+ # get some vars from stdin
+ uptime=`echo $INPUT | cut -d' ' -f5`
+ peer=`echo $INPUT | cut -d' ' -f8 | sed -e 's/SNMPv2-SMI::mib-2.15.3.1.14.//g'`
+ peerstate=`echo $INPUT | cut -d' ' -f13`
+ errorcode=`echo $INPUT | cut -d' ' -f9 | sed -e 's/\\"//g'`
+ suberrorcode=`echo $INPUT | cut -d' ' -f10 | sed -e 's/\\"//g'`
+ remoteas=`snmpget -v2c -c $COMMUNITY localhost SNMPv2-SMI::mib-2.15.3.1.9.$peer | cut -d' ' -f4`
+
+ WHOISINFO=`whois -h whois.ripe.net " -r AS$remoteas" | egrep '(as-name|descr)'`
+ asname=`echo "$WHOISINFO" | grep "^as-name:" | sed -e 's/^as-name://g' -e 's/ //g' -e 's/^ //g' | uniq`
+ asdescr=`echo "$WHOISINFO" | grep "^descr:" | sed -e 's/^descr://g' -e 's/ //g' -e 's/^ //g' | uniq`
+
+ # if peer address is in $WARN_PEER, the email should also
+ # be sent to $EMAILADDR_WARN
+ for ip in $WARN_PEERS; do
+ if [ "x$ip" == "x$peer" ]; then
+ EMAILADDR="$EMAILADDR,$EMAILADDR_WARN"
+ TYPE="WARNING"
+ break
+ fi
+ done
+
+ # convert peer state
+ case "$peerstate" in
+ 1) peerstate="Idle" ;;
+ 2) peerstate="Connect" ;;
+ 3) peerstate="Active" ;;
+ 4) peerstate="Opensent" ;;
+ 5) peerstate="Openconfirm" ;;
+ 6) peerstate="Established" ;;
+ *) peerstate="Unknown" ;;
+ esac
+
+ # get textual messages for errors
+ case "$errorcode" in
+ 00)
+ error="No error"
+ suberror=""
+ ;;
+ 01)
+ error="Message Header Error"
+ case "$suberrorcode" in
+ 01) suberror="Connection Not Synchronized" ;;
+ 02) suberror="Bad Message Length" ;;
+ 03) suberror="Bad Message Type" ;;
+ *) suberror="Unknown" ;;
+ esac
+ ;;
+ 02)
+ error="OPEN Message Error"
+ case "$suberrorcode" in
+ 01) suberror="Unsupported Version Number" ;;
+ 02) suberror="Bad Peer AS" ;;
+ 03) suberror="Bad BGP Identifier" ;;
+ 04) suberror="Unsupported Optional Parameter" ;;
+ 05) suberror="Authentication Failure" ;;
+ 06) suberror="Unacceptable Hold Time" ;;
+ *) suberror="Unknown" ;;
+ esac
+ ;;
+ 03)
+ error="UPDATE Message Error"
+ case "$suberrorcode" in
+ 01) suberror="Malformed Attribute List" ;;
+ 02) suberror="Unrecognized Well-known Attribute" ;;
+ 03) suberror="Missing Well-known Attribute" ;;
+ 04) suberror="Attribute Flags Error" ;;
+ 05) suberror="Attribute Length Error" ;;
+ 06) suberror="Invalid ORIGIN Attribute" ;;
+ 07) suberror="AS Routing Loop" ;;
+ 08) suberror="Invalid NEXT_HOP Attribute" ;;
+ 09) suberror="Optional Attribute Error" ;;
+ 10) suberror="Invalid Network Field" ;;
+ 11) suberror="Malformed AS_PATH" ;;
+ *) suberror="Unknown" ;;
+ esac
+ ;;
+ 04)
+ error="Hold Timer Expired"
+ suberror=""
+ ;;
+ 05)
+ error="Finite State Machine Error"
+ suberror=""
+ ;;
+ 06)
+ error="Cease"
+ case "$suberrorcode" in
+ 01) suberror="Maximum Number of Prefixes Reached" ;;
+ 02) suberror="Administratively Shutdown" ;;
+ 03) suberror="Peer Unconfigured" ;;
+ 04) suberror="Administratively Reset" ;;
+ 05) suberror="Connection Rejected" ;;
+ 06) suberror="Other Configuration Change" ;;
+ 07) suberror="Connection collision resolution" ;;
+ 08) suberror="Out of Resource" ;;
+ 09) suberror="MAX" ;;
+ *) suberror="Unknown" ;;
+ esac
+ ;;
+ *)
+ error="Unknown"
+ suberror=""
+ ;;
+ esac
+
+ # create textual message from errorcodes
+ if [ "x$suberror" == "x" ]; then
+ NOTIFY="$errorcode ($error)"
+ else
+ NOTIFY="$errorcode/$suberrorcode ($error/$suberror)"
+ fi
+
+ # form a decent subject
+ SUBJECT="$TYPE: $ROUTER [bgp] $peer is $peerstate: $NOTIFY"
+ # create the email body
+ MAIL=`cat << EOF
+ BGP notification on router $ROUTER.
+
+ Peer: $peer
+ AS: $remoteas
+ New state: $peerstate
+ Notification: $NOTIFY
+
+ Info:
+ $asname
+ $asdescr
+
+ Snmpd uptime: $uptime
+ EOF`
+
+ # mail the notification
+ echo "$MAIL" | mail -s "$SUBJECT" $EMAILADDR
BGP, with IP VPNs and Tunnel Encapsulation, is used to distribute VN
information between NVAs. BGP based IP VPN support is defined in
:rfc:`4364`, and
-@cite{RFC4659, BGP-MPLS IP Virtual Private Network (VPN) Extension for
-IPv6 VPN }. Both the Encapsulation Subsequent Address Family Identifier
-(SAFI) and the Tunnel Encapsulation Attribute, @cite{RFC5512, The BGP
-Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP
-Tunnel Encapsulation Attribute}, are supported.
+:rfc:`4659`. Both the Encapsulation Subsequent Address Family Identifier
+(SAFI) and the Tunnel Encapsulation Attribute, :rfc:`5512` are supported.
The protocol that is used to communicate routing and Ethernet / Layer 2
(L2) forwarding information between NVAs and NVEs is referred to as the
projects / mirror / frr.git / commitdiff