bgp tcp connection.
When the BGP peer is configured between two bgp routes both routers would create
peer structure , when they receive each other’s open message. In this event both
speakers, open duplicate TCP sessions and send OPEN messages on each socket
simultaneously, the BGP Identifier is used to resolve which socket should be closed.
If BGP GR is enabled the old tcp session is dumped and the new session is retained.
So while this transfer of connection is happening, if all the bgp gr config
is not migrated to the new connection, the new bgp gr mode will never get applied.
Fix Summary:
1. Replicate GR configuration from the old session to the new session in bgp_accept().
2. Replicate GR configuration from stub to full-fledged peer in bgp_establish().
3. Disable all NSF flags, clear stale routes (if present), stop restart & stale timers
(if they are running) when the bgp GR mode is changed to “Disabled”.
4. Disable R-bit in cap, if it is not set the received open message.
Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
* Changing GR mode on a router needs a session reset from the
SAME router to negotiate new GR capability.
* The present GR implementation needs a session reset after every
new BGP GR mode change.
* When BGP session reset happens due to sending or receiving BGP
notification after changing BGP GR mode, there is no need of
explicit session reset.
Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
* Selection Deferral Timer for Graceful Restart.
* Added selection deferral timer handling function.
* Route marking as selection defer when update message is received.
* Staggered processing of routes which are pending best selection.
* Fix for multi-path test case.
Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
* Added new show command to show the graceful restart
information for each neighbor.
Cmd: show bgp [<ipv4|ipv6>] neighbors [<A.B.C.D|X:X::X:X|WORD>] graceful-restart
* Changes to show neighbors commands for displaying
graceful restart information.
Cmd :show [ip] bgp [<view|vrf> VIEWVRFNAME] [<ipv4|ipv6>] neighbors [<A.B.C.D|X:X::X:X|
Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
* Added FSM for peer and global configuration for graceful restart
* Added debug option BGP_GRACEFUL_RESTART for logs specific to
graceful restart processing
Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
We should send a NOTIFICATION message with the Error Code Finite State
Machine Error if we receive NOTIFICATION in OpenSent state
as defined in https://tools.ietf.org/html/rfc4271#section-8.2.2
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Problem: BGP peer pointer is present in keepalive hash table
even when socket has been closed in some race condition.
When keepalive tries to access this peer it asserts.
RCA: Below sequence of events causing assert.
1. Config node peer has went down due to TCP reset
it's FD has been set to -1.
2. Doppelganger peer goes to established state and it has
been added to peer hash table for keepalive when it was
in openconfirm state.
3. Config node parameters including FD are exchanged with
doppelganger. Doppelganger will not have FD -1.
4. Doppelganger will be deleted as part of this it will
remove it from the keepalive peer hash table.
5. While removing from hash table it tries to acquire lock.
6. During this time keepalive thread has the lock and in
a loop trying to send keepalive for peers in hash table.
7. It tries to send keepalive for doppelganger peer with fd
set to -1 and asserts.
Signed-off-by: Santosh P K <sapk@vmware.com>
This change addresses the following:
1) Ensures logs under DEBUG macro checks are categorized
as zlog_debug instead of zlog_info.
2) Error logs are categorized as zlog_err instead of zlog_info.
3) Rephrasing certain logs to make them appear more intuitive.
Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
There was a silly bug introduced when the command to show failed sessions
was added. A missing "," caused the wrong error message to be printed.
Debugging this led down a path that:
- Led to discovering one more error message that needed to be added
- Providing the error code along with the string in the JSON output
to allow programs to key off numbers rather than strings.
- Fixing the missing ","
- Changing the error message to "Waiting for Peer IPv6 LLA" to
make it clear that we're waiting for the link local addr.
Signed-off-by: Dinesh G Dutt <5016467+ddutt@users.noreply.github.com>
frr_with_mutex(...) { ... } locks and automatically unlocks the listed
mutex(es) when the block is exited. This adds a bit of safety against
forgetting the unlock in error paths & co. and makes the code a slight
bit more readable.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
In a data center, having 32-128 peers is not uncommon. In such a situation, to find a
peer that has failed and why is several commands. This hinders both the automatability of
failure detection and the ease/speed with which the reason can be found. To simplify this
process of catching a failure and its cause quicker, this patch does the following:
1. Created a new function, bgp_show_failed_summary to display the
failed summary output for JSON and vty
2. Created a new function to display the reset code/subcode. This is now used in the
failed summary code and in the show neighbors code
3. Added a new variable failedPeers in all the JSON outputs, including the vanilla
"show bgp summary" family. This lists the failed session count.
4. Display peer, dropped count, estd count, uptime and the reason for failure as the
output of "show bgp summary failed" family of commands
5. Added three resset codes for the case where we're waiting for NHT, waiting for peer
IPv6 addr, waiting for VRF to init.
This also counts the case where only one peer has advertised an AFI/SAFI.
The new command has the optional keyword "failed" added to the classical summary command.
The changes affect only one existing output, that of "show [ip] bgp neighbors <nbr>". As
we track the lack of NHT resolution for a peer or the lack of knowing a peer IPv6 addr,
the output of that command will show a "waiting for NHT" etc. as the last reset reason.
This patch includes update to the documentation too.
Signed-off-by: Dinesh G Dutt <5016467+ddutt@users.noreply.github.com>
In the case of IPv4 route exchange using GUA IPv6 peering, the route install
into the FIB involves mapping the immediate next hop to an IPv4 link-local
address and installing neighbor entries for this next hop address. To
accomplish the latter, IPv6 Router Advertisements are exchanged (the next hop
or peer must also have this enabled) and the RAs are dynamically initiated
based on next hop resolution.
However, in the case of a passive connection where the local system has not
initiated anything, no NHT entry is created for the peer, hence RAs were not
getting triggered. Address this by ensuring that a NHT entry is created even
in this situation. This is done at the time the connection becomes established
because the code has other assumptions that a NHT entry will be present only
for the "configured" peer. The API to create the entry ensures there are
no duplicates.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Generally available hook for plugging application-specific
code in for bgp peer change events.
This hook (peer_status_changed) replaces the previous, more
specific 'peer_established' hook with a more general-purpose one.
Also, 'bgp_dump_state' is now registered under this hook.
Signed-off-by: Marton Kun-Szabo <martonk@amazon.com>
The MRT dump code is already hooked in at the right places to write out
packets; the BMP code needs exactly the same access so let's make this
a hook.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
When debugging I was having a hard time correlating some data and noticed that
a particular debug was not being very useful.
Signed-off-by: Donald Sharp <sharpd@cumulusnstworks.com>
This commit fixes a previous commit:
"bfdd: remove operational bfd sessions from remote daemons"
where the handling of unregister call triggers the deletion of bfd
session.
Actually, the BFD session should not be deleted, while bgp session is
configured with BGP. this permits to receive BFD events up, and permit
quicker reconnecion.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
if bfd comes back up, and a bgp reconnection is in progress, theorically
it should be necessary to wait for the end of the reconnection process.
however, since that reconnection process may take some time, update the
fsm by cancelling the connect timer. This done, one just have to call
the start timer.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Views are perfectly valid and should be allowed to connect.
In a bgp instance scenario the vrf_id will always be UNKNOWN,
so allow it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* The function bgp_router_id_zebra_bump() will check for active bgp
peers before chenging the router ID.
If there are established peers, router ID is not modified
which prevents the flapping of established peer connection
* Added field in bgp structure to store the count of established peers
Signed-off-by: kssoman <somanks@vmware.com>
Problems were reported with the name of the default vrf and the
default bgp instance being different, creating confusion. This
fix changes both to "default" for consistency.
Ticket: CM-21791
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-7658
Testing: manual testing and automated tests before pushing
When we add/remove peers we need to do a bit better job
of tracking them in the bgp->peerhash.
1) When we have the doppelganger take over, make sure the
winner is the one represented in the peerhash.
2) When creating the doppelganger, leave the current one
in place instead of blindly replacing it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
During peer startup there exists the possibility that both
locally and remote peers try to start communication at the
same time. In addition it is possible for local configuration
to change at the same time this is going on. When this happens
try to notice that the remote peer may be in opensent or openconfirm
and if so we need to restart the connection from both sides.
Additionally try to write a bit of extra code in peer_xfer_conn
to notice when this happens and to emit a error message to
the end user about this happening so that it can be cleaned up.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This commit implements BGP peer-group overrides for the timer flags,
which control the value of the hold, keepalive, advertisement-interval
and connect connect timers. It was kept separated on purpose as the
whole timer implementation is quite complex and merging this commit
together with with the other flag implementations did not seem right.
Basically three new peer flags were introduced, namely
*PEER_FLAG_ROUTEADV*, *PEER_FLAG_TIMER* and *PEER_FLAG_TIMER_CONNECT*.
The overrides work exactly the same way as they did before, but
introducing these flags made a few conditionals simpler as they no
longer had to compare internal data structures against eachother.
Last but not least, the test suite has been adjusted accordingly to test
the newly implemented flag overrides.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
When bgp is thinking about opening a connection to a peer,
if we are connected to zebra, allow that to influence our
decision to start the connection.
Found Scenario:
Both bgp and zebra are started up at the same time. Zebra is
being used to create the connected route through which bgp
will establish a peering relationship. The machine is a
bit loaded due to other startup conditions and as such bgp
gets to the connection stage here before zebra has installed
the route. If bgp does not respect zebra data when it does
have a connection then we will attempt to connect. The
connect will fail because there is no route. At that time
we will go into the connect timeout(2 minutes) and delay
connection.
What this does. If we have established a zebra connection and
we do not have a clear path to the destination at this point
do not allow the connection to proceed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The handling of the return codes for getsockopt was slightly wrong.
getsockopt returns -1 on error and errno is set.
What to do with the return code at that point is dependent
on what sockopt you are asking about. In this case
status holds the error returned for SO_ERROR.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Routes that have labels must be sent via a nexthop that also has labels.
This change notes whether any path in a nexthop update from zebra contains
labels. If so, then the nexthop is valid for routes that have labels.
If a nexthop update has no labeled paths, then any labeled routes
referencing the nexthop are marked not valid.
Add a route flag BGP_INFO_ANNC_NH_SELF that means "advertise myself
as nexthop when announcing" so that we can track our notion of the
nexthop without revealing it to peers.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
The following types are nonstandard:
- u_char
- u_short
- u_int
- u_long
- u_int8_t
- u_int16_t
- u_int32_t
Replace them with the C99 standard types:
- uint8_t
- unsigned short
- unsigned int
- unsigned long
- uint8_t
- uint16_t
- uint32_t
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
We lock and set peer->bgp at peer creation and only
remove it at deletion. Therefore these tests are
not needed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Upon starting a BGP VRF instance, the server socket is not created,
because the VRF ID is not known, and then underlying VRF backend is not
ready yet. Because of that, the peer connection attempt will not be
started before.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The change contained in this commit does the following:
- discovery of vrf id from zebra daemon, and adaptation of bgp contexts
with BGP.
The list of network addresses contain a reference to the bgp context
supporting the vrf.
The bgp context contains a vrf pointer that gives information about
the netns path in case the vrf is a netns path.
Only some contexts are impacted, namely socket creation, and retrieval
of local IP settings. ( this requires vrf identifier).
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The multithreading code has a comment that reads:
"XXX: Heavy abuse of stream API. This needs a ring buffer."
This patch makes the relevant code use a ring buffer.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
During initial session establishment, bgpd performs a "connection
transfer" to a new peer struct if the connection was initiated passively
(i.e. by the remote peer). With the addition of buffered input and a
reorganized packet processor, the following race condition manifests:
1. Remote peer initiates a connection. After exchanging OPEN messages,
we send them a KEEPALIVE. They send us a KEEPALIVE followed by
10,000 UPDATE messages. The I/O thread pushes these onto our local
peer's input buffer and schedules a packet processing job on the
main thread.
2. The packet job runs and processes the KEEPALIVE, which completes the
handshake on our end. As part of transferring to ESTABLISHED we
transfer all peer state to a new struct, as mentioned. Upon returning
from the KEEPALIVE processing routing, the peer context we had has
now been destroyed. We notice this and stop processing. Meanwhile
10k UPDATE messages are sitting on the input buffer.
3. N seconds later, the remote peer sends us a KEEPALIVE. The I/O thread
schedules another process job, which finds 10k UPDATEs waiting for
it. Convergence is achieved, but has been delayed by the value of the
KEEPALIVE timer.
The racey part is that if the remote peer takes a little bit of time to
send UPDATEs after KEEPALIVEs -- somewhere on the order of a few hundred
milliseconds -- we complete the transfer successfully and the packet
processing job is scheduled on the new peer upon arrival of the UPDATE
messages. Yuck.
The solution is to schedule a packet processing job on the new peer
struct after transferring state.
Lengthy commit message in case someone has to debug similar problems in
the future...
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
During initial session establishment, bgpd performs a "connection
transfer" to a new peer struct if the connection was initiated passively
(i.e. by the remote peer). With the addition of buffered input, I forgot
to transfer the raw input buffer to the new peer. This resulted in
infrequent failures during session handshaking whereby half of a packet
would be thrown away in the middle of a read causing us to send a NOTIFY
for an unsynchronized header. Usually the transfer coincided with a
clean input buffer, hence why it only showed up once in a while.
At some point when rearranging FSM code, bgpd lost the ability to
perform active opens because it was only paying attention to POLLIN and
not POLLOUT, when the latter is used to signify a successful connection
in the active case.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* Keepalive on/off calls are necessary in certain cases due to screwy
fsm flow not turning them on after transferring a passive peer
connection in peer_xfer_conn
* Missed a case bgp_event_update() that resulted in a return code of -1
instead of BGP_Stop, which confuses the packet processing routine
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Despaghettification of bgp_packet.c and bgp_fsm.c
Sometimes we call bgp_event_update() inline packet parsing.
Sometimes we post events instead.
Sometimes we increment packet counters in the FSM.
Sometimes we do it in packet routines.
Sometimes we update EOR's in FSM.
Sometimes we do it in packet routines.
Fix the madness.
bgp_process_packet() is now the centralized place to:
- Update message counters
- Execute FSM events in response to incoming packets
FSM events are now executed directly from this function instead of being
queued on the thread_master. This is to ensure that the FSM contains the
proper state after each packet is parsed. Otherwise there could be race
conditions where two packets are parsed in succession without the
appropriate FSM update in between, leading to session closure due to
receiving inappropriate messages for the current FSM state.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Instead of reading a packet header and the rest of the packet in two
separate i/o cycles, instead read a chunk of data at one time and then
parse as many packets as possible out of the chunk.
Also changes bgp_packet.c to batch process packets.
To avoid thrashing on useless mutex locks, the scheduling call for
bgp_process_packet has been changed to always succeed at the cost of no
longer being cancel-able. In this case this is acceptable; following the
pattern of other event-based callbacks, an additional check in
bgp_process_packet to ignore stray events is sufficient. Before deleting
the peer all events are cleared which provides the requisite ordering.
XXX: chunk hardcoded to 5, should use something similar to wpkt_quanta
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* Move and modify all network input related code to bgp_io.c
* Add a real input buffer to `struct peer`
* Move connection initialization to its own thread.c task instead of
piggybacking off of bgp_read()
* Tons of little fixups
Primary changes are in bgp_packet.[ch], bgp_io.[ch], bgp_fsm.[ch].
Changes made elsewhere are almost exclusively refactoring peer->ibuf to
peer->curr since peer->ibuf is now the true FIFO packet input buffer
while peer->curr represents the packet currently being processed by the
main pthread.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
After implement threading, bgp_packet.c was serving the double purpose
of consolidating packet parsing functionality and handling actual I/O
operations. This is somewhat messy and difficult to understand. I've
thus moved all code and data structures for handling threaded packet
writes to bgp_io.[ch].
Although bgp_io.[ch] only handles writes at the moment to keep the noise
on this commit series down, for organization purposes, it's probably
best to move bgp_read() and its trappings into here as well and
restructure that code so that read()'s happen in the pthread and packet
processing happens on the main thread.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
On TCP connection failure during session setup, bgp_stop() checks
whether peer->t_read is non-null to know whether or not to unschedule
select() on peer->fd before calling close() on it. Using the API exposed
by thread.c instead of bgpd's wrapper macro BGP_READ_ON() results in
this thread value never being set, which causes bgp_stop() to skip the
cancellation of select() before calling close(). Subsequent calls to
select() on that fd crash the daemon.
Use the macro instead.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
During transition from OpenConfirm -> Established, we wipe the peer stub's
output buffer. Because thread.c prioritizes I/O operations over regular
background threads and events, in a single threaded environment this ordering
meant that the output buffer would be happily empty at wipe time. In MT-land,
this convenient coincidence is no longer true; thus we need to make sure that
any packets remaining on the peer stub get transferred over to the peer proper.
Also removes misleading comment indicating that bgp_establish() sends a
keepalive packet. It does not.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This patch, in tandem with moving packet writes into a dedicated kernel
thread, fixes session flaps caused by long-running internal operations
starving the (old) userspace write thread.
BGP keepalives are now produced by a kernel thread and placed onto the
peer's output queue. These are then consumed by the write thread. Both
of these tasks are concurrent with the rest of bgpd, obviating the
session flaps described above.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Prior to this change, after initiating a nonblocking connection to the
remote peer bgpd would call both BGP_READ_ON and BGP_WRITE_ON on the
peer's socket. This resulted in a call to select(), so that when some
event (either a connection success or failure) occurred on the socket,
one of bgp_read() or bgp_write() would run. At the beginning of each of
those functions was a hook into bgp_connect_check(), which checked the
socket status and issued the correct connection event onto the BGP FSM.
This code is better suited for bgp_fsm.c. Placing it there avoids
scheduling packet reads or writes when we don't know if the socket has
established a connection yet, and the specific functionality is a better
fit for the responsibility scope of this unit.
This change also helps isolate the responsibilities of the
packet-writing kernel thread.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Problem reported that we weren't adjusting the keepalive timer
correctly when we negotiated a lower hold time learned from a
peer. While working on this, found we didn't do inheritance
correctly at all. This fix solves the first problem and also
ensures that the timers are configured correctly based on this
priority order - peer defined > peer-group defined > global config.
This fix also displays the timers as "configured" regardless of
which of the three locations above is used.
Ticket: CM-18408
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-6807
Testing-performed: Manual testing successful, fix tested by
submitter, bgp-smoke completed successfully
SAFI values have been a major source of confusion over the last few
years. That's because each SAFI needs to be represented in two different
ways:
* IANA's value used to send/receive packets over the network;
* Internal value used for array indexing.
In the second case, defining reserved values makes no sense because we
don't want to index SAFIs that simply don't exist. The sole purpose of
the internal SAFI values is to remove the gaps we have among the IANA
values, which would represent wasted memory in C arrays. With that said,
remove these reserved SAFIs to avoid further confusion in the future.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This reverts commit c14777c6bf.
clang 5 is not widely available enough for people to indent with. This
is particularly problematic when rebasing/adjusting branches.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
log.c provides functionality for associating a constant (typically a
protocol constant) with a string and finding the string given the
constant. However this is highly delicate code that is extremely prone
to stack overflows and off-by-one's due to requiring the developer to
always remember to update the array size constant and to do so correctly
which, as shown by example, is never a good idea.b
The original goal of this code was to try to implement lookups in O(1)
time without a linear search through the message array. Since this code
is used 99% of the time for debugs, it's worth the 5-6 additional cmp's
worst case if it means we avoid explitable bugs due to oversights...
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Ensure that we have a valid vrf before we log
information about it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
When bgp logs ADJCHANGE messages include the
hostname and vrf that this change is being made
in.
Ticket: CM-10922
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Problem found to be derefencing a vrf that had already been deleted. Fix
verifies that vrf exists before using it.
Ticket: CM-13682
Signed-off-by: Don Slice
Reviewed By: Vivek Venkatraman
Testing Done: manual testing, re-run of failing scripts good
When bgp logs ADJCHANGE messages include the
hostname and vrf that this change is being made
in.
Ticket: CM-10922
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ensure that we have a valid vrf before we log
information about it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
When bgp logs ADJCHANGE messages include the
hostname and vrf that this change is being made
in.
Ticket: CM-10922
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The FSF's address changed, and we had a mixture of comment styles for
the GPL file header. (The style with * at the beginning won out with
580 to 141 in existing files.)
Note: I've intentionally left intact other "variations" of the copyright
header, e.g. whether it says "Zebra", "Quagga", "FRR", or nothing.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The way thread.c is written, a caller who wishes to be able to cancel a
thread or avoid scheduling it twice must keep a reference to the thread.
Typically this is done with a long lived pointer whose value is checked
for null in order to know if the thread is currently scheduled. The
check-and-schedule idiom is so common that several wrapper macros in
thread.h existed solely to provide it.
This patch removes those macros and adds a new parameter to all
thread_add_* functions which is a pointer to the struct thread * to
store the result of a scheduling call. If the value passed is non-null,
the thread will only be scheduled if the value is null. This helps with
consistency.
A Coccinelle spatch has been used to transform code of the form:
if (t == NULL)
t = thread_add_* (...)
to the form
thread_add_* (..., &t)
The THREAD_ON macros have also been transformed to the underlying
thread.c calls.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Implement support for negotiating IPv4 or IPv6 labeled-unicast address
family, exchanging prefixes and installing them in the routing table, as
well as interactions with Zebra for FEC registration. This is the
implementation of RFC 3107.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
This means there are no ties into the SNMP code anymore other than the
init call at startup.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This patch enable the support of graceful restart for routes sets with
vpnv4 address family format. In this specific case, data model is
slightly different and some additional processing must be done when
accessing bgp tables and nodes.
The clearing stale algorithm takes into account the specificity where
the 2 node level for MPLS has to be reached.
Signed-off-by: Julien Courtat <julien.courtat@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Reverts the --enable-bgp-standalone and makes it so that you
need to use --enable-cumulus to get the cumulus behavior.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This is a rather large mechanical commit that splits up the memory types
defined in lib/memtypes.c and distributes them into *_memory.[ch] files
in the individual daemons.
The zebra change is slightly annoying because there is no nice place to
put the #include "zebra_memory.h" statement.
bgpd, ospf6d, isisd and some tests were reusing MTYPEs defined in the
library for its own use. This is bad practice and would break when the
memtype are made static.
Acked-by: Vincent JARDIN <vincent.jardin@6wind.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
[CF: rebased for cmaster-next]
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
lib/zebra.h has FILTER_X #define's. These do not belong there.
Put them in lib/filter.h where they belong.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
(cherry picked from commit 0490729cc033a3483fc6b0ed45085ee249cac779)
Ticket:
Reviewed By:
Testing Done:
For interface-based peering, we don't update the reset reason to be
interface down. Similarly, we don't update the reason to be loss of
neighbor address (maybe due to RA loss). This patch addresses these
limitations.
Various changes and fixes related to VRF registration, deletion,
BGP exit etc.
- Define instance type
- Ensure proper handling upon instance create, delete and
VRF add/delete from zebra
- Cleanup upon bgp_exit()
- Ensure messages are not sent to zebra for unknown VRFs
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-9128, CM-7203
Reviewed By: CCR-4098
Testing Done: Manual
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-8122
per draft-ietf-idr-ix-bgp-route-server-09:
2.3.2.2.2. BGP ADD-PATH Approach
The [I-D.ietf-idr-add-paths] Internet draft proposes a different
approach to multiple path propagation, by allowing a BGP speaker to
forward multiple paths for the same prefix on a single BGP session.
As [RFC4271] specifies that a BGP listener must implement an implicit
withdraw when it receives an UPDATE message for a prefix which
already exists in its Adj-RIB-In, this approach requires explicit
support for the feature both on the route server and on its clients.
If the ADD-PATH capability is negotiated bidirectionally between the
route server and a route server client, and the route server client
propagates multiple paths for the same prefix to the route server,
then this could potentially cause the propagation of inactive,
invalid or suboptimal paths to the route server, thereby causing loss
of reachability to other route server clients. For this reason, ADD-
PATH implementations on a route server should enforce send-only mode
with the route server clients, which would result in negotiating
receive-only mode from the client to the route server.
This allows us to delete all of the following code:
- All XXXX_rsclient() functions
- peer->rib
- BGP_TABLE_MAIN and BGP_TABLE_RSCLIENT
- RMAP_IMPORT and RMAP_EXPORT
BGP ORF prefix lists are in a separate namespace; this was previously
hooked up with a special-purpose AFI value. This is a little kludgy for
extension, hence this splits it off.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Ticket: CM-7140
Reviewed By: CCR-3412
Testing Done: bgpsmoke, Atul verified fix
BGP Unnumbered and Interface based peering can interact in some strange
ways. One of them is when there's an IPv4 address on a link on which
BGP Unnumbered session is beng attempted, but the IPv4 address is not
a /30 or /31. As per the bug report, we end up attempting to start the
BGP FSM on receiving a notification that an IPv4 address is present on
an interface. To avoid attempting to go past BGP's start state in the
absence of a valid peer address is the right thing to do. And this
simple patch does just that.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Vipin Kumar <vipin@cumulusnetworks.com>
Ticket: CM-7861
Reviewed by: CCR-3651
Testing: See bug
bgp is using both bm->master and master pointers interchangebly
for thread manipulation. Since they are the same thing consolidate
to one pointer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-7439
Reviewed By: Donald Sharp
Testing Done:
If a session was reset due to a NOTIFICATION the "show ip bgp
neighbor" output would not display details on what the
notification actually was. This patch changes that. Example:
superm-redxp-05# show ip bgp neighbors 20.1.2.2
BGP neighbor is 20.1.2.2, remote AS 21, local AS 10, external link
[snip]
Last reset 01:05:07, due to NOTIFICATION sent (OPEN Message Error/Bad Peer AS)
This patch adds a hostname capability. The node's hostname and
domainname are exchanged in the new capability and used in show command
outputs based on a knob enabled by the user. The hostname and domainname
can be a maximum of 64 chars long, each.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com>
Ticket: CM-5660
Reviewed By: CCR-2563
Testing Done:
Ticket: CM-4109
Reviewed-by: CCR-3414
Testing: See bug
Fixup of these memory issues:
(A) peer->clear_node_queue was accidently removed. Add back in.
(B) Clean up bm->process_main_queue and bm->process_rsclient_queue initialization
(C) Some memory leaks
(D) Clean up unused threads
Ticket: CM-6789
Reviewed By: CCR-3263
Testing Done: Manual Testing and smoke tests
Whenever some sort of output is encountered, added a json version with
proper logic as well.
Also, there is no reason stored in the last_reset field when BGP peer goes down due BFD. Incorrect/no peer down reason can get logged when BGP peer goes down due to BFD. Fixed it by adding new BFD peer down reason code and storing it in the peer last_reset field when peer is broght down due to BFD.
This patch also adds BFD multihop support for BGP. Whether a peer is multi-hop or single hop is determined internally. All IGP peers are considered as multi-hop peers. EBGP peers are considered as single hop unless configured as multi-hop.
BGP BFD command enhancement to configure BFD parameters (detect multiplier, min rx and min tx).
router bgp <as-number>
neighbor <name/ip-address> bfd <detect mult> <min rx> <min tx>
Signed-off-by: Radhika Mahankali <radhika@cumulusnetworks.com>
Reviewed-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Reviewed-by: Vipin Kumar <vipin@cumulusnetworks.com>
Reviewed-by: Kanna Rajagopal <kanna@cumulusnetworks.com>
bgpd: Exchange hostname capability and display hostnames in outputs
This patch adds a hostname capability. The node's hostname and
domainname are exchanged in the new capability and used in show command
outputs based on a knob enabled by the user. The hostname and domainname
can be a maximum of 64 chars long, each.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com>
bgp: Fixup of the remote-as command to allow user to not have to enter an actual as number
Signed-off-by: Donald Sharp<sharpd@cumulusnetworks.com>
Reviewed-by:
peer - one initiated by the local system and the other initiated by the peer.
Enhance key debug logs to also print the socket file descriptor so that it is
clear which events pertain to which connection.
broken by some earlier patches. Instead of staying in Connect state
after reattempting the connection, the state used to go back to Idle
and then try to connect. This patch fixes this error.
state to facilitate clearing of the routes received from the peer - remove
from the RIB, reselect best path, update/delete from Zebra and to other
peers etc. At the end of this, a Clearing_Completed event is generated to
the FSM which will allow the peer to move out of Clearing to Idle.
The issue in the code is that there is a possibility of multiple Clearing
Completed events being generated for a peer, one per AFI/SAFI. Upon the
first such event, the peer would move to Idle. If other events happened
(e.g., new connection got established) before the last Clearing_Completed
event is received, bad things can happen.
Fix to ensure only one Clearing_Completed event is generated.
state through bgp_ignore() as that may not do required cleanup. Instead,
define a new event handler to handle such cases, which will go through
bgp_stop(). A similar change is also done to handle the case where an
event handler fails.
Also add a couple of variables to keep track of events for a peer.
When BGP connection setup was moved to rely on nexthop tracking, a few silly
bugs were introduced.
- bgp_connect_check() was called unnecessarily which resulted in false
positives which resulted in log messages indicating an error and the FSM
was unnecessarily reset.
- When routes to peer disappeared, and the peer was not directly connected,
the session was not immediately torn down, but only on hold timer expiry.
- When NHT indicated that route to session IP addr was available, the previous
state was not reset and as a result, connect retry timer had to expire
before a reconnection was attempted.
- connected check MUST be enabled only for EBGP non-multihop sessions and
only if disbale-connected-check option is not enabled.
This patch fixes all these errors.
change processing etc.) that refer to the BGP instance, the correct BGP
instance must be referenced and not the default BGP instance. The default
BGP instance is the first instance on the instance list. In a scenario
where one BGP instance is deleted (through operator action such as a
"no router bgp" command) and another instance exists or is created, there
may still be events in-flight that need to be processed against the
deleted instance. Trying to process these against the default instance
is erroneous. The calls to bgp_get_default() must be limited to the user
interface (vtysh) context.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
sessions dynamically. The operator configures a range of neighbor addresses
to which peering is allowed. The ranges are configured as subnets and
multiple ranges are allowed. Each range is associated with a peer-group
so that additional parameters can be configured.
BGP neighbor sessions are dynamically created when connections are initiated
by remote neighbors whose addresses fall within a configured range. The
sessions are deleted when the BGP connection terminates.
A limit on the number of neighbors allowed from each range of addresses
can be specified.
IPv4 and IPv6 peering is supported. Over the peering, any of the address
families configured for the peer-group can be negotiated.
This patch implements the 'update-groups' functionality in BGP. This is a
function that can significantly improve BGP performance for Update generation
and resultant network convergence. BGP Updates are formed for "groups" of
peers and then replicated and sent out to each peer rather than being formed
for each peer. Thus major BGP operations related to outbound policy
application, adj-out maintenance and actual Update packet formation
are optimized.
BGP update-groups dynamically groups peers together based on configuration
as well as run-time criteria. Thus, it is more flexible than update-formation
based on peer-groups, which relies on operator configuration.
[Note that peer-group based update formation has been introduced into BGP by
Cumulus but is currently intended only for specific releases.]
From 11098af65b2b8f9535484703e7f40330a71cbae4 Mon Sep 17 00:00:00 2001
Subject: [PATCH] updgrp commits
Summary of changes
- added an option to enable keepalive debugs for a specific peer
- added an option to enable inbound and/or outbound updates debugs for a specific peer
- added an option to enable update debugs for a specific prefix
- added an option to enable zebra debugs for a specific prefix
- combined "deb bgp", "deb bgp events" and "deb bgp fsm" into "deb bgp neighbor-events". "deb bgp neighbor-events" can be enabled for a specific peer.
- merged "deb bgp filters" into "deb bgp update"
- moved the per-peer logging to one central log file. We now have the ability to filter all verbose debugs on a per-peer and per-prefix basis so we no longer need to keep log files per-peer. This simplifies troubleshooting by keeping all BGP logs in one location. The use
r can then grep for the peer IP they are interested in if they wish to see the logs for a specific peer.
- Changed "show debugging" in isis to "show debugging isis" to be consistent with all other protocols. This was very confusing for the user because they would type "show debug" and expect to see a list of debugs enabled across all protocols.
- Removed "undebug" from the parser for BGP. Again this was to be consisten with all other protocols.
- Removed the "all" keyword from the BGP debug parser. The user can now do "no debug bgp" to disable all BGP debugs, before you had to type "no deb all bgp" which was confusing.
The new parse tree for BGP debugging is:
deb bgp as4
deb bgp as4 segment
deb bgp keepalives [A.B.C.D|WORD|X:X::X:X]
deb bgp neighbor-events [A.B.C.D|WORD|X:X::X:X]
deb bgp nht
deb bgp updates [in|out] [A.B.C.D|WORD|X:X::X:X]
deb bgp updates prefix [A.B.C.D/M|X:X::X:X/M]
deb bgp zebra
deb bgp zebra prefix [A.B.C.D/M|X:X::X:X/M]
- Schedule write thread for advertisements and withdraws only if corresponding
FIFOs are growing and/or upon work_queue getting fully processed.
- Set non-default yield time for the main work_queue, as the default value
of 10ms results in yielding after processing very few nodes.
- Remove unnecessary scheduling of write thread when update packet is formed.
- If MRAI is 0, don't start a timer unnecessarily, directly schedule write
thread.
- Some debugs.
COMMAND:
Possible forms of the command configuration:
[no] bgp max-med administrative
[no] bgp max-med administrative <max-med-value>
[no] bgp max-med on-startup <period>
[no] bgp max-med on-startup <period> <max-med-value>
DESCRIPTION:
'administrative' takes effect from the time of the config until the config is
removed.
'on-startup' is effective only at the startup time for the given '<period>'
after the first peer is established.
'<max-med-value>' is used as the MED value to be sent out when the max-med
is effective. Default max-med value is 4294967294.
NOTE:
When max-med is active, MED is changed only in the outgoing attributes to the
peers, it doesn't modify any MED specific state of the attributes in BGP on
the local node.
Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
ISSUE:
During startup, BGP update prefix packing wasnt optimal and route installation
was found to be spread over.
SOLUTION:
With this patch, update-delay post processing is serialized to achieve:
a. better peer update packing
(which helps in reducing total number of BGP update packets)
b. installation of the resulting routes in zebra as close to each others
as possible.
(which can help zebra batch its processing and updates to Kernel better)
BGP: Fix FSM to handle active/passive connections better
The existing code didn't work well when dual connections resulted between
peers during session bringup. This patch fixes that.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
BGP: Event-driven route announcement taking into account min route advertisement interval
ISSUE
BGP starts the routeadv timer (peer->t_routeadv) to expire in 1 sec
when a peer is established. From then on, the timer expires
periodically based on the configured MRAI value (default: 30sec for
EBGP, 5sec for IBGP). At the expiry, the write thread is triggered
that takes the routes from peer's sync FIFO (adj-rib-out) and sends
UPDATEs. This has a few drawbacks:
(1) Delay in new route announcement: Even when the last UPDATE message
was sent a while back, the next route change will necessarily have
to wait for routeadv expiry
(2) CPU usage: The timer is always armed. If the operator chooses to
configure a lower value of MRAI (zero second is a preferred choice
in many deployments) for better convergence, it leads to high CPU
usage for BGP process, even at the times of no network churn.
PATCH
Make the route advertisement event-driven - When routes are added to
peer's sync FIFO, check if the routeadv timer needs to be adjusted (or
started). Conversely, do not arm the routeadv timer unconditionally.
The patch also addresses route announcements during read-only mode
(update-delay). During read-only mode operation, the routeadv timer
is not started. When BGP comes out of read-only mode and all the
routes are processed, the timer is started for all peers with zero
expiry, so that the UPDATEs can be sent all at once. This leads to
(near-)optimal UPDATE packing.
Finally, the patch makes the "max # packets to write to peer socket at
a time" configurable. Currently it is hard-coded to 10. The command is
at the top router-bgp mode and is called "write-quanta <number>". It
is a useful convergence parameter to tweak.
Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
COMMAND:
'update-delay <max-delay in seconds> [<establish-wait in seconds>]'
DESCRIPTION:
This feature is used to enable read-only mode on BGP process restart or when
BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode
would begin as soon as the first peer reaches Established state and a timer
for <max-delay> seconds is started.
During this mode BGP doesn't run any best-path or generate any updates to its
peers. This mode continues until:
1. All the configured peers, except the shutdown peers, have sent explicit EOR
(End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached
Established is considered an implicit-EOR.
If the <establish-wait> optional value is given, then BGP will wait for
peers to reach establish from the begining of the update-delay till the
establish-wait period is over, i.e. the minimum set of established peers for
which EOR is expected would be peers established during the establish-wait
window, not necessarily all the configured neighbors.
2. max-delay period is over.
On hitting any of the above two conditions, BGP resumes the decision process
and generates updates to its peers.
Default <max-delay> is 0, i.e. the feature is off by default.
This feature can be useful in reducing CPU/network used as BGP restarts/clears.
Particularly useful in the topologies where BGP learns a prefix from many peers.
Intermediate bestpaths are possible for the same prefix as peers get established
and start receiving updates at different times. This feature should offer a
value-add if the network has a high number of such prefixes.
IMPLEMENTATION OBJECTIVES:
Given this is an optional feature, minimized the code-churn. Used existing
constructs wherever possible (existing queue-plug/unplug were used to achieve
delay and resume of best-paths/update-generation). As a result, no new
data-structure(s) had to be defined and allocated. When the feature is disabled,
the new node is not exercised for the most part.
Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com>
Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com>
Dinesh Dutt <ddutt@cumulusnetworks.com>
Quagga sources have inherited a slew of Page Feed (^L, \xC) characters
from ancient history. Among other things, these break patchwork's
XML-RPC API because \xC is not a valid character in XML documents.
Nuke them from high orbit.
Patches can be adapted simply by:
sed -e 's%^L%%' -i filename.patch
(you can type page feeds in some environments with Ctrl-V Ctrl-L)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Keepalives and updates are not expected in OpenSent, prior to receiving
the peer's open message. Terminate the session with the proper
notification.
From: Leonid Rosenboim <lrosenbo@wrs.com>
[split off FSM changes, some reordering & cleanup. read handling needs
to be separately addressed]
Signed-off-by: David Lamparter <equinox@diac24.net>
- SAFI value 3 is reserved. It was assigned by RFC 2858 for a use
that was never fully implemented, so it is deprecated by this
document.
* zebra.h: rename macro
* bgp_fsm.c: (bgp_graceful_restart_timer_expire,
bgp_graceful_stale_timer_expire, bgp_stop, bgp_establish): update
* bgpd.c: (peer_nsf_stop): update
* bgp_open.c: (bgp_capability_vty_out): SAFI 3 isn't a recognized case
any more
BGP uses time() to get system time of day; but that value
fluctuates with time adjustments from NTP. This can cause premature
flapping of peer sessions and other failures.
Use the system monotonic clock supported by Quagga thread library
to avoid issue.
See: http://bugzilla.vyatta.com/show_bug.cgi?id=4467
* bgpd/bgp_fsm.c
* bgp_uptime_reset(): dismiss function
* bgpd/bgpd.c
* bgp_clock(): new function
* bgpd/bgp_damp.c
* bgp_reuse_timer(): employ bgp_clock() instead of time(NULL)
* bgp_damp_withdraw(): idem
* bgp_damp_update(): idem
* bgp_damp_scan(): idem
* bgp_damp_info_vty(): idem
* bgp_damp_reuse_time_vty(): idem
* bgpd/bgp_fsm.c
* bgp_routeadv_timer(): idem
* bgp_stop(): idem
* bgp_establish(): idem
* bgpd/bgp_packet.c
* bgp_update_receive(): idem
* bgpd/bgp_route.c
* bgp_update_rsclient(): idem
* bgp_update_main(): idem
* bgp_static_update_rsclient(): idem
* bgp_static_update_main(): idem
* bgp_static_update_vpnv4(): idem
* bgp_aggregate_route(): idem
* bgp_aggregate_add(): idem
* bgp_redistribute_add(): idem
* bgpd/bgp_snmp.c
* bgpPeerTable(): idem
* bgpTrapEstablished(): idem
* bgpTrapBackwardTransition(): idem
* bgpd/bgpd.c
* peer_create(): idem
* peer_uptime(): idem
* bgp_master_init(): idem
* bgpd/bgp_fsm.c
* bgp_clearing_completed(): only used in one file, can be static
* bgpd/bgp_packet.c
* afi2str(): sayonara
* safi2str(): sayonara
* bgpd/bgp_route.c
* bgp_distance_reset(): sayonara
* bgpd/bgp_zebra.c
* bgp_ifindex_by_nexthop(): sayonara
* bgp_fsm.c: I have found an fd leak in bgpd that is caused by the 'new'
Clearing state. I've been seeing it from hold timer failures, but it can
also be triggered by other things.
When Hold_Timer_expired fires in Established state, a notify is sent and
BGP_Stop event queued. The fsm then transitions into Clearing state.
That is the problem; When the BGP_Stop event is serviced, the state table
says to ignore it while in Clearing. Thus bgp_stop is not called and the
fd leaks. Previously the peer would be in Idle state, which correctly
handles the BGP_Stop event.
Fix by making bgp_stop safe to call from Clearing state, without losing
ClearingCompleted events, and then ensuring it is called prior to
transition from Clearing->Idle.
