Henning Brauer wrote:
* Graeme Lee <[EMAIL PROTECTED]> [2008-08-21 03:31]:
Henning Brauer wrote:
* Graeme Lee <[EMAIL PROTECTED]> [2008-08-21 01:51]:
I've had to connect to a new upstream peer which is advertising an IPv4
safi of 128 (MPLS-labelled VPN address)
see http://www.iana.org/assignments/safi-namespace
I've modified the source to temporarily ignore this (actually anything
over 127) as it currently only accepts 1 thru 3. Once the session is
established, everything works well. What I really need to know is if
this is potentially A Huge Mistake, or should bgpd be able to ignore
unsupported capabilities being advertised to it?
the standards are pretty unclear about it, but the most logical
interpretation is that we have to send back a notification telling the
peer that we don't support this so capability negotiation actually works.
what is the peer? first time i hear sth doens't work w/ capa negitiation...
The peer is NexGen networks. I gather they're using an Alcatel OS/R.
All I've done to work around this at present is extended the test in
session.c to ignore mp_safi < 128 after the first test fails. Otherwise I
just get this in the log every 30 seconds:
Aug 19 11:01:30 gw-nexgen bgpd[22795]: neighbor 121.200.227.93 (NexGen):
state change Idle -> Active, reason: Start
Aug 19 11:01:30 gw-nexgen bgpd[22795]: neighbor 121.200.227.93 (NexGen):
state change Active -> OpenSent, reason: Connection opened
Aug 19 11:01:30 gw-nexgen bgpd[22795]: neighbor 121.200.227.93 (NexGen):
parse_capabilities: AFI IPv4, mp_safi 128 illegal
Aug 19 11:01:30 gw-nexgen bgpd[22795]: neighbor 121.200.227.93 (NexGen):
state change OpenSent -> Idle, reason: OPEN message received
oh. you're not talking about a capability but a safi. otoh i don't
really remember the what the standards demand about that. we can
probably ignore unknown safis there since that is just the neighbor
telling us he would accept prefixes of that safi.
Yes but the safi's are handled during capability negotiation (in
function parse_capabilities in session.c)
Do I need to do more than just ignore the unknown safi's? Currently,
the return (-1) in the mp_safi test never allows the connection to
establish. Removing this at least allows the bgp session to function,
but I'm not sure if that's all that's needed, or even if it's safe to do so.
BGP neighbor is 121.200.227.93, remote AS 38809
Description: NexGen
BGP version 4, remote router-id
BGP state = Established, up for 5d00h00m
Last read 00:00:02, holdtime 90s, keepalive interval 30s
Neighbor capabilities:
Multiprotocol extensions: IPv4 unknown (128)
Route Refresh
