Re: Incorrect manual next hop attribute
On Tue, Feb 05, 2013 at 11:15:06AM +0200, Jordan Grigorov (Neterra NMT) wrote:
Hello,
I think our scenario does not contradicts with BGP standard (RFC 4271 5.1.3).
Assuming a Bird RS with 2 interfaces: 192.168.0.1/24 eth0 <--> BIRD <--> eth1 10.0.0.1/24
We would like to manually set hext hop(192.168.0.50) of certain routes advertised to BGP neighbors in the segment 192.168.0.0/24.
So you receive route from eth1, change its next hop to 192.168.0.50 and announce to eth0? BIRD checks (for single hop eBGP) whether route was received on the same iface as it is send, but that is done before export filter. Did you modify the next hop in the export filter of outgoing BGP or in the import filter of incoming BGP? Did you really modify it? (You could check that by print in export filter.) How exactly looks your filter? -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@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."
Unfortunately changing it in the export filter also doesn't work. In birdc command line I see the correctly modified next hop but the bgp update sends the local address. Is there any other solution we can test? If you plan to implement such an option to never touch the next hop address when should we expect it?
participants (2)
-
Jordan -
Ondrej Zajicek