Incorrect manual next hop attribute

[Ondrej Zajicek]

On Thu, Feb 07, 2013 at 11:17:48AM +0200, Jordan Grigorov (Neterra NMT) wrote:
> To be more specific we receive a route at a subinterface eth1.10 and  
> announce it to a subinterface eth1.192 with next hop 192.168.0.50.
> We modify the next hop using the following function. AS65065 is the  
> exact peer that we would like to alter the nexthop of received prefixes.

So the bgp_next_hop was changed in import filter? That would make sense.
The code in BIRD works that when route is exported to single-hop eBGP,
then bgp_next_hop is stripped and replaced with local IP if the route
came from an different interface. Then the export filter is executed. So
you could change it in the export filters and it should work (AFAIK, but
i didn't test that), but it is probably less convenient.

We probably should add some option to never touch the bgp_next_hop and make
it default for route servers, but the current behavior is as i wrote above.

-- 
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/20130207/e508298b/attachment-0001.asc>