From ec8404d84bb2fd348ba5a5c48224245b60e7791e Mon Sep 17 00:00:00 2001 From: Quentin Young Date: Fri, 26 Jan 2018 17:09:25 -0500 Subject: [PATCH] doc: remove some more @stuff{} Signed-off-by: Quentin Young --- doc/user/appendix.rst | 22 +-- doc/user/isisd.rst | 8 +- doc/user/ospf_fundamentals.rst | 95 +++++----- doc/user/ospfd.rst | 3 +- doc/user/rpki.rst | 9 +- doc/user/snmp.rst | 3 +- doc/user/snmptrap.rst | 323 +++++++++++++++++---------------- doc/user/vnc.rst | 7 +- 8 files changed, 227 insertions(+), 243 deletions(-) diff --git a/doc/user/appendix.rst b/doc/user/appendix.rst index e2948312a3..2615123451 100644 --- a/doc/user/appendix.rst +++ b/doc/user/appendix.rst @@ -209,14 +209,14 @@ If 'type' is PROTOCOL_BGP4MP and 'subtype' is BGP4MP_SNAPSHOT:: 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 diff --git a/doc/user/isisd.rst b/doc/user/isisd.rst index 83d7af55b0..7c2012687c 100644 --- a/doc/user/isisd.rst +++ b/doc/user/isisd.rst @@ -5,11 +5,11 @@ ISIS **** :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: diff --git a/doc/user/ospf_fundamentals.rst b/doc/user/ospf_fundamentals.rst index 8651ad0287..c91c2ac8ff 100644 --- a/doc/user/ospf_fundamentals.rst +++ b/doc/user/ospf_fundamentals.rst @@ -9,7 +9,7 @@ OSPF Fundamentals :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. @@ -28,9 +28,9 @@ through to all other routers in a link-state routing domain, by a 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 `_ +:abbr:`SPF (Shortest Path First)` algorithm. .. index:: Link-state routing protocol advantages @@ -57,8 +57,8 @@ link-state area increases, in managing the :abbr:`LSDB` and required 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 --------------- @@ -117,7 +117,7 @@ broadly classed as: *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. @@ -149,7 +149,7 @@ broadly classed as: 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`. @@ -157,7 +157,7 @@ broadly classed as: 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. @@ -176,7 +176,7 @@ All LSAs share a common header with the following information: * Type Different types of :abbr:`LSA`s describe different things in - :abbr:`OSPF`@. Types include: + :abbr:`OSPF`. Types include: * Router LSA * Network LSA @@ -195,10 +195,10 @@ All LSAs share a common header with the following information: 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`. @@ -214,7 +214,7 @@ All LSAs share a common header with the following information: 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 @@ -270,24 +270,17 @@ called :term:`intra-area routes`. 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* @@ -300,8 +293,8 @@ called :term:`intra-area routes`. * 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 @@ -319,23 +312,19 @@ called :term:`intra-area routes`. 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 @@ -424,10 +413,10 @@ are fully adjacent with 192.168.0.49. 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 @@ -437,10 +426,10 @@ links and Network and Router LSAs, etc. etc. 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 @@ -471,7 +460,7 @@ External LSAs 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. diff --git a/doc/user/ospfd.rst b/doc/user/ospfd.rst index da46905e8a..b87f75e138 100644 --- a/doc/user/ospfd.rst +++ b/doc/user/ospfd.rst @@ -89,8 +89,7 @@ Command {no router ospf} {} 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 diff --git a/doc/user/rpki.rst b/doc/user/rpki.rst index c1a62ea859..59cae088a1 100644 --- a/doc/user/rpki.rst +++ b/doc/user/rpki.rst @@ -16,10 +16,9 @@ In combination with a BGP Prefix Origin Validation scheme a router is able 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: @@ -174,7 +173,7 @@ Validating BGP Updates {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. diff --git a/doc/user/snmp.rst b/doc/user/snmp.rst index a315cc127c..9b82cf2967 100644 --- a/doc/user/snmp.rst +++ b/doc/user/snmp.rst @@ -203,5 +203,4 @@ The following syntax is understood by the FRR daemons for configuring SNMP using {Command} {no agentx} {} - @include snmptrap.texi - +.. include:: snmptrap.rst diff --git a/doc/user/snmptrap.rst b/doc/user/snmptrap.rst index dccff057db..28cc5fceca 100644 --- a/doc/user/snmptrap.rst +++ b/doc/user/snmptrap.rst @@ -7,15 +7,17 @@ correctly as described in the frr documentation in :ref:`SNMP_Support`. 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 @@ -25,7 +27,7 @@ Configure the snmptrapd daemon by adding the following line to :: - 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 @@ -40,161 +42,160 @@ The snmptrap_handle.sh script I personally use for handling BGP4 traps 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="" - -# 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="" + + # 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 diff --git a/doc/user/vnc.rst b/doc/user/vnc.rst index 78366713b6..2f87308e86 100644 --- a/doc/user/vnc.rst +++ b/doc/user/vnc.rst @@ -20,11 +20,8 @@ Ethernet/Layer 2 (L2) VNs are supported. 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 -- 2.39.5