| Age | Commit message (Collapse) | Author |
|---|
|
nameley the show ones. needed for looking glass style applications,
monitoring etc. claudio ok
|
|
link between bgpctl and bgpd mostly because of rde_attr.c.
|
|
followed by a START event. Instead of sending START immediately, start the
IdleHoldTimer with a very low value (5 seconds) so that we restart the
session these seconds later. some other implementations deal poorly with
our previously superfast reconnects, namely, that commercial one from
san jose, claudio ok
|
|
when a peer drops to IDLE, we have to force him in IDLE for some time to
prevent fast flapping. however, the forced idle time is annoying when the
connection could be re-established immediately, i. e. bgpctl nei $peer clear
or similar.
implement an error counter per peer, increased every time we receive a
notification. when we are in state IDLE and get a connection from the peer
in question, check if the error counter is 1 or smaller. if so, change state
to active and accept the connection, otherwise keep the current behaviour
and reject the connection.
the error counter gets scaled back by the IdleHoldResetTimer that scales the
IdleHoldTime back as well
|
|
the peer stats struct, and clear them as soon as the session leaves IDLE
|
|
|
|
|
|
|
|
|
|
peer->capa.ann from this
|
|
by two instances of the new struct capabilities, one for announcements
and one for the received capabilities
|
|
individual capability flags where needed
|
|
|
|
disabled for now, claudio ok
|
|
writing to a member of a const struct is no good, so un-const struct peer
for log_statechange()
|
|
-the session alternates between Active and Connect. Other states reset logging
-the error is the same as the last connect() error seen
jajajaja claudio
|
|
|
|
with this, if a neighbor is configured as dependent on carp0 for example,
the neighbor will remain in state IDLE as long as carp0 is not master.
once carp0 becomes master the session(s) depending on it immediately
go to CONNECT (or ACTIVE, if they're configured passive), reducing failover
time. claudio ok, with some input from ryan as well
|
|
ok claudio
|
|
but keep him around for some more time (an hour here).
fixes an issue Arvid was reporting: when a cloned neighbor rejects our OPEN
message due to capability negotiation (or missing implementation of those),
we set a marker and retry without. However, if we remove the peer immediately,
it gets freshly cloned on the next trial, with default settings, thus including
capability negotiation, and thus failes again.
this will also help with route flap dampening.
ok claudio
|
|
the current and max prefix count back to bgpctl. OK henning@
|
|
save 1k per peer. OK henning@
|
|
and not an int.
|
|
we should close
|
|
more than once
|
|
it to let the main process to prepare new listening sockets (socket() and
bind()) on behalf of the session engine, which of course cannot bind() to
ports < 1024 any more once it dropped privileges. with some help from theo,
claudio ok
|
|
we used a ststic one with OPEN_MAX entries, which is a rather arbitary limit
as OPEN_MAX is _not_ the max # of open fds we can have, but just a default
for that setting.
in the same move we have to allocate the peer_l array, basically there
for pfd-index to peer pointers to prevent peer list scans all time,
dynamiccaly to. we overallocate a little and use that reserve until we
have to realloc again later to prevent reallocs for every single control
connection or a single flapping peer.
help & ok claudio
|
|
supported address familiy, keep a tailq of an arbitary number of them.
the new struct listen_addr contains the sockaddr and the fd.
this fixes quite some nasty behaviour which was a consequence of the previous
model.
looks right deraadt@, and discussed with claudio
|
|
at runtime and disable said subsystems if so. helps the guys porting bgpd
to $otherBSD, and is actually the right thing to do. claudio ok
|
|
log_conn_attempt
|
|
|
|
|
|
to send a NOTIFICATION and thus ternminating the session when it sees a
capability it doesn't support (who would guess: zebra does so), parse the
data section of the notifcication to find out what what capabilties it didn't
like and do not advertise them the next time the session gets up. In case we
get a notification about unsupported capabilities with an empty data part
(don't ask for RFCs... and guess who does that), disable capabilty announcement
alltogether.
claudio ok
|
|
otherwise, markus ok
|
|
add a generic "method" field that expresses what method
(none/md5sig/ipsec manual/ipsec ike) is in use
markus ok
|
|
process incoming route refresh request and notify the RDE
not advertised via capabilities yet, claudio ok
|
|
|
|
this implies ourgoing capabilities annoucnement is there and just needs the
values to be filled in for other shitz we'll support soonish
|
|
longer to be synced between parent, SE and RDE. OK henning@
|
|
|
|
|
|
the peer struct, claudio ok
|
|
|
|
|
|
the members after fork
|
|
the list entries and the head there after forking
|
|
this includes handling "unsupported optional parameter" notifications from the
peer and retrying without capability announcement. claudio ok
|
|
|
|
RFC 3392. we don't support any capability yet but this at least avoids one
session teardown and reestablishment when talking to peers which do support
capability announcement (as in: basically any) and we'll start supporting
some soon.
|
|
|
