bgpd: fix fast external fallover behavior

ISSUES

1. When an interface goes down, the zclient callbacks are invoked
   in the following order: (a) address_delete() that removes the
   connected address list: ifp->connected, (b) interface_down()
   that performs "fast external fallover" operation. The operation
   relies on ifp->connected to look for peers that should be brought
   down. That's a cyclic dependency.

2. 'ttl-security' configuration handler sets peer->ttl to
   MAXTTL (so that BGP packets are sent with TTL=255, as per the
   requirement of ttl-security). This, however, is incompatible
   with 'fast external fallover' as the fallover operation checks
   for (ttl == 1) to determine directly connected peers.

3. The current fallover operation does not work for IPv6 address family.

PATCH

1. The patch removes the dependency on 'ifp->connected' list for fast
   fallover. The peer already contains a nexthop structure that reflects
   the peering address. The nexthop structure has a pointer to the
   interface (ifp) that peering address resolves to. Everytime the TCP
   connection succeeds, the ifp is updated. The patch uses this ifp in
   the interface_down() callback for a match for the peers that should be
   brought down.

2. The evaluation for directly connected peering is enhanced as
   'peer->ttl == 1' OR 'peer->gtsm_hops == 1'. Thus a ttl-security
   configuration on the peer with one hop is directly connected and
   should be brought down under 'fast external fallover'.

3. Because of fix (1), IPv6 address family works automatically.

Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com>
Reviewed-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
bgpd: factor out TTL setting

TTL/min TTL are set from both bgp_accept() and bgp_connect().  Factor
them out so the following change to enable iBGP GTSM becomes more
readable.

[DL: originally by Dinesh G Dutt <ddutt@cumulusnetworks.com>,
     split off from the next commit]
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
bgpd: factor out eBGP multihop check

The check for an eBGP multihop configuration is unwieldy;  factor it out
into a separate function.

[DL: originally by Dinesh G Dutt <ddutt@cumulusnetworks.com>,
     split off from the next commit]
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
bgpd: support TTL-security with iBGP

Traditionally, ttl-security feature has been associated with EBGP
sessions as those identify directly connected external peers. The
GTSM RFC (rfc 5082) does not make any restrictions on type of
peering. In fact, it is beneficial to support ttl-security for both
EBGP and IBGP sessions. Specifically, in data centers, there are
directly connected IBGP peerings that will benefit from the protection
ttl-security provides.

Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Reviewed-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com>
[DL: function refactoring split out into previous 2 patches.  changes:
     - bgp_set_socket_ttl(): ret type int -> void
     - is_ebgp_multihop_configured(): stripped peer == NULL check
     - comments/whitespace]
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
bgpd: Fix condition allowas-in in rsclient code

Currently when you set neighbour's 'allowas-in' option on route server side
you get redistribution of the prefixes from this neighbour's table into all
neighbour's tables which have the same AS number. I think that wanted behaviour
is to allow import prefixes from neighbour's tables with the same AS num
into neighbour which has 'allowas-in' option set.

Signed-off-by: Milan Kocian <milon@wq.cz>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>