On Thu, Jul 27, 2017 at 05:55:40PM +0200, Job Snijders wrote: > Hi all, > > Here is a patch to decode received BGP shutdown communication messages > as specified in RFC 8203. In the following example scenario I'm sending > a shutdown communication with openbgpd: > > $ bgpctl neighbor 94.142.241.204 down "TICKET-2331 we are upgrading, > back in 30 min" > request processed
Hi Merged with some significant changes, with support for both RX and TX of shutdown communication: https://gitlab.labs.nic.cz/labs/bird/commit/cd1d99611e445c9fe2452d05627ccfc624f35c39 I generalized it a bit, so the message is not specific to BGP, but can be attached to any protocol, so it makes sense that it can be changed by general commands like disable, restart. That means it also changed the output a bit: bird> show protocols all bgp2 name proto table state since info bgp2 BGP master down 19:39:00 Description: My BGP session Message: Planned shutdown, back in 30 min Preference: 100 Input filter: ACCEPT Output filter: (unnamed) BGP state: Down Neighbor address: 10.0.1.1 Neighbor AS: 10 Conceptually, it is one-item mailbox, which can be set by either the core (using enable/disable/restart commands) or the protocol (received BGP Notification with the RFC 8203 message). I am not sure if it would not be better to have two separate mailboxes for both directions, but it probably does not matter. The message can be send from BIRD shell: birdc> disable bgp1 "hi, we will upgrade to bird 1.6.4" Unfortunately, that means that from Unix shell you have to do double qouting: birdc disable bgp1 '"hi, we will upgrade to bird 1.6.4"' Currently no support for message associated with 'disabled' in bird.conf or for message associated with BIRD global shutdown. Otherwise, there are some minor changes w.r.t. your patch: 1) Your patch requires that RFC 8203 message fills the entire space of BGP notification (i.e. msg_len + 1 == remaining_len). I do not see any such requirement in RFC 8203, so i accept if (msg_len + 1 <= remaining_len) 2) I reset the message not with any RX notification, but only with administrative shutdown/reset notification. That prevents message reset with subsequent errors unrelated to administrative notification. 3) Proper handling of zero-length messages (should be handled equally like no message at all according to RFC 8203). 4) Some basic sanitization of received strings to avoid escape-attacks and newlines in logs. Any comments, suggestions, opposition? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
