Propagating /32 from OSPF to BGP

[Ondrej Zajicek]

On Wed, Jun 19, 2013 at 12:46:04PM +1200, Michael Ludvig wrote:
> Hi
> 
> we've got a private AS with two uplinks to our ISP, and we've got a
> number of subnets that we advertise. Now we got a new assignment and it
> doesn't work as expected.
> 
> Here is the situation:
> 
> ...
> 
> As it is now a ping from outside to x.x.74.113 (that's advertised as
> /31) goes to GW_1, which is correct and a ping to x.x.74.114 (that's
> advertised as /32) goes to GW_2, that's incorrect.
> 
> How come? I can't see what am I doing wrong...?

Hi

The main question is whether there is any reason why ISP should prefer
these routers from GW_1 or from GW_2. Unless you do some attribute
modification in export filters then IMHO there is no such reason - IGP
metric is not propagated through eBGP and therefore ISP receives two
more or less equivalent routes for the same prefix. It is strange that
it chooses different GW for x.x.74.112/31 and for x.x.74.114/32 - when
routes are the same, ISP should consistently choose one received from
the router with smaller router ID, but it could be configured to use RFC
5004 behavior and prefer the older one, which would be nondeterministic.

The solution would be to propagate IGP metric as BGP MED attribute
(and ensure that ISP do not ignore this attribute). If you are sure
that ospf_metric2 is the same, you could do that simply by using 
'bgp_med = ospf_metric1;' for routes from OSPF in BGP export filters.

Also, the best info would be to see these routes (with their BGP attributes)
on ISP router.

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago at 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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20130619/222eb8e4/attachment-0001.asc>