samrussell / beeper Goto Github PK

We don't know how to handle these - the app dies, which kind of helps, but it should probably handle it gracefully and return to active state

We need to handle Update messages, which allows us to not blow up when we receive routes, but also allows us to share routes in the future

Need a way to check if we have enough data on the socket to continue rather than blocking. There's a rare case where we get half a BGP message and need to cache the first half, but it'll happen often enough that we'll get into trouble if we don't handle that correctly.

They unpack ok (breaking the RFC by not preserving transient options), need to make them pack so we can send route updates

From the RFC (ignore the manualstart/stop events)

Active

• When an Open message is received:
  -- Ignore contents of the Open message (handle Open and BGP error checking in another issue)
  -- Send an Open message
  -- Send a Keepalive message
  -- Advance to OpenConfirm
  -- Start the keepalive and hold timers (should be based on the open message but just use config for now)
• When a Notification message is received:
  -- Move to the idle state (no way out of there)
  -- It is up to the holder of the Beeper to handle the socket (we need some way to alert when this happens)
• When a Shutdown event is received:
  -- Move to the idle state (no way out of there)
  -- It is up to the holder of the Beeper to handle the socket
• When any other event happens (mainly Update message, possibly more timers later on but make this a catch-all):
  -- Move to the idle state (no way out of there)
  -- It is up to the holder of the Beeper to handle the socket (we need some way to alert when this happens)

OpenConfirm

• When a Shutdown event is received:
  -- Send a notification message with Cease
  -- Move to the idle state (no way out of there)
  -- It is up to the holder of the Beeper to handle the socket
• When the hold timer expires (timer expired event and hold timer is done)
  -- Send a notification message with error code hold timer expired
  -- Move to the idle state (no way out of there)
  -- It is up to the holder of the Beeper to handle the socket (we need some way to alert when this happens)
• When the keepalive timer expires (timer expired event and keepalive timer is done)
  -- Send a keepalive message and reset the timer
• When a Keepalive message is received:
  -- Reset the hold timer
  -- Move to the Established state
• When a Notification message is received:
  -- Move to the idle state (no way out of there)
  -- It is up to the holder of the Beeper to handle the socket (we need some way to alert when this happens)
• When an Open message is received:
  -- Send a notification message with Cease
  -- Move to the idle state (no way out of there)
  -- It is up to the holder of the Beeper to handle the socket (we need some way to alert when this happens)
• When any other event happens (mainly Update message, possibly more timers later on but make this a catch-all):
  -- Send a notification message with error code Finite State Machine Error
  -- Move to the idle state (no way out of there)
  -- It is up to the holder of the Beeper to handle the socket (we need some way to alert when this happens)

Established

• Normal processing for Keepalive and Update messages (resetting hold timer)
• Process everything else like OpenConfirm (except Keepalive keeps us in this state)
• No error detection here yet (we'll accept messages with valid headers that parse correctly)

When we move to the idle state nothing is really defined - we should throw an error or something once we end up in idle (possibly raise an event when transitioning here too)

We use gevent here, using eventlet might let it play a bit nicer with faucet

Handle both IPv4 and IPv6 peers and route updates

We just accept things (I think it explodes on bad marker), but we need to deal with them correctly (mostly by firing off notification messages and exiting)

We've got hardcoded values in Beeper - let them be passed in as part of init, and maybe some sane defaults for others

We don't handle keepalive or hold timers in the base case (run.py), these need to send a keepalive or kill the session when triggered, and also be replenished when we send or receive a keepalive, respectively

Magic numbers everywhere, it'll just take a simple set of consts - even the codes (not subcodes) will make a huge difference

Need a way to send routes - mandatory fields are origin, AS path (just use self) and next_hop

We ignore the capabilities field when doing open messages, this probably isn't the end of the world but needs to be handled at some point

Faucet queries uptime stats on peers, we should be able to do this too

Make this into a package that we can pip install

Might be able to go live without this, not really my call, but it does seem like a useful feature