peeringtestbed / client Goto Github PK

Requires extending the functions that interact with BIRD and file paths so they correctly refer to BIRDv4 and BIRDv6 instances and file paths.

Document that containers in amsterdam01 do not have enough RAM to run BIRD. Clients must run BIRD on their client (i.e., outside of the mux) to manage the control plane, but can still run programs to interact with the data plane on the container.

Fix enum field in JSON announcement schema; should inline a comment about people needing to change the value to the prefix allocated to them.

59bd40a#r33458183

We should briefly describe how clients can use dataplane by routing traffic through a specific table

Issue by bschlinker
Sunday Jan 26, 2014 at 08:41 GMT
Originally opened as https://github.com/PEERINGTestbed/client-update/issues/8

For all intensive purposes, disabling reverse path filtering is a good idea for TP mux clients. Follow-up will be provided at a later date.

The legacy configuration guide is outdated (it is from the time when we used Quagga). Bringing it up to date would make it a starting point for people who need functionality not provided by the default client control scripts.

In the help text for the '-c' option it says:

-c id       Attach community (47065,id) to the announcement.  This
            will let the announcement through peer with the given
            id.  May be added multiple times to announce **from**
            multiple peers.  [default: announce to all peers]
            (see https://peering.usc.edu/peers for the list of peers)

I think that 'from' should be a 'to', right?
Also:

[default: announce to all peers]

When announcing via: ./peering prefix announce -m amsterdam01 <prefix> I noticed that not all amsterdam01 peers (according to PEERING website) actually see the prefix.

Check return code from OpenVPN to determine if VPN started successfully. If it doesn't, print error message along with path of logfile to check.

If OpenVPN dies, the PID in the PID file will become invalid.

Right now, status checks will always try to send a signal to that PID. However, if that PID is invalid, you get an error like this:
error [openvpn/logs//tap5.pid exists but cannot send signal]

Issue by bschlinker
Saturday Jan 25, 2014 at 02:59 GMT
Originally opened as https://github.com/PEERINGTestbed/client-update/issues/2

vtysh must be enabled in debian.conf
bgpd must be enabled in daemons

We should automatically run ip rule add from 184.164.224.0/19 table 151 when Bird comes up.

(Note we use table 151 in the client to support installations with old version of Bird that support only 255 routing tables.)

Seems good to change tap5.log -> amsterdam01.log and so on.

Probably should also add a log command, which just dumps the log file to console.

migrate function openvpn_all (PR#424 apiclient-sh.source) to peering-openvpn file on client repo. It is being used in multiple containers.

peering should not fail if I do not have a prefixes.txt. It should warn that there's no prefixes provided.

If no tun device exists, we should advise the user that they may need to create one...
https://serverfault.com/questions/429461/no-tun-device-in-lxc-guest-for-openvpn

Exclude everything except ca.crt

This prevents accidental commits of client certificates

1. When a VPN session is being brought up, we should wait for the session to come up before returning. We could do this by listening to a dynamically generated status file (that is passed into the openvpn config) or by querying the management socket.

2. If I call up multiple times on the same remote server the client becomes out of state because it will overwrite the existing PID file, try to start another OpenVPN client, and then discover that it cannot start a new connection, as another connection is already running. Since the PID file has been overwritten, the associated OpenVPN client becomes a "zombie", unmanageable by the wrapper tools.

We need to expand the JSON schema for announcement specifications to support IPv6 prefixes. Example limitation:

Hi,

After starting my muxes with peering openvpn up MUX for every mux listed in peering openvpn status, I then run peering bgp start.

However, it then returns this error:
bird: /home/user/peering/client/configs/bird/bird.conf, line 9: syntax error

In configs/bird/bird.conf, the error is the first table line:

log "var/bird.log" all;

table rtup;
table igptable;
...

The output of bird --version: BIRD version 2.0.2

I am running on Arch Linux, Kernel 4.15.13-1-ARCH. I installed Bird with pacman -Sy bird.

The documentation does not state which bird version you are using. I believe that is the issue.

Thanks

Check:

• Prefixes included
• ASNs included
• Muxes included

SBU is no longer hosting a PEERING mux, and the Phoenix-IX mux is unreachable.

If the client's VPN credentials are expired, they should be notified.

Sockets bound to a specific network device (say tun9) and sourcing packets from a PEERING address (say 184.164.224.1) will get routed by table 151 due to the source-routing rule from 184.164.224.0/24 lookup 151. This rule is added for each prefix announced through the client.

One problem is that if the client is connected to multiple muxes, BIRD may have multiple choices for a given destination prefix and will install its preferred route to table 151. If the user tries to ping -I tap9 8.8.8.8, Linux will look for the gateway on table 151. If the route BIRD prefers is not through the mux connected to tap9, then the gateway will not be locally reachable on tap9, Linux has no valid route, and will resort to ARP'ing for the destination over the OpenVPN tunnel (which had me confused until I figured this out).

To avoid this issue, we should maintain mux-specific tables that need to be populated by BIRD. We then need to source-route packets from sockets bound to a specific interface using that table by creating rules with oif tapX lookup 100+X prio 100+X. Note that the priority needs to be higher (lower number) than 151 so the oif rule gets applied first for sockets bound to specific interfaces.

Users have reported an unbounded variable error in our scripts; needs investigation. Here is a snipped of the faulty code:

line 186:     for poison in "${poison_list[@]}" ; do

Communities such as (47065,0) are valid, but not permitted currently.

With #9 this would enable the client to answer pings and traceroutes. Need something like ip addr add $prefix.1/32 dev tap1.

we no longer need prefix identifiers. rename this file and move it somewhere up in the hierarchy to make it clearer that it is just a list of prefixes that clients should be messing up with.

It is not supported by older versions of BIRD (1.4?), should leave it commented out so people who need it enable it on demand.

The website not generates client configs, we need to automatically push them to this repository.