Age | Commit message (Collapse) | Author |
|
Currently, GoBGP sends the ROUTE_DELETE messages to Zebra for the paths
whose nexthop was determined as unreachable by IGP, but when Zebra
received the ROUTE_DELETE messages for the unreachable nexthop, Zebra
will send the NEXTHOP_UPDATE message with the given nexthop is
reachable via the default interface. This message unexpectedly causes
updates of the unreachable path to be reachable (not true though). Then
GoBGP will send ROUTE_ADD messages to Zebra, but those paths soon will
be invalidated via the NEXTHOP_UPDATE message, GoBGP will send the
ROUTE_DELETE messages and ... (infinite loop).
This patch fixes to avoid sending the ROUTE_DELETE messages for the
unreachable paths because those paths are inactivated on Zebra and not
installed to FIB.
Signed-off-by: IWASE Yusuke <iwase.yusuke0@gmail.com>
|
|
Currently, the received messages from Zebra are printed as byte slice
and it is difficult to determine which message was received.
This patch fixes to output the received message as the decoded
structure for the readability.
Signed-off-by: IWASE Yusuke <iwase.yusuke0@gmail.com>
|
|
|
|
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
|
This fixes an issue where GoBGP would incorrectly defer sending routes to a peer on a graceful restart.
RFC4724 states:
> Once the session between the Restarting Speaker and the Receiving
> Speaker is re-established, the Restarting Speaker will receive and
> process BGP messages from its peers. However, it MUST defer route
> selection for an address family until it either (a) receives the
> End-of-RIB marker from all its peers (excluding the ones with the
> "Restart State" bit set in the received capability and excluding the
> ones that do not advertise the graceful restart capability) or (b)
> the Selection_Deferral_Timer referred to below has expired.
The scenario that this fixes is where you have 3 (or more) peers, and 2 of the peers ("A" and "B") perform a graceful restart at the same time, but the 3rd ("C") does not. If after restart peer C sends EOR to peer A before peer B reaches BGP_FSM_ESTABLISHED with peer A, it defers the route selection. However once peer B does reach BGP_FSM_ESTABLISHED, peer A still wouldn't send any updates to peer C until the deferral expired.
This commit changes the behavior so that upon restart, once the peer receives EOR from all non-restarting peers and reaches BGP_FSM_ESTABLISHED for all restarting peers, the routes are sent to all peers.
|
|
Signed-off-by: Satoshi Fujimoto <satoshi.fujimoto7@gmail.com>
|
|
Quagga seems to advertise routes to neighbors by intervals of 30 seconds
(eBGP) or 5 seconds (iBGP) by default. Because of this delay, timer in
"bgp_confederation_test.py", 60 seconds, can be exceeded when the UPDATE
messages need to go through multi ASs.
This patch fixes to use minimum advertisement-interval and reduces the
time of test cases.
Signed-off-by: IWASE Yusuke <iwase.yusuke0@gmail.com>
|
|
Also removes a debug print
Signed-off-by: IWASE Yusuke <iwase.yusuke0@gmail.com>
|
|
To improve the stability of "bgp_router_test.py", this patch fixes to
retry assertions of RIB on a Quagga router after shutting down a
neighbor.
Signed-off-by: IWASE Yusuke <iwase.yusuke0@gmail.com>
|
|
For the stability of some scenario tests, this patch fixes to wait for
GoBGP starting up after restarting GoBGP daemon. Currently, there are
cases that CLI command can be called without checking whether GoBGP
daemon is surely started or not.
Signed-off-by: IWASE Yusuke <iwase.yusuke0@gmail.com>
|
|
GoBGPContainer.graceful_restart() does not "restart" GoBGP daemon, but
just stops (kills) GoBGP daemon. Then this patch renames
graceful_restart() to stop_gobgp() to avoid confusion.
Signed-off-by: IWASE Yusuke <iwase.yusuke0@gmail.com>
|
|
Improves pylint result.
Signed-off-by: IWASE Yusuke <iwase.yusuke0@gmail.com>
|
|
close #1661
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
|
fix a mess in the commit 388ef503f2c9cae.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
|
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
|
Signed-off-by: IWASE Yusuke <iwase.yusuke0@gmail.com>
|
|
For reloading locally generated routes by using MRT dump file, this
patch enables to include locally generated routes into TABLE_DUMPv2
records.
Signed-off-by: IWASE Yusuke <iwase.yusuke0@gmail.com>
|
|
We had to serialize all the paths once because the paths could be
modified later. Now they are immutable so we don't need.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
|
Now you can read Path objects in rib safely. Nobody modifies
them. GetRib() API doesn't need to clone the objects. With full
routes, this avoid allocating temporary huge memory.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
|
Seems that fabric v2 doesn't work with the current files. Let's keep
using v1.X for now.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
|
This patch enables to configure VRF tables by using config file. This
feature is useful when using VRF-Neighbor feature.
Example of Usage:
```toml
[[vrfs]]
[vrfs.config]
name = "vrf1"
id = 1
rd = "65000:100"
both-rt-list = ["65000:100"]
```
Signed-off-by: IWASE Yusuke <iwase.yusuke0@gmail.com>
|
|
Signed-off-by: Satoshi Fujimoto <satoshi.fujimoto7@gmail.com>
|
|
The `router-mac` option in `gobgp` CLI allows sending Router's
MAC Extended Community via BGP EVPN Type 2 and Type 5 advertisements.
As explained in below RFC draft, this community is used to carry the
MAC address of the VTEP where MAC-IP pair resides.
More info: For example, GoBGP router (R1) peers with Cisco router (R2).
R1 is used by an orchestraction platform, e.g. OpenStack, Docker Swarm,
etc., to advertise container MAC-IP bindings. When R1 advertises the
binding it also sets next hop for the route as the host where the MAC-IP
binding (i.e. container) resides. When R2 receives the route, it will
not install it unless Router's MAC Extended Community is present. R2
will use the MAC address in the community to create an entry in MAC
address table of R2 pointint to NVE interface.
```
gobgp global rib -a evpn add macadv e9:72:d7:aa:1f:b4 \
172.16.100.100 etag 0 label 34567 rd 10.1.1.1:100 \
rt 65001:100 encap vxlan nexthop 10.10.10.10 \
origin igp router-mac e9:72:d7:aa:1f:b4
gobgp global rib -a evpn add nexthop 10.10.10.10 origin igp \
prefix 172.16.100.100/32 esi 0 etag 0 rd 10.1.1.1:100 \
rt 65001:100 gw 10.10.10.10 label 34567 encap vxlan \
router-mac e9:72:d7:aa:1f:b4
```
In the above example, a host with IP of `10.10.10.10` runs a
container connected to an Open vSwitch instance. The container's IP
address is `172.16.100.100` and MAC address `e9:72:d7:aa:1f:b4`.
The Open vSwitch is VTEP with `tunnel_key=34567`, i.e. VNID `34567`.
GoBGP (R1) and Cisco (R2) routers are in BGP AS 65001. R1's IP is
`10.1.1.1`. R2 used RT of `65001:100` to import routes and place
them into appropriate VRF. In this case the VRF is associated with
L2VNI from VLAN 300. Upon the receipt of the above BGP EVPN
Type 2 and Type 5 routes, R2 will create create a MAC address
entry pointing to it's NVE interface with destination IP address
of `10.10.10.10`.
```
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link,
(T) - True, (F) - False, C - ControlPlane MAC
VLAN MAC Address Type age Secure NTFY Ports
---------+-----------------+--------+---------+------+----+------------------
* 300 e972.d7aa.1fb4 static - F F nve1(10.10.10.10)
```
The R2 will use the `router-mac e9:72:d7:aa:1f:b4` as the destination MAC
address of the inner VXLAN packet. For example, an underlay host `20.20.20.20`
ping the container. The inner VXLAN L2 destination address is
`e9:72:d7:aa:1f:b4`. The inner VXLAN L2 source address is R2's MAC. The outer
VXLAN L3 source address, i.e. `10.2.2.2` is R2' NVE address.
```
OUTER VXLAN L2: 10:20:08:d0:ff:23 > b2:0e:19:6a:8d:51
OUTER VXLAN L3: 10.2.2.2.45532 > 10.10.10.10.4789: VXLAN, flags [I] (0x08), vni 34567
INNER VXLAN L2: 4e:f4:ca:aa:f6:7b > e9:72:d7:aa:1f:b4
INNER VXLAN L3: 20.20.20.20 > 172.16.100.100: ICMP echo reply, id 66, seq 1267, length 64
```
See also: https://tools.ietf.org/html/draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-05#section-6.1
Signed-off-by: Paul Greenberg <greenpau@outlook.com>
|
|
save about 100MB memory.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
|
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
|
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
|
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
|
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
|
A path object in the adj-in is also in the master rib. We can't update
such.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
|
Shrink memory usage.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
|
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
|
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
|
https://github.com/osrg/gobgp/issues/1249
The IN policy was removed. The modification by the IMPORT policy are
visible to all route server peers.
This saves some dozens bytes memory per a path.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
|
This commit contains `systemd` unit file and the documentation
describing how to run `gobgp` as `systemd` managed service
on CentOS/RHEL Linux distribution.
Signed-off-by: Paul Greenberg <greenpau@outlook.com>
|
|
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
|
Signed-off-by: IWASE Yusuke <iwase.yusuke0@gmail.com>
|
|
|
|
|
|
RFC4724(Graceful Restart) says that if "Restart State" bit is set
in the Open message, its peer must not wait for the EoR marker
from the speaker before advertising routing information to the speaker.
But currently, GoBGP waits EoR even if "Restart State" bit is set
in graceful restart process.
This commit fixes it to skipping syncing process for the
restarting peers.
Signed-off-by: Satoshi Fujimoto <satoshi.fujimoto7@gmail.com>
|
|
Currently, the result of Route Target Constraint filter is unexpectedly
ignored when Route Reflector reflecting the VPN routes because "ignore"
flag can be overwritten without evaluated.
This patch fixes to return "nil" before "ignore" flag overwritten and
enable to filter outgoing VPN routes based on RTC.
Signed-off-by: IWASE Yusuke <iwase.yusuke0@gmail.com>
|
|
Signed-off-by: IWASE Yusuke <iwase.yusuke0@gmail.com>
|
|
Signed-off-by: IWASE Yusuke <iwase.yusuke0@gmail.com>
|
|
Signed-off-by: IWASE Yusuke <iwase.yusuke0@gmail.com>
|
|
Signed-off-by: IWASE Yusuke <iwase.yusuke0@gmail.com>
|
|
fixes #1640
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
|
When GoBGP dropped adj-Rib-out per Peer, we fixed to send the same Route
Target Membership (RTM) NLRI even if it is already sent. This can cause
the infinite UPDATE loop when Route Reflector(RR) reflects RTM NLRI to
its clients.
For example, the following situation causes the infinite UPDATE loop.
Topology:
+----- RR -----+
| |
Client1 Client2
When Client1 has VRF with RT 65000:1 and sends a RTM NLRI to RR, then RR
reflects the NLRI to Client2. If a new VRF with the same RT 65000:1 on
Client2 is created, Client2 will notify it to RR, then RR calculates the
best, but RR will send the NLRI from Client2 to Client1 even if it is
not the best. Client1 receives the NLRI again, calculates the best and
re-sends the best. Then, RR reflects the received NLRI ... (infinite
loop).
This patch fixes to compare the candidate path to be sent with the old
path and assume the given candidate path was already sent before if the
candidate path and the old path is the same path. Then avoids the
infinite UPDATE loop.
Signed-off-by: IWASE Yusuke <iwase.yusuke0@gmail.com>
|
|
The typo in function Less() was causing logical error during comparison
and the comparison would always return whether AS number was less or not
regardless of Maxlen.
fixes #1633
|
|
This patch adds getter functions for the segment type and AS list of
each segment without using type assertion.
Signed-off-by: IWASE Yusuke <iwase.yusuke0@gmail.com>
|
|
When initializing IPv4AddressSpecificExtended or
IPv6AddressSpecificExtended structure, nil value will be returned when
an invalid IP address is given.
But the redirect action extended community types;
- RedirectIPv4AddressSpecificExtended
- RedirectIPv6AddressSpecificExtended
which embed IP address specific extended community types, are not aware
of nil value when initializing, so these redirect action extended
community can be unexpectedly initialized with nil value.
This patch fixes to check return value of the embedded structure and
also return nil when failure of initializing it.
Signed-off-by: IWASE Yusuke <iwase.yusuke0@gmail.com>
|
|
Signed-off-by: IWASE Yusuke <iwase.yusuke0@gmail.com>
|