as-override equivalent for OpenBGPD
Hi All, I'm currently implementing some multi-site redundancy across data centers and I'm planning on doing it with a single AS. I can do it on my other JunOS routers via as-override (allows routes originating from an AS to be accepted by a router residing in the same AS), which is not the default for BGP, of course. I checked through bgpd.conf, but asides from transparent-as, I didn't see any other features that would let me do what I'm trying to do. Any suggestions or work arounds? -casey
Re: OpenBGPD selecting wrong nexthop over openvpn tunnel
On Nov 22, 2007, at 2:42 AM, Henning Brauer wrote: bgpctl show nexthop probably does not list tun0 for 10.8.1.2? in the logs, you'll see a "nexthop 10.8.1.2 now valid" message, what does it say exactly? I do have tun0 listed in the nexthop: gw0# bgpctl sh nexthop Nexthop State 10.8.1.2 valid tun0UP gw0# Regarding the 'now valid' messages, just cycles between these 2: nexthop 10.8.1.2 now invalid nexthop 10.8.1.2 now valid: via 10.8.1.248 -casey
Re: OpenBGPD selecting wrong nexthop over openvpn tunnel
On Nov 21, 2007, at 3:30 PM, Henning Brauer wrote: what does "route -n get 10.8.1.2" show? I suspect there's a bug with tun not setting the ifindexin the routing message (*sigh*, another one) gw0# route -n get 10.8.1.2 route to: 10.8.1.2 destination: 10.8.1.2 interface: tun0 flags: recvpipe sendpipe ssthresh rtt,msecrttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 -casey
Re: OpenBGPD selecting wrong nexthop over openvpn tunnel
Also pardon the double post that will soon follow. I thought my mail
client had fed this mail to a black hole so I sent another.
-casey
On Nov 21, 2007, at 9:51 AM, Casey Ransom wrote:
Hi all,
I've been doing some testing with OpenBGPD to possibly replace
quagga/zebra on some of our host based routers. One problem I
have found is that when it is connecting to a peer over a tun
device (we use openvpn), the bgp daemon gets the proper nexthop
information but when it is added to the routing table, it installs
the local address as the nexthop to the routes it received. I
can't decide if this is an undocumented function or a bug, but I
can replicate it over both FreeBSD (our main platform) and OpenBSD
and using all versions of openbgpd I could find. For example, I
have a machine at 10.8.1.248 connecting to 10.8.1.2:
tun0: flags=8051 mtu 1500
inet 10.8.1.248 --> 10.8.1.2 netmask 0x
Opened by PID 49178
The connection is working fine and quagga<->quagga connections work
normally (10.8.1.2 is a FreeBSD 6.1 machine) with a translated but
identical functionality configuration.
10.8.1.2 has all the interesting routes I want to see from
10.8.1.248, but the daemon is installing 10.8.1.248 as the nexthop
to those routes, for example:
gw0# bgpctl sho ip bgp | grep 10.3.116.33/32
10.3.116.33/32 10.8.1.2 100 0 64820 65502
64830 64910 i
gw0# netstat -nrf inet | grep 10.3.116.33/32
10.3.116.33/32 10.8.1.248 UG1 00 fxp0.1
It's baffling me as bgpd is reporting the nexthop as 10.8.1.2, but
is actually installing 10.8.1.248, which makes no sense to me.
This is a pretty cut and dry ebgp session, nothing fancy going on.
bgpd.conf:
AS 65530
router-id 10.8.1.248
log updates
fib-update yes
network 10.12.0.0/16
neighbor 10.8.1.2 {
remote-as 64820
descr 'at-br1.sv'
}
From the other side of the connection, the 10.12/16 network is
advertised normally and that route is propagated. I also tried
(without luck) to set the nexthop to 10.8.1.2 to force it to use
the correct IP, but only get repeated messages of:
nexthop 10.8.1.2 now valid: via 10.8.1.248
nexthop 10.8.1.2 now invalid
I looked through the openbgpd source but it quickly went over my
head. Any ideas?
-casey
OpenBGPD not inserting correct nexthop over openvpn tunnel
Hi all,
I'm having some issues with OpenBGPD across a point-to-point openvpn
link. Some quick background: we have a number of quagga based
FreeBSD machines doing BGP sessions for our redundancy and due to
some recent backstabbing by quagga, want to test out openbgpd. It
worked well in a normal setup with full tables and advertising our
networks, but we hit a snag when we attempted to do some routing over
a couple vpn links. Over the tun link, OpenBGPD connects to the peer
and advertises the networks properly, but when selecting the nexthop
for the remote side prefixes, it installs the local IP in to the
routing table. I've tested every version of OpenBGPD I could get my
hands on (and I'm currently using the latest release) and have tested
it on OpenBSD and FreeBSD (currently using FreeBSD in this example,
but I can duplicate it on OpenBSD too)
For example, our tunnel interface looks like:
tun0: flags=8051 mtu 1500
inet 10.8.1.248 --> 10.8.1.2 netmask 0x
Opened by PID 49178
10.8.1.2 has a number of routes I'm interested in. When I start up
openbgpd, I'll get the normal route update messages:
neighbor 10.8.1.2 (AS64820) update 10.14.112.20/32 via 10.8.1.2
neighbor 10.8.1.2 (AS64820) update 10.14.113.5/32 via 10.8.1.2
neighbor 10.8.1.2 (AS64820) update 10.14.113.4/32 via 10.8.1.2
etc
and the BGP RIB has the same info:
*>10.14.113.1/32 10.8.1.2 100 0 64820 65400
65402 i
*>10.14.113.2/32 10.8.1.2 100 0 64820 65400
65402 i
*>10.14.113.4/32 10.8.1.2 100 0 64820 65400
65402 i
etc
but when I look at the routes installed in the kernel:
10.14.113.1/32 10.8.1.248 UG1 00 fxp0.1
10.14.113.2/32 10.8.1.248 UG1 00 fxp0.1
10.14.113.4/32 10.8.1.248 UG1 00 fxp0.1
This is a very straightforward ebgp connection, bgpd.conf is below.
This was translated from a quagga/zebra configuration which is
identical and works properly. I've also tried adding a nexthop
10.8.1.2 but the nexthop still isn't set properly. I started looking
through the openbgpd source but it quickly went over my head. Is
this a bug or a behavior that I can't find any documentation on? Any
ideas?
bgpd.conf:
gw0# cat /usr/local/etc/bgpd.conf
AS 65530
router-id 10.8.1.248
log updates
fib-update yes
network 10.12.0.0/16
neighbor 10.8.1.2 {
remote-as 64820
descr 'at-br1.sv'
}
-casey
OpenBGPD selecting wrong nexthop over openvpn tunnel
Hi all,
I've been doing some testing with OpenBGPD to possibly replace quagga/
zebra on some of our host based routers. One problem I have found
is that when it is connecting to a peer over a tun device (we use
openvpn), the bgp daemon gets the proper nexthop information but when
it is added to the routing table, it installs the local address as
the nexthop to the routes it received. I can't decide if this is an
undocumented function or a bug, but I can replicate it over both
FreeBSD (our main platform) and OpenBSD and using all versions of
openbgpd I could find. For example, I have a machine at 10.8.1.248
connecting to 10.8.1.2:
tun0: flags=8051 mtu 1500
inet 10.8.1.248 --> 10.8.1.2 netmask 0x
Opened by PID 49178
The connection is working fine and quagga<->quagga connections work
normally (10.8.1.2 is a FreeBSD 6.1 machine) with a translated but
identical functionality configuration.
10.8.1.2 has all the interesting routes I want to see from
10.8.1.248, but the daemon is installing 10.8.1.248 as the nexthop to
those routes, for example:
gw0# bgpctl sho ip bgp | grep 10.3.116.33/32
10.3.116.33/32 10.8.1.2 100 0 64820 65502
64830 64910 i
gw0# netstat -nrf inet | grep 10.3.116.33/32
10.3.116.33/32 10.8.1.248 UG1 00 fxp0.1
It's baffling me as bgpd is reporting the nexthop as 10.8.1.2, but is
actually installing 10.8.1.248, which makes no sense to me. This is
a pretty cut and dry ebgp session, nothing fancy going on.
bgpd.conf:
AS 65530
router-id 10.8.1.248
log updates
fib-update yes
network 10.12.0.0/16
neighbor 10.8.1.2 {
remote-as 64820
descr 'at-br1.sv'
}
From the other side of the connection, the 10.12/16 network is
advertised normally and that route is propagated. I also tried
(without luck) to set the nexthop to 10.8.1.2 to force it to use the
correct IP, but only get repeated messages of:
nexthop 10.8.1.2 now valid: via 10.8.1.248
nexthop 10.8.1.2 now invalid
I looked through the openbgpd source but it quickly went over my
head. Any ideas?
-casey
