MBGP: eBGP multihop session incorrect gw attribute value when resolving nexthop

[Sergey Popovich]

I do not know is there is really BUG and should be reported in special
manner or our configuration weakness, so I consider to ask before.

Deploying BIRD for IPv6 recently on one of the our new Access Server
we spot problem: routes not installed by kernel protocol in kernel's
routing table.

  Multihoop MBGP session successfuly established with our RSs (OpenBGP)
and route information exchanged in both directions:
(confirmed by
 birdc6 'show route export as65001_rs1' and
 birdc6 'show route protocol as65001_rs1').

  Routing information received from RSes received with correct nexthop
(confirmed by
 birdc6 'show route protocol as65001_rs1 all' and
 network packet analyzer)

  But BIRD's `gw` attribute is set to :: (contrary to non ::
(not link-local) nexthop received from RSes!)

Our configuration follows
=========================
We have an Access Server on which we plan to use dual-stack configuration
and two Route Servers based on OpenBGP to establish multihop eBGP session
with.

Configuration for both BGPv4 and MBGP differs only in session network protocol
(BGPv4 - over IPv4, MBGP - over IPv6) and small set of filter rules 
(especially
address family dependent). BIRD's version also equal (1.3.9).

So far we have no such problem for BGPv4 (IPv4 configuration).

Here's BIRD's configuration summary comes
-----------------------------------------

###
## Direct
###

protocol direct direct254 {
	# These routes are not installed in kernel by "kernel254" protocol
	# (they already installed by kernel (proto kernel)).
	#
	# Import these routes to BIRD's internal table to let BIRD correctly
	# resolve recursive nexthops and late install (by kernel254) into
	# kernel routing table.
	interface "bond0.*";
}

###
## Static
###

# Install in kernel routing table to route MBGP session packets
# to RSes
protocol static static254 {
	# RS1 & RS2
	route <rs1_ipv6_address>/128 via <gw_ipv6_to_rs>;
	route <rs2_ipv6_address>/128 via <gw_ipv6_to_rs>;
}

###
## Kernel
###

protocol kernel kernel254 {
	persist no;
	scan time 120;
	learn yes;
	device routes no;
	kernel table ipt_main;
	import filter {
		# Import only routes marked as static
		if krt_source != ipp_static then
			reject;
		accept;
	};
	export all;
}

###
## BGP
###

# Common BGP session template
template bgp bgp_templ {
	capabilities yes;
	advertise ipv4 yes;
	enable route refresh yes;
	enable as4 yes;
	start delay time 10;
	connect retry time 60;
	startup hold time 30;
	keepalive time 10;
	hold time 30;
	### This is default for multihop ###
	gateway recursive;
}

# RS server
filter fl_import_from_as65001
{
	# Apply ingress route policy here

	###
	### This is quick (and wery dirty!) workaround for problem:
	###   Explicitely overwrite `gw' attribute with nexthop value.
	###
	### Tested and found working. Should be considered as temporary.
        ###
	if gw = :: then
		gw = bgp_next_hop;

	accept;
}

filter fl_export_to_as65001
{
	# Apply egress route policy here

	accept;
}

template bgp bgp_templ_rs from bgp_templ {
	multihop 4;
	local <our_ipv6_address> as 65002;
	import filter fl_import_from_as65001;
	export filter fl_export_to_as65001;
}

# as65001, rs1
protocol bgp as65001_rs1 from bgp_templ_rs {
	neighbor <rs1_ipv6_address> as 65001;
}

# as65001, rs2
protocol bgp as65001_rs2 from bgp_templ_rs {
	neighbor <rs2_ipv6_address> as 65001;
}

Detailed problem investigation
==============================

This problem probably comes from bgp_set_next_hop() in proto/bgp/packets.c.

For IPv6 we have allocating an array of nexthops (with index 0 for NEXT_HOP
from packet (or zero if none) and 1 for Link-Local), but
it seems in bgp_attach_next_hop() in proto/bgp/packets.c we might set
nexthop[1] with IPA_NONE in case no LL address received in update
(which is in case of multihop configuration).

It seems we need additionally (only?) check for ipa_nonzero(nexthop[1]) in
bgp_set_next_hop() as this done in bgp_format_next_hop() and 
bgp_create_update()
in proto/bgp/attrs.c.


-- 
SP5474-RIPE
Sergey Popovich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bird-1.3.9-fix-mBGP-multihop-gateway-resolution.patch
Type: text/x-patch
Size: 581 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20130327/750f07f9/attachment.bin>