mirror of
https://git.proxmox.com/git/mirror_frr
synced 2025-08-05 11:30:55 +00:00
Martin Winter
GitHub
commit
aab81a046e
229
doc/Makefile.am
229
doc/Makefile.am
@ -122,138 +122,139 @@ developer-html:
|
||||
|
||||
# dist tarballs want doc sources
|
||||
EXTRA_DIST = frr-sphinx.mk \
|
||||
manpages/defines.rst \
|
||||
manpages/ldpd.rst \
|
||||
manpages/index.rst \
|
||||
manpages/bgpd.rst \
|
||||
manpages/watchfrr.rst \
|
||||
manpages/ospfclient.rst \
|
||||
manpages/ripd.rst \
|
||||
manpages/zebra.rst \
|
||||
manpages/epilogue.rst \
|
||||
manpages/eigrpd.rst \
|
||||
manpages/isisd.rst \
|
||||
manpages/ospf6d.rst \
|
||||
manpages/common-options.rst \
|
||||
manpages/ospfd.rst \
|
||||
manpages/vtysh.rst \
|
||||
manpages/nhrpd.rst \
|
||||
manpages/pimd.rst \
|
||||
manpages/mtracebis.rst \
|
||||
manpages/ripngd.rst \
|
||||
manpages/frr.rst \
|
||||
manpages/conf.py \
|
||||
manpages/defines.rst \
|
||||
manpages/eigrpd.rst \
|
||||
manpages/epilogue.rst \
|
||||
manpages/frr.rst \
|
||||
manpages/index.rst \
|
||||
manpages/isisd.rst \
|
||||
manpages/ldpd.rst \
|
||||
manpages/Makefile \
|
||||
developer/Building_FRR_on_NetBSD7.rst \
|
||||
developer/ldpd-basic-test-setup.md \
|
||||
developer/cli.rst \
|
||||
developer/index.rst \
|
||||
developer/library.rst \
|
||||
developer/memtypes.rst \
|
||||
manpages/mtracebis.rst \
|
||||
manpages/nhrpd.rst \
|
||||
manpages/ospf6d.rst \
|
||||
manpages/ospfclient.rst \
|
||||
manpages/ospfd.rst \
|
||||
manpages/pimd.rst \
|
||||
manpages/ripd.rst \
|
||||
manpages/ripngd.rst \
|
||||
manpages/vtysh.rst \
|
||||
manpages/watchfrr.rst \
|
||||
manpages/zebra.rst \
|
||||
developer/bgpd.rst \
|
||||
developer/draft-zebra-00.ms \
|
||||
developer/dev-modules.md \
|
||||
developer/conf.py \
|
||||
developer/next-hop-tracking.rst \
|
||||
developer/Building_FRR_on_FreeBSD11.rst \
|
||||
developer/bgp-typecodes.rst \
|
||||
developer/building-frr-on-alpine.rst \
|
||||
developer/building-frr-on-centos6.rst \
|
||||
developer/building-frr-on-centos7.rst \
|
||||
developer/building-frr-on-debian8.rst \
|
||||
developer/building-frr-on-debian9.rst \
|
||||
developer/building-frr-on-fedora24.rst \
|
||||
developer/building-frr-on-freebsd10.rst \
|
||||
developer/building-frr-on-freebsd11.rst \
|
||||
developer/building-frr-on-freebsd9.rst \
|
||||
developer/building-frr-on-lede-openwrt.rst \
|
||||
developer/building-frr-on-netbsd6.rst \
|
||||
developer/building-frr-on-netbsd7.rst \
|
||||
developer/building-frr-on-omnios.rst \
|
||||
developer/building-frr-on-openbsd6.rst \
|
||||
developer/building-frr-on-ubuntu1204.rst \
|
||||
developer/building-frr-on-ubuntu1404.rst \
|
||||
developer/building-frr-on-ubuntu1604.rst \
|
||||
developer/building.rst \
|
||||
developer/Building_FRR_on_CentOS6.rst \
|
||||
developer/Building_FRR_on_Ubuntu1604.rst \
|
||||
developer/ospf-api.rst \
|
||||
developer/ospf-sr.rst \
|
||||
developer/Building_FRR_on_OpenBSD6.rst \
|
||||
developer/Building_FRR_on_Debian8.rst \
|
||||
developer/Building_FRR_on_NetBSD6.rst \
|
||||
developer/Building_FRR_on_Debian9.rst \
|
||||
developer/Building_FRR_on_LEDE-OpenWRT.rst \
|
||||
developer/modules.rst \
|
||||
developer/Building_FRR_on_FreeBSD10.rst \
|
||||
developer/Building_FRR_on_Ubuntu1204.rst \
|
||||
developer/Building_FRR_on_Fedora24.rst \
|
||||
developer/Makefile \
|
||||
developer/Building_FRR_on_FreeBSD9.rst \
|
||||
developer/BGP-TypeCode \
|
||||
developer/Building_FRR_on_OmniOS.rst \
|
||||
developer/Building_FRR_on_CentOS7.rst \
|
||||
developer/cli.rst \
|
||||
developer/conf.py \
|
||||
developer/draft-zebra-00.ms \
|
||||
developer/hooks.rst \
|
||||
developer/OSPF-API.md \
|
||||
developer/index.rst \
|
||||
developer/ldpd-basic-test-setup.md \
|
||||
developer/library.rst \
|
||||
developer/Makefile \
|
||||
developer/memtypes.rst \
|
||||
developer/modules.rst \
|
||||
developer/next-hop-tracking.rst \
|
||||
developer/ospf-api.rst \
|
||||
developer/ospf.rst \
|
||||
developer/ospf-sr.rst \
|
||||
developer/workflow.rst \
|
||||
developer/Building_FRR_on_Ubuntu1404.rst \
|
||||
developer/Building_FRR_on_Alpine.rst \
|
||||
user/ospf_fundamentals.rst \
|
||||
user/routemap.rst \
|
||||
user/index.rst \
|
||||
user/conf.py \
|
||||
user/ipv6.rst \
|
||||
user/ripd.rst \
|
||||
user/vnc.rst \
|
||||
user/zebra.rst \
|
||||
user/installation.rst \
|
||||
user/overview.rst \
|
||||
user/protocol.rst \
|
||||
user/eigrpd.rst \
|
||||
user/rpki.rst \
|
||||
user/kernel.rst \
|
||||
user/isisd.rst \
|
||||
user/ospf6d.rst \
|
||||
user/Useful_Sysctl_Settings.md \
|
||||
user/basic.rst \
|
||||
user/ospfd.rst \
|
||||
user/vtysh.rst \
|
||||
user/filter.rst \
|
||||
user/nhrpd.rst \
|
||||
user/Makefile \
|
||||
user/routeserver.rst \
|
||||
developer/zebra.rst \
|
||||
user/appendix.rst \
|
||||
user/bgp.rst \
|
||||
user/babeld.rst \
|
||||
user/snmp.rst \
|
||||
user/pim.rst \
|
||||
user/ripngd.rst \
|
||||
user/snmptrap.rst \
|
||||
user/basic.rst \
|
||||
user/bgp.rst \
|
||||
user/conf.py \
|
||||
user/eigrpd.rst \
|
||||
user/filter.rst \
|
||||
user/glossary.rst \
|
||||
user/index.rst \
|
||||
user/installation.rst \
|
||||
user/ipv6.rst \
|
||||
user/isisd.rst \
|
||||
user/kernel.rst \
|
||||
user/Makefile \
|
||||
user/nhrpd.rst \
|
||||
user/ospf6d.rst \
|
||||
user/ospfd.rst \
|
||||
user/ospf_fundamentals.rst \
|
||||
user/overview.rst \
|
||||
user/pim.rst \
|
||||
user/ripd.rst \
|
||||
user/ripngd.rst \
|
||||
user/routemap.rst \
|
||||
user/routeserver.rst \
|
||||
user/rpki.rst \
|
||||
user/snmp.rst \
|
||||
user/snmptrap.rst \
|
||||
user/Useful_Sysctl_Settings.md \
|
||||
user/vnc.rst \
|
||||
user/vtysh.rst \
|
||||
user/zebra.rst \
|
||||
mpls/ChangeLog.opaque.txt \
|
||||
mpls/ospfd.conf \
|
||||
mpls/cli_summary.txt \
|
||||
mpls/opaque_lsa.txt \
|
||||
figures/frr-logo.png \
|
||||
figures/fig-vnc-commercial-route-reflector.dia \
|
||||
figures/ospf_api_msghdr.png \
|
||||
figures/fig-normal-processing.txt \
|
||||
figures/fig-vnc-gw-rr.txt \
|
||||
figures/fig-vnc-mesh.dia \
|
||||
figures/frr-logo-medium.png \
|
||||
figures/git_branches.svg \
|
||||
figures/fig-vnc-commercial-route-reflector.txt \
|
||||
figures/fig_topologies_rs.txt \
|
||||
figures/git_branches.png \
|
||||
figures/fig-vnc-mesh.txt \
|
||||
figures/ospf_api_msgs1.png \
|
||||
figures/fig-vnc-redundant-route-reflectors.txt \
|
||||
figures/fig-vnc-commercial-route-reflector.png \
|
||||
figures/fig-vnc-gw.png \
|
||||
figures/fig_topologies_rs.png \
|
||||
figures/fig_topologies_full.txt \
|
||||
figures/fig-vnc-frr-route-reflector.txt \
|
||||
figures/cligraph.png \
|
||||
figures/cligraph.svg \
|
||||
figures/fig-normal-processing.dia \
|
||||
figures/fig-vnc-redundant-route-reflectors.png \
|
||||
figures/fig-vnc-frr-route-reflector.dia \
|
||||
figures/fig_topologies_full.png \
|
||||
figures/fig-vnc-redundant-route-reflectors.dia \
|
||||
figures/fig-normal-processing.png \
|
||||
figures/fig-normal-processing.txt \
|
||||
figures/fig-rs-processing.dia \
|
||||
figures/ospf_api_msgs2.png \
|
||||
figures/fig-vnc-gw.dia \
|
||||
figures/fig-rs-processing.txt \
|
||||
figures/frr-logo-icon.png \
|
||||
figures/ospf_api_architecture.png \
|
||||
figures/fig-vnc-gw.txt \
|
||||
figures/fig-rs-processing.png \
|
||||
figures/frr-icon.svg \
|
||||
figures/fig_topologies_rs.dia \
|
||||
figures/fig-vnc-frr-route-reflector.png \
|
||||
figures/fig-vnc-gw-rr.png \
|
||||
figures/fig-vnc-gw-rr.dia \
|
||||
figures/fig-rs-processing.txt \
|
||||
figures/fig_topologies_full.dia \
|
||||
figures/fig_topologies_full.png \
|
||||
figures/fig_topologies_full.txt \
|
||||
figures/fig_topologies_rs.dia \
|
||||
figures/fig_topologies_rs.png \
|
||||
figures/fig_topologies_rs.txt \
|
||||
figures/fig-vnc-commercial-route-reflector.dia \
|
||||
figures/fig-vnc-commercial-route-reflector.png \
|
||||
figures/fig-vnc-commercial-route-reflector.txt \
|
||||
figures/fig-vnc-frr-route-reflector.dia \
|
||||
figures/fig-vnc-frr-route-reflector.png \
|
||||
figures/fig-vnc-frr-route-reflector.txt \
|
||||
figures/fig-vnc-gw.dia \
|
||||
figures/fig-vnc-gw.png \
|
||||
figures/fig-vnc-gw-rr.dia \
|
||||
figures/fig-vnc-gw-rr.png \
|
||||
figures/fig-vnc-gw-rr.txt \
|
||||
figures/fig-vnc-gw.txt \
|
||||
figures/fig-vnc-mesh.dia \
|
||||
figures/fig-vnc-mesh.png \
|
||||
figures/fig-vnc-mesh.txt \
|
||||
figures/fig-vnc-redundant-route-reflectors.dia \
|
||||
figures/fig-vnc-redundant-route-reflectors.png \
|
||||
figures/fig-vnc-redundant-route-reflectors.txt \
|
||||
figures/frr-icon.svg \
|
||||
figures/frr-logo-icon.png \
|
||||
figures/frr-logo-medium.png \
|
||||
figures/frr-logo.png \
|
||||
figures/frr-logo-small.png \
|
||||
figures/fig-vnc-mesh.png
|
||||
figures/git_branches.png \
|
||||
figures/git_branches.svg \
|
||||
figures/ospf_api_architecture.png \
|
||||
figures/ospf_api_msghdr.png \
|
||||
figures/ospf_api_msgs1.png \
|
||||
figures/ospf_api_msgs2.png
|
||||
|
||||
@ -1,24 +0,0 @@
|
||||
|
||||
BGP-4[+] UPDATE Attribute TypeCode list
|
||||
|
||||
Value Attribute References
|
||||
=========================================================================
|
||||
1 ORIGIN [RFC 4271]
|
||||
2 AS_PATH [RFC 4271]
|
||||
3 NEXT_HOP [RFC 4271]
|
||||
4 MULTI_EXIT_DISC [RFC 4271]
|
||||
5 LOCAL_PREF [RFC 4271]
|
||||
6 ATOMIC_AGGREGATE [RFC 4271]
|
||||
7 AGGREGATOR [RFC 4271]
|
||||
8 COMMUNITIES [RFC 1997]
|
||||
9 ORIGINATOR_ID [RFC 4456]
|
||||
10 CLUSTER_LIST [RFC 4456]
|
||||
11 DPA [draft-ietf-idr-bgp-dpa-05.txt(expired)]
|
||||
12 ADVERTISER [RFC 1863]
|
||||
13 RCID_PATH [RFC 1863]
|
||||
14 MP_REACH_NLRI [RFC 4760]
|
||||
15 MP_UNREACH_NLRI [RFC 4760]
|
||||
16 EXT_COMMUNITIES [RFC 4360]
|
||||
17 AS4_PATH [RFC 4893]
|
||||
18 AS4_AGGREGATOR [RFC 4893]
|
||||
=========================================================================
|
||||
@ -1,263 +0,0 @@
|
||||
# OSPF API Documentation
|
||||
|
||||
[TOC]
|
||||
|
||||
## Disclaimer
|
||||
|
||||
The OSPF daemon contains an API for application access to the LSA database. This API was created by Ralph Keller, originally as patch for Zebra. Unfortunately, the page containing documentation of the API is no longer online. This page is an attempt to recreate documentation for the API (with lots of help of the WayBackMachine)
|
||||
|
||||
## 1. Introduction
|
||||
|
||||
This page describes an API that allows external applications to access the link-state database (LSDB) of the OSPF daemon. The implementation is based on the OSPF code from FRRouting (forked from Quagga and formerly Zebra) routing protocol suite and is subject to the GNU General Public License. The OSPF API provides you with the following functionality:
|
||||
|
||||
* Retrieval of the full or partial link-state database of the OSPF daemon. This allows applications to obtain an exact copy of the LSDB including router LSAs, network LSAs and so on. Whenever a new LSA arrives at the OSPF daemon, the API module immediately informs the application by sending a message. This way, the application is always synchronized with the LSDB of the OSPF daemon.
|
||||
* Origination of own opaque LSAs (of type 9, 10, or 11) which are then distributed transparently to other routers within the flooding scope and received by other applications through the OSPF API.
|
||||
|
||||
Opaque LSAs, which are described in RFC 2370 , allow you to distribute application-specific information within a network using the OSPF protocol. The information contained in opaque LSAs is transparent for the routing process but it can be processed by other modules such as traffic engineering (e.g., MPLS-TE).
|
||||
|
||||
## 2. Architecture
|
||||
|
||||
The following picture depicts the architecture of the Quagga/Zebra protocol suite. The OSPF daemon is extended with opaque LSA capabilities and an API for external applications. The OSPF core module executes the OSPF protocol by discovering neighbors and exchanging neighbor state. The opaque module, implemented by Masahiko Endo, provides functions to exchange opaque LSAs between routers. Opaque LSAs can be generated by several modules such as the MPLS-TE module or the API server module. These modules then invoke the opaque module to flood their data to neighbors within the flooding scope.
|
||||
|
||||
The client, which is an application potentially running on a different node than the OSPF daemon, links against the OSPF API client library. This client library establishes a socket connection with the API server module of the OSPF daemon and uses this connection to retrieve LSAs and originate opaque LSAs.
|
||||
|
||||
|
||||
|
||||
The OSPF API server module works like any other internal opaque module (such as the MPLS-TE module), but listens to connections from external applications that want to communicate with the OSPF daemon. The API server module can handle multiple clients concurrently.
|
||||
|
||||
One of the main objectives of the implementation is to make as little changes to the existing Zebra code as possible.
|
||||
|
||||
## 3. Installation & Configuration
|
||||
|
||||
Download FRRouting and unpack
|
||||
|
||||
Configure your frr version (note that --enable-opaque-lsa also enables the ospfapi server and ospfclient).
|
||||
|
||||
```
|
||||
% update-autotools
|
||||
% sh ./configure --enable-opaque-lsa
|
||||
% make
|
||||
|
||||
```
|
||||
|
||||
This should also compile the client library and sample application in ospfclient.
|
||||
|
||||
Make sure that you have enabled opaque LSAs in your configuration. Add the ospf opaque-lsa statement to your ospfd.conf:
|
||||
|
||||
```
|
||||
! -*- ospf -*-
|
||||
!
|
||||
! OSPFd sample configuration file
|
||||
!
|
||||
!
|
||||
hostname xxxxx
|
||||
password xxxxx
|
||||
|
||||
router ospf
|
||||
router-id 10.0.0.1
|
||||
network 10.0.0.1/24 area 1
|
||||
neighbor 10.0.0.2
|
||||
network 10.0.1.2/24 area 1
|
||||
neighbor 10.0.1.1
|
||||
ospf opaque-lsa <============ add this statement!
|
||||
|
||||
```
|
||||
|
||||
## 4. Usage
|
||||
|
||||
In the following we describe how you can use the sample application to originate opaque LSAs. The sample application first registers with the OSPF daemon the opaque type it wants to inject and then waits until the OSPF daemon is ready to accept opaque LSAs of that type. Then the client application originates an opaque LSA, waits 10 seconds and then updates the opaque LSA with new opaque data. After another 20 seconds, the client application deletes the opaque LSA from the LSDB. If the clients terminates unexpectedly, the OSPF API module will remove all the opaque LSAs that the application registered. Since the opaque LSAs are flooded to other routers, we will see the opaque LSAs in all routers according to the flooding scope of the opaque LSA.
|
||||
|
||||
We have a very simple demo setup, just two routers connected with an ATM point-to-point link. Start the modified OSPF daemons on two adjacent routers. First run on msr2:
|
||||
|
||||
```
|
||||
> msr2:/home/keller/ospfapi/zebra/ospfd# ./ospfd -f /usr/local/etc/ospfd.conf
|
||||
```
|
||||
|
||||
And on the neighboring router msr3:
|
||||
|
||||
|
||||
```
|
||||
> msr3:/home/keller/ospfapi/zebra/ospfd# ./ospfd -f /usr/local/etc/ospfd.conf
|
||||
```
|
||||
|
||||
Now the two routers form adjacency and start exchanging their databases. Looking at the OSPF daemon of msr2 (or msr3), you see this:
|
||||
|
||||
```
|
||||
ospfd> show ip ospf database
|
||||
|
||||
OSPF Router with ID (10.0.0.1)
|
||||
|
||||
Router Link States (Area 0.0.0.1)
|
||||
|
||||
Link ID ADV Router Age Seq# CkSum Link count
|
||||
10.0.0.1 10.0.0.1 55 0x80000003 0xc62f 2
|
||||
10.0.0.2 10.0.0.2 55 0x80000003 0xe3e4 3
|
||||
|
||||
Net Link States (Area 0.0.0.1)
|
||||
|
||||
Link ID ADV Router Age Seq# CkSum
|
||||
10.0.0.2 10.0.0.2 60 0x80000001 0x5fcb
|
||||
|
||||
```
|
||||
|
||||
Now we start the sample main application that originates an opaque LSA.
|
||||
|
||||
|
||||
```
|
||||
> cd ospfapi/apiclient
|
||||
> ./main msr2 10 250 20 0.0.0.0 0.0.0.1
|
||||
|
||||
```
|
||||
|
||||
This originates an opaque LSA of type 10 (area local), with opaque type 250 (experimental), opaque id of 20 (chosen arbitrarily), interface address 0.0.0.0 (which is used only for opaque LSAs type 9), and area 0.0.0.1
|
||||
|
||||
Again looking at the OSPF database you see:
|
||||
|
||||
```
|
||||
ospfd> show ip ospf database
|
||||
|
||||
OSPF Router with ID (10.0.0.1)
|
||||
|
||||
Router Link States (Area 0.0.0.1)
|
||||
|
||||
Link ID ADV Router Age Seq# CkSum Link count
|
||||
10.0.0.1 10.0.0.1 437 0x80000003 0xc62f 2
|
||||
10.0.0.2 10.0.0.2 437 0x80000003 0xe3e4 3
|
||||
|
||||
Net Link States (Area 0.0.0.1)
|
||||
|
||||
Link ID ADV Router Age Seq# CkSum
|
||||
10.0.0.2 10.0.0.2 442 0x80000001 0x5fcb
|
||||
|
||||
Area-Local Opaque-LSA (Area 0.0.0.1)
|
||||
|
||||
Opaque-Type/Id ADV Router Age Seq# CkSum
|
||||
250.0.0.20 10.0.0.1 0 0x80000001 0x58a6 <=== opaque LSA
|
||||
|
||||
```
|
||||
|
||||
You can take a closer look at this opaque LSA:
|
||||
|
||||
```
|
||||
ospfd> show ip ospf database opaque-area
|
||||
|
||||
OSPF Router with ID (10.0.0.1)
|
||||
|
||||
|
||||
Area-Local Opaque-LSA (Area 0.0.0.1)
|
||||
|
||||
LS age: 4
|
||||
Options: 66
|
||||
LS Type: Area-Local Opaque-LSA
|
||||
Link State ID: 250.0.0.20 (Area-Local Opaque-Type/ID)
|
||||
Advertising Router: 10.0.0.1
|
||||
LS Seq Number: 80000001
|
||||
Checksum: 0x58a6
|
||||
Length: 24
|
||||
Opaque-Type 250 (Private/Experimental)
|
||||
Opaque-ID 0x14
|
||||
Opaque-Info: 4 octets of data
|
||||
Added using OSPF API: 4 octets of opaque data
|
||||
Opaque data: 1 0 0 0 <==== counter is 1
|
||||
|
||||
```
|
||||
|
||||
Note that the main application updates the opaque LSA after 10 seconds, then it looks as follows:
|
||||
|
||||
```
|
||||
ospfd> show ip ospf database opaque-area
|
||||
|
||||
OSPF Router with ID (10.0.0.1)
|
||||
|
||||
|
||||
Area-Local Opaque-LSA (Area 0.0.0.1)
|
||||
|
||||
LS age: 1
|
||||
Options: 66
|
||||
LS Type: Area-Local Opaque-LSA
|
||||
Link State ID: 250.0.0.20 (Area-Local Opaque-Type/ID)
|
||||
Advertising Router: 10.0.0.1
|
||||
LS Seq Number: 80000002
|
||||
Checksum: 0x59a3
|
||||
Length: 24
|
||||
Opaque-Type 250 (Private/Experimental)
|
||||
Opaque-ID 0x14
|
||||
Opaque-Info: 4 octets of data
|
||||
Added using OSPF API: 4 octets of opaque data
|
||||
Opaque data: 2 0 0 0 <==== counter is now 2
|
||||
|
||||
```
|
||||
|
||||
Note that the payload of the opaque LSA has changed as you can see above.
|
||||
|
||||
Then, again after another 20 seconds, the opaque LSA is flushed from the LSDB.
|
||||
|
||||
#### Important note:
|
||||
|
||||
In order to originate an opaque LSA, there must be at least one active opaque-capable neighbor. Thus, you cannot originate opaque LSAs of no neighbors are present. If you try to originate even so no neighbor is ready, you will receive a not ready error message. The reason for this restriction is that it might be possible that some routers have an identical opaque LSA from a previous origination in their LSDB that unfortunately could not be flushed due to a crash, and now if the router comes up again and starts originating a new opaque LSA, the new opaque LSA is considered older since it has a lower sequence number and is ignored by other routers (that consider the stalled opaque LSA as more recent). However, if the originating router first synchronizes the database before originating opaque LSAs, it will detect the older opaque LSA and can flush it first.
|
||||
|
||||
|
||||
## 5. Protocol and Message Formats
|
||||
|
||||
If you are developing your own client application and you don't want to make use of the client library (due to the GNU license restriction or whatever reason), you can implement your own client-side message handling. The OSPF API uses two connections between the client and the OSPF API server: One connection is used for a synchronous request /reply protocol and another connection is used for asynchronous notifications (e.g., LSA update, neighbor status change).
|
||||
|
||||
Each message begins with the following header:
|
||||
|
||||
|
||||
|
||||
The message type field can take one of the following values:
|
||||
|
||||
Messages to OSPF deamon | Value
|
||||
----------------------- | -----
|
||||
MSG_REGISTER_OPAQUETYPE | 1
|
||||
MSG_UNREGISTER_OPAQUETYPE | 2
|
||||
MSG_REGISTER_EVENT | 3
|
||||
MSG_SYNC_LSDB | 4
|
||||
MSG_ORIGINATE_REQUEST | 5
|
||||
MSG_DELETE_REQUEST | 6
|
||||
|
||||
Messages from OSPF deamon | Value
|
||||
------------------------- | -----
|
||||
MSG_REPLY | 10
|
||||
MSG_READY_NOTIFY | 11
|
||||
MSG_LSA_UPDATE_NOTIFY | 12
|
||||
MSG_LSA_DELETE_NOTIFY | 13
|
||||
MSG_NEW_IF | 14
|
||||
MSG_DEL_IF | 15
|
||||
MSG_ISM_CHANGE | 16
|
||||
MSG_NSM_CHANGE | 17
|
||||
|
||||
The synchronous requests and replies have the following message formats:
|
||||
|
||||
|
||||
|
||||
The origin field allows to select according to the following types of origins:
|
||||
|
||||
Origin | Value
|
||||
------ | -----
|
||||
NON_SELF_ORIGINATED | 0
|
||||
SELF_ORIGINATED | 1
|
||||
ANY_ORIGIN | 2
|
||||
|
||||
The reply message has on of the following error codes:
|
||||
|
||||
Error code | Value
|
||||
---------- | -----
|
||||
API_OK | 0
|
||||
API_NOSUCHINTERFACE | -1
|
||||
API_NOSUCHAREA | -2
|
||||
API_NOSUCHLSA | -3
|
||||
API_ILLEGALSATYPE | -4
|
||||
API_ILLEGALOPAQUETYPE | -5
|
||||
API_OPAQUETYPEINUSE | -6
|
||||
API_NOMEMORY | -7
|
||||
API_ERROR | -99
|
||||
API_UNDEF | -100
|
||||
|
||||
The asynchronous notifications have the following message formats:
|
||||
|
||||
|
||||
|
||||
## 6. Original Acknowledgments from Ralph Keller
|
||||
|
||||
I would like to thank Masahiko Endo, the author of the opaque LSA extension module, for his great support. His wonderful ASCII graphs explaining the internal workings of this code, and his invaluable input proved to be crucial in designing a useful API for accessing the link state database of the OSPF daemon. Once, he even decided to take the plane from Tokyo to Zurich so that we could actually meet and have face-to-face discussions, which was a lot of fun. Clearly, without Masahiko no API would ever be completed. I also would like to thank Daniel Bauer who wrote an opaque LSA implementation too and was willing to test the OSPF API code in one of his projects.
|
||||
28
doc/developer/bgp-typecodes.rst
Normal file
28
doc/developer/bgp-typecodes.rst
Normal file
@ -0,0 +1,28 @@
|
||||
BGP-4[+] UPDATE Attribute Preprocessor Constants
|
||||
================================================
|
||||
|
||||
This is a list of preprocessor constants that map to BGP attributes defined by
|
||||
various BGP RFCs. In the code these are defined as BGP_ATTR_<ATTR>.
|
||||
|
||||
+-------+------------------+------------------------------------------+
|
||||
| Value | Attribute | References |
|
||||
+=======+==================+==========================================+
|
||||
| 1 | ORIGIN | [RFC 4271] |
|
||||
| 2 | AS_PATH | [RFC 4271] |
|
||||
| 3 | NEXT_HOP | [RFC 4271] |
|
||||
| 4 | MULTI_EXIT_DISC | [RFC 4271] |
|
||||
| 5 | LOCAL_PREF | [RFC 4271] |
|
||||
| 6 | ATOMIC_AGGREGATE | [RFC 4271] |
|
||||
| 7 | AGGREGATOR | [RFC 4271] |
|
||||
| 8 | COMMUNITIES | [RFC 1997] |
|
||||
| 9 | ORIGINATOR_ID | [RFC 4456] |
|
||||
| 10 | CLUSTER_LIST | [RFC 4456] |
|
||||
| 11 | DPA | [draft-ietf-idr-bgp-dpa-05.txt(expired)] |
|
||||
| 12 | ADVERTISER | [RFC 1863] |
|
||||
| 13 | RCID_PATH | [RFC 1863] |
|
||||
| 14 | MP_REACH_NLRI | [RFC 4760] |
|
||||
| 15 | MP_UNREACH_NLRI | [RFC 4760] |
|
||||
| 16 | EXT_COMMUNITIES | [RFC 4360] |
|
||||
| 17 | AS4_PATH | [RFC 4893] |
|
||||
| 18 | AS4_AGGREGATOR | [RFC 4893] |
|
||||
+-------+------------------+------------------------------------------+
|
||||
@ -1,8 +1,11 @@
|
||||
.. _bgpd:
|
||||
|
||||
****
|
||||
BGPD
|
||||
=========================
|
||||
****
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
next-hop-tracking
|
||||
|
||||
bgp-typecodes
|
||||
|
||||
@ -6,42 +6,54 @@ For building Alpine Linux dev packages, we use docker.
|
||||
Install docker 17.05 or later
|
||||
-----------------------------
|
||||
|
||||
Depending on your host, there are different ways of installing
|
||||
docker. Refer to the documentation here for instructions on how
|
||||
to install a free version of docker: https://www.docker.com/community-edition
|
||||
Depending on your host, there are different ways of installing docker. Refer
|
||||
to the documentation here for instructions on how to install a free version of
|
||||
docker: https://www.docker.com/community-edition
|
||||
|
||||
Work with sources
|
||||
-----------------
|
||||
|
||||
git clone https://github.com/frrouting/frr.git frr
|
||||
cd frr
|
||||
::
|
||||
|
||||
git clone https://github.com/frrouting/frr.git frr
|
||||
cd frr
|
||||
|
||||
Build apk packages
|
||||
------------------
|
||||
|
||||
./docker/alpine/build.sh
|
||||
::
|
||||
|
||||
./docker/alpine/build.sh
|
||||
|
||||
This will put the apk packages in:
|
||||
|
||||
./docker/pkgs/apk/x86_64/
|
||||
::
|
||||
|
||||
./docker/pkgs/apk/x86_64/
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
||||
To add the packages to a docker image, create a Dockerfile in ./docker/pkgs:
|
||||
|
||||
FROM alpine:3.7
|
||||
RUN mkdir -p /pkgs
|
||||
ADD apk/ /pkgs/
|
||||
RUN apk add --no-cache --allow-untrusted /pkgs/x86_64/*.apk
|
||||
::
|
||||
|
||||
FROM alpine:3.7
|
||||
RUN mkdir -p /pkgs
|
||||
ADD apk/ /pkgs/
|
||||
RUN apk add --no-cache --allow-untrusted /pkgs/x86_64/*.apk
|
||||
|
||||
And build a docker image:
|
||||
|
||||
docker build --rm --force-rm -t alpine-dev-pkgs:latest docker/pkgs
|
||||
::
|
||||
|
||||
docker build --rm --force-rm -t alpine-dev-pkgs:latest docker/pkgs
|
||||
|
||||
And run the image:
|
||||
|
||||
docker run -it --rm alpine-dev-pkgs:latest /bin/sh
|
||||
::
|
||||
|
||||
docker run -it --rm alpine-dev-pkgs:latest /bin/sh
|
||||
|
||||
Currently, we only package the raw daemons and example files, so, you'll
|
||||
need to run the daemons by hand (or, better, orchestrate in the Dockerfile).
|
||||
@ -4,20 +4,20 @@ Building FRR
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
Building_FRR_on_LEDE-OpenWRT
|
||||
Building_FRR_on_Alpine
|
||||
Building_FRR_on_CentOS6
|
||||
Building_FRR_on_CentOS7
|
||||
Building_FRR_on_Debian8
|
||||
Building_FRR_on_Debian9
|
||||
Building_FRR_on_Fedora24
|
||||
Building_FRR_on_FreeBSD10
|
||||
Building_FRR_on_FreeBSD11
|
||||
Building_FRR_on_FreeBSD9
|
||||
Building_FRR_on_NetBSD6
|
||||
Building_FRR_on_NetBSD7
|
||||
Building_FRR_on_OmniOS
|
||||
Building_FRR_on_OpenBSD6
|
||||
Building_FRR_on_Ubuntu1204
|
||||
Building_FRR_on_Ubuntu1404
|
||||
Building_FRR_on_Ubuntu1604
|
||||
building-frr-on-lede-openwrt
|
||||
building-frr-on-alpine
|
||||
building-frr-on-centos6
|
||||
building-frr-on-centos7
|
||||
building-frr-on-debian8
|
||||
building-frr-on-debian9
|
||||
building-frr-on-fedora24
|
||||
building-frr-on-freebsd10
|
||||
building-frr-on-freebsd11
|
||||
building-frr-on-freebsd9
|
||||
building-frr-on-netbsd6
|
||||
building-frr-on-netbsd7
|
||||
building-frr-on-omnios
|
||||
building-frr-on-openbsd6
|
||||
building-frr-on-ubuntu1204
|
||||
building-frr-on-ubuntu1404
|
||||
building-frr-on-ubuntu1604
|
||||
|
||||
@ -457,7 +457,7 @@ As a working example, here is the graph of the following command: ::
|
||||
|
||||
show [ip] bgp neighbors [<A.B.C.D|X:X::X:X|WORD>] [json]
|
||||
|
||||
.. figure:: ../figures/cligraph.svg
|
||||
.. figure:: ../figures/cligraph.png
|
||||
:align: center
|
||||
|
||||
Graph of example CLI command
|
||||
|
||||
@ -1,119 +0,0 @@
|
||||
# Module and Hook support (developer docs)
|
||||
|
||||
## What it does
|
||||
|
||||
It uses `dlopen()` to load DSOs at startup.
|
||||
|
||||
|
||||
## Limitations
|
||||
|
||||
* can't load, unload, or reload during runtime. This just needs some work
|
||||
and can probably be done in the future.
|
||||
* doesn't fix any of the "things need to be changed in the code in the library"
|
||||
issues. Most prominently, you can't add a CLI node because CLI nodes are
|
||||
listed in the library...
|
||||
* if your module crashes, the daemon crashes. Should be obvious.
|
||||
* **does not provide a stable API or ABI**. Your module must match a version
|
||||
of FRR and you may have to update it frequently to match changes.
|
||||
* **does not create a license boundary**. Your module will need to link
|
||||
libzebra and include header files from the daemons, meaning it will be
|
||||
GPL-encumbered.
|
||||
|
||||
|
||||
## Installation
|
||||
|
||||
Look for `moduledir` in `configure.ac`, default is normally
|
||||
`/usr/lib64/frr/modules` but depends on `--libdir` / `--prefix`.
|
||||
|
||||
The daemon's name is prepended when looking for a module, e.g. "snmp" tries
|
||||
to find "zebra_snmp" first when used in zebra. This is just to make it nicer
|
||||
for the user, with the snmp module having the same name everywhere.
|
||||
|
||||
Modules can be packaged separately from FRR. The SNMP and FPM modules are
|
||||
good candidates for this because they have dependencies (net-snmp / protobuf)
|
||||
that are not FRR dependencies. However, any distro packages should have an
|
||||
"exact-match" dependency onto the FRR package. Using a module from a
|
||||
different FRR version will probably blow up nicely.
|
||||
|
||||
For snapcraft (and during development), modules can be loaded with full path
|
||||
(e.g. -M `$SNAP/lib/frr/modules/zebra_snmp.so`). Note that libtool puts output
|
||||
files in the .libs directory, so during development you have to use
|
||||
`./zebra -M .libs/zebra_snmp.so`.
|
||||
|
||||
|
||||
## Creating a module
|
||||
|
||||
... best to look at the existing SNMP or FPM modules.
|
||||
|
||||
Basic boilerplate:
|
||||
|
||||
```
|
||||
#include "hook.h"
|
||||
#include "module.h"
|
||||
|
||||
static int
|
||||
module_init (void)
|
||||
{
|
||||
hook_register(frr_late_init, module_late_init);
|
||||
return 0;
|
||||
}
|
||||
|
||||
FRR_MODULE_SETUP(
|
||||
.name = "my module",
|
||||
.version = "0.0",
|
||||
.description = "my module",
|
||||
.init = module_init,
|
||||
)
|
||||
```
|
||||
|
||||
The `frr_late_init` hook will be called after the daemon has finished its
|
||||
other startup and is about to enter the main event loop; this is the best
|
||||
place for most initialisation.
|
||||
|
||||
|
||||
## Compiler & Linker magic
|
||||
|
||||
There's a `THIS_MODULE` (like in the Linux kernel), which uses `visibility`
|
||||
attributes to restrict it to the current module. If you get a linker error
|
||||
with `_frrmod_this_module`, there is some linker SNAFU. This shouldn't be
|
||||
possible, though one way to get it would be to not include libzebra (which
|
||||
provides a fallback definition for the symbol).
|
||||
|
||||
libzebra and the daemons each have their own `THIS_MODULE`, as do all loadable
|
||||
modules. In any other libraries (e.g. `libfrrsnmp`), `THIS_MODULE` will use
|
||||
the definition in libzebra; same applies if the main executable doesn't use
|
||||
`FRR_DAEMON_INFO` (e.g. all testcases).
|
||||
|
||||
The deciding factor here is "what dynamic linker unit are you using the symbol
|
||||
from." If you're in a library function and want to know who called you, you
|
||||
can't use `THIS_MODULE` (because that'll just tell you you're in the library).
|
||||
Put a macro around your function that adds `THIS_MODULE` in the *caller's
|
||||
code calling your function*.
|
||||
|
||||
The idea is to use this in the future for module unloading. Hooks already
|
||||
remember which module they were installed by, as groundwork for a function
|
||||
that removes all of a module's installed hooks.
|
||||
|
||||
There's also the `frr_module` symbol in modules, pretty much a standard entry
|
||||
point for loadable modules.
|
||||
|
||||
|
||||
## Hooks
|
||||
|
||||
Hooks are just points in the code where you can register your callback to
|
||||
be called. The parameter list is specific to the hook point. Since there is
|
||||
no stable API, the hook code has some extra type safety checks making sure
|
||||
you get a compiler warning when the hook parameter list doesn't match your
|
||||
callback. Don't ignore these warnings.
|
||||
|
||||
|
||||
## Relation to MTYPE macros
|
||||
|
||||
The MTYPE macros, while primarily designed to decouple MTYPEs from the library
|
||||
and beautify the code, also work very nicely with loadable modules -- both
|
||||
constructors and destructors are executed when loading/unloading modules.
|
||||
|
||||
This means there is absolutely no change required to MTYPEs, you can just use
|
||||
them in a module and they will even clean up themselves when we implement
|
||||
module unloading and an unload happens. In fact, it's impossible to create
|
||||
a bug where unloading fails to de-register a MTYPE.
|
||||
@ -5,9 +5,8 @@ Welcome to FRR's documentation!
|
||||
:maxdepth: 2
|
||||
|
||||
workflow
|
||||
building
|
||||
library
|
||||
bgpd
|
||||
building
|
||||
ospf-api
|
||||
ospf-sr
|
||||
|
||||
ospf
|
||||
zebra
|
||||
|
||||
12
doc/developer/ospf.rst
Normal file
12
doc/developer/ospf.rst
Normal file
@ -0,0 +1,12 @@
|
||||
.. _ospfd:
|
||||
|
||||
*****
|
||||
OSPFD
|
||||
*****
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
ospf-api
|
||||
ospf-sr
|
||||
|
||||
@ -1,8 +1,10 @@
|
||||
.. _zebra-protocol:
|
||||
.. _zebra:
|
||||
|
||||
**************
|
||||
Zebra Protocol
|
||||
**************
|
||||
*****
|
||||
Zebra
|
||||
*****
|
||||
|
||||
.. _zebra-protocol:
|
||||
|
||||
Overview of the Zebra Protocol
|
||||
==============================
|
||||
BIN
doc/figures/cligraph.png
Normal file
BIN
doc/figures/cligraph.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 40 KiB |
426
doc/user/bgp.rst
426
doc/user/bgp.rst
@ -100,75 +100,59 @@ BGP decision process
|
||||
|
||||
The decision process FRR BGP uses to select routes is as follows:
|
||||
|
||||
1. Weight check
|
||||
|
||||
|
||||
1. *Weight check*
|
||||
Prefer higher local weight routes to lower routes.
|
||||
|
||||
2. Local preference check
|
||||
|
||||
|
||||
2. *Local preference check*
|
||||
Prefer higher local preference routes to lower.
|
||||
|
||||
3. Local route check
|
||||
|
||||
3. *Local route check*
|
||||
Prefer local routes (statics, aggregates, redistributed) to received routes.
|
||||
|
||||
4. AS path length check
|
||||
|
||||
4. *AS path length check*
|
||||
Prefer shortest hop-count AS_PATHs.
|
||||
|
||||
5. Origin check
|
||||
|
||||
5. *Origin check*
|
||||
Prefer the lowest origin type route. That is, prefer IGP origin routes to
|
||||
EGP, to Incomplete routes.
|
||||
|
||||
6. MED check
|
||||
|
||||
6. *MED check*
|
||||
Where routes with a MED were received from the same AS, prefer the route
|
||||
with the lowest MED. :ref:`bgp-med`.
|
||||
|
||||
7. External check
|
||||
|
||||
7. *External check*
|
||||
Prefer the route received from an external, eBGP peer over routes received
|
||||
from other types of peers.
|
||||
|
||||
8. IGP cost check
|
||||
|
||||
8. *IGP cost check*
|
||||
Prefer the route with the lower IGP cost.
|
||||
|
||||
9. Multi-path check
|
||||
|
||||
9. *Multi-path check*
|
||||
If multi-pathing is enabled, then check whether the routes not yet
|
||||
distinguished in preference may be considered equal. If
|
||||
:clicmd:`bgp bestpath as-path multipath-relax` is set, all such routes are
|
||||
considered equal, otherwise routes received via iBGP with identical AS_PATHs
|
||||
or routes received from eBGP neighbours in the same AS are considered equal.
|
||||
|
||||
10. Already-selected external check
|
||||
|
||||
10. *Already-selected external check*
|
||||
Where both routes were received from eBGP peers, then prefer the route
|
||||
which is already selected. Note that this check is not applied if
|
||||
:clicmd:`bgp bestpath compare-routerid` is configured. This check can
|
||||
prevent some cases of oscillation.
|
||||
|
||||
11. Router-ID check
|
||||
|
||||
11. *Router-ID check*
|
||||
Prefer the route with the lowest `router-ID`. If the route has an
|
||||
`ORIGINATOR_ID` attribute, through iBGP reflection, then that router ID is
|
||||
used, otherwise the `router-ID` of the peer the route was received from is
|
||||
used.
|
||||
|
||||
12. Cluster-List length check
|
||||
|
||||
12. *Cluster-List length check*
|
||||
The route with the shortest cluster-list length is used. The cluster-list
|
||||
reflects the iBGP reflection path the route has taken.
|
||||
|
||||
|
||||
13. Peer address
|
||||
|
||||
Prefer the route received from the peer with the higher
|
||||
transport layer address, as a last-resort tie-breaker.
|
||||
13. *Peer address*
|
||||
Prefer the route received from the peer with the higher transport layer
|
||||
address, as a last-resort tie-breaker.
|
||||
|
||||
|
||||
.. index:: bgp bestpath as-path confed
|
||||
@ -213,10 +197,8 @@ BGP route flap dampening
|
||||
|
||||
.. clicmd:: bgp dampening (1-45) (1-20000) (1-20000) (1-255)
|
||||
|
||||
|
||||
This command enables BGP route-flap dampening and specifies dampening parameters.
|
||||
|
||||
|
||||
half-life
|
||||
Half-life time for the penalty
|
||||
|
||||
@ -675,13 +657,12 @@ required.
|
||||
.. index:: neighbor PEER version VERSION
|
||||
.. clicmd:: neighbor PEER version VERSION
|
||||
|
||||
Set up the neighbor's BGP version. `version` can be `4`,
|
||||
`4+` or `4-`. BGP version `4` is the default value used for
|
||||
BGP peering. BGP version `4+` means that the neighbor supports
|
||||
Multiprotocol Extensions for BGP-4. BGP version `4-` is similar but
|
||||
the neighbor speaks the old Internet-Draft revision 00's Multiprotocol
|
||||
Extensions for BGP-4. Some routing software is still using this
|
||||
version.
|
||||
Set up the neighbor's BGP version. `version` can be `4`, `4+` or `4-`. BGP
|
||||
version `4` is the default value used for BGP peering. BGP version `4+`
|
||||
means that the neighbor supports Multiprotocol Extensions for BGP-4. BGP
|
||||
version `4-` is similar but the neighbor speaks the old Internet-Draft
|
||||
revision 00's Multiprotocol Extensions for BGP-4. Some routing software is
|
||||
still using this version.
|
||||
|
||||
.. index:: neighbor PEER interface IFNAME
|
||||
.. clicmd:: neighbor PEER interface IFNAME
|
||||
@ -733,9 +714,9 @@ required.
|
||||
.. index:: no neighbor PEER default-originate
|
||||
.. clicmd:: no neighbor PEER default-originate
|
||||
|
||||
*bgpd*'s default is to not announce the default route (0.0.0.0/0) even it
|
||||
is in routing table. When you want to announce default routes to the
|
||||
peer, use this command.
|
||||
*bgpd*'s default is to not announce the default route (0.0.0.0/0) even if it
|
||||
is in routing table. When you want to announce default routes to the peer,
|
||||
use this command.
|
||||
|
||||
.. index:: neighbor PEER port PORT
|
||||
.. clicmd:: neighbor PEER port PORT
|
||||
@ -1351,23 +1332,22 @@ Lists.
|
||||
.. index:: ip extcommunity-list standard NAME permit|deny EXTCOMMUNITY
|
||||
.. clicmd:: ip extcommunity-list standard NAME permit|deny EXTCOMMUNITY
|
||||
|
||||
This command defines a new standard extcommunity-list.
|
||||
`extcommunity` is extended communities value. The
|
||||
`extcommunity` is compiled into extended community structure. We
|
||||
can define multiple extcommunity-list under same name. In that case
|
||||
match will happen user defined order. Once the extcommunity-list
|
||||
matches to extended communities attribute in BGP updates it return
|
||||
permit or deny based upon the extcommunity-list definition. When
|
||||
there is no matched entry, deny will be returned. When
|
||||
`extcommunity` is empty it matches to any routes.
|
||||
This command defines a new standard extcommunity-list. `extcommunity` is
|
||||
extended communities value. The `extcommunity` is compiled into extended
|
||||
community structure. We can define multiple extcommunity-list under same
|
||||
name. In that case match will happen user defined order. Once the
|
||||
extcommunity-list matches to extended communities attribute in BGP updates
|
||||
it return permit or deny based upon the extcommunity-list definition. When
|
||||
there is no matched entry, deny will be returned. When `extcommunity` is
|
||||
empty it matches to any routes.
|
||||
|
||||
.. index:: ip extcommunity-list expanded NAME permit|deny LINE
|
||||
.. clicmd:: ip extcommunity-list expanded NAME permit|deny LINE
|
||||
|
||||
This command defines a new expanded extcommunity-list. `line` is
|
||||
a string expression of extended communities attribute. `line` can
|
||||
be a regular expression (:ref:`bgp-regular-expressions`) to match an
|
||||
extended communities attribute in BGP updates.
|
||||
This command defines a new expanded extcommunity-list. `line` is a string
|
||||
expression of extended communities attribute. `line` can be a regular
|
||||
expression (:ref:`bgp-regular-expressions`) to match an extended communities
|
||||
attribute in BGP updates.
|
||||
|
||||
.. index:: no ip extcommunity-list NAME
|
||||
.. clicmd:: no ip extcommunity-list NAME
|
||||
@ -1378,10 +1358,9 @@ Lists.
|
||||
.. index:: no ip extcommunity-list expanded NAME
|
||||
.. clicmd:: no ip extcommunity-list expanded NAME
|
||||
|
||||
These commands delete extended community lists specified by
|
||||
`name`. All of extended community lists shares a single name
|
||||
space. So extended community lists can be removed simpley specifying
|
||||
the name.
|
||||
These commands delete extended community lists specified by `name`. All of
|
||||
extended community lists shares a single name space. So extended community
|
||||
lists can be removed simpley specifying the name.
|
||||
|
||||
.. index:: show ip extcommunity-list
|
||||
.. clicmd:: show ip extcommunity-list
|
||||
@ -1389,8 +1368,8 @@ Lists.
|
||||
.. index:: show ip extcommunity-list NAME
|
||||
.. clicmd:: show ip extcommunity-list NAME
|
||||
|
||||
This command displays current extcommunity-list information. When
|
||||
`name` is specified the community list's information is shown.
|
||||
This command displays current extcommunity-list information. When `name` is
|
||||
specified the community list's information is shown.
|
||||
|
||||
::
|
||||
|
||||
@ -1456,23 +1435,22 @@ Two types of large community lists are supported, namely `standard` and
|
||||
.. index:: ip large-community-list standard NAME permit|deny LARGE-COMMUNITY
|
||||
.. clicmd:: ip large-community-list standard NAME permit|deny LARGE-COMMUNITY
|
||||
|
||||
This command defines a new standard large-community-list.
|
||||
`large-community` is the Large Community value. We
|
||||
can add multiple large communities under same name. In that case
|
||||
the match will happen in the user defined order. Once the large-community-list
|
||||
matches the Large Communities attribute in BGP updates it will return
|
||||
permit or deny based upon the large-community-list definition. When
|
||||
there is no matched entry, a deny will be returned. When `large-community`
|
||||
is empty it matches any routes.
|
||||
This command defines a new standard large-community-list. `large-community`
|
||||
is the Large Community value. We can add multiple large communities under
|
||||
same name. In that case the match will happen in the user defined order.
|
||||
Once the large-community-list matches the Large Communities attribute in BGP
|
||||
updates it will return permit or deny based upon the large-community-list
|
||||
definition. When there is no matched entry, a deny will be returned. When
|
||||
`large-community` is empty it matches any routes.
|
||||
|
||||
.. index:: ip large-community-list expanded NAME permit|deny LINE
|
||||
.. clicmd:: ip large-community-list expanded NAME permit|deny LINE
|
||||
|
||||
This command defines a new expanded large-community-list. Where `line` is
|
||||
a string matching expression, it will be compared to the entire Large Communities
|
||||
attribute as a string, with each large-community in order from lowest to highest.
|
||||
`line` can also be a regular expression which matches this Large
|
||||
Community attribute.
|
||||
This command defines a new expanded large-community-list. Where `line` is a
|
||||
string matching expression, it will be compared to the entire Large
|
||||
Communities attribute as a string, with each large-community in order from
|
||||
lowest to highest. `line` can also be a regular expression which matches
|
||||
this Large Community attribute.
|
||||
|
||||
.. index:: no ip large-community-list NAME
|
||||
.. clicmd:: no ip large-community-list NAME
|
||||
@ -1483,9 +1461,9 @@ Two types of large community lists are supported, namely `standard` and
|
||||
.. index:: no ip large-community-list expanded NAME
|
||||
.. clicmd:: no ip large-community-list expanded NAME
|
||||
|
||||
These commands delete Large Community lists specified by
|
||||
`name`. All Large Community lists share a single namespace.
|
||||
This means Large Community lists can be removed by simply specifying the name.
|
||||
These commands delete Large Community lists specified by `name`. All Large
|
||||
Community lists share a single namespace. This means Large Community lists
|
||||
can be removed by simply specifying the name.
|
||||
|
||||
.. index:: show ip large-community-list
|
||||
.. clicmd:: show ip large-community-list
|
||||
@ -1509,8 +1487,8 @@ BGP Large Communities in Route Map
|
||||
.. index:: match large-community LINE
|
||||
.. clicmd:: match large-community LINE
|
||||
|
||||
Where `line` can be a simple string to match, or a regular expression.
|
||||
It is very important to note that this match occurs on the entire
|
||||
Where `line` can be a simple string to match, or a regular expression. It
|
||||
is very important to note that this match occurs on the entire
|
||||
large-community string as a whole, where each large-community is ordered
|
||||
from lowest to highest.
|
||||
|
||||
@ -1535,67 +1513,65 @@ BGP Large Communities in Route Map
|
||||
BGP VRFs
|
||||
========
|
||||
|
||||
Bgpd supports multiple VRF instances via the *router bgp* command:
|
||||
Bgpd supports multiple VRF instances via the *router bgp* command:
|
||||
|
||||
.. index:: router bgp ASN vrf VRFNAME
|
||||
.. clicmd:: router bgp ASN vrf VRFNAME
|
||||
|
||||
VRFNAME is matched against VRFs configured in the kernel. When no
|
||||
*vrf VRFNAME* is specified, the BGP protocol process belongs to
|
||||
the default VRF.
|
||||
VRFNAME is matched against VRFs configured in the kernel. When no *vrf VRFNAME*
|
||||
is specified, the BGP protocol process belongs to the default VRF.
|
||||
|
||||
BGP routes may be leaked (i.e., copied) between a unicast VRF RIB
|
||||
and the VPN safi RIB of the default VRF (leaking is also permitted
|
||||
between the unicast RIB of the default VRF and VPN). A common
|
||||
application of this feature is to connect a customer's private
|
||||
routing domain to a provider's VPN service. Leaking is configured
|
||||
from the point of view of an individual VRF: ``import`` refers to
|
||||
routes leaked from VPN to a unicast VRF, whereas ``export`` refers
|
||||
to routes leaked from a unicast VRF to VPN.
|
||||
BGP routes may be leaked (i.e., copied) between a unicast VRF RIB and the VPN
|
||||
safi RIB of the default VRF (leaking is also permitted between the unicast RIB
|
||||
of the default VRF and VPN). A common application of this feature is to
|
||||
connect a customer's private routing domain to a provider's VPN service.
|
||||
Leaking is configured from the point of view of an individual VRF: ``import``
|
||||
refers to routes leaked from VPN to a unicast VRF, whereas ``export`` refers to
|
||||
routes leaked from a unicast VRF to VPN.
|
||||
|
||||
Required Parameters
|
||||
-------------------
|
||||
|
||||
Routes exported from a unicast VRF to the VPN RIB must be augmented
|
||||
by two parameters:
|
||||
a route-distinguisher (RD) and a route-target list (RTLIST).
|
||||
Configuration for these exported routes must, at a minimum, specify
|
||||
these two parameters.
|
||||
Routes exported from a unicast VRF to the VPN RIB must be augmented by two
|
||||
parameters:
|
||||
|
||||
Routes imported from the VPN RIB to a unicast VRF are selected
|
||||
according to their RTLISTs.
|
||||
Routes whose RTLIST contains at least one route-target in common with
|
||||
the configured import RTLIST are leaked.
|
||||
Configuration for these imported routes must specify an RTLIST to be matched.
|
||||
- an :abbr:`RD (Route Distinguisher)`
|
||||
- an :abbr:`RTLIST (Route-target List)`
|
||||
|
||||
The RD, which carries no semantic value, is intended to make the
|
||||
route unique in the VPN RIB among all routes of its prefix that
|
||||
originate from all the customers and sites that are attached
|
||||
to the provider's VPN service. Accordingly, each site of each customer
|
||||
is typically assigned an RD that is unique across the entire provider
|
||||
network.
|
||||
Configuration for these exported routes must, at a minimum, specify these two
|
||||
parameters.
|
||||
|
||||
The RTLIST is a set of route-target extended community values whose
|
||||
purpose is to specify route-leaking policy. Typically, a customer
|
||||
is assigned a single route-target value for import and export to be
|
||||
used at all customer sites. This configuration specifies a simple
|
||||
topology wherein a customer has a single routing domain which is
|
||||
shared across all its sites. More complex routing topologies are possible
|
||||
through use of additional route-targets to augment the leaking of
|
||||
sets of routes in various ways.
|
||||
Routes imported from the VPN RIB to a unicast VRF are selected according to
|
||||
their RTLISTs. Routes whose RTLIST contains at least one route-target in
|
||||
common with the configured import RTLIST are leaked. Configuration for these
|
||||
imported routes must specify an RTLIST to be matched.
|
||||
|
||||
The RD, which carries no semantic value, is intended to make the route unique
|
||||
in the VPN RIB among all routes of its prefix that originate from all the
|
||||
customers and sites that are attached to the provider's VPN service.
|
||||
Accordingly, each site of each customer is typically assigned an RD that is
|
||||
unique across the entire provider network.
|
||||
|
||||
The RTLIST is a set of route-target extended community values whose purpose is
|
||||
to specify route-leaking policy. Typically, a customer is assigned a single
|
||||
route-target value for import and export to be used at all customer sites. This
|
||||
configuration specifies a simple topology wherein a customer has a single
|
||||
routing domain which is shared across all its sites. More complex routing
|
||||
topologies are possible through use of additional route-targets to augment the
|
||||
leaking of sets of routes in various ways.
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
Configuration of route leaking between a unicast VRF RIB and the
|
||||
VPN safi RIB of the default VRF is accomplished via commands in the
|
||||
context of a VRF address-family:
|
||||
Configuration of route leaking between a unicast VRF RIB and the VPN safi RIB
|
||||
of the default VRF is accomplished via commands in the context of a VRF
|
||||
address-family:
|
||||
|
||||
.. index:: rd vpn export AS:NN|IP:nn
|
||||
.. clicmd:: rd vpn export AS:NN|IP:nn
|
||||
|
||||
Specifies the route distinguisher to be added to a route exported
|
||||
from the current unicast VRF to VPN.
|
||||
Specifies the route distinguisher to be added to a route exported from the
|
||||
current unicast VRF to VPN.
|
||||
|
||||
.. index:: no rd vpn export [AS:NN|IP:nn]
|
||||
.. clicmd:: no rd vpn export [AS:NN|IP:nn]
|
||||
@ -1605,12 +1581,12 @@ context of a VRF address-family:
|
||||
.. index:: rt vpn import|export|both RTLIST...
|
||||
.. clicmd:: rt vpn import|export|both RTLIST...
|
||||
|
||||
Specifies the route-target list to be attached to a route (export)
|
||||
or the route-target list to match against (import) when
|
||||
exporting/importing between the current unicast VRF and VPN.
|
||||
Specifies the route-target list to be attached to a route (export) or the
|
||||
route-target list to match against (import) when exporting/importing between
|
||||
the current unicast VRF and VPN.
|
||||
|
||||
The RTLIST is a space-separated list of route-targets, which are
|
||||
BGP extended community values as described in
|
||||
The RTLIST is a space-separated list of route-targets, which are BGP
|
||||
extended community values as described in
|
||||
:ref:`bgp-extended-communities-attribute`.
|
||||
|
||||
.. index:: no rt vpn import|export|both [RTLIST...]
|
||||
@ -1621,8 +1597,8 @@ context of a VRF address-family:
|
||||
.. index:: label vpn export (0..1048575)
|
||||
.. clicmd:: label vpn export (0..1048575)
|
||||
|
||||
Specifies an optional MPLS label to be attached to a route exported
|
||||
from the current unicast VRF to VPN.
|
||||
Specifies an optional MPLS label to be attached to a route exported from the
|
||||
current unicast VRF to VPN.
|
||||
|
||||
.. index:: no label vpn export [(0..1048575)]
|
||||
.. clicmd:: no label vpn export [(0..1048575)]
|
||||
@ -1632,9 +1608,9 @@ context of a VRF address-family:
|
||||
.. index:: nexthop vpn export A.B.C.D|X:X::X:X
|
||||
.. clicmd:: nexthop vpn export A.B.C.D|X:X::X:X
|
||||
|
||||
Specifies an optional nexthop value to be assigned to a route exported
|
||||
from the current unicast VRF to VPN. If left unspecified, the nexthop
|
||||
will be set to 0.0.0.0 or 0:0::0:0 (self).
|
||||
Specifies an optional nexthop value to be assigned to a route exported from
|
||||
the current unicast VRF to VPN. If left unspecified, the nexthop will be set
|
||||
to 0.0.0.0 or 0:0::0:0 (self).
|
||||
|
||||
.. index:: no nexthop vpn export [A.B.C.D|X:X::X:X]
|
||||
.. clicmd:: no nexthop vpn export [A.B.C.D|X:X::X:X]
|
||||
@ -1644,8 +1620,8 @@ context of a VRF address-family:
|
||||
.. index:: route-map vpn import|export MAP
|
||||
.. clicmd:: route-map vpn import|export MAP
|
||||
|
||||
Specifies an optional route-map to be applied to routes imported
|
||||
or exported betwen the current unicast VRF and VPN.
|
||||
Specifies an optional route-map to be applied to routes imported or exported
|
||||
betwen the current unicast VRF and VPN.
|
||||
|
||||
.. index:: no route-map vpn import|export [MAP]
|
||||
.. clicmd:: no route-map vpn import|export [MAP]
|
||||
@ -1710,7 +1686,8 @@ Showing BGP information
|
||||
.. index:: show ip bgp community COMMUNITY exact-match
|
||||
.. clicmd:: show ip bgp community COMMUNITY exact-match
|
||||
|
||||
This command displays BGP routes using `community` (:ref:`display-bgp-routes-by-community`).
|
||||
This command displays BGP routes using `community`
|
||||
(:ref:`display-bgp-routes-by-community`).
|
||||
|
||||
.. index:: show ip bgp community-list WORD
|
||||
.. clicmd:: show ip bgp community-list WORD
|
||||
@ -1718,7 +1695,8 @@ Showing BGP information
|
||||
.. index:: show ip bgp community-list WORD exact-match
|
||||
.. clicmd:: show ip bgp community-list WORD exact-match
|
||||
|
||||
This command displays BGP routes using community list (:ref:`display-bgp-routes-by-community`).
|
||||
This command displays BGP routes using community list
|
||||
(:ref:`display-bgp-routes-by-community`).
|
||||
|
||||
.. index:: show bgp ipv4|ipv6 summary
|
||||
.. clicmd:: show bgp ipv4|ipv6 summary
|
||||
@ -1788,31 +1766,30 @@ Capability Negotiation
|
||||
======================
|
||||
|
||||
When adding IPv6 routing information exchange feature to BGP. There were some
|
||||
proposals. :abbr:`IETF (Internet Engineering Task Force)` :abbr:`IDR ( Inter
|
||||
Domain Routing)` :abbr:`IDR ( Inter Domain Routing)` adopted a proposal called
|
||||
Multiprotocol Extension for BGP. The specification is described in :rfc:`2283`.
|
||||
The protocol does not define new protocols. It defines new attributes to
|
||||
existing BGP. When it is used exchanging IPv6 routing information it is called
|
||||
BGP-4+. When it is used for exchanging multicast routing information it is
|
||||
called MBGP.
|
||||
proposals. :abbr:`IETF (Internet Engineering Task Force)`
|
||||
:abbr:`IDR (Inter Domain Routing)` adopted a proposal called Multiprotocol
|
||||
Extension for BGP. The specification is described in :rfc:`2283`. The protocol
|
||||
does not define new protocols. It defines new attributes to existing BGP. When
|
||||
it is used exchanging IPv6 routing information it is called BGP-4+. When it is
|
||||
used for exchanging multicast routing information it is called MBGP.
|
||||
|
||||
*bgpd* supports Multiprotocol Extension for BGP. So if remote peer supports the
|
||||
protocol, *bgpd* can exchange IPv6 and/or multicast routing information.
|
||||
*bgpd* supports Multiprotocol Extension for BGP. So if a remote peer supports
|
||||
the protocol, *bgpd* can exchange IPv6 and/or multicast routing information.
|
||||
|
||||
Traditional BGP did not have the feature to detect remote peer's capabilities,
|
||||
e.g. whether it can handle prefix types other than IPv4 unicast routes. This
|
||||
was a big problem using Multiprotocol Extension for BGP to operational network.
|
||||
:rfc:`2842` adopted a feature called Capability Negotiation. *bgpd* use this
|
||||
Capability Negotiation to detect the remote peer's capabilities. If the peer is
|
||||
only configured as IPv4 unicast neighbor, *bgpd* does not send these Capability
|
||||
Negotiation packets (at least not unless other optional BGP features require
|
||||
capability negotation).
|
||||
Traditional BGP did not have the feature to detect a remote peer's
|
||||
capabilities, e.g. whether it can handle prefix types other than IPv4 unicast
|
||||
routes. This was a big problem using Multiprotocol Extension for BGP in an
|
||||
operational network. :rfc:`2842` adopted a feature called Capability
|
||||
Negotiation. *bgpd* use this Capability Negotiation to detect the remote peer's
|
||||
capabilities. If a peer is only configured as an IPv4 unicast neighbor, *bgpd*
|
||||
does not send these Capability Negotiation packets (at least not unless other
|
||||
optional BGP features require capability negotation).
|
||||
|
||||
By default, FRR will bring up peering with minimal common capability for the
|
||||
both sides. For example, local router has unicast and multicast capabilitie and
|
||||
remote router has unicast capability. In this case, the local router will
|
||||
establish the connection with unicast only capability. When there are no common
|
||||
capabilities, FRR sends Unsupported Capability error and then resets the
|
||||
both sides. For example, if the local router has unicast and multicast
|
||||
capabilities and the remote router only has unicast capability the local router
|
||||
will establish the connection with unicast only capability. When there are no
|
||||
common capabilities, FRR sends Unsupported Capability error and then resets the
|
||||
connection.
|
||||
|
||||
If you want to completely match capabilities with remote peer. Please use
|
||||
@ -1824,13 +1801,14 @@ If you want to completely match capabilities with remote peer. Please use
|
||||
.. index:: no neighbor PEER strict-capability-match
|
||||
.. clicmd:: no neighbor PEER strict-capability-match
|
||||
|
||||
Strictly compares remote capabilities and local capabilities. If capabilities
|
||||
are different, send Unsupported Capability error then reset connection.
|
||||
Strictly compares remote capabilities and local capabilities. If
|
||||
capabilities are different, send Unsupported Capability error then reset
|
||||
connection.
|
||||
|
||||
You may want to disable sending Capability Negotiation OPEN message
|
||||
optional parameter to the peer when remote peer does not implement
|
||||
Capability Negotiation. Please use *dont-capability-negotiate*
|
||||
command to disable the feature.
|
||||
You may want to disable sending Capability Negotiation OPEN message optional
|
||||
parameter to the peer when remote peer does not implement Capability
|
||||
Negotiation. Please use *dont-capability-negotiate* command to disable the
|
||||
feature.
|
||||
|
||||
.. index:: neighbor PEER dont-capability-negotiate
|
||||
.. clicmd:: neighbor PEER dont-capability-negotiate
|
||||
@ -1838,19 +1816,18 @@ If you want to completely match capabilities with remote peer. Please use
|
||||
.. index:: no neighbor PEER dont-capability-negotiate
|
||||
.. clicmd:: no neighbor PEER dont-capability-negotiate
|
||||
|
||||
Suppress sending Capability Negotiation as OPEN message optional
|
||||
parameter to the peer. This command only affects the peer is configured
|
||||
other than IPv4 unicast configuration.
|
||||
Suppress sending Capability Negotiation as OPEN message optional parameter
|
||||
to the peer. This command only affects the peer is configured other than
|
||||
IPv4 unicast configuration.
|
||||
|
||||
When remote peer does not have capability negotiation feature, remote
|
||||
peer will not send any capabilities at all. In that case, bgp
|
||||
configures the peer with configured capabilities.
|
||||
When remote peer does not have capability negotiation feature, remote peer
|
||||
will not send any capabilities at all. In that case, bgp configures the peer
|
||||
with configured capabilities.
|
||||
|
||||
You may prefer locally configured capabilities more than the negotiated
|
||||
capabilities even though remote peer sends capabilities. If the peer
|
||||
is configured by *override-capability*, *bgpd* ignores
|
||||
received capabilities then override negotiated capabilities with
|
||||
configured values.
|
||||
capabilities even though remote peer sends capabilities. If the peer is
|
||||
configured by *override-capability*, *bgpd* ignores received capabilities
|
||||
then override negotiated capabilities with configured values.
|
||||
|
||||
.. index:: neighbor PEER override-capability
|
||||
.. clicmd:: neighbor PEER override-capability
|
||||
@ -1882,16 +1859,15 @@ Route Server
|
||||
============
|
||||
|
||||
At an Internet Exchange point, many ISPs are connected to each other by the
|
||||
"full mesh method". As with internal BGP full mesh formation,
|
||||
|
||||
this method has a scaling problem.
|
||||
"full mesh method". As with internal BGP full mesh formation, this method has a
|
||||
scaling problem.
|
||||
|
||||
This scaling problem is well known. Route Server is a method to resolve the
|
||||
problem. Each ISP's BGP router only peers to Route Server. Route Server serves
|
||||
as BGP information exchange to other BGP routers. By applying this method,
|
||||
numbers of BGP connections is reduced from O(n*(n-1)/2) to O(n).
|
||||
|
||||
Unlike normal BGP router, Route Server must have several routing tables for
|
||||
Unlike a normal BGP router, Route Server must have several routing tables for
|
||||
managing different routing policies for each BGP speaker. We call the routing
|
||||
tables as different "views". *bgpd* can work as normal BGP router or Route
|
||||
Server or both at the same time.
|
||||
@ -1925,25 +1901,26 @@ When you want to make configuration more Cisco like one,
|
||||
|
||||
When bgp config-type cisco is specified,
|
||||
|
||||
'no synchronization' is displayed.
|
||||
'no auto-summary' is displayed.
|
||||
``no synchronization`` is displayed.
|
||||
``no auto-summary`` is displayed.
|
||||
|
||||
'network' and 'aggregate-address' argument is displayed as
|
||||
'A.B.C.D M.M.M.M'
|
||||
The ``network`` and ``aggregate-address`` arguments are displayed as::
|
||||
|
||||
FRR: network 10.0.0.0/8
|
||||
Cisco: network 10.0.0.0
|
||||
A.B.C.D M.M.M.M
|
||||
|
||||
FRR: aggregate-address 192.168.0.0/24
|
||||
Cisco: aggregate-address 192.168.0.0 255.255.255.0
|
||||
FRR: network 10.0.0.0/8
|
||||
Cisco: network 10.0.0.0
|
||||
|
||||
Community attribute handling is also different. If there is no
|
||||
configuration is specified community attribute and extended community
|
||||
attribute are sent to neighbor. When user manually disable the
|
||||
feature community attribute is not sent to the neighbor. In case of
|
||||
*bgp config-type cisco* is specified, community attribute is not
|
||||
sent to the neighbor by default. To send community attribute user has
|
||||
to specify *neighbor A.B.C.D send-community* command.::
|
||||
FRR: aggregate-address 192.168.0.0/24
|
||||
Cisco: aggregate-address 192.168.0.0 255.255.255.0
|
||||
|
||||
Community attribute handling is also different. If no configuration is
|
||||
specified community attribute and extended community attribute are sent to the
|
||||
neighbor. If a user manually disables the feature, the community attribute is
|
||||
not sent to the neighbor. When ``bgp config-type cisco`` is specified, the
|
||||
community attribute is not sent to the neighbor by default. To send the
|
||||
community attribute user has to specify *neighbor A.B.C.D send-community*
|
||||
command.::
|
||||
|
||||
!
|
||||
router bgp 1
|
||||
@ -1970,14 +1947,14 @@ to specify *neighbor A.B.C.D send-community* command.::
|
||||
BGP instance and view
|
||||
---------------------
|
||||
|
||||
BGP instance is a normal BGP process. The result of route selection
|
||||
goes to the kernel routing table. You can setup different AS at the
|
||||
same time when BGP multiple instance feature is enabled.
|
||||
BGP instance is a normal BGP process. The result of route selection goes to the
|
||||
kernel routing table. You can setup different AS at the same time when BGP
|
||||
multiple instance feature is enabled.
|
||||
|
||||
.. index:: router bgp AS-NUMBER
|
||||
.. clicmd:: router bgp AS-NUMBER
|
||||
|
||||
Make a new BGP instance. You can use arbitrary word for the `name`.
|
||||
Make a new BGP instance. You can use an arbitrary word for the `name`.
|
||||
|
||||
::
|
||||
|
||||
@ -1992,9 +1969,9 @@ same time when BGP multiple instance feature is enabled.
|
||||
neighbor 10.0.0.4 remote-as 5
|
||||
|
||||
|
||||
BGP view is almost same as normal BGP process. The result of
|
||||
route selection does not go to the kernel routing table. BGP view is
|
||||
only for exchanging BGP routing information.
|
||||
BGP view is almost same as normal BGP process. The result of route selection
|
||||
does not go to the kernel routing table. BGP view is only for exchanging BGP
|
||||
routing information.
|
||||
|
||||
.. index:: router bgp AS-NUMBER view NAME
|
||||
.. clicmd:: router bgp AS-NUMBER view NAME
|
||||
@ -2022,8 +1999,8 @@ only for exchanging BGP routing information.
|
||||
Routing policy
|
||||
--------------
|
||||
|
||||
You can set different routing policy for a peer. For example, you can
|
||||
set different filter for a peer.::
|
||||
You can set different routing policy for a peer. For example, you can set
|
||||
different filter for a peer.::
|
||||
|
||||
bgp multiple-instance
|
||||
!
|
||||
@ -2040,10 +2017,10 @@ set different filter for a peer.::
|
||||
exit-address-family
|
||||
|
||||
|
||||
This means BGP update from a peer 10.0.0.1 goes to both BGP view 1 and view
|
||||
2. When the update is inserted into view 1, distribute-list 1 is
|
||||
applied. On the other hand, when the update is inserted into view 2,
|
||||
distribute-list 2 is applied.
|
||||
This means BGP update from a peer 10.0.0.1 goes to both BGP view 1 and view 2.
|
||||
When the update is inserted into view 1, distribute-list 1 is applied. On the
|
||||
other hand, when the update is inserted into view 2, distribute-list 2 is
|
||||
applied.
|
||||
|
||||
.. _viewing-the-view:
|
||||
|
||||
@ -2062,10 +2039,9 @@ To display routing table of BGP view, you must specify view name.
|
||||
BGP Regular Expressions
|
||||
=======================
|
||||
|
||||
BGP regular expressions are based on `POSIX 1003.2` regular
|
||||
expressions. The following description is just a quick subset of the
|
||||
`POSIX` regular expressions. Adding to that, the special character
|
||||
'_' is added.
|
||||
BGP regular expressions are based on `POSIX 1003.2` regular expressions. The
|
||||
following description is just a quick subset of the `POSIX` regular
|
||||
expressions. Adding to that, the special character '_' is added.
|
||||
|
||||
|
||||
.*
|
||||
@ -2157,10 +2133,10 @@ Dump BGP packets and table
|
||||
.. clicmd:: no dump bgp all [PATH] [INTERVAL]
|
||||
|
||||
Dump all BGP packet and events to `path` file.
|
||||
If `interval` is set, a new file will be created for echo `interval` of seconds.
|
||||
The path `path` can be set with date and time formatting (strftime).
|
||||
The type ‘all-et’ enables support for Extended Timestamp Header (:ref:`packet-binary-dump-format`).
|
||||
(:ref:`packet-binary-dump-format`)
|
||||
If `interval` is set, a new file will be created for echo `interval` of
|
||||
seconds. The path `path` can be set with date and time formatting
|
||||
(strftime). The type ‘all-et’ enables support for Extended Timestamp Header
|
||||
(:ref:`packet-binary-dump-format`).
|
||||
|
||||
.. index:: dump bgp updates PATH [INTERVAL]
|
||||
.. clicmd:: dump bgp updates PATH [INTERVAL]
|
||||
@ -2172,9 +2148,10 @@ Dump BGP packets and table
|
||||
.. clicmd:: no dump bgp updates [PATH] [INTERVAL]
|
||||
|
||||
Dump only BGP updates messages to `path` file.
|
||||
If `interval` is set, a new file will be created for echo `interval` of seconds.
|
||||
The path `path` can be set with date and time formatting (strftime).
|
||||
The type ‘updates-et’ enables support for Extended Timestamp Header (:ref:`packet-binary-dump-format`).
|
||||
If `interval` is set, a new file will be created for echo `interval` of
|
||||
seconds. The path `path` can be set with date and time formatting
|
||||
(strftime). The type ‘updates-et’ enables support for Extended Timestamp
|
||||
Header (:ref:`packet-binary-dump-format`).
|
||||
|
||||
.. index:: dump bgp routes-mrt PATH
|
||||
.. clicmd:: dump bgp routes-mrt PATH
|
||||
@ -2185,9 +2162,9 @@ Dump BGP packets and table
|
||||
.. index:: no dump bgp route-mrt [PATH] [INTERVAL]
|
||||
.. clicmd:: no dump bgp route-mrt [PATH] [INTERVAL]
|
||||
|
||||
Dump whole BGP routing table to `path`. This is heavy process.
|
||||
The path `path` can be set with date and time formatting (strftime).
|
||||
If `interval` is set, a new file will be created for echo `interval` of seconds.
|
||||
Dump whole BGP routing table to `path`. This is heavy process. The path
|
||||
`path` can be set with date and time formatting (strftime). If `interval` is
|
||||
set, a new file will be created for echo `interval` of seconds.
|
||||
|
||||
Note: the interval variable can also be set using hours and minutes: 04h20m00.
|
||||
|
||||
@ -2214,13 +2191,12 @@ Example of a session to an upstream, advertising only one prefix to it.::
|
||||
ip prefix-list pl-allowed-adv seq 5 permit 82.195.133.0/25
|
||||
ip prefix-list pl-allowed-adv seq 10 deny any
|
||||
|
||||
A more complex example. With upstream, peer and customer sessions.
|
||||
Advertising global prefixes and NO_EXPORT prefixes and providing
|
||||
actions for customer routes based on community values. Extensive use of
|
||||
route-maps and the 'call' feature to support selective advertising of
|
||||
prefixes. This example is intended as guidance only, it has NOT been
|
||||
tested and almost certainly containts silly mistakes, if not serious
|
||||
flaws.
|
||||
A more complex example. With upstream, peer and customer sessions. Advertising
|
||||
global prefixes and NO_EXPORT prefixes and providing actions for customer
|
||||
routes based on community values. Extensive use of route-maps and the 'call'
|
||||
feature to support selective advertising of prefixes. This example is intended
|
||||
as guidance only, it has NOT been tested and almost certainly containts silly
|
||||
mistakes, if not serious flaws.
|
||||
|
||||
::
|
||||
|
||||
|
||||
@ -14,7 +14,6 @@ Welcome to FRR's documentation!
|
||||
kernel
|
||||
snmp
|
||||
zebra
|
||||
protocol
|
||||
bgp
|
||||
babeld
|
||||
eigrpd
|
||||
|
||||
Loading…
Reference in New Issue
Block a user