Re: OT iBGP without full meesh
On 2022-06-27, Ivo Chutkin wrote: > Hello guys, > It is not related to OpenBSD. Since I started my admin "career" with > OpenBGPD and OpenBSD, I just need some thoughts and advises from anyone > more experienced. > > The situation is as follows: > I have 2 border routers in main location. All Upstreams,IX-es and > clients have eBGP sessions. Clients are mostly small regional ISPs. > We carry customers traffic from main location to their region over L2 > vlans. On all regional POPs, I have L3 switches (Brocade ICX6650). > > The idea I have is to make eBGP session with regional ISPs on their > local POP switch and distribute their prefixes to other ISPs connected > there. To make some kind of Internet Exchange on regional level or even > national level for our customers. > > As far as I know, all routers (BGP running switches) in a single AS, > should be connected via iBGP (If I am not mistaken, it is called full > mesh). But, on main routers, I have number of full feeds that regional > switches are not capable to handle. > > Do you think it could be done somehow without iBGP full mesh or it is > stupid idea by design? You do want either full mesh or to use route reflectors, but you don't need to send a full BGP table to all the routers, you can filter in various ways (for example, maybe just carry national routes, or peer routes, or routes with a short AS path length, or...there are lots of options). But you do need to make sure that other destinations are still reachable from routers receiving a partial table so in that case you will want to generate/announce a default route; probably arrange your filters so that the default route is only sent/accepted on those routers with a partial table - for the full table routers you'll usually want _no_ default route so that packets for nonexistent destinations get "net unreachable" rather than maybe flip-flopping between a couple of routers which point default to each other. -- Please keep replies on the mailing list.
OT iBGP without full meesh
Hello guys, It is not related to OpenBSD. Since I started my admin "career" with OpenBGPD and OpenBSD, I just need some thoughts and advises from anyone more experienced. The situation is as follows: I have 2 border routers in main location. All Upstreams,IX-es and clients have eBGP sessions. Clients are mostly small regional ISPs. We carry customers traffic from main location to their region over L2 vlans. On all regional POPs, I have L3 switches (Brocade ICX6650). The idea I have is to make eBGP session with regional ISPs on their local POP switch and distribute their prefixes to other ISPs connected there. To make some kind of Internet Exchange on regional level or even national level for our customers. As far as I know, all routers (BGP running switches) in a single AS, should be connected via iBGP (If I am not mistaken, it is called full mesh). But, on main routers, I have number of full feeds that regional switches are not capable to handle. Do you think it could be done somehow without iBGP full mesh or it is stupid idea by design? Thanks for any help, Ivo
Re: bgpd, announce to ibgp from 2 routers, prefixes only show up from 1
On Mon, Nov 29, 2021 at 10:38:21PM +0100, Sebastian Benoit wrote:
> Stuart Henderson(s...@spacehopper.org) on 2021.11.13 00:11:08 +:
> > I have a pair of -current routers running bgpd (let's call them rtr-a
> > and rtr-b) on a subnet which also has some vpn gateways and firewalls.
> >
> > These routers provide a carp address which the vpn gateways are using
> > as default route. There are some networks behind the vpn gateways (a
> > /32 to accept incoming vpn connections and some other prefixes that vpn
> > clients are numbered from).
> >
> > rtr-a and rtr-b have static routes to those networks, and they have
> > network statements in bgpd.conf to announce them to their ibgp peers
> > ("network 172.24.232.0/21 set nexthop XXX" etc) so the paths are reachable
> > from the rest of the network. (This is replacing an existing setup using
> > ospf, trying to remove routing protocols from machines that don't really
> > need them).
> >
> > It is working but something seems a little odd - the paths are announced
> > from both routers briefly and show up on the rest of the network from
> > both rtr-a and rtr-b. But after a few seconds, rtr-b receives these
> > paths from rtr-a, and then rtr-b stops announcing them itself. (they
> > stop showing in "bgpctl sh rib out" on rtr-b; "bgpctl sh nex" does
> > correctly identify the associated nexthops as connected/UP).
> >
> > Is this expected/correct behaviour?
>
> It is expected: once rtr-b receives the route from rtr-a, it will run the
> route decision process on it. IF both routers are configured identically
> except for the router-id, one of the routes will be prefered at either the
> "oldest path" or the "lowest bgp id" criteria.
>
> As only one route is a best route, that one will be annouced to the
> neighbors. However this is IBGP. In a set of IBGP connected routers, a
> router will not announce a route to other IBGP peers that it received from
> on a IBGP session. Thus, rtr-b will stop announcing that route.
>
> When rtr-a goes down, the session is shut down or the prefix is filtered,
> bgpd wont see the "better" route anymore and announce its own instead.
>
> > I'd prefer to have them announced from both rtr-a and rtr-b, so there's
> > no blackhole period if rtr-a is restarted while rtr-b figures out that
> > it should start announcing them, etc. (No need for tracking carp state
> > in this case, I'm not using stateful pf rules on the traffic involved).
>
> This is a place where ospf might give you faster failover, especiall y with
> the redistribute ... depend on ... syntax.
>
> > If rtr-b stops seeing the prefixes from rtr-a (either by taking down
> > the ibgp session, or by filtering) I see the announcements from both
> > rtr-a and rtr-b again. So the obvious workaround is to filter, but
> > I thought I'd ask first in case it's something that is better handled
> > by code changes rather than config.
Or the other way is to alter localpref, as-path or metric of those routes
in some way that makes sure that both router-A and router-B announce a
"better" route.
You can do this in multiple ways. One way would be to use something like
this:
pass out on ibgp metric +1
or
pass in on ibgp metric -1
Long term it would be nice to reintroduce route metrics and use this
to sort nexthops in bgpd.
--
:wq Claudio
Re: bgpd, announce to ibgp from 2 routers, prefixes only show up from 1
On 2021-11-29, Sebastian Benoit wrote: > > It is expected: once rtr-b receives the route from rtr-a, it will run the > route decision process on it. IF both routers are configured identically > except for the router-id, one of the routes will be prefered at either the > "oldest path" or the "lowest bgp id" criteria. > > As only one route is a best route, that one will be annouced to the > neighbors. However this is IBGP. In a set of IBGP connected routers, a > router will not announce a route to other IBGP peers that it received from > on a IBGP session. Thus, rtr-b will stop announcing that route. Thanks, the explanation makes sense (though it doesn't feel quite like expected behaviour - it makes sense that it doesn't announce the route received over IBGP but seems a little strange that an explicitly configured local announcement from a static route depends on BGP from other routers). Anyway filtering the incoming prefixes is having the desired effect. > When rtr-a goes down, the session is shut down or the prefix is filtered, > bgpd wont see the "better" route anymore and announce its own instead. > >> I'd prefer to have them announced from both rtr-a and rtr-b, so there's >> no blackhole period if rtr-a is restarted while rtr-b figures out that >> it should start announcing them, etc. (No need for tracking carp state >> in this case, I'm not using stateful pf rules on the traffic involved). > > This is a place where ospf might give you faster failover, especiall y with > the redistribute ... depend on ... syntax. Reducing the number of machines running ospfd was the whole reason for changing this. And with the timers I'm having to run on OSPF to get something vaguely approaching stability I can't say that it will be any faster than BGP!
Re: bgpd, announce to ibgp from 2 routers, prefixes only show up from 1
[apologies in advance for top-posting]
bgpd(8) is excellent in many ways, and I am SO very grateful it exists. (Thank
you Henning, Claudio, Peter and everyone else who has contributed to it over
the years! It has straight-up saved my bacon a couple of times.)
But one feature it does not yet AFAIK have is Additional Paths
("additional-path", or just "add-path") [1]. This is where a BGP speaker
advertises not only its "best" routes, but *all* its routes, to its peers. The
FIB remains unchanged, but the RIB can grow very large in a well-connected AS.
Since each router now knows all the available paths through every other router,
convergence is - at least in theory - sped up quite dramatically, and you
mostly avoid the "hole" described. It's not a perfect solution but it works
very well.
If you're brave enough, at least some versions/forks of Bird/Quagga/Zebra have
support for add-path. I wouldn't recommend running these on OpenBSD, generally
speaking - bgpd(8) is more appropriate 99.999% of the time - but you might find
it worthwhile, depending on your needs. Be particularly careful of any routing
software that lacks the ability to affect kernel routes - unless you're just
running a route reflector, that will change your design *significantly*.
Or, as Stuart said, running a "proper" IGP like OSPF could bridge some of the
gaps you might see. YMMV.
-Adam
P.S. From what I heard a few years ago, OpenBSD isn't completely ignoring
add-path, it's just
complex/difficult/time-consuming/unfunded/low-priority/pick-your-favourite-reason.
[1] https://datatracker.ietf.org/doc/html/rfc7911
-Original Message-
From: owner-m...@openbsd.org On Behalf Of Sebastian
Benoit
Sent: Monday, November 29, 2021 3:38 PM
To: misc@openbsd.org
Subject: Re: bgpd, announce to ibgp from 2 routers, prefixes only show up from 1
Stuart Henderson(s...@spacehopper.org) on 2021.11.13 00:11:08 +:
> I have a pair of -current routers running bgpd (let's call them rtr-a
> and rtr-b) on a subnet which also has some vpn gateways and firewalls.
>
> These routers provide a carp address which the vpn gateways are using
> as default route. There are some networks behind the vpn gateways (a
> /32 to accept incoming vpn connections and some other prefixes that
> vpn clients are numbered from).
>
> rtr-a and rtr-b have static routes to those networks, and they have
> network statements in bgpd.conf to announce them to their ibgp peers
> ("network 172.24.232.0/21 set nexthop XXX" etc) so the paths are
> reachable from the rest of the network. (This is replacing an existing
> setup using ospf, trying to remove routing protocols from machines
> that don't really need them).
>
> It is working but something seems a little odd - the paths are
> announced from both routers briefly and show up on the rest of the
> network from both rtr-a and rtr-b. But after a few seconds, rtr-b
> receives these paths from rtr-a, and then rtr-b stops announcing them
> itself. (they stop showing in "bgpctl sh rib out" on rtr-b; "bgpctl sh
> nex" does correctly identify the associated nexthops as connected/UP).
>
> Is this expected/correct behaviour?
It is expected: once rtr-b receives the route from rtr-a, it will run the route
decision process on it. IF both routers are configured identically except for
the router-id, one of the routes will be prefered at either the "oldest path"
or the "lowest bgp id" criteria.
As only one route is a best route, that one will be annouced to the neighbors.
However this is IBGP. In a set of IBGP connected routers, a router will not
announce a route to other IBGP peers that it received from on a IBGP session.
Thus, rtr-b will stop announcing that route.
When rtr-a goes down, the session is shut down or the prefix is filtered, bgpd
wont see the "better" route anymore and announce its own instead.
> I'd prefer to have them announced from both rtr-a and rtr-b, so
> there's no blackhole period if rtr-a is restarted while rtr-b figures
> out that it should start announcing them, etc. (No need for tracking
> carp state in this case, I'm not using stateful pf rules on the traffic
> involved).
This is a place where ospf might give you faster failover, especiall y with the
redistribute ... depend on ... syntax.
> If rtr-b stops seeing the prefixes from rtr-a (either by taking down
> the ibgp session, or by filtering) I see the announcements from both
> rtr-a and rtr-b again. So the obvious workaround is to filter, but I
> thought I'd ask first in case it's something that is better handled by
> code changes rather than config.
Re: bgpd, announce to ibgp from 2 routers, prefixes only show up from 1
Stuart Henderson(s...@spacehopper.org) on 2021.11.13 00:11:08 +:
> I have a pair of -current routers running bgpd (let's call them rtr-a
> and rtr-b) on a subnet which also has some vpn gateways and firewalls.
>
> These routers provide a carp address which the vpn gateways are using
> as default route. There are some networks behind the vpn gateways (a
> /32 to accept incoming vpn connections and some other prefixes that vpn
> clients are numbered from).
>
> rtr-a and rtr-b have static routes to those networks, and they have
> network statements in bgpd.conf to announce them to their ibgp peers
> ("network 172.24.232.0/21 set nexthop XXX" etc) so the paths are reachable
> from the rest of the network. (This is replacing an existing setup using
> ospf, trying to remove routing protocols from machines that don't really
> need them).
>
> It is working but something seems a little odd - the paths are announced
> from both routers briefly and show up on the rest of the network from
> both rtr-a and rtr-b. But after a few seconds, rtr-b receives these
> paths from rtr-a, and then rtr-b stops announcing them itself. (they
> stop showing in "bgpctl sh rib out" on rtr-b; "bgpctl sh nex" does
> correctly identify the associated nexthops as connected/UP).
>
> Is this expected/correct behaviour?
It is expected: once rtr-b receives the route from rtr-a, it will run the
route decision process on it. IF both routers are configured identically
except for the router-id, one of the routes will be prefered at either the
"oldest path" or the "lowest bgp id" criteria.
As only one route is a best route, that one will be annouced to the
neighbors. However this is IBGP. In a set of IBGP connected routers, a
router will not announce a route to other IBGP peers that it received from
on a IBGP session. Thus, rtr-b will stop announcing that route.
When rtr-a goes down, the session is shut down or the prefix is filtered,
bgpd wont see the "better" route anymore and announce its own instead.
> I'd prefer to have them announced from both rtr-a and rtr-b, so there's
> no blackhole period if rtr-a is restarted while rtr-b figures out that
> it should start announcing them, etc. (No need for tracking carp state
> in this case, I'm not using stateful pf rules on the traffic involved).
This is a place where ospf might give you faster failover, especiall y with
the redistribute ... depend on ... syntax.
> If rtr-b stops seeing the prefixes from rtr-a (either by taking down
> the ibgp session, or by filtering) I see the announcements from both
> rtr-a and rtr-b again. So the obvious workaround is to filter, but
> I thought I'd ask first in case it's something that is better handled
> by code changes rather than config.
Re: bgpd, announce to ibgp from 2 routers, prefixes only show up from 1
On Sat, Nov 13, 2021 at 12:11:08AM +, Stuart Henderson wrote:
> I have a pair of -current routers running bgpd (let's call them rtr-a
> and rtr-b) on a subnet which also has some vpn gateways and firewalls.
>
> These routers provide a carp address which the vpn gateways are using
> as default route. There are some networks behind the vpn gateways (a
> /32 to accept incoming vpn connections and some other prefixes that vpn
> clients are numbered from).
>
> rtr-a and rtr-b have static routes to those networks, and they have
> network statements in bgpd.conf to announce them to their ibgp peers
> ("network 172.24.232.0/21 set nexthop XXX" etc) so the paths are reachable
> from the rest of the network. (This is replacing an existing setup using
> ospf, trying to remove routing protocols from machines that don't really
> need them).
>
> It is working but something seems a little odd - the paths are announced
> from both routers briefly and show up on the rest of the network from
> both rtr-a and rtr-b. But after a few seconds, rtr-b receives these
> paths from rtr-a, and then rtr-b stops announcing them itself. (they
> stop showing in "bgpctl sh rib out" on rtr-b; "bgpctl sh nex" does
> correctly identify the associated nexthops as connected/UP).
>
> Is this expected/correct behaviour?
>
> I'd prefer to have them announced from both rtr-a and rtr-b, so there's
> no blackhole period if rtr-a is restarted while rtr-b figures out that
> it should start announcing them, etc. (No need for tracking carp state
> in this case, I'm not using stateful pf rules on the traffic involved).
>
> If rtr-b stops seeing the prefixes from rtr-a (either by taking down
> the ibgp session, or by filtering) I see the announcements from both
> rtr-a and rtr-b again. So the obvious workaround is to filter, but
> I thought I'd ask first in case it's something that is better handled
> by code changes rather than config.
>
This reminds me of the knob "bgp best external" on some routers.
Juniper:
https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/ref/sta
+tement/advertise-external-edit-protocols-bgp.html
Cisco:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/x
+e-17/irg-xe-17-book/bgp-best-external.html
The difference is that in your case it's an internal route
Remi
bgpd, announce to ibgp from 2 routers, prefixes only show up from 1
I have a pair of -current routers running bgpd (let's call them rtr-a
and rtr-b) on a subnet which also has some vpn gateways and firewalls.
These routers provide a carp address which the vpn gateways are using
as default route. There are some networks behind the vpn gateways (a
/32 to accept incoming vpn connections and some other prefixes that vpn
clients are numbered from).
rtr-a and rtr-b have static routes to those networks, and they have
network statements in bgpd.conf to announce them to their ibgp peers
("network 172.24.232.0/21 set nexthop XXX" etc) so the paths are reachable
from the rest of the network. (This is replacing an existing setup using
ospf, trying to remove routing protocols from machines that don't really
need them).
It is working but something seems a little odd - the paths are announced
from both routers briefly and show up on the rest of the network from
both rtr-a and rtr-b. But after a few seconds, rtr-b receives these
paths from rtr-a, and then rtr-b stops announcing them itself. (they
stop showing in "bgpctl sh rib out" on rtr-b; "bgpctl sh nex" does
correctly identify the associated nexthops as connected/UP).
Is this expected/correct behaviour?
I'd prefer to have them announced from both rtr-a and rtr-b, so there's
no blackhole period if rtr-a is restarted while rtr-b figures out that
it should start announcing them, etc. (No need for tracking carp state
in this case, I'm not using stateful pf rules on the traffic involved).
If rtr-b stops seeing the prefixes from rtr-a (either by taking down
the ibgp session, or by filtering) I see the announcements from both
rtr-a and rtr-b again. So the obvious workaround is to filter, but
I thought I'd ask first in case it's something that is better handled
by code changes rather than config.
Re: Reflected IBGP VPNv4 Routes overstaying their welcome
Thanks Claudio, I was hoping you would see this.
I know that you guys fixed some other MPLS bugs as I was affected by
the LDP/ARP issue as well.
I have one PE running -current that I confirmed was no longer getting
the LDP drops/crashes
but I have not tested this against it as I just discovered it.
I'll spin up some test machines and report back what I find out.
-Henry
On Tue, Apr 9, 2019 at 5:48 AM Claudio Jeker wrote:
>
> On Mon, Apr 08, 2019 at 05:08:32PM -0400, Henry Bonath wrote:
> > Hello, I am seeing some BGP VPNv4 routes staying populated in
> > the RIB of route-reflector clients even after dropping the originating
> > neighbor.
> >
> > I'm on OpenBSD 6.4, running MPLS L3VPN.
> >
> > I have 2 IBGP route-reflectors, both OpenBSD 6.4.
> > I run OSPF to distribute Loopbacks into an Area (100)
> > We run Cisco devices for our Provider Edge installed on site at
> > Customer Premise.
> > All MPLS PE devices neighbor with both route reflectors.
> >
> > My bgpd.conf from the route reflectors:
> > ===
> > ASN="64670"
> >
> > # global configuration
> > AS $ASN
> > router-id 172.16.16.212
> > nexthop qualify via default
> >
> > group "IBGP" {
> > remote-as $ASN
> > announce IPv4 vpn
> > route-reflector 172.16.16.212
> > local-address 172.16.16.212
> > neighbor 100.92.64.0/18 {
> > }
> >
> > }
> >
> > # IBGP: allow all updates to and from our IBGP neighbors
> > allow from any
> > allow to any
> > ===
> >
> > bgpd.conf from an OpenBSD PE:
> > ===
> > ASN="64670"
> >
> > # global configuration
> > AS $ASN
> > router-id 100.92.127.121
> >
> > rdomain 2 {
> > rd 64670:37
> > import-target rt 64670:37
> > export-target rt 64670:37
> > # advertise summary of tenant Subnet:
> > network 172.29.21.0/24
> >
> > # Redistribute from OSPF (Priority 32)
> > network inet priority 32
> > depend on mpe1
> > }
> >
> > group "IBGP" {
> > remote-as $ASN
> > announce IPv4 vpn
> > set rtlabel FROM_BGP
> > local-address 100.92.127.121
> > neighbor 172.16.16.211 {
> > descr "bgp-rr-01"
> > }
> > neighbor 172.16.16.212 {
> > descr "bgp-rr-02"
> > }
> >
> > }
> >
> > # IBGP: allow all updates to and from our IBGP neighbors
> > allow from ibgp
> > allow to ibgp
> >
> > ===
> >
> > The problem comes if I shutdown one of my Premise equipment PE
> > devices, or an OpenBSD PE,
> > on the other OpenBSD PEs that remain up, they still show the routes
> > that were advertised by the
> > now shutdown device.
> >
> > If I log into a route reflector and run a "bgpctl show rib" those
> > routes are no longer there as i expected,
> > though they persist at the OpenBSD reflector clients.
> >
> > Example output after shutting down the 100.92.127.21 Cisco PE observed
> > from the OpenBSD PE
> > that is listening to 64670:37 rt/rd:
> >
> > flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
> >S = Stale, E = Error
> > origin validation state: N = not-found, V = valid, ! = invalid
> > origin: i = IGP, e = EGP, ? = Incomplete
> >
> > flags ovs destination gateway lpref med aspath origin
> > I*> N rd 64670:37 192.168.11.0/24 100.92.127.21 100 2 ?
> > I* N rd 64670:37 192.168.11.0/24 100.92.127.21 100 2 ?
> > I*> N rd 64670:37 192.168.15.0/24 100.92.127.21 100 2 ?
> > I* N rd 64670:37 192.168.15.0/24 100.92.127.21 100 2 ?
> > I*> N rd 64670:37 192.168.20.0/24 100.92.127.21 100 3 ?
> > I* N rd 64670:37 192.168.20.0/24 100.92.127.21 100 3 ?
> > I*> N rd 64670:37 192.168.100.0/24 100.92.127.21 100 2 ?
> > I* N rd 64670:37 192.168.100.0/24 100.92.127.21 100 2 ?
> > I*> N rd 64670:37 192.168.110.0/24 100.92.127.21 100 3 ?
> > I* N rd 64670:37 192.168.110.0/24 100.92.127.21 100 3 ?
> > I*> N rd 64670:37 192.168.150.0/24 100.92.127.21 100 2 ?
> > I* N rd 64670:37 192.168.150.0/24 100.92.127.21 100 2 ?
> > I*> N rd 64670:37 192.168.200.0/24 100.92.127.21 100 2 ?
> > I* N rd 64670:37 192.168.200.0/24 100.92.127.21 100 2 ?
> >
> > Shouldn't those routes disappear once the 100.92.127.21 router is shutdown?
> >
> > Thanks for any help you all have to offer!
>
> Are you able to test this with -current? There were some fixes and changes
> done for MPLS VPN support. I have the feeling that this may be already
> fixed. Also I would desiable gracefull restart on the RR with 'announce
> restart no' for the template.
>
> --
> :wq Claudio
>
Re: Reflected IBGP VPNv4 Routes overstaying their welcome
On Mon, Apr 08, 2019 at 05:08:32PM -0400, Henry Bonath wrote:
> Hello, I am seeing some BGP VPNv4 routes staying populated in
> the RIB of route-reflector clients even after dropping the originating
> neighbor.
>
> I'm on OpenBSD 6.4, running MPLS L3VPN.
>
> I have 2 IBGP route-reflectors, both OpenBSD 6.4.
> I run OSPF to distribute Loopbacks into an Area (100)
> We run Cisco devices for our Provider Edge installed on site at
> Customer Premise.
> All MPLS PE devices neighbor with both route reflectors.
>
> My bgpd.conf from the route reflectors:
> ===
> ASN="64670"
>
> # global configuration
> AS $ASN
> router-id 172.16.16.212
> nexthop qualify via default
>
> group "IBGP" {
> remote-as $ASN
> announce IPv4 vpn
> route-reflector 172.16.16.212
> local-address 172.16.16.212
> neighbor 100.92.64.0/18 {
> }
>
> }
>
> # IBGP: allow all updates to and from our IBGP neighbors
> allow from any
> allow to any
> ===
>
> bgpd.conf from an OpenBSD PE:
> ===
> ASN="64670"
>
> # global configuration
> AS $ASN
> router-id 100.92.127.121
>
> rdomain 2 {
> rd 64670:37
> import-target rt 64670:37
> export-target rt 64670:37
> # advertise summary of tenant Subnet:
> network 172.29.21.0/24
>
> # Redistribute from OSPF (Priority 32)
> network inet priority 32
> depend on mpe1
> }
>
> group "IBGP" {
> remote-as $ASN
> announce IPv4 vpn
> set rtlabel FROM_BGP
> local-address 100.92.127.121
> neighbor 172.16.16.211 {
> descr "bgp-rr-01"
> }
> neighbor 172.16.16.212 {
> descr "bgp-rr-02"
> }
>
> }
>
> # IBGP: allow all updates to and from our IBGP neighbors
> allow from ibgp
> allow to ibgp
>
> ===
>
> The problem comes if I shutdown one of my Premise equipment PE
> devices, or an OpenBSD PE,
> on the other OpenBSD PEs that remain up, they still show the routes
> that were advertised by the
> now shutdown device.
>
> If I log into a route reflector and run a "bgpctl show rib" those
> routes are no longer there as i expected,
> though they persist at the OpenBSD reflector clients.
>
> Example output after shutting down the 100.92.127.21 Cisco PE observed
> from the OpenBSD PE
> that is listening to 64670:37 rt/rd:
>
> flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
>S = Stale, E = Error
> origin validation state: N = not-found, V = valid, ! = invalid
> origin: i = IGP, e = EGP, ? = Incomplete
>
> flags ovs destination gateway lpref med aspath origin
> I*> N rd 64670:37 192.168.11.0/24 100.92.127.21 100 2 ?
> I* N rd 64670:37 192.168.11.0/24 100.92.127.21 100 2 ?
> I*> N rd 64670:37 192.168.15.0/24 100.92.127.21 100 2 ?
> I* N rd 64670:37 192.168.15.0/24 100.92.127.21 100 2 ?
> I*> N rd 64670:37 192.168.20.0/24 100.92.127.21 100 3 ?
> I* N rd 64670:37 192.168.20.0/24 100.92.127.21 100 3 ?
> I*> N rd 64670:37 192.168.100.0/24 100.92.127.21 100 2 ?
> I* N rd 64670:37 192.168.100.0/24 100.92.127.21 100 2 ?
> I*> N rd 64670:37 192.168.110.0/24 100.92.127.21 100 3 ?
> I* N rd 64670:37 192.168.110.0/24 100.92.127.21 100 3 ?
> I*> N rd 64670:37 192.168.150.0/24 100.92.127.21 100 2 ?
> I* N rd 64670:37 192.168.150.0/24 100.92.127.21 100 2 ?
> I*> N rd 64670:37 192.168.200.0/24 100.92.127.21 100 2 ?
> I* N rd 64670:37 192.168.200.0/24 100.92.127.21 100 2 ?
>
> Shouldn't those routes disappear once the 100.92.127.21 router is shutdown?
>
> Thanks for any help you all have to offer!
Are you able to test this with -current? There were some fixes and changes
done for MPLS VPN support. I have the feeling that this may be already
fixed. Also I would desiable gracefull restart on the RR with 'announce
restart no' for the template.
--
:wq Claudio
Re: Reflected IBGP VPNv4 Routes overstaying their welcome
So in today's case, I went into the Cisco BGP process and did a "neighbor
x.x.x.x shutdown"
>From there the OpenBSD route-reflector removed the routes from those
neighbors from the rib.
The other OpenBSD route-reflector clients however kept those routes around.
This was first noticed on Friday, when I changed peering interfaces on
PE-CE, which re-ran LDP against the OSPF routes,
but those routes never made it back to my PE in the Datacenter, and the
Customer's network was down while
I troubleshooted. I think I need to do some more testing and data gathering
and perhaps send a bug report
if my configs look good there. I would just think that if the PE withdrew
the route from the route-reflector, that
the reflector clients would remove the routes as well...
On Mon, Apr 8, 2019 at 5:29 PM Tom Smyth
wrote:
> Hi Henry,
>
> How long are you leaving the sessions down for on the PE router ?
> are you leaving the sessions down past the hold time value on the neigbour
> of the router that you are shutting down.
> are you doing a graceful shutdown?
> or are you simply rebooting the neigbour
> if im not mistaken I dont think the neighbour would withdraw the
> routes until the
> hold time has expired ...
> im subject to correction on this one... but it is the behaviour I have
> empirically observed
> on the bgp routers that i manage
> I hope this helps
> Tom Smyth
>
>
>
>
>
> On Mon, 8 Apr 2019 at 22:11, Henry Bonath wrote:
> >
> > Hello, I am seeing some BGP VPNv4 routes staying populated in
> > the RIB of route-reflector clients even after dropping the originating
> neighbor.
> >
> > I'm on OpenBSD 6.4, running MPLS L3VPN.
> >
> > I have 2 IBGP route-reflectors, both OpenBSD 6.4.
> > I run OSPF to distribute Loopbacks into an Area (100)
> > We run Cisco devices for our Provider Edge installed on site at
> > Customer Premise.
> > All MPLS PE devices neighbor with both route reflectors.
> >
> > My bgpd.conf from the route reflectors:
> > ===
> > ASN="64670"
> >
> > # global configuration
> > AS $ASN
> > router-id 172.16.16.212
> > nexthop qualify via default
> >
> > group "IBGP" {
> > remote-as $ASN
> > announce IPv4 vpn
> > route-reflector 172.16.16.212
> > local-address 172.16.16.212
> > neighbor 100.92.64.0/18 {
> > }
> >
> > }
> >
> > # IBGP: allow all updates to and from our IBGP neighbors
> > allow from any
> > allow to any
> > ===
> >
> > bgpd.conf from an OpenBSD PE:
> > ===
> > ASN="64670"
> >
> > # global configuration
> > AS $ASN
> > router-id 100.92.127.121
> >
> > rdomain 2 {
> > rd 64670:37
> > import-target rt 64670:37
> > export-target rt 64670:37
> > # advertise summary of tenant Subnet:
> > network 172.29.21.0/24
> >
> > # Redistribute from OSPF (Priority 32)
> > network inet priority 32
> > depend on mpe1
> > }
> >
> > group "IBGP" {
> > remote-as $ASN
> > announce IPv4 vpn
> > set rtlabel FROM_BGP
> > local-address 100.92.127.121
> > neighbor 172.16.16.211 {
> > descr "bgp-rr-01"
> > }
> > neighbor 172.16.16.212 {
> > descr "bgp-rr-02"
> > }
> >
> > }
> >
> > # IBGP: allow all updates to and from our IBGP neighbors
> > allow from ibgp
> > allow to ibgp
> >
> > ===
> >
> > The problem comes if I shutdown one of my Premise equipment PE
> > devices, or an OpenBSD PE,
> > on the other OpenBSD PEs that remain up, they still show the routes
> > that were advertised by the
> > now shutdown device.
> >
> > If I log into a route reflector and run a "bgpctl show rib" those
> > routes are no longer there as i expected,
> > though they persist at the OpenBSD reflector clients.
> >
> > Example output after shutting down the 100.92.127.21 Cisco PE observed
> > from the OpenBSD PE
> > that is listening to 64670:37 rt/rd:
> >
> > flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
> >S = Stale, E = Error
> > origin validation state: N = not-found, V = valid, ! = invalid
> > ori
Re: Reflected IBGP VPNv4 Routes overstaying their welcome
Hi Henry,
How long are you leaving the sessions down for on the PE router ?
are you leaving the sessions down past the hold time value on the neigbour
of the router that you are shutting down.
are you doing a graceful shutdown?
or are you simply rebooting the neigbour
if im not mistaken I dont think the neighbour would withdraw the
routes until the
hold time has expired ...
im subject to correction on this one... but it is the behaviour I have
empirically observed
on the bgp routers that i manage
I hope this helps
Tom Smyth
On Mon, 8 Apr 2019 at 22:11, Henry Bonath wrote:
>
> Hello, I am seeing some BGP VPNv4 routes staying populated in
> the RIB of route-reflector clients even after dropping the originating
> neighbor.
>
> I'm on OpenBSD 6.4, running MPLS L3VPN.
>
> I have 2 IBGP route-reflectors, both OpenBSD 6.4.
> I run OSPF to distribute Loopbacks into an Area (100)
> We run Cisco devices for our Provider Edge installed on site at
> Customer Premise.
> All MPLS PE devices neighbor with both route reflectors.
>
> My bgpd.conf from the route reflectors:
> ===
> ASN="64670"
>
> # global configuration
> AS $ASN
> router-id 172.16.16.212
> nexthop qualify via default
>
> group "IBGP" {
> remote-as $ASN
> announce IPv4 vpn
> route-reflector 172.16.16.212
> local-address 172.16.16.212
> neighbor 100.92.64.0/18 {
> }
>
> }
>
> # IBGP: allow all updates to and from our IBGP neighbors
> allow from any
> allow to any
> ===
>
> bgpd.conf from an OpenBSD PE:
> ===
> ASN="64670"
>
> # global configuration
> AS $ASN
> router-id 100.92.127.121
>
> rdomain 2 {
> rd 64670:37
> import-target rt 64670:37
> export-target rt 64670:37
> # advertise summary of tenant Subnet:
> network 172.29.21.0/24
>
> # Redistribute from OSPF (Priority 32)
> network inet priority 32
> depend on mpe1
> }
>
> group "IBGP" {
> remote-as $ASN
> announce IPv4 vpn
> set rtlabel FROM_BGP
> local-address 100.92.127.121
> neighbor 172.16.16.211 {
> descr "bgp-rr-01"
> }
> neighbor 172.16.16.212 {
> descr "bgp-rr-02"
> }
>
> }
>
> # IBGP: allow all updates to and from our IBGP neighbors
> allow from ibgp
> allow to ibgp
>
> ===
>
> The problem comes if I shutdown one of my Premise equipment PE
> devices, or an OpenBSD PE,
> on the other OpenBSD PEs that remain up, they still show the routes
> that were advertised by the
> now shutdown device.
>
> If I log into a route reflector and run a "bgpctl show rib" those
> routes are no longer there as i expected,
> though they persist at the OpenBSD reflector clients.
>
> Example output after shutting down the 100.92.127.21 Cisco PE observed
> from the OpenBSD PE
> that is listening to 64670:37 rt/rd:
>
> flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
>S = Stale, E = Error
> origin validation state: N = not-found, V = valid, ! = invalid
> origin: i = IGP, e = EGP, ? = Incomplete
>
> flags ovs destination gateway lpref med aspath origin
> I*> N rd 64670:37 192.168.11.0/24 100.92.127.21 100 2 ?
> I* N rd 64670:37 192.168.11.0/24 100.92.127.21 100 2 ?
> I*> N rd 64670:37 192.168.15.0/24 100.92.127.21 100 2 ?
> I* N rd 64670:37 192.168.15.0/24 100.92.127.21 100 2 ?
> I*> N rd 64670:37 192.168.20.0/24 100.92.127.21 100 3 ?
> I* N rd 64670:37 192.168.20.0/24 100.92.127.21 100 3 ?
> I*> N rd 64670:37 192.168.100.0/24 100.92.127.21 100 2 ?
> I* N rd 64670:37 192.168.100.0/24 100.92.127.21 100 2 ?
> I*> N rd 64670:37 192.168.110.0/24 100.92.127.21 100 3 ?
> I* N rd 64670:37 192.168.110.0/24 100.92.127.21 100 3 ?
> I*> N rd 64670:37 192.168.150.0/24 100.92.127.21 100 2 ?
> I* N rd 64670:37 192.168.150.0/24 100.92.127.21 100 2 ?
> I*> N rd 64670:37 192.168.200.0/24 100.92.127.21 100 2 ?
> I* N rd 64670:37 192.168.200.0/24 100.92.127.21 100 2 ?
>
> Shouldn't those routes disappear once the 100.92.127.21 router is shutdown?
>
> Thanks for any help you all have to offer!
> -Henry
>
--
Kindest regards,
Tom Smyth
The information contained in
Reflected IBGP VPNv4 Routes overstaying their welcome
Hello, I am seeing some BGP VPNv4 routes staying populated in
the RIB of route-reflector clients even after dropping the originating neighbor.
I'm on OpenBSD 6.4, running MPLS L3VPN.
I have 2 IBGP route-reflectors, both OpenBSD 6.4.
I run OSPF to distribute Loopbacks into an Area (100)
We run Cisco devices for our Provider Edge installed on site at
Customer Premise.
All MPLS PE devices neighbor with both route reflectors.
My bgpd.conf from the route reflectors:
===
ASN="64670"
# global configuration
AS $ASN
router-id 172.16.16.212
nexthop qualify via default
group "IBGP" {
remote-as $ASN
announce IPv4 vpn
route-reflector 172.16.16.212
local-address 172.16.16.212
neighbor 100.92.64.0/18 {
}
}
# IBGP: allow all updates to and from our IBGP neighbors
allow from any
allow to any
===
bgpd.conf from an OpenBSD PE:
===
ASN="64670"
# global configuration
AS $ASN
router-id 100.92.127.121
rdomain 2 {
rd 64670:37
import-target rt 64670:37
export-target rt 64670:37
# advertise summary of tenant Subnet:
network 172.29.21.0/24
# Redistribute from OSPF (Priority 32)
network inet priority 32
depend on mpe1
}
group "IBGP" {
remote-as $ASN
announce IPv4 vpn
set rtlabel FROM_BGP
local-address 100.92.127.121
neighbor 172.16.16.211 {
descr "bgp-rr-01"
}
neighbor 172.16.16.212 {
descr "bgp-rr-02"
}
}
# IBGP: allow all updates to and from our IBGP neighbors
allow from ibgp
allow to ibgp
===
The problem comes if I shutdown one of my Premise equipment PE
devices, or an OpenBSD PE,
on the other OpenBSD PEs that remain up, they still show the routes
that were advertised by the
now shutdown device.
If I log into a route reflector and run a "bgpctl show rib" those
routes are no longer there as i expected,
though they persist at the OpenBSD reflector clients.
Example output after shutting down the 100.92.127.21 Cisco PE observed
from the OpenBSD PE
that is listening to 64670:37 rt/rd:
flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
S = Stale, E = Error
origin validation state: N = not-found, V = valid, ! = invalid
origin: i = IGP, e = EGP, ? = Incomplete
flags ovs destination gateway lpref med aspath origin
I*> N rd 64670:37 192.168.11.0/24 100.92.127.21 100 2 ?
I* N rd 64670:37 192.168.11.0/24 100.92.127.21 100 2 ?
I*> N rd 64670:37 192.168.15.0/24 100.92.127.21 100 2 ?
I* N rd 64670:37 192.168.15.0/24 100.92.127.21 100 2 ?
I*> N rd 64670:37 192.168.20.0/24 100.92.127.21 100 3 ?
I* N rd 64670:37 192.168.20.0/24 100.92.127.21 100 3 ?
I*> N rd 64670:37 192.168.100.0/24 100.92.127.21 100 2 ?
I* N rd 64670:37 192.168.100.0/24 100.92.127.21 100 2 ?
I*> N rd 64670:37 192.168.110.0/24 100.92.127.21 100 3 ?
I* N rd 64670:37 192.168.110.0/24 100.92.127.21 100 3 ?
I*> N rd 64670:37 192.168.150.0/24 100.92.127.21 100 2 ?
I* N rd 64670:37 192.168.150.0/24 100.92.127.21 100 2 ?
I*> N rd 64670:37 192.168.200.0/24 100.92.127.21 100 2 ?
I* N rd 64670:37 192.168.200.0/24 100.92.127.21 100 2 ?
Shouldn't those routes disappear once the 100.92.127.21 router is shutdown?
Thanks for any help you all have to offer!
-Henry
Announcing learned iBGP route to eBGP peer
I have an iBGP learned route that Iâm trying to advertise to an eBGP peer in
OpenBGPD. I set up announce all, but my neighbor does not see the route. If
I do an explicit network statement my peer obviously sees the route, but I
want it to advertise the learned route instead.
Here is my bgpd.conf and output of the rib:
AS 24
nexthop qualify via default
neighbor 2001:ABCD:::1 {
remote-as 64515
local-address 2001:ABCD:ac01:294:5400:ff:fe48:dd09
multihop 2
tcp md5sig password XXX
announce all
}
neighbor 2a06:DCBA:20f0::1 {
remote-as 24
local-address 2a06:DCBA:20f0::2
}
deny to 2001:ABCD:::1
allow to 2001:ABCD:::1 prefix 2a06:DCBA:2000::/40
deny from any prefix ::/0 prefixlen = 0
# bgpctl show rib | grep 2a06:DCBA:2000::/40
I*> 2a06:DCBA:2000::/40 2a06:DCBA:20f0::1 100 0 24 24 24 i
Note that the route shows up as I*>, instead of IA*>, so it is not getting
announced. I mocked this up in my Cisco lab, and the iBGP route gets
advertised automatically.
Thanks,
Mattias Lindgren
--
Mattias Lindgren
Re: OpenBGPd - iBGP next-hop translation using IGP (OSPF)
Hi Stuart, I have tried with a carp netmask equal to the physical interface (/24 for example in my lab) and a /32 (like when you have many CARP IP addresses). From investigation the problem seems to occur because when a box is the carp master, their will be a /32 route in the routing table for that specific IP address (regardless of netmask in hostname.carpX) attached to the interface 'carpX'. For example, run 'netstat -rn' on your carp master and you will see lines like the following; Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface 170.16.3/24170.16.3.1 UG 00 -48 em1 170.16.3.2 08:00:27:a4:02:3d UHLc 04 - 4 lo0 170.16.3.3 08:00:27:9f:83:ca UHLc 1 1019447 - L 4 em1 170.16.3.4 170.16.3.4 UH 00 - 4 carp1 .2 is this firewall (master), .3 is the other firewall (backup), and .4 is the shared CARP IP. Because the interface for the .4 IP address is carp1 and not em1 (where the BGP neighbor is connected), setting the nexthop to .4 fails. If you run the same on the backup; Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface 170.16.3/24link#2 UC 20 - 4 em1 170.16.3.1 c2:00:01:e4:00:00 UHLc 5 143456 - L 4 em1 170.16.3.2 08:00:27:a4:02:3d UHLc 4 158601 - L 4 em1 Notice their is no /32 route for the CARP IP address as it is not the carp master. As a result the BGP announcements from the backup firewall do successfully set the nexthop! So only the backup firewall can set the nexthop of BGP announcements to a CARP IP address. The master has those /32 routes which breaks the nexthop validation check because it thinks the IP you are trying to set is not in the network directly connected to the neighbor even though it actually is. Cheers, Andy. On Tue 01 Apr 2014 15:03:29 BST, Stuart Henderson wrote: On 2014-04-01, Andy wrote: Specifically to accommodate CARP interfaces, to allow setting the nexthop on an announced route to a CARP IP address? This currently doesn't work as OpenBGPD considers the CARP interface as being a different network to the physical interface, even though they are on the same segment and valid according to the BGP rules of being directly connected. What netmasks are you using? I think perhaps there needs to be some reach-around where a carp has a /32 or /128, to determine the netmask of the carpdev and use that instead in some cases...
Re: OpenBGPd - iBGP next-hop translation using IGP (OSPF)
On 2014-04-01, Andy wrote: > Specifically to accommodate CARP interfaces, to allow setting the > nexthop on an announced route to a CARP IP address? > > This currently doesn't work as OpenBGPD considers the CARP interface as > being a different network to the physical interface, even though they > are on the same segment and valid according to the BGP rules of being > directly connected. What netmasks are you using? I think perhaps there needs to be some reach-around where a carp has a /32 or /128, to determine the netmask of the carpdev and use that instead in some cases...
Re: OpenBGPd - iBGP next-hop translation using IGP (OSPF)
On Tue 01 Apr 2014 10:27:03 BST, Andy wrote: On Tue 01 Apr 2014 10:10:02 BST, Andy wrote: Hi Claudio and Stuart, thanks for your replies. On Mon 31 Mar 2014 22:29:47 BST, Claudio Jeker wrote: On Mon, Mar 31, 2014 at 07:59:19PM +0100, Stuart Henderson wrote: On 2014/03/31 09:31, Andy wrote: Hi Stuart, Does Henning, Claudio or any of the other developers have any plan to implement BGP equal cost multi-path support (maximum-paths) to OpenBGPd? No idea about anyone else's plans... For me it is fairly low on the todo list. I think that BGP equal cost multi-path will not trigger most of the time since the routes need to be equal till fairly far down the decision tree. There are more important things to solve first (some of them bugs, some of them "features" and some of them real features). PS forgive me for bringing up an old discussion, but do any of these features include enhancing the nexthop validation code? Specifically to accommodate CARP interfaces, to allow setting the nexthop on an announced route to a CARP IP address? This currently doesn't work as OpenBGPD considers the CARP interface as being a different network to the physical interface, even though they are on the same segment and valid according to the BGP rules of being directly connected. Cheers :) Andy PS; Forgot to mention that we have sponsored a PhD/RA chap who is slowly looking at this specific 'setting nexthop to CARP' enhancement in his spare time. He's currently familiarizing himself with the OpenBGPD code. Yea that will definitely be the case for multi-homed redundant Transits. And I have no doubt there are other very important things on the list too. If its OK I would like to highlight however that nearly every network I know (the vast majority of the networks who we peer with at LONAP and LINX in London and Amsterdam at least) have multiple routers attached to the IXP exchanges, and in all those cases nearly every route learned from those peers do match all the way down. Our peerings now cover over 13% of the full Internet routing table (currently 65549 routes out of 487459) and this is increasing. And so around 12% of the Internet is being forced out only one IXP connection via one ASBR leaving the other one mostly idle except for some inbound packets which I am trying to steer with MEDs etc. Anyway, this is becoming more common as IXPs now reach more and more data centers and providers connect to the same exchanges at multiple data centers. I guess it should be quite quick to add as OpenOSPFd already supports this and the kernel FIB is ready. I don't think it's safe to assume "quick" here - at the very least, bgp has a bunch more code handling nexthop validity than ospfd does. The bgpd RIB and FIB is a fair bit different from the ospfd one. While some basic ideas may be reused I doubt there is a lot of code that could be shared. Additionally I suspect this will result in bgpd needing to revalidate routes more often, which is a known problem area for out-of-memory crashes in bgpd's RDE. Yeah, this is something we need to fix first (see above). Interesting, does that mean OpenBGPD currently only revalidates the FIB routes and not the RIB routes. Adding these two features has obvious and significant benefits. BIRD already supports ECMP and BFD but I would rather stick with OpenBGPd as it is developed against OpenBSD :) Note that I mostly added the BIRD port to test interop with bgpd/ospfd - I've only run it minimally to test basic operation, and haven't had much feedback about the port, so consider it not particularly well tested on OpenBSD at this point. If running BIRD I'd suggest probably doing it on a Linux-ish system.. While it does get some use on BSDs (I know of someone using it for a big wireless network on FreeBSD) it's originally written for Linux and some things aren't supported on BSDs. Case in point: $ cat `find . -type f` | grep -c RTF_MPATH 0 :) As mentioned we would rather stick with OpenBGPD than try and make BIRD work. I really don't want to have to go down that road.. There is also a GSoC project to get BFD into OpenBSD. So if a student is interested in working on that that would be an oportunity. Great news, crossing fingers we have some budding student with awesome C skills is up for the challenge. As always, thanks for your great work! Cheers Andy.
Re: OpenBGPd - iBGP next-hop translation using IGP (OSPF)
On Tue 01 Apr 2014 10:10:02 BST, Andy wrote: Hi Claudio and Stuart, thanks for your replies. On Mon 31 Mar 2014 22:29:47 BST, Claudio Jeker wrote: On Mon, Mar 31, 2014 at 07:59:19PM +0100, Stuart Henderson wrote: On 2014/03/31 09:31, Andy wrote: Hi Stuart, Does Henning, Claudio or any of the other developers have any plan to implement BGP equal cost multi-path support (maximum-paths) to OpenBGPd? No idea about anyone else's plans... For me it is fairly low on the todo list. I think that BGP equal cost multi-path will not trigger most of the time since the routes need to be equal till fairly far down the decision tree. There are more important things to solve first (some of them bugs, some of them "features" and some of them real features). PS forgive me for bringing up an old discussion, but do any of these features include enhancing the nexthop validation code? Specifically to accommodate CARP interfaces, to allow setting the nexthop on an announced route to a CARP IP address? This currently doesn't work as OpenBGPD considers the CARP interface as being a different network to the physical interface, even though they are on the same segment and valid according to the BGP rules of being directly connected. Cheers :) Andy Yea that will definitely be the case for multi-homed redundant Transits. And I have no doubt there are other very important things on the list too. If its OK I would like to highlight however that nearly every network I know (the vast majority of the networks who we peer with at LONAP and LINX in London and Amsterdam at least) have multiple routers attached to the IXP exchanges, and in all those cases nearly every route learned from those peers do match all the way down. Our peerings now cover over 13% of the full Internet routing table (currently 65549 routes out of 487459) and this is increasing. And so around 12% of the Internet is being forced out only one IXP connection via one ASBR leaving the other one mostly idle except for some inbound packets which I am trying to steer with MEDs etc. Anyway, this is becoming more common as IXPs now reach more and more data centers and providers connect to the same exchanges at multiple data centers. I guess it should be quite quick to add as OpenOSPFd already supports this and the kernel FIB is ready. I don't think it's safe to assume "quick" here - at the very least, bgp has a bunch more code handling nexthop validity than ospfd does. The bgpd RIB and FIB is a fair bit different from the ospfd one. While some basic ideas may be reused I doubt there is a lot of code that could be shared. Additionally I suspect this will result in bgpd needing to revalidate routes more often, which is a known problem area for out-of-memory crashes in bgpd's RDE. Yeah, this is something we need to fix first (see above). Interesting, does that mean OpenBGPD currently only revalidates the FIB routes and not the RIB routes. Adding these two features has obvious and significant benefits. BIRD already supports ECMP and BFD but I would rather stick with OpenBGPd as it is developed against OpenBSD :) Note that I mostly added the BIRD port to test interop with bgpd/ospfd - I've only run it minimally to test basic operation, and haven't had much feedback about the port, so consider it not particularly well tested on OpenBSD at this point. If running BIRD I'd suggest probably doing it on a Linux-ish system.. While it does get some use on BSDs (I know of someone using it for a big wireless network on FreeBSD) it's originally written for Linux and some things aren't supported on BSDs. Case in point: $ cat `find . -type f` | grep -c RTF_MPATH 0 :) As mentioned we would rather stick with OpenBGPD than try and make BIRD work. I really don't want to have to go down that road.. There is also a GSoC project to get BFD into OpenBSD. So if a student is interested in working on that that would be an oportunity. Great news, crossing fingers we have some budding student with awesome C skills is up for the challenge. As always, thanks for your great work! Cheers Andy.
Re: OpenBGPd - iBGP next-hop translation using IGP (OSPF)
Definitely agree Theo. Our topology is less than ideal just to ensure we have OSPF's fast convergence changing the nexthops of our intra-AS routers for what are otherwise BGP routes. Whilst people say bird 1.4 supports BFD, BIRD is generally used on Linux route servers (not forwarding traffic), and OpenBGPD is mostly used on OpenBSD routers which are forwarding traffic (imho). Cheers, Andy. On Tue 01 Apr 2014 01:09:12 BST, Theo de Raadt wrote: There is also a GSoC project to get BFD into OpenBSD. So if a student is interested in working on that that would be an oportunity. Honestly, I think many people are building hacks because they lack a carefully-integrated BFD. If we had it, it would not solve fair-share problems, but it would solve many other cases. I am baffled noone has stepped up with something yet, GSoC or otherwise.
Re: OpenBGPd - iBGP next-hop translation using IGP (OSPF)
Hi Claudio and Stuart, thanks for your replies. On Mon 31 Mar 2014 22:29:47 BST, Claudio Jeker wrote: On Mon, Mar 31, 2014 at 07:59:19PM +0100, Stuart Henderson wrote: On 2014/03/31 09:31, Andy wrote: Hi Stuart, Does Henning, Claudio or any of the other developers have any plan to implement BGP equal cost multi-path support (maximum-paths) to OpenBGPd? No idea about anyone else's plans... For me it is fairly low on the todo list. I think that BGP equal cost multi-path will not trigger most of the time since the routes need to be equal till fairly far down the decision tree. There are more important things to solve first (some of them bugs, some of them "features" and some of them real features). Yea that will definitely be the case for multi-homed redundant Transits. And I have no doubt there are other very important things on the list too. If its OK I would like to highlight however that nearly every network I know (the vast majority of the networks who we peer with at LONAP and LINX in London and Amsterdam at least) have multiple routers attached to the IXP exchanges, and in all those cases nearly every route learned from those peers do match all the way down. Our peerings now cover over 13% of the full Internet routing table (currently 65549 routes out of 487459) and this is increasing. And so around 12% of the Internet is being forced out only one IXP connection via one ASBR leaving the other one mostly idle except for some inbound packets which I am trying to steer with MEDs etc. Anyway, this is becoming more common as IXPs now reach more and more data centers and providers connect to the same exchanges at multiple data centers. I guess it should be quite quick to add as OpenOSPFd already supports this and the kernel FIB is ready. I don't think it's safe to assume "quick" here - at the very least, bgp has a bunch more code handling nexthop validity than ospfd does. The bgpd RIB and FIB is a fair bit different from the ospfd one. While some basic ideas may be reused I doubt there is a lot of code that could be shared. Additionally I suspect this will result in bgpd needing to revalidate routes more often, which is a known problem area for out-of-memory crashes in bgpd's RDE. Yeah, this is something we need to fix first (see above). Interesting, does that mean OpenBGPD currently only revalidates the FIB routes and not the RIB routes. Adding these two features has obvious and significant benefits. BIRD already supports ECMP and BFD but I would rather stick with OpenBGPd as it is developed against OpenBSD :) Note that I mostly added the BIRD port to test interop with bgpd/ospfd - I've only run it minimally to test basic operation, and haven't had much feedback about the port, so consider it not particularly well tested on OpenBSD at this point. If running BIRD I'd suggest probably doing it on a Linux-ish system.. While it does get some use on BSDs (I know of someone using it for a big wireless network on FreeBSD) it's originally written for Linux and some things aren't supported on BSDs. Case in point: $ cat `find . -type f` | grep -c RTF_MPATH 0 :) As mentioned we would rather stick with OpenBGPD than try and make BIRD work. I really don't want to have to go down that road.. There is also a GSoC project to get BFD into OpenBSD. So if a student is interested in working on that that would be an oportunity. Great news, crossing fingers we have some budding student with awesome C skills is up for the challenge. As always, thanks for your great work! Cheers Andy.
Re: OpenBGPd - iBGP next-hop translation using IGP (OSPF)
> There is also a GSoC project to get BFD into OpenBSD. So if a student is > interested in working on that that would be an oportunity. Honestly, I think many people are building hacks because they lack a carefully-integrated BFD. If we had it, it would not solve fair-share problems, but it would solve many other cases. I am baffled noone has stepped up with something yet, GSoC or otherwise.
Re: OpenBGPd - iBGP next-hop translation using IGP (OSPF)
On Mon, Mar 31, 2014 at 07:59:19PM +0100, Stuart Henderson wrote: > On 2014/03/31 09:31, Andy wrote: > > Hi Stuart, > > > > Does Henning, Claudio or any of the other developers have any plan to > > implement BGP equal cost multi-path support (maximum-paths) to OpenBGPd? > > No idea about anyone else's plans... > For me it is fairly low on the todo list. I think that BGP equal cost multi-path will not trigger most of the time since the routes need to be equal till fairly far down the decision tree. There are more important things to solve first (some of them bugs, some of them "features" and some of them real features). > > I guess it should be quite quick to add as OpenOSPFd already supports this > > and the kernel FIB is ready. > > I don't think it's safe to assume "quick" here - at the very least, bgp > has a bunch more code handling nexthop validity than ospfd does. The bgpd RIB and FIB is a fair bit different from the ospfd one. While some basic ideas may be reused I doubt there is a lot of code that could be shared. > Additionally I suspect this will result in bgpd needing to revalidate > routes more often, which is a known problem area for out-of-memory crashes > in bgpd's RDE. Yeah, this is something we need to fix first (see above). > > Adding these two features has obvious and significant benefits. BIRD already > > supports ECMP and BFD but I would rather stick with OpenBGPd as it is > > developed against OpenBSD :) > > Note that I mostly added the BIRD port to test interop with bgpd/ospfd - > I've only run it minimally to test basic operation, and haven't had much > feedback about the port, so consider it not particularly well tested on > OpenBSD at this point. > > If running BIRD I'd suggest probably doing it on a Linux-ish system.. > While it does get some use on BSDs (I know of someone using it for a big > wireless network on FreeBSD) it's originally written for Linux and some > things aren't supported on BSDs. Case in point: > > $ cat `find . -type f` | grep -c RTF_MPATH > 0 > There is also a GSoC project to get BFD into OpenBSD. So if a student is interested in working on that that would be an oportunity. -- :wq Claudio
Re: OpenBGPd - iBGP next-hop translation using IGP (OSPF)
On 2014/03/31 09:31, Andy wrote: > Hi Stuart, > > Does Henning, Claudio or any of the other developers have any plan to > implement BGP equal cost multi-path support (maximum-paths) to OpenBGPd? No idea about anyone else's plans... > I guess it should be quite quick to add as OpenOSPFd already supports this > and the kernel FIB is ready. I don't think it's safe to assume "quick" here - at the very least, bgp has a bunch more code handling nexthop validity than ospfd does. Additionally I suspect this will result in bgpd needing to revalidate routes more often, which is a known problem area for out-of-memory crashes in bgpd's RDE. > Adding these two features has obvious and significant benefits. BIRD already > supports ECMP and BFD but I would rather stick with OpenBGPd as it is > developed against OpenBSD :) Note that I mostly added the BIRD port to test interop with bgpd/ospfd - I've only run it minimally to test basic operation, and haven't had much feedback about the port, so consider it not particularly well tested on OpenBSD at this point. If running BIRD I'd suggest probably doing it on a Linux-ish system.. While it does get some use on BSDs (I know of someone using it for a big wireless network on FreeBSD) it's originally written for Linux and some things aren't supported on BSDs. Case in point: $ cat `find . -type f` | grep -c RTF_MPATH 0
Re: OpenBGPd - iBGP next-hop translation using IGP (OSPF)
Hi Stuart, Does Henning, Claudio or any of the other developers have any plan to implement BGP equal cost multi-path support (maximum-paths) to OpenBGPd? I guess it should be quite quick to add as OpenOSPFd already supports this and the kernel FIB is ready. Actually quite surprised this isn't already supported which is why I wanted to check with people here as BGP multipath is step 9 of the BGP Best Path Selection Algorithm. I know that Rivo Nurges and one of two other developers have also expressed intent and interest to add BFD support to OpenBGPd at least (and ideally static routes and OSPF) for obvious reasons. Adding these two features has obvious and significant benefits. BIRD already supports ECMP and BFD but I would rather stick with OpenBGPd as it is developed against OpenBSD :) Thanks for your time and thoughts. Cheers, Andy. On Sun 30 Mar 2014 21:28:03 BST, Stuart Henderson wrote: On 2014-03-29, Andy wrote: Hi, Is OpenBGPD capable of inserting equal cost multi-path routes into the kernel FIB like OpenOSPFD can? In a word: no. Maybe it could be modified to do this, but that's how it is currently.
Re: OpenBGPd - iBGP next-hop translation using IGP (OSPF)
On 2014-03-29, Andy wrote: > Hi, > > Is OpenBGPD capable of inserting equal cost multi-path routes into the > kernel FIB like OpenOSPFD can? In a word: no. Maybe it could be modified to do this, but that's how it is currently.
Re: OpenBGPd - iBGP next-hop translation using IGP (OSPF)
On further thought, using option 1 and randomising the next hop used wouldn't provide a very good distribution of load as it would be on a per network route basis and not on a per IP basing like proper multipath. Would also be costly in route look ups etc. So looks like we would need to use 'maximum-paths n' in OpenBGP to insert multiple routes into the kernel FIB and use next-hop-self on the iBGP neighbour ASBR routers connecting to the exchange etc, to achieve full load balancing across ASBRs. That would provide a good load distribution but means we also have to wait for BFD (Bidirectional Forward Detection) support on BGP to address the convergence issues of using next-hop-self. What do people think? Thanks for your thoughts :) Andy Sent from my iPhone > On 29 Mar 2014, at 21:45, Andy wrote: > > Hi, > > Is OpenBGPD capable of inserting equal cost multi-path routes into the > kernel FIB like OpenOSPFD can? > > > I have equal cost routes being received into OpenOSPFD's RIB from two > different OSPF ASBR neighbors, for accessing the same IXP network to > which we are connected. These two multi-path routes are inserted into > the Kernel FIB fine. > If I ping various routers on the IXP network I can see that multi-path > is being used and a different ASBR neighbor is used for each IP etc.. > Great :) > > [LIVE]root@mg131:~# ospfctl show rib | grep 5.57.80 > 5.57.80.0/22 185.25.30.2 Type 1 ext Network 21 01w1d09h > 5.57.80.0/22 185.25.30.1 Type 1 ext Network 21 01w0d04h > > [LIVE]root@mg131:~# netstat -rn | grep 5.57.80 > 5.57.80/22 185.25.30.2UGP0 42 -32 vlan202 > 5.57.80/22 185.25.30.1UGP0 77 -32 vlan202 > > > > I therefore of course also have equal cost routes being received into > OpenBGPD's RIB from the two different iBGP peers (the same two ASBR > neighbors as above), for all the networks received via our IXP BGP peerings. > OpenBGPd by default only selects one path to the remote networks, the > nexthop in the IXP network for the path is translated into a directly > connected nexthop (using the OSPF routes for the IXP network). > > [LIVE]root@mg131:~# bgpctl show rib | more > flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale > origin: i = IGP, e = EGP, ? = Incomplete > > flags destination gateway lpref med aspath origin > I*> 1.0.0.0/24 5.57.80.136 1000 0 15169 i > I*1.0.0.0/24 5.57.80.136 1000 0 15169 i > I*> 1.0.4.0/24 5.57.80.128100 1 6939 7545 56203 i > I*1.0.4.0/24 5.57.80.128100 1 6939 7545 56203 i > I*> 1.0.5.0/24 5.57.80.128100 1 6939 7545 56203 i > I*1.0.5.0/24 5.57.80.128100 1 6939 7545 56203 i > . > . > > [LIVE]root@mg1311:~# netstat -rn | more > Routing tables > > Internet: > DestinationGatewayFlags Refs Use Mtu Prio Iface > 1.0.0/24 185.25.30.2UG 00 -48 vlan2302 > 1.0.4/24 185.25.30.2UG 00 -48 vlan2302 > 1.0.5/24 185.25.30.2UG 00 -48 vlan2302 > . > . > > However it always chooses the same directly connected ASBR for every > route during the next-hop translation step and no load balancing is > achieved. :( > > Even if I use 'next-hop-self' on the ASBR's to remove the nexthop > translation step, the same ASBR is always chosen (due to BGP best path > selection always matching for each route). > > I also don't want to use next-hop-self anyway as that would *destroy* > convergence times should an ASBR be unavailable, as in the absence of > BFD it would be relying on BGP long timers to change the route, instead > of having OSPF's fast convergence to change the next-hop in less than a > second. > > > From my understanding the only options are; > 1) Randomize the directly connected nexthop used during in the next-hop > translation step. > 2) Use next-hop-self on the ASBR's to insert two routes into the RIB > with different next-hops (one for each ASBR) (requiring BFD for BGP to > not destroy convergence), and also enable BGP multi-hop > (http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html#bgpmpath) > > to insert both RIB routes into the FIB, so the kernel can perform > equal-cost multi-path routing. > > > Thanks for your time and for reading. > Cheers, Andy. > > > > > /**/
OpenBGPd - iBGP next-hop translation using IGP (OSPF)
Hi, Is OpenBGPD capable of inserting equal cost multi-path routes into the kernel FIB like OpenOSPFD can? I have equal cost routes being received into OpenOSPFD's RIB from two different OSPF ASBR neighbors, for accessing the same IXP network to which we are connected. These two multi-path routes are inserted into the Kernel FIB fine. If I ping various routers on the IXP network I can see that multi-path is being used and a different ASBR neighbor is used for each IP etc.. Great :) [LIVE]root@mg131:~# ospfctl show rib | grep 5.57.80 5.57.80.0/22 185.25.30.2 Type 1 ext Network 21 01w1d09h 5.57.80.0/22 185.25.30.1 Type 1 ext Network 21 01w0d04h [LIVE]root@mg131:~# netstat -rn | grep 5.57.80 5.57.80/22 185.25.30.2UGP0 42 -32 vlan202 5.57.80/22 185.25.30.1UGP0 77 -32 vlan202 I therefore of course also have equal cost routes being received into OpenBGPD's RIB from the two different iBGP peers (the same two ASBR neighbors as above), for all the networks received via our IXP BGP peerings. OpenBGPd by default only selects one path to the remote networks, the nexthop in the IXP network for the path is translated into a directly connected nexthop (using the OSPF routes for the IXP network). [LIVE]root@mg131:~# bgpctl show rib | more flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin I*> 1.0.0.0/24 5.57.80.136 1000 0 15169 i I*1.0.0.0/24 5.57.80.136 1000 0 15169 i I*> 1.0.4.0/24 5.57.80.128100 1 6939 7545 56203 i I*1.0.4.0/24 5.57.80.128100 1 6939 7545 56203 i I*> 1.0.5.0/24 5.57.80.128100 1 6939 7545 56203 i I*1.0.5.0/24 5.57.80.128100 1 6939 7545 56203 i . . [LIVE]root@mg1311:~# netstat -rn | more Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface 1.0.0/24 185.25.30.2UG 00 -48 vlan2302 1.0.4/24 185.25.30.2UG 00 -48 vlan2302 1.0.5/24 185.25.30.2UG 00 -48 vlan2302 . . However it always chooses the same directly connected ASBR for every route during the next-hop translation step and no load balancing is achieved. :( Even if I use 'next-hop-self' on the ASBR's to remove the nexthop translation step, the same ASBR is always chosen (due to BGP best path selection always matching for each route). I also don't want to use next-hop-self anyway as that would *destroy* convergence times should an ASBR be unavailable, as in the absence of BFD it would be relying on BGP long timers to change the route, instead of having OSPF's fast convergence to change the next-hop in less than a second. From my understanding the only options are; 1) Randomize the directly connected nexthop used during in the next-hop translation step. 2) Use next-hop-self on the ASBR's to insert two routes into the RIB with different next-hops (one for each ASBR) (requiring BFD for BGP to not destroy convergence), and also enable BGP multi-hop (http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html#bgpmpath) to insert both RIB routes into the FIB, so the kernel can perform equal-cost multi-path routing. Thanks for your time and for reading. Cheers, Andy. /**/
Re: OpenBGP - iBGP peers not announcing after 3 hops
On Tue, Feb 05, 2013 at 10:34:02AM +, Stuart Henderson wrote: > On 2013-02-04, Eduardo Meyer wrote: > >> On 02/04/2013 03:59 PM, Eduardo Meyer wrote: > >> > Hello, > >> > > >> > I am facing a strange behavior, > >> > > >> > I have the following scenario > >> > > >> > eBGP1<->iBGP1<->iBGP2<->iBGP3<->eBGP2 > >> > >> iBGP must be fully meshed, a session between iBGP1 and iBGP3 is > >> missing. > > > > Really? It's difficult for me in this environment, do I have another option? > > This doesn't mean that they need to be directly connected; iBGP sessions > can be run over multiple hops by default. It just means you need neighbour > configs for 1<>2, 1<>3, 2<>3. > > You could use a route reflector as others suggested but it's a bit > much for this setup imo; it will be a critical part of the network so > you'll probably want a redundant pair. These come into their own when the > number of routers goes up. It should be possible to make all routers route-reflectors and not do a full mesh but route-reflector setups are not inherently stable. In some setups they can result in a unstable network. Especially when adding redundancies to setups (by additional RRs or additional iBGP links) it is possible to end up with a not converging network which is fun fun fun... In general if you have less than a handfull bgp router us a full mesh. The pain of fiddeling with RR is not worth the few sessions you save. -- :wq Claudio
Re: OpenBGP - iBGP peers not announcing after 3 hops
On Tue, Feb 5, 2013 at 8:34 AM, Stuart Henderson wrote: > On 2013-02-04, Eduardo Meyer wrote: > >> On 02/04/2013 03:59 PM, Eduardo Meyer wrote: > >> > Hello, > >> > > >> > I am facing a strange behavior, > >> > > >> > I have the following scenario > >> > > >> > eBGP1<->iBGP1<->iBGP2<->iBGP3<->eBGP2 > >> > >> iBGP must be fully meshed, a session between iBGP1 and iBGP3 is > >> missing. > > > > Really? It's difficult for me in this environment, do I have another > option? > > This doesn't mean that they need to be directly connected; iBGP sessions > can be run over multiple hops by default. It just means you need neighbour > configs for 1<>2, 1<>3, 2<>3. > > You could use a route reflector as others suggested but it's a bit > much for this setup imo; it will be a critical part of the network so > you'll probably want a redundant pair. These come into their own when the > number of routers goes up. > > Yeah, you are all right, multihop peering just did fine; as well as route-reflector for iBGP group just worked fine; yeah I need to read some bgp basics; usually I tend to learn by experience and this is when such a great community comes to hand; I learn more with you than books but certainly some bgp theory will be on my reading list for the weekends; thanks veryone who kindly replied, I will think about the expected growing rate of the network and complexity to decide if I go with peering or route-reflector for this environment; -- === Eduardo Meyer pessoal: dudu.me...@gmail.com profissional: ddm.farmac...@saude.gov.br
Re: OpenBGP - iBGP peers not announcing after 3 hops
On 2013-02-04, Eduardo Meyer wrote: >> On 02/04/2013 03:59 PM, Eduardo Meyer wrote: >> > Hello, >> > >> > I am facing a strange behavior, >> > >> > I have the following scenario >> > >> > eBGP1<->iBGP1<->iBGP2<->iBGP3<->eBGP2 >> >> iBGP must be fully meshed, a session between iBGP1 and iBGP3 is >> missing. > > Really? It's difficult for me in this environment, do I have another option? This doesn't mean that they need to be directly connected; iBGP sessions can be run over multiple hops by default. It just means you need neighbour configs for 1<>2, 1<>3, 2<>3. You could use a route reflector as others suggested but it's a bit much for this setup imo; it will be a critical part of the network so you'll probably want a redundant pair. These come into their own when the number of routers goes up.
Re: OpenBGP - iBGP peers not announcing after 3 hops
Eduardo Meyer(dudu.me...@gmail.com) on 2013.02.04 13:51:25 -0200: > On Mon, Feb 4, 2013 at 1:36 PM, Peter Hessler wrote: > > > make iBGP2 a route server. > > > > Sounds promising, what are the key configurations in bgpd.conf to do so? So > I can look further. > > Are we talking 'bout reflector/collector? A reflector, you need to use "route-reflector " on your sessions on iBGP2. You might want to pick up a book on BGP. Stuart recently recommended "BGP" by Iljitsch van Beijnum (O'Reilly), and "BGP Design and Implementation" from Cisco will also help you along.
Re: OpenBGP - iBGP peers not announcing after 3 hops
Am 04.02.2013 16:32, schrieb Eduardo Meyer: > Really? It's difficult for me in this environment, do I have another option? add a route collector that peers with all ibgp neighbors...
Re: OpenBGP - iBGP peers not announcing after 3 hops
On 4 Feb 2013, at 10:36, Peter Hessler wrote: > make iBGP2 a route server. I think this would be a route reflector since you're dealing with iBGP. Michael
Re: OpenBGP - iBGP peers not announcing after 3 hops
On Mon, Feb 4, 2013 at 1:36 PM, Peter Hessler wrote: > make iBGP2 a route server. > Sounds promising, what are the key configurations in bgpd.conf to do so? So I can look further. Are we talking 'bout reflector/collector? > > On 2013 Feb 04 (Mon) at 13:32:43 -0200 (-0200), Eduardo Meyer wrote: > :Really? It's difficult for me in this environment, do I have another > option? > : > : > :On Mon, Feb 4, 2013 at 1:30 PM, Florian Obser wrote: > : > :> > :> > :> On 02/04/2013 03:59 PM, Eduardo Meyer wrote: > :> > Hello, > :> > > :> > I am facing a strange behavior, > :> > > :> > I have the following scenario > :> > > :> > eBGP1<->iBGP1<->iBGP2<->iBGP3<->eBGP2 > :> > :> iBGP must be fully meshed, a session between iBGP1 and iBGP3 is > :> missing. > :> > : > : > : > :-- > :=== > :Eduardo Meyer > :pessoal: dudu.me...@gmail.com > :profissional: ddm.farmac...@saude.gov.br > : > > -- > I don't care who does the electing as long as I get to do the nominating > -- Boss Tweed > -- === Eduardo Meyer pessoal: dudu.me...@gmail.com profissional: ddm.farmac...@saude.gov.br
Re: OpenBGP - iBGP peers not announcing after 3 hops
make iBGP2 a route server. On 2013 Feb 04 (Mon) at 13:32:43 -0200 (-0200), Eduardo Meyer wrote: :Really? It's difficult for me in this environment, do I have another option? : : :On Mon, Feb 4, 2013 at 1:30 PM, Florian Obser wrote: : :> :> :> On 02/04/2013 03:59 PM, Eduardo Meyer wrote: :> > Hello, :> > :> > I am facing a strange behavior, :> > :> > I have the following scenario :> > :> > eBGP1<->iBGP1<->iBGP2<->iBGP3<->eBGP2 :> :> iBGP must be fully meshed, a session between iBGP1 and iBGP3 is :> missing. :> : : : :-- :=== :Eduardo Meyer :pessoal: dudu.me...@gmail.com :profissional: ddm.farmac...@saude.gov.br : -- I don't care who does the electing as long as I get to do the nominating -- Boss Tweed
Re: OpenBGP - iBGP peers not announcing after 3 hops
Really? It's difficult for me in this environment, do I have another option? On Mon, Feb 4, 2013 at 1:30 PM, Florian Obser wrote: > > > On 02/04/2013 03:59 PM, Eduardo Meyer wrote: > > Hello, > > > > I am facing a strange behavior, > > > > I have the following scenario > > > > eBGP1<->iBGP1<->iBGP2<->iBGP3<->eBGP2 > > iBGP must be fully meshed, a session between iBGP1 and iBGP3 is > missing. > -- === Eduardo Meyer pessoal: dudu.me...@gmail.com profissional: ddm.farmac...@saude.gov.br
Re: OpenBGP - iBGP peers not announcing after 3 hops
On 02/04/2013 03:59 PM, Eduardo Meyer wrote: > Hello, > > I am facing a strange behavior, > > I have the following scenario > > eBGP1<->iBGP1<->iBGP2<->iBGP3<->eBGP2 iBGP must be fully meshed, a session between iBGP1 and iBGP3 is missing.
OpenBGP - iBGP peers not announcing after 3 hops
Hello, I am facing a strange behavior, I have the following scenario eBGP1<->iBGP1<->iBGP2<->iBGP3<->eBGP2 The very first eBGP (eBGP1) is my customer, the later (eBGP2) is my carrier (WAN). eBGP1 announces its network successfully to iBGP1, which announces everything successfuly to iBGP2, but iBGP2 never announces it to iBGP3. I have announce all and absolutely no filter. If I set up eBGP using reserved ASN in substitution to iBGP2 and iBGP3, the announcement just happens fine. All received/announced networks up to iBGP2 are considered valid using "bgpctl sh rib det nei iBGP1". Any suggestions on what might be going wrong? -- === Eduardo Meyer pessoal: dudu.me...@gmail.com profissional: ddm.farmac...@saude.gov.br
Re: OpenBGPd iBGP and IPv6
On Tue, Nov 06, 2012 at 12:52:10PM +0100, Laurent CARON wrote:
> On R1:
> # bgpctl show | egrep '(iv6_gw-001_to_004|ev6_gw-001_to_NERIM)'
> ev6_gw-001_to_NERIM 13193 302495 94094 0 01w3d21h 10543
> iv6_gw-001_to_004 49463 317993 154496 0 00:53:17 2
Hi,
I did finally use the following workaround:
R3R4: bgpd.conf:
COMMUNITY_PEERING="49463:555"
match from group Peering_France-IX set { community $COMMUNITY_PEERING }
R1/R2: bgpd.conf:
COMMUNITY_PEERING="49463:555"
match from group iBGP_VTY_TMM community $COMMUNITY_PEERING set { localpref 150 }
I now have the expected behavior.
# bgpctl show | egrep '(iv6_gw-001_to_004|ev6_gw-001_to_NERIM)'
ev6_gw-001_to_NERIM 13193 91485 27011 0 3d03h01m 10638
iv6_gw-001_to_004 49463 119710 63278 0 3d03h01m 10915
Laurent
Re: OpenBGPd iBGP and IPv6
On Fri, Nov 09, 2012 at 12:23:45AM +0800, Patrick Coleman wrote: > Is there any reason you need to restrict capabilities like this on > iBGP? Have you tried removing the the announce IPv6 unicast lines (so > the announce all inherits from the parent clause) to see what happens? Hi, announce (IPv4|IPv6) (none|unicast|vpn) For the given address family, control which subsequent address families (at the moment, only none, which disables the announcement of that address family, unicast, and vpn, which allows the distribution of BGP MPLS VPNs, are supported) are announced during the capabilities negotiation. Only routes for that address family and subsequent address family will be announced and processed. Since I only want/need/have unicast address family, there is apparently no need to change it. After trying with this statement removed, it doesn't change anything :( > The announce IPv6 unicast statement will affect the capabilities you > send to the peer, reading the manpage, so that seems suspicious. The > other thing I would check would be the internal routing - I assume you > have appropriate routes between the peers? Sure I do. Internal routing between loopback interfaces is done through OSPF. > Here's some of my IPv6 iBGP config. Note when filtering I also permit > all from the iBGP group (last line). These could probably be tightened > up a bit, but it might be a good place to start. I tried with disabled filters, it didn't help either. I'll no matter what still continue to find where this issue comes from. Cheers, Laurent
Re: OpenBGPd iBGP and IPv6
On Tue, Nov 6, 2012 at 7:52 PM, Laurent CARON wrote:
>
> group "iBGP_VTY_TMM" {
> remote-as 49463
> announceall
> set nexthop self
>
> neighbor 2a02:27d0:100:114::4 {
> descr iv6_gw-001_to_004
> local-address 2a02:27d0:0:112::1
> announce IPv6 unicast
Is there any reason you need to restrict capabilities like this on
iBGP? Have you tried removing the the announce IPv6 unicast lines (so
the announce all inherits from the parent clause) to see what happens?
The announce IPv6 unicast statement will affect the capabilities you
send to the peer, reading the manpage, so that seems suspicious. The
other thing I would check would be the internal routing - I assume you
have appropriate routes between the peers?
Here's some of my IPv6 iBGP config. Note when filtering I also permit
all from the iBGP group (last line). These could probably be tightened
up a bit, but it might be a good place to start.
-Patrick
...
group "iBGP - AS55881" {
remote-as 55881
announce all
set nexthop self
neighbor 202.1.16.86 {
descr "iBGP: atri-edge-001-a IPv4"
}
neighbor 2405:6a00:6:fd::2 {
descr "iBGP: atri-edge-001-a IPv6"
}
...
deny from any
allow from any inet prefixlen 8 - 24
allow from any inet6 prefixlen 8 - 48
# filter bogus networks: IPv4
deny from any prefix 10.0.0.0/8 prefixlen >= 8
deny from any prefix 172.16.0.0/12 prefixlen >= 12
deny from any prefix 192.168.0.0/16 prefixlen >= 16
deny from any prefix 169.254.0.0/16 prefixlen >= 16
deny from any prefix 192.0.2.0/24 prefixlen >= 24
deny from any prefix 224.0.0.0/4 prefixlen >= 4
deny from any prefix 240.0.0.0/4 prefixlen >= 4
# filter bogus networks: IPv6
deny from any prefix 3ffe::/16 prefixlen >= 16# 6bone
deny from any prefix 2001:db8::/32 prefixlen >=32# documentation
deny from any prefix ::/8 prefixlen >= 8# loopback
deny from any prefix fe00::/8 prefixlen >= 8# multicast (RFC3513)
deny from any prefix ff00::/8 prefixlen >= 8# multicast (RFC3513)
# Permit anything from our iBGP peers
allow from group "iBGP - AS55881"
OpenBGPd iBGP and IPv6
Hi,
I'm running what I would call a fairly basic setup composed of:
- 4 routers (OpenBGPd) / R{1..4}
- 2 transits AS{8218,13193}
- my AS: 49463
- BGP session over loopback interfaces (2a02:27d0:0:112::1 /
2a02:27d0:100:114::4)
- Several peering sessions (HE, ...)
R1 - bgpd.conf:
AS 49463
network 2a02:27d0::/48
socket "/var/www/logs/bgpd.rsock" restricted
group "eBGP_Transit" {
announceself
holdtime30
holdtime min3
set med 100
neighbor 2001:7a8:1:9FF2::1 {
remote-as 13193
descr ev6_gw-001_to_NERIM
local-address 2001:7a8:1:9FF2::2
announce IPv6 unicast
announce IPv4 none
}
}
group "iBGP_VTY_TMM" {
remote-as 49463
announceall
set nexthop self
neighbor 2a02:27d0:100:114::4 {
descr iv6_gw-001_to_004
local-address 2a02:27d0:0:112::1
announce IPv6 unicast
announce IPv4 none
set prepend-neighbor4
set prepend-self1
}
}
deny from any
allow from any inet6 prefixlen 16 - 48
deny from any prefix ::/8 prefixlen >= 8
deny from any prefix 2001:2::/48 prefixlen >= 48# BMWG [RFC5180]
deny from any prefix 2001:10::/28 prefixlen >= 28 # ORCHID [RFC4843]
deny from any prefix 2001:db8::/32 prefixlen >= 32 # docu range [RFC3849]
deny from any prefix 3ffe::/16 prefixlen >= 16 # old 6bone
deny from any prefix fc00::/7 prefixlen >= 7# unique local unicast
deny from any prefix fe80::/10 prefixlen >= 10 # link local unicast
deny from any prefix fec0::/10 prefixlen >= 10 # old site local unicast
deny from any prefix ff00::/8 prefixlen >= 8# multicast
R4 - bgpd.conf:
AS 49463
network 2a02:27d0:100::/48
socket "/var/www/logs/bgpd.rsock" restricted
group "eBGP_Transit_NEO" {
remote-as 8218
holdtime30
holdtime min3
announceself
set med 100
neighbor2001:1b48:2:103::175{
descr ev6_gw-004_to_NEO
local-address 2001:1b48:2:103::176
announce IPv4 none
announce IPv6 unicast
}
}
group "iBGP_VTY_TMM" {
remote-as 49463
announceall
neighbor2a02:27d0:0:112::1 {
descr iv6_gw-004_to_001
local-address 2a02:27d0:100:114::4
announce IPv6 unicast
announce IPv4 none
set prepend-neighbor1
set prepend-self1
set nexthop self
}
}
deny from any
allow from any inet6 prefixlen 16 - 48
deny from any prefix ::/8 prefixlen >= 8
deny from any prefix 2001:2::/48 prefixlen >= 48# BMWG [RFC5180]
deny from any prefix 2001:10::/28 prefixlen >= 28 # ORCHID [RFC4843]
deny from any prefix 2001:db8::/32 prefixlen >= 32 # docu range [RFC3849]
deny from any prefix 3ffe::/16 prefixlen >= 16 # old 6bone
deny from any prefix fc00::/7 prefixlen >= 7# unique local unicast
deny from any prefix fe80::/10 prefixlen >= 10 # link local unicast
deny from any prefix fec0::/10 prefixlen >= 10 # old site local unicast
deny from any prefix ff00::/8 prefixlen >= 8# multicast
On R1:
# bgpctl show | egrep '(iv6_gw-001_to_004|ev6_gw-001_to_NERIM)'
ev6_gw-001_to_NERIM 13193 302495 94094 0 01w3d21h 10543
iv6_gw-001_to_004 49463 317993 154496 0 00:53:17 2
I receive 10543 IPv6 prefixes from my transit, but only 2 over the iBGP
session.
# bgpctl show rib nei iv6_gw-001_to_004 in
I*2001:7f8:4::/48 2a02:27d0:100:114::4100 200 49463 49463 49463
49463 49463 49463 49463 49463 8218 8218 5459 i
I*2a02:27d0:100::/48 2a02:27d0:100:114::4100 0 49463 49463 49463
49463 49463 49463 49463 49463 i
# bgpctl show rib nei iv6_gw-001_to_004 out
*>2001:559:8008::/48 2001:7a8:1:9ff2::1100 100 49463 13193 3356
7015 7015 7015 7015 ?
*>2001:7f8:4::/48 2001:7a8:1:9ff2::1100 100 49463 13193 5459 i
AI*> 2a02:27d0::/48 :: 100 0 49463 i
On R4:
# bgpctl show | egrep '(iv6_gw-004_to_001|ev6_gw-004_to_NEO)'
ev6_gw-004_to_NEO8218 8451331 0 00:54:35 10849
iv6_gw-004_to_001 49463263562 0 00:54:35 3
I receive 10849 IPv6 prefixes from my transit, but only 3 over the iBGP
session.
# bgpctl show rib nei iv6_gw-004_to_001 in
flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale
origin: i = IGP, e = EGP, ? = Incomplete
flags destination
Re: BGPD Socket errors when trying to establish IBGP on lo1
>First try without "tcp md5sig" and enable it only when it is
>working.
>But I guess your problem is that the other side is expecting the
>connection to come from a different IP than the one selected by
>the route
>lookup. In that case set "local-address 172.16.101.170" in the
>iBGP group.
>
>Setting "local-address" is a good habit and necessary if you use
>loopback
>interfaces or have non directly attached peers.
>--
>:wq Claudio
Per your kind comments, I have re-configured IBGP group as below.
This time it seems that despite "local-address" being configured,
it seems one of the peers is picking up its bge0 address
(172.16.101.178)
group "iBGP_Neighbors" {
remote-as $MY_ASN
announce all
neighbor 172.16.101.169
local-address $MY_ROUTER_ID
}
group "iBGP_Neighbors" {
remote-as $MY_ASN
announce all
neighbor 172.16.101.170
local-address $MY_ROUTER_ID
}
# bgpd -dv
startup
MY_ASN = "65015"
MY_IPV4NET = "172.16.101.0/21"
MY_ROUTER_ID = "172.16.101.169"
route decision engine ready
session engine ready
listening on 0.0.0.0
listening on ::
SE reconfigured
neighbor 172.16.101.170: state change None -> Idle, reason: None
neighbor 172.16.101.170: state change Idle -> Connect, reason: Start
neighbor 172.16.101.170: state change Connect -> OpenSent, reason:
Connection opened
neighbor 172.16.101.170: state change OpenSent -> Active, reason:
Connection closed
RDE reconfigured
neighbor 172.16.101.170: state change Active -> Idle, reason: Stop
session engine exiting
Lost child: session engine exited
route decision engine exiting
kernel routing table decoupled
Terminating
# bgpd -dv
startup
MY_ASN = "65015"
MY_IPV4NET = "172.16.101.0/21"
MY_ROUTER_ID = "172.16.101.170"
route decision engine ready
RDE reconfigured
session engine ready
listening on 0.0.0.0
listening on ::
SE reconfigured
neighbor 172.16.101.169: state change None -> Idle, reason: None
neighbor 172.16.101.169: state change Idle -> Connect, reason: Start
neighbor 172.16.101.169: socket error: Connection refused
neighbor 172.16.101.169: state change Connect -> Active, reason:
Connection open failed
connection from non-peer 172.16.101.178 refused
neighbor 172.16.101.169: socket error: Connection refused
neighbor 172.16.101.169: state change Active -> Idle, reason: Stop
session engine exiting
Lost child: session engine exited
route decision engine exiting
kernel routing table decoupled
Terminating
Re: BGPD Socket errors when trying to establish IBGP on lo1
On Wed, Jun 02, 2010 at 10:56:59AM +0100, rh...@hushmail.com wrote:
> Despite having a working OSPF setup and no PF config, I'm seeing
> socket errors in the logs when attempting to establish an IBGP
> session to lo1 on another machine.
>
> # ospfctl sh ne
> ID Pri StateDeadTime Address Iface
> Uptime
> 172.16.101.169 100 FULL/BCKUP 00:00:13 172.16.101.178 bge0
> 00:42:50
>
> # ping 172.16.101.169
> PING 172.16.101.169 (172.16.101.169): 56 data bytes
> 64 bytes from 172.16.101.169: icmp_seq=0 ttl=255 time=0.355 ms
> 64 bytes from 172.16.101.169: icmp_seq=1 ttl=255 time=0.240 ms
> 64 bytes from 172.16.101.169: icmp_seq=2 ttl=255 time=0.240 ms
>
> # pfctl -sr
> pass all flags S/SA keep state
> block drop in on ! lo0 proto tcp from any to any port 6000:6010
>
>
> # bgpd -dv
> startup
> MY_ASN = "65015"
> MY_IPV4NET = "172.16.101.0/20"
> MY_ROUTER_ID = "172.16.101.170"
> route decision engine ready
> RDE reconfigured
> session engine ready
> listening on 0.0.0.0
> listening on ::
> SE reconfigured
> neighbor 172.16.101.169: state change None -> Idle, reason: None
> neighbor 172.16.101.169: state change Idle -> Connect, reason: Start
> neighbor 172.16.101.169: socket error: Operation timed out
> neighbor 172.16.101.169: state change Connect -> Active, reason:
> Connection open failed
> neighbor 172.16.101.169: socket error: Operation timed out
> neighbor 172.16.101.169: state change Connect -> Idle, reason: Stop
> session engine exiting
> Lost child: session engine exited
> route decision engine exiting
> kernel routing table decoupled
> Terminating
>
> bgpd.conf:
> MY_ASN = "65015"
> MY_IPV4NET = "172.16.101.0/20"
> MY_ROUTER_ID = "172.16.101.170"
> AS $MY_ASN
> router-id $MY_ROUTER_ID
> holdtime 90
> holdtime min 3
> fib-update yes
> network 172.16.101.0/20
> group "iBGP_Neighbors" {
> remote-as $MY_ASN
> tcp md5sig password **
> announce all
> neighbor 172.16.101.169
> }
>
First try without "tcp md5sig" and enable it only when it is working.
But I guess your problem is that the other side is expecting the
connection to come from a different IP than the one selected by the route
lookup. In that case set "local-address 172.16.101.170" in the iBGP group.
Setting "local-address" is a good habit and necessary if you use loopback
interfaces or have non directly attached peers.
--
:wq Claudio
BGPD Socket errors when trying to establish IBGP on lo1
Despite having a working OSPF setup and no PF config, I'm seeing
socket errors in the logs when attempting to establish an IBGP
session to lo1 on another machine.
# ospfctl sh ne
ID Pri StateDeadTime Address Iface
Uptime
172.16.101.169 100 FULL/BCKUP 00:00:13 172.16.101.178 bge0
00:42:50
# ping 172.16.101.169
PING 172.16.101.169 (172.16.101.169): 56 data bytes
64 bytes from 172.16.101.169: icmp_seq=0 ttl=255 time=0.355 ms
64 bytes from 172.16.101.169: icmp_seq=1 ttl=255 time=0.240 ms
64 bytes from 172.16.101.169: icmp_seq=2 ttl=255 time=0.240 ms
# pfctl -sr
pass all flags S/SA keep state
block drop in on ! lo0 proto tcp from any to any port 6000:6010
# bgpd -dv
startup
MY_ASN = "65015"
MY_IPV4NET = "172.16.101.0/20"
MY_ROUTER_ID = "172.16.101.170"
route decision engine ready
RDE reconfigured
session engine ready
listening on 0.0.0.0
listening on ::
SE reconfigured
neighbor 172.16.101.169: state change None -> Idle, reason: None
neighbor 172.16.101.169: state change Idle -> Connect, reason: Start
neighbor 172.16.101.169: socket error: Operation timed out
neighbor 172.16.101.169: state change Connect -> Active, reason:
Connection open failed
neighbor 172.16.101.169: socket error: Operation timed out
neighbor 172.16.101.169: state change Connect -> Idle, reason: Stop
session engine exiting
Lost child: session engine exited
route decision engine exiting
kernel routing table decoupled
Terminating
bgpd.conf:
MY_ASN = "65015"
MY_IPV4NET = "172.16.101.0/20"
MY_ROUTER_ID = "172.16.101.170"
AS $MY_ASN
router-id $MY_ROUTER_ID
holdtime 90
holdtime min 3
fib-update yes
network 172.16.101.0/20
group "iBGP_Neighbors" {
remote-as $MY_ASN
tcp md5sig password **
announce all
neighbor 172.16.101.169
}
Re: Possible bug ? Re: 4.7 Release - bgpd not passing IBGP routes
Thanks for the heads up Claudio, will look into it a bit more in light of your comments.
Re: Possible bug ? Re: 4.7 Release - bgpd not passing IBGP routes
On Sun, May 30, 2010 at 10:38:01PM +, a b wrote: > (1) With "set localpref 500" on EBGP session on BSD02 > > "bgpctl sh rib" on BSD01 : > I*> 0.0.0.0/0172.16.99.254500065432i > * 0.0.0.0/0172.16.99.254100065432i > > "bgpctl sh rib" on BSD02 : > *> 0.0.0.0/0172.16.99.254500065432i > This looks right. BSD02 is propegating the route to BSD01 and BSD01 selects that one as more prefered over the non iBGP route. > (2) With no localpref set on EBGP session on BGP02 > > "bgpctl sh rib" on BSD01 : > *> 0.0.0.0/0172.16.99.254100065432i > I* 0.0.0.0/0172.16.99.254100065432i > > "bgpctl sh rib" on BSD02 : > *> 0.0.0.0/0172.16.99.254100065432i > I* 0.0.0.0/0172.16.99.254100065432i > Again correct, both routers select the eBGP route since the prefixes have the same metrics until the tiebreaker reaches the ebgp vs ibgp check. In both cases the router select the eBGP route and propagate that route to the other iBGP router. > (3) With "set localpref 25" on EBGP session on BSD02 > > "bgpctl sh rib" on BSD01 : > *>0.0.0.0/0172.16.99.254 100065432i > > "bgpctl sh rib" on BSD02 : > I*> 0.0.0.0/0 172.16.99.254100065432i > *0.0.0.0/0 172.16.99.25425 065432i > Again everything is fine. BSD01 selects the eBGP route and propagets that route as iBGP route the BSD02 where that route is more prefered because of the higher localpref. Note, only the active route is redistributed and over iBGP sessions only the active routes that are not internal are redistributed. That is the reason why in case 1 and 3 only one router ends up with both routes. PS: please fix your mailclient. It is almost impossible to read the mails because of the insane linewrapping. -- :wq Claudio
Re: Possible bug ? Re: 4.7 Release - bgpd not passing IBGP routes
(1) With "set localpref 500" on EBGP session on BSD02 "bgpctl sh rib" on BSD01 : I*>0.0.0.0/0172.16.99.254500065432i * 0.0.0.0/0172.16.99.254100065432i "bgpctl sh rib" on BSD02 : *>0.0.0.0/0172.16.99.254500065432i (2) With no localpref set on EBGP session on BGP02 "bgpctl sh rib" on BSD01 : *> 0.0.0.0/0172.16.99.254100065432i I*0.0.0.0/0 172.16.99.254100065432i "bgpctl sh rib" on BSD02 : *> 0.0.0.0/0172.16.99.254100065432i I*0.0.0.0/0 172.16.99.254100065432i (3) With "set localpref 25" on EBGP session on BSD02 "bgpctl sh rib" on BSD01 : *>0.0.0.0/0172.16.99.254 100065432i "bgpctl sh rib" on BSD02 : I*>0.0.0.0/0 172.16.99.254100065432i *0.0.0.0/0172.16.99.25425 065432i
Re: Possible bug ? Re: 4.7 Release - bgpd not passing IBGP routes
Hi, On Sun, 30 May 2010 02:34:12 +0700, a b wrote: Hi, Further to my earlier email, additional experimentation shows that removal of "set localpref" from my config file on BSD02 allows full mesh IBGP to correctly occur. Reinsertion of "set localpref" makes the issue originally reported reappear. By setting received prefixes to localpref 400, it would be preferable to the router thus made other similar prefixes with lower localpref unselected. But, yes, it should appeared on RIB. Please show us "bgpctl sh rib" output from all routers. And, if I'm not mistaken, if there are prefixes with the same metrics comes from both eBGP and iBGP, prefixes from eBGP peers will be chosen. HTH, -- insandotpraja(at)gmaildotcom
Re: 4.7 Release - bgpd not passing IBGP routes
Hello,
Thank you for your reply.
Ref. your pointing out
> group
>
"transit 65432" {
> set localpref 400
> remote-as $PEER_ASN
> neighbor
$REMOTE_IP {
> descr "EBGP BOX"
> announce self
^
Please
explain why, therefore, when I remove "set localpref 400", the IBGP mesh
defined in the next section of the config occurs correctly ?
When "set
localpref 400" is removed, both primary and secondary routes (with default
pref 100) are visible on both IGBP peers.
As soon as "set localpref 400" is
reinserted, the issue originally presented reappears.
Many thanks again for
your kind assistance.
Re: 4.7 Release - bgpd not passing IBGP routes
Hi,
On Sat, 29 May 2010 18:25:12 +0700, a b wrote:
Hi,
I've got a curious problem with a test I've been doing with bgpd on 4.7
release. Hopefully someone can point out where I am going wrong.
Test Layout
:
BSD01 -> EBGP01
BSD02 -> EBGP01
BSDxx are both 4.7 release BGP speakers in
private ASN 64550 (OSPF running between them as IGP)
EBGP01 is a non OpenBSD
BGP speaker in private ASN 65432 (just sending default route for test
purposes)
BSD01 does not appear to be receiving routes from BSD02 (in this
case, it should be learning a higher pref default route from BSD02 over
IBGP)
on BSD01 :
# bgpctl show sum
Neighbor ASMsgRcvd MsgSent OutQ
Up/Down State/PrfRcvd
BSD0264550 19 19 0
00:15:25 0
EBGP BOX 65432 20 19 0
00:17:09 1
#bgpctl show rib
*> 0.0.0.0/0 172.16.99.254 400 0
65432 i
on BSD02 :
# bgpctl show sum
Neighbor AS
MsgRcvd MsgSent OutQ Up/Down
State/PrfRcvd
BSD0164550 121
125 0
00:20:25 1
EBGP BOX 65432 1163 1188
0 01:17:09 1
#bgpctl show rib
I*> 0.0.0.0/0 172.16.99.254
400 0 65432 i
* 0.0.0.0/0 172.16.99.254 100 0 65432 i
bgpd.conf from
BSD01 :
PEER_ASN="65432"
LOCAL_ASN="64550"
MY_ID="192.168.152.1"
REMOTE_IP="172.16.99.254"
IBGP_PEER="192.168.152.2"
LO1_IP="192.168.152.1"
AS
$LOCAL_ASN
router-id $MY_ID
holdtime 180
holdtime min 3
fib-update yes
group
"transit 65432" {
set localpref 400
remote-as $PEER_ASN
neighbor $REMOTE_IP {
descr "EBGP BOX"
announce self
^
I think you need to re-assess that. from man (5) bgpd.conf
announce (all|none|self|default-route)
If set to none, no UPDATE messages will be sent to the
neighbor.
If set to default-route, only the default route will be
announced
to the neighbor. If set to all, all generated UPDATE messages
will be sent to the neighbor. This is usually used for
transit
AS's and IBGP peers. The default value for EBGP peers is
self,
which limits the sent UPDATE messages to announcements of the
local AS. The default for IBGP peers is all.
Which, you need to have sth like:
network 0.0.0.0/0
}
}
group "IBGP Mesh" {
remote-as $LOCAL_ASN
local-address $LO1_IP
neighbor $IBGP_PEER {
descr "BSD02"
}
}
bgpd.conf from
BSD02 :
PEER_ASN="65432"
LOCAL_ASN="64550"
MY_ID="192.168.152.2"
REMOTE_IP="172.16.99.254"
IBGP_PEER="192.168.152.1"
LO1_IP="192.168.152.2"
AS
$LOCAL_ASN
router-id $MY_ID
holdtime 180
holdtime min 3
fib-update yes
group
"transit 65432" {
set localpref 400
remote-as $PEER_ASN
neighbor $REMOTE_IP {
descr "EBGP BOX"
announce self
}
}
group "IBGP Mesh" {
remote-as $LOCAL_ASN
local-address $LO1_IP
neighbor $IBGP_PEER {
descr "BSD01"
}
}
HTH,
--
insandotpraja(at)gmaildotcom
Possible bug ? Re: 4.7 Release - bgpd not passing IBGP routes
Hi, Further to my earlier email, additional experimentation shows that removal of "set localpref" from my config file on BSD02 allows full mesh IBGP to correctly occur. Reinsertion of "set localpref" makes the issue originally reported reappear.
4.7 Release - bgpd not passing IBGP routes
Hi,
I've got a curious problem with a test I've been doing with bgpd on 4.7
release. Hopefully someone can point out where I am going wrong.
Test Layout
:
BSD01 -> EBGP01
BSD02 -> EBGP01
BSDxx are both 4.7 release BGP speakers in
private ASN 64550 (OSPF running between them as IGP)
EBGP01 is a non OpenBSD
BGP speaker in private ASN 65432 (just sending default route for test
purposes)
BSD01 does not appear to be receiving routes from BSD02 (in this
case, it should be learning a higher pref default route from BSD02 over IBGP)
on BSD01 :
# bgpctl show sum
Neighbor ASMsgRcvd MsgSent OutQ
Up/Down State/PrfRcvd
BSD0264550 19 19 0
00:15:25 0
EBGP BOX 65432 20 19 0
00:17:09 1
#bgpctl show rib
*> 0.0.0.0/0 172.16.99.254 400 0
65432 i
on BSD02 :
# bgpctl show sum
Neighbor AS
MsgRcvd MsgSent OutQ Up/Down
State/PrfRcvd
BSD0164550 121
125 0
00:20:25 1
EBGP BOX 65432 1163 1188
0 01:17:09 1
#bgpctl show rib
I*> 0.0.0.0/0 172.16.99.254
400 0 65432 i
* 0.0.0.0/0 172.16.99.254 100 0 65432 i
bgpd.conf from
BSD01 :
PEER_ASN="65432"
LOCAL_ASN="64550"
MY_ID="192.168.152.1"
REMOTE_IP="172.16.99.254"
IBGP_PEER="192.168.152.2"
LO1_IP="192.168.152.1"
AS
$LOCAL_ASN
router-id $MY_ID
holdtime 180
holdtime min 3
fib-update yes
group
"transit 65432" {
set localpref 400
remote-as $PEER_ASN
neighbor $REMOTE_IP {
descr "EBGP BOX"
announce self
}
}
group "IBGP Mesh" {
remote-as $LOCAL_ASN
local-address $LO1_IP
neighbor $IBGP_PEER {
descr "BSD02"
}
}
bgpd.conf from
BSD02 :
PEER_ASN="65432"
LOCAL_ASN="64550"
MY_ID="192.168.152.2"
REMOTE_IP="172.16.99.254"
IBGP_PEER="192.168.152.1"
LO1_IP="192.168.152.2"
AS
$LOCAL_ASN
router-id $MY_ID
holdtime 180
holdtime min 3
fib-update yes
group
"transit 65432" {
set localpref 400
remote-as $PEER_ASN
neighbor $REMOTE_IP {
descr "EBGP BOX"
announce self
}
}
group "IBGP Mesh" {
remote-as $LOCAL_ASN
local-address $LO1_IP
neighbor $IBGP_PEER {
descr "BSD01"
}
}
Re: Inconsistency between IPv6 and IPv4 announces between eBGP peers hooked through an iBGP session (OpenBGPd)
On 08/02/2010 18:41, Claudio Jeker wrote: Could you give it a spin? I just tried it and so far it seems successful. I'll let it run for a few days on my secondary bgp box and upgrade the primary one if successful. Many thanks
Re: Inconsistency between IPv6 and IPv4 announces between eBGP peers hooked through an iBGP session (OpenBGPd)
On Sat, Jan 30, 2010 at 03:21:32PM +0100, Laurent CARON wrote: > On 30/01/2010 14:59, Laurent CARON wrote: > >My last test was with current as of 20100119. > > > >I did tests with 20091201 and 20091202 because the problem did appear > >just between those 2 dates and is reproductible. > > > >I'll try to upgrade to current and see if it helps. > > Since no commits were done on bgpd since 20100113 and my last test > was from 20100119 with current from 20100119, I think the issue is > still there. > I just commited something that may be the reason for you IPv6 issues. "Unbreak IPv6 local address lookups. Some idiot aka me optimised a loop and because of that either the IPv4 or IPv6 local address was not set. Because of this prefixes were sent out with all zero nexthops." Could you give it a spin? I still try to reproduce your problem but am unable to do so. Could I get the bgpd.conf and ifconfig output for the interface to the failing system? -- :wq Claudio
Re: Inconsistency between IPv6 and IPv4 announces between eBGP peers hooked through an iBGP session (OpenBGPd)
On 30/01/2010 14:59, Laurent CARON wrote: My last test was with current as of 20100119. I did tests with 20091201 and 20091202 because the problem did appear just between those 2 dates and is reproductible. I'll try to upgrade to current and see if it helps. Since no commits were done on bgpd since 20100113 and my last test was from 20100119 with current from 20100119, I think the issue is still there. Thanks
Re: Inconsistency between IPv6 and IPv4 announces between eBGP peers hooked through an iBGP session (OpenBGPd)
On 30/01/2010 13:49, Claudio Jeker wrote: I'll have a look at this. Please make sure you test against a -current bgpd instead of the 20091202 version since I already fixed a few issues with regard to the AF, AFI/SAFI -> AID commit that was done between 20091201 and 20091202. Currently I have the strange feeling that for some reason the IPv6 routes are skipped when doing the initial table dump. I know I tried this during n2k10 and could not reproduce it so there must be some difference between your setup and my test. Hi Claudio, My last test was with current as of 20100119. I did tests with 20091201 and 20091202 because the problem did appear just between those 2 dates and is reproductible. I'll try to upgrade to current and see if it helps. Thanks Laurent
Re: Inconsistency between IPv6 and IPv4 announces between eBGP peers hooked through an iBGP session (OpenBGPd)
On Thu, Jan 21, 2010 at 10:50:21AM +0100, Laurent CARON wrote: > On 19/01/2010 14:03, Laurent CARON wrote: > >On 19/01/2010 13:23, Sebastian Spies wrote: > >>Seems, that the Cisco doesn't send the initial Keepalive. Could you > >>please provide a longer caption using -s 4096 and the OPEN messages of > >>20091201 > > > >$ tcpdump -s 4096 -w /tmp/bgpd_20091201_4096 -i bge0 host > >2001:7A8:1:9FF2::1 > >$ tcpdump -s 4096 -w /tmp/bgpd_20091202_4096 -i bge0 host > >2001:7A8:1:9FF2::1 > > > >http://zenon.apartia.fr/stuff/bgpd_20091201_4096 <=> Working announces > >http://zenon.apartia.fr/stuff/bgpd_20091202_4096 <=> Non-Working announces > > > > Hi, > > Do you have a clue about this problem ? > I'll have a look at this. Please make sure you test against a -current bgpd instead of the 20091202 version since I already fixed a few issues with regard to the AF, AFI/SAFI -> AID commit that was done between 20091201 and 20091202. Currently I have the strange feeling that for some reason the IPv6 routes are skipped when doing the initial table dump. I know I tried this during n2k10 and could not reproduce it so there must be some difference between your setup and my test. -- :wq Claudio
Re: Inconsistency between IPv6 and IPv4 announces between eBGP peers hooked through an iBGP session (OpenBGPd)
On 19/01/2010 14:03, Laurent CARON wrote: On 19/01/2010 13:23, Sebastian Spies wrote: Seems, that the Cisco doesn't send the initial Keepalive. Could you please provide a longer caption using -s 4096 and the OPEN messages of 20091201 $ tcpdump -s 4096 -w /tmp/bgpd_20091201_4096 -i bge0 host 2001:7A8:1:9FF2::1 $ tcpdump -s 4096 -w /tmp/bgpd_20091202_4096 -i bge0 host 2001:7A8:1:9FF2::1 http://zenon.apartia.fr/stuff/bgpd_20091201_4096 <=> Working announces http://zenon.apartia.fr/stuff/bgpd_20091202_4096 <=> Non-Working announces Hi, Do you have a clue about this problem ? Thanks
Re: Inconsistency between IPv6 and IPv4 announces between eBGP peers hooked through an iBGP session (OpenBGPd)
On 19/01/2010 13:23, Sebastian Spies wrote: Seems, that the Cisco doesn't send the initial Keepalive. Could you please provide a longer caption using -s 4096 and the OPEN messages of 20091201 $ tcpdump -s 4096 -w /tmp/bgpd_20091201_4096 -i bge0 host 2001:7A8:1:9FF2::1 $ tcpdump -s 4096 -w /tmp/bgpd_20091202_4096 -i bge0 host 2001:7A8:1:9FF2::1 http://zenon.apartia.fr/stuff/bgpd_20091201_4096 <=> Working announces http://zenon.apartia.fr/stuff/bgpd_20091202_4096 <=> Non-Working announces
Re: Inconsistency between IPv6 and IPv4 announces between eBGP peers hooked through an iBGP session (OpenBGPd)
Laurent CARON wrote: > On 19/01/2010 12:18, Sebastian Spies wrote: >> Would you please provide a packet capture? > > Here you go: > > http://zenon.apartia.fr/stuff/bgpd_20091201 <=> Working announces > http://zenon.apartia.fr/stuff/bgpd_20091202 <=> Non-Working announces > > Captures produced with: > $ tcpdump -w /tmp/bgpd_20091201 -i bge0 host 2001:7A8:1:9FF2::1 > $ tcpdump -w /tmp/bgpd_20091202 -i bge0 host 2001:7A8:1:9FF2::1 Seems, that the Cisco doesn't send the initial Keepalive. Could you please provide a longer caption using -s 4096 and the OPEN messages of 20091201 -- Sebastian Spies e-mail: sebastian.sp...@de-cix.net DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt Mobile: +49 1577 7830883 Geschaeftsfuehrer Harald A. SummaFax: +49 69 4056 2716 Registergericht AG Koeln, HRB 51135 http://www.de-cix.net Zentrale: Lichtstr. 43i, 50825 Koeln [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: Inconsistency between IPv6 and IPv4 announces between eBGP peers hooked through an iBGP session (OpenBGPd)
On 19/01/2010 12:18, Sebastian Spies wrote: Would you please provide a packet capture? Here you go: http://zenon.apartia.fr/stuff/bgpd_20091201 <=> Working announces http://zenon.apartia.fr/stuff/bgpd_20091202 <=> Non-Working announces Captures produced with: $ tcpdump -w /tmp/bgpd_20091201 -i bge0 host 2001:7A8:1:9FF2::1 $ tcpdump -w /tmp/bgpd_20091202 -i bge0 host 2001:7A8:1:9FF2::1 Thanks
Re: Inconsistency between IPv6 and IPv4 announces between eBGP peers hooked through an iBGP session (OpenBGPd)
Laurent CARON wrote: > On 09/01/2010 11:48, Laurent CARON wrote: >> IPv6 works in latest version only on iBGP link and in a tunnel link to >> hurricane electric but not directly to a cisco peer. > > Hi, > > I finally managed to track down the date of the commit that made the > 2nd IPv6 session fail. > > cvs -d$CVSROOT up -D "2009-12-01 12:00" => works > cvs -d$CVSROOT up -D "2009-12-02 12:00" => doesn't work > > Reminder: > I'm connecting 2 OpenBGPd boxes to *one* cisco router (BGP4/BGP4+). > > BGP4+ sessions never comes up when I use OpenBGPd dated from or after > 2009-12-02. Would you please provide a packet capture? -- Sebastian Spies e-mail: sebastian.sp...@de-cix.net DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt Mobile: +49 1577 7830883 Geschaeftsfuehrer Harald A. SummaFax: +49 69 4056 2716 Registergericht AG Koeln, HRB 51135 http://www.de-cix.net Zentrale: Lichtstr. 43i, 50825 Koeln [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: Inconsistency between IPv6 and IPv4 announces between eBGP peers hooked through an iBGP session (OpenBGPd)
On 09/01/2010 11:48, Laurent CARON wrote: IPv6 works in latest version only on iBGP link and in a tunnel link to hurricane electric but not directly to a cisco peer. Hi, I finally managed to track down the date of the commit that made the 2nd IPv6 session fail. cvs -d$CVSROOT up -D "2009-12-01 12:00" => works cvs -d$CVSROOT up -D "2009-12-02 12:00" => doesn't work Reminder: I'm connecting 2 OpenBGPd boxes to *one* cisco router (BGP4/BGP4+). BGP4+ sessions never comes up when I use OpenBGPd dated from or after 2009-12-02. Thanks
Re: Inconsistency between IPv6 and IPv4 announces between eBGP peers hooked through an iBGP session (OpenBGPd)
On 09/01/2010 03:58, Claudio Jeker wrote:
The missing "A" is correct in this case. Because 'A' is only set when the
network is announced on this router (config has a network XY statement).
Since the prefix is in the Adj-Rib-Out it will be sent to the other side.
Hi,
Both prefixes (v4 and v6) are announced on both routers
ISP1---
| |
BGPGW001--IBGP--BGPGW002
| |
ISP2---
IPv6 announcement works for me on my test setup, even accross iBGP
sessions.
IPv6 works in latest version only on iBGP link and in a tunnel link to
hurricane electric but not directly to a cisco peer.
Laurent
Re: Inconsistency between IPv6 and IPv4 announces between eBGP peers hooked through an iBGP session (OpenBGPd)
On Tue, Jan 05, 2010 at 04:39:28PM +0100, Laurent CARON wrote: > Hi, > > Background: > > Two OpenBSD routers hooked each to two ISPs. > > Announced networks: > 2001:7a8:820::/44 > 213.215.28.0/23 > > Relevant config snippets on bgpgw-001: > http://pastebin.com/m77017bcd > > Relevant config snippets on bgpgw-002: > http://pastebin.com/d74d05557 This link is dead. > Strangeness: > > On peer bgpgw-001: v4 and v6 networks are announced. On bgpgw-002 v6 > networks are received from bgpgw-001 but not announced. > > bgpgw-001:/var/log# bgpctl sho rib neigh nerim-ipv6-bgp-peer out > flags: * = Valid, > = Selected, I = via IBGP, A = Announced > origin: i = IGP, e = EGP, ? = Incomplete > > flags destination gateway lpref med aspath origin > AI*> 2001:7a8:820::/44 :: 100 0 i > bgpgw-001:/var/log# bgpctl sho rib neigh nerim-ipv4-bgp-peer out > flags: * = Valid, > = Selected, I = via IBGP, A = Announced > origin: i = IGP, e = EGP, ? = Incomplete > > flags destination gateway lpref med aspath origin > AI*> 213.215.28.0/23 0.0.0.0100 0 i > > > bgpgw-002:~# bgpctl sho rib neigh nerim-ipv6-bgp-peer out > flags: * = Valid, > = Selected, I = via IBGP, A = Announced > origin: i = IGP, e = EGP, ? = Incomplete > > flags destination gateway lpref med aspath origin > I*> 2001:7a8:820::/44 2001:7a8:820::1100 0 i The missing "A" is correct in this case. Because 'A' is only set when the network is announced on this router (config has a network XY statement). Since the prefix is in the Adj-Rib-Out it will be sent to the other side. > bgpgw-002:~# bgpctl sho rib neigh nerim-ipv4-bgp-peer out > flags: * = Valid, > = Selected, I = via IBGP, A = Announced > origin: i = IGP, e = EGP, ? = Incomplete > > flags destination gateway lpref med aspath origin > AI*> 213.215.28.0/23 0.0.0.0100 0 i > IPv6 announcement works for me on my test setup, even accross iBGP sessions. -- :wq Claudio
Re: Inconsistency between IPv6 and IPv4 announces between eBGP peers hooked through an iBGP session (OpenBGPd)
On 05/01/2010 16:39, Laurent CARON wrote: Hi, Background: Two OpenBSD routers hooked each to two ISPs. Announced networks: 2001:7a8:820::/44 213.215.28.0/23 Relevant config snippets on bgpgw-001: http://pastebin.com/m77017bcd Relevant config snippets on bgpgw-002: http://pastebin.com/d74d05557 Strangeness: On peer bgpgw-001: v4 and v6 networks are announced. On bgpgw-002 v6 networks are received from bgpgw-001 but not announced. bgpgw-001:/var/log# bgpctl sho rib neigh nerim-ipv6-bgp-peer out flags: * = Valid, > = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin AI*> 2001:7a8:820::/44 :: 100 0 i bgpgw-001:/var/log# bgpctl sho rib neigh nerim-ipv4-bgp-peer out flags: * = Valid, > = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin AI*> 213.215.28.0/23 0.0.0.0 100 0 i bgpgw-002:~# bgpctl sho rib neigh nerim-ipv6-bgp-peer out flags: * = Valid, > = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin I*> 2001:7a8:820::/44 2001:7a8:820::1 100 0 i bgpgw-002:~# bgpctl sho rib neigh nerim-ipv4-bgp-peer out flags: * = Valid, > = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin AI*> 213.215.28.0/23 0.0.0.0 100 0 i Thanks Hi, After reverting to stable BGPD/BGPCTL, I don't have this problem anymore. It seems this issue has recently been introduced. Claudio, do you have a clue about it ? Thanks
Inconsistency between IPv6 and IPv4 announces between eBGP peers hooked through an iBGP session (OpenBGPd)
Hi, Background: Two OpenBSD routers hooked each to two ISPs. Announced networks: 2001:7a8:820::/44 213.215.28.0/23 Relevant config snippets on bgpgw-001: http://pastebin.com/m77017bcd Relevant config snippets on bgpgw-002: http://pastebin.com/d74d05557 Strangeness: On peer bgpgw-001: v4 and v6 networks are announced. On bgpgw-002 v6 networks are received from bgpgw-001 but not announced. bgpgw-001:/var/log# bgpctl sho rib neigh nerim-ipv6-bgp-peer out flags: * = Valid, > = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin AI*> 2001:7a8:820::/44 :: 100 0 i bgpgw-001:/var/log# bgpctl sho rib neigh nerim-ipv4-bgp-peer out flags: * = Valid, > = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin AI*> 213.215.28.0/23 0.0.0.0100 0 i bgpgw-002:~# bgpctl sho rib neigh nerim-ipv6-bgp-peer out flags: * = Valid, > = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin I*> 2001:7a8:820::/44 2001:7a8:820::1100 0 i bgpgw-002:~# bgpctl sho rib neigh nerim-ipv4-bgp-peer out flags: * = Valid, > = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin AI*> 213.215.28.0/23 0.0.0.0100 0 i Thanks
Re: Inconsistency between IPv6 and IPv4 announces between eBGP peers hooked through an iBGP session (OpenBGPd)
On 05/01/2010 16:39, Laurent CARON wrote: Strangeness: On peer bgpgw-001: v4 and v6 networks are announced. On bgpgw-002 v6 networks are received from bgpgw-001 but not announced. bgpgw-001:/var/log# bgpctl sho rib neigh nerim-ipv6-bgp-peer out flags: * = Valid, > = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin AI*> 2001:7a8:820::/44 :: 100 0 i bgpgw-001:/var/log# bgpctl sho rib neigh nerim-ipv4-bgp-peer out flags: * = Valid, > = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin AI*> 213.215.28.0/23 0.0.0.0 100 0 i bgpgw-002:~# bgpctl sho rib neigh nerim-ipv6-bgp-peer out flags: * = Valid, > = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin I*> 2001:7a8:820::/44 2001:7a8:820::1 100 0 i bgpgw-002:~# bgpctl sho rib neigh nerim-ipv4-bgp-peer out flags: * = Valid, > = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin AI*> 213.215.28.0/23 0.0.0.0 100 0 i I forgot to mention that this problem doesn't occur when the iBGP session is down between bgpgw-001 and bgpgw-002.
iBGP and eBGP and AS Filter
Hi Misc@,
Right now i'm playin' with bgpd filter setup. I've successfully create an
ebgp between another obsd4.3-current and ibgp between a fbsd/zebra.
I understand on most ibgp implementation (ciscoz/quagga), prefixes from
ebgp peer are more preferred than ibgp. But that isn't happening here.
Say,
|--quagga/linux-|
| as65020 |
| |
| |ebgp---|4.3current|-ebgp|
| | || as65024 | |
fbsd/zebra ibgp--- 4.3-current carp1 ibgp carp0 |
as65021| as65021 || | |
|ebgp---|4.3current|-ebgp|
as65024
fbsd/zebra as65021 have the same peer/prefix feeder(as65020) as
as65024/4.3-current. But 4.3current/as65021 prefer prefixes from
fbsd/zebra as the paths are sorter, I think..
So I create a filter:
deny from {IP_address_fbsd/zebra} AS 65020
But it still receive valid prefixes from fbsd/zebra. I appriciate if
someone could help me/hints me on howto prefer prefixes from
as65024(ebgp-peers) than ibgp peers without changing the setting on
fbsd/zebra.
Thanks,
--
insandotpraja(at)gmaildotcom
Re: Cannot Inject routes learned from iBGP session to FIB
On Mon, 21 Jan 2008 21:50:42 +0700, Stuart Henderson <[EMAIL PROTECTED]> wrote: On 2008/01/21 21:36, Insan Praja SW wrote: Currently I'm setting up ibgp session between quagga and openbgpd, I got it up, but it seem no route injected to the fib, when I traced to an address learned from quagga, it still choose default route and using "bgpctl fib couple" and "bgpctl -n reload" is not changing anything. If upgrading to -current will solved this, then it's do-able. I appreciated any input to this matter. How are your nexthops? (bgpctl sh nex) Hi misc@, after reading carefully the man page(s), I got it work. Thanks all, it all working when I removed "route-collector yes" Thanks for all the hints, Insan, PS: I promise to read the man pages carefully :D -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: Cannot Inject routes learned from iBGP session to FIB
On Mon, 21 Jan 2008 21:50:42 +0700, Stuart Henderson <[EMAIL PROTECTED]>
wrote:
On 2008/01/21 21:36, Insan Praja SW wrote:
Currently I'm setting up ibgp session between quagga and openbgpd, I got
it up, but it seem no route injected to the fib, when I traced to an
address learned from quagga, it still choose default route and using
"bgpctl fib couple" and "bgpctl -n reload" is not changing anything. If
upgrading to -current will solved this, then it's do-able.
I appreciated any input to this matter.
How are your nexthops? (bgpctl sh nex)
One thing Stuart,
When I do "bgpctl -n show rib" none of the learned routes gets selected, I
wonder is it because iBGP combination with default or something on the
bgpd.conf?
Here is my conf.
AS 65021
router-id 202.149.93.226
listen on 202.149.93.2
fib-update yes
route-collector yes
neighbor 202.149.93.1 {
remote-as 65021
descr upstream
multihop2
local-address 202.149.93.225
holdtime180
holdtime min3
announceself
}
deny from any prefix 0.0.0.0/32
# filter bogus networks
deny from any prefix 10.0.0.0/8 prefixlen >= 8
deny from any prefix 172.16.0.0/12 prefixlen >= 12
deny from any prefix 192.168.0.0/16 prefixlen >= 16
deny from any prefix 169.254.0.0/16 prefixlen >= 16
deny from any prefix 192.0.2.0/24 prefixlen >= 24
deny from any prefix 224.0.0.0/4 prefixlen >= 4
deny from any prefix 240.0.0.0/4 prefixlen >= 4
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: Cannot Inject routes learned from iBGP session to FIB
On Mon, 21 Jan 2008 21:50:42 +0700, Stuart Henderson <[EMAIL PROTECTED]> wrote: On 2008/01/21 21:36, Insan Praja SW wrote: Currently I'm setting up ibgp session between quagga and openbgpd, I got it up, but it seem no route injected to the fib, when I traced to an address learned from quagga, it still choose default route and using "bgpctl fib couple" and "bgpctl -n reload" is not changing anything. If upgrading to -current will solved this, then it's do-able. I appreciated any input to this matter. How are your nexthops? (bgpctl sh nex) Like this, GreenOfficeBorder# bgpctl -n show next Nexthop State 202.149.93.9 valid vlan2 UP, Ethernet, active, 100 MBit/s 202.149.93.5 valid vlan2 UP, Ethernet, active, 100 MBit/s 202.149.93.4 valid vlan2 UP, Ethernet, active, 100 MBit/s 202.149.93.3 valid vlan2 UP, Ethernet, active, 100 MBit/s 202.149.93.1 valid vlan2 UP, Ethernet, active, 100 MBit/s 202.149.94.255 valid 202.149.94.233 valid 202.149.94.232 valid 202.149.94.229 valid 202.149.94.169 valid Thanks, Insan -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: Cannot Inject routes learned from iBGP session to FIB
On 2008/01/21 21:36, Insan Praja SW wrote: > Currently I'm setting up ibgp session between quagga and openbgpd, I got > it up, but it seem no route injected to the fib, when I traced to an > address learned from quagga, it still choose default route and using > "bgpctl fib couple" and "bgpctl -n reload" is not changing anything. If > upgrading to -current will solved this, then it's do-able. > I appreciated any input to this matter. How are your nexthops? (bgpctl sh nex)
Cannot Inject routes learned from iBGP session to FIB
Dear Misc@, Currently I'm setting up ibgp session between quagga and openbgpd, I got it up, but it seem no route injected to the fib, when I traced to an address learned from quagga, it still choose default route and using "bgpctl fib couple" and "bgpctl -n reload" is not changing anything. If upgrading to -current will solved this, then it's do-able. I appreciated any input to this matter. Thanks, Insan OpenBSD 4.2-stable (GREENLINKS.MP) #2: Thu Nov 29 02:01:15 WIT 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/ GREENLINKS.MP real mem = 1063776256 (1014MB) avail mem = 1021526016 (974MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.34 @ 0x3f6ee000 (78 entries) bios0: vendor FUJITSU SIEMENS // Phoenix Technologies Ltd. version "5.00 R1.10.2151.A1 " date 05/08/2006 bios0: FUJITSU SIEMENS D2151-A1 acpi0 at mainbus0: rev 2 acpi0: tables DSDT FACP ASF! SSDT MCFG HPET APIC BOOT acpitimer at acpi0 not configured acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Pentium(R) D CPU 2.66GHz, 2660.50 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,S SE3,MWAIT,DS-CPL,TM2,CNXT-ID,CX16,xTPR,NXE,LONG cpu0: 1MB 64b/line 8-way L2 cache cpu0: apic clock running at 133MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Pentium(R) D CPU 2.66GHz, 2660.07 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,S SE3,MWAIT,DS-CPL,TM2,CNXT-ID,CX16,xTPR,NXE,LONG cpu1: 1MB 64b/line 8-way L2 cache ioapic0 at mainbus0 apid 2 pa 0xfec0, version 20, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 0 (PEXA) acpiprt2 at acpi0: bus 3 (PEXB) acpiprt3 at acpi0: bus 5 (PEXC) acpiprt4 at acpi0: bus 7 (PEXD) acpiprt5 at acpi0: bus 9 (PEXE) acpiprt6 at acpi0: bus 11 (PCIH) acpicpu at acpi0 not configured acpicpu at acpi0 not configured acpicpu at acpi0 not configured acpicpu at acpi0 not configured acpibtn at acpi0 not configured pci0 at mainbus0 bus 0: configuration mode 1 pchb0 at pci0 dev 0 function 0 "Intel 82945GP" rev 0x02 vga1 at pci0 dev 2 function 0 "Intel 82945G Video" rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x01: apic 2 int 18 (irq 9) azalia0: host: High Definition Audio rev. 1.0 azalia0: codec: Realtek ALC260 (rev. 4.0), HDA version 1.0 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01 pci1 at ppb0 bus 3 ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x01 pci2 at ppb1 bus 5 bge0 at pci2 dev 0 function 0 "Broadcom BCM5751" rev 0x01, BCM5750 A1 (0x4001): apic 2 int 17 (irq 11), address 00:30:05:c9:79 :df brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0 ppb2 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x01 pci3 at ppb2 bus 7 ppb3 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x01 pci4 at ppb3 bus 9 uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 2 int 23 (irq 11) uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 2 int 22 (irq 10) uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 2 int 21 (irq 5) uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: apic 2 int 20 (irq 9) ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 2 int 23 (irq 11) ehci0: timed out waiting for BIOS usb0 at ehci0: USB revision 2.0 uhub0 at usb0: Intel EHCI root hub, rev 2.00/1.00, addr 1 ppb4 at pci0 dev 30 function 0 "Intel 82801BA AGP" rev 0xe1 pci5 at ppb4 bus 11 em0 at pci5 dev 5 function 0 "Intel PRO/1000MT (82540EM)" rev 0x02: apic 2 int 22 (irq 10), address 00:07:e9:0f:44:37 rl0 at pci5 dev 7 function 0 "D-Link Systems 530TX+" rev 0x10: apic 2 int 21 (irq 5), address 00:11:95:63:48:63 rlphy0 at rl0 phy 0: RTL internal PHY pcib0 at pci0 dev 31 function 0 "Intel 82801GB LPC" rev 0x01 pciide0 at pci0 dev 31 function 2 "Intel 82801GB SATA" rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to com patibility wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 152627MB, 312581808 sectors wd1 at pciide0 channel 0 drive 1: wd1: 16-sector PIO, LBA48, 152627MB, 312581808 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 5 atapiscsi0 at pciide0 channel 1 drive 1 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: SCSI0 5/cdrom removable cd0(pciide0:1:1): using PIO mode 4, Ultra-DMA mode 2 ichiic0 at pci0 dev 31 function 3 "Intel 82801GB SMBus" rev 0x01: apic 2 int 19 (irq 9) iic0 at ichiic0 us
Re: ibgp
On Mon, Dec 03, 2007 at 01:00:37PM -0800, Tom Bombadil wrote: > Greetings... > > We are trying to use a couple routers with carp and uplinks with 2 > different providers. One router as master and another one slave. The > slave getting all the routes from the master using IBGP. > > The problem is that when I bring to interface of the master down to test > if the failover works, the slave deletes all the routes it got from the > master. > > Is there any way of retaining those IBGP routes for sometime after the > tcp connection is severed, or until the slave server (now master) can > connect to the external peers and the get routes from them? > > Or... if anybody has any other hint for a more resilient setup, I'd be > glad to hear. > Currently it is not possible to keep routing infos around after a session died. If a session dies bgpd must remove all the routing records from that session or bad things happen. If people are interested to sponsor some work to allow seamless carp/bgp failover I know a way to abuse the "Graceful Restart Mechanism for BGP" of RFC4724 to allow that. -- :wq Claudio
Re: ibgp
Tom Bombadil ??: Greetings... We are trying to use a couple routers with carp and uplinks with 2 different providers. One router as master and another one slave. The slave getting all the routes from the master using IBGP. The problem is that when I bring to interface of the master down to test if the failover works, the slave deletes all the routes it got from the master. Is there any way of retaining those IBGP routes for sometime after the tcp connection is severed, or until the slave server (now master) can connect to the external peers and the get routes from them? Or... if anybody has any other hint for a more resilient setup, I'd be glad to hear. Thanks a bunch, g. Several days ago I wrote something on the topic, but not sure if it made it to the list: Carl Roberso wrote: NetOne - Doichin Dokov wrote: The BGP problem is solved by doing this: Thank you very much Doichin for pointing this out: all of you was so helpful! Best wishes!rt You're more than welcome! In fact, we use also a bit more complicated BGP setup. Don't know if it would be in any help for you, but i'll describe it here just for the thread to be complete in case anyone starts digging :) The configuration I described in my previous post (3 IPs per upstream provider, 2 dedicated, 1 CARP-shared) works flawlessly, BUT traffic goes only through one of the routers at a time. As we were not just routing, but also doing a lot of shaping, we wanted to loadbalance things and make both of the systems do some job when they are both up. So, the scheme grew from 3 to 4 IPs per upstream provider - 2 dedicated IPs for each firewall, and 2 CARP-shared IPs. Firewall #1 was default master for shared IP one, Firewall #2 was default master for shared IP two. Let's say the IPs are: Firewall #1 172.16.0.1 - static, not in CARP, used for BGP communication with upstream 172.16.0.3 - CARP shared, default master 172.16.0.4 - CARP shared, default slave Firewall #2 172.16.0.2 - static, not in CARP, used for BGP communication with upstream 172.16.0.3 - CARP shared, default slave 172.16.0.4 - CARP shared, default master Then, we told our provider to set nexthop to 172.16.0.3 for networks we sent to them with a community COMM1, and having nexthop set to 172.16.0.4 for networks we sent to them with a community COMM2. Then, in our BGP setup (equal on both firewalls, despite the IP address / router ID), all we had to do is mark half of the networks, which we wanted to go through Firewall #1 by default, with community COMM1, and the others to go to Firewall #2 by default, with community COMM2. Of course, you have to have similiar setup (though probably withouth BGP) on the internal side of the firewalls for things to work properly, again 2 CARP ifs and traffic originating from the networks routed to Firewall #1 and Firewall #2 sent to the very same machine, otherwise you run into state problems, shaping problems (if you do that on the machines, we do), and maybe something else i could not come up with now :) By the way, a nice new IP loadbalance option was recently added to CARP, which might obsolete the setup I describe, but I've not played with that yet. Whatever you choose to do, you could always come back for help in case you need it. Regards, Doichin
ibgp
Greetings... We are trying to use a couple routers with carp and uplinks with 2 different providers. One router as master and another one slave. The slave getting all the routes from the master using IBGP. The problem is that when I bring to interface of the master down to test if the failover works, the slave deletes all the routes it got from the master. Is there any way of retaining those IBGP routes for sometime after the tcp connection is severed, or until the slave server (now master) can connect to the external peers and the get routes from them? Or... if anybody has any other hint for a more resilient setup, I'd be glad to hear. Thanks a bunch, g.
Re: iBGP: losing routes after eBGP flap
* Toni Mueller <[EMAIL PROTECTED]> [2007-08-06 15:30]: > Hi Ronnie, > > On Mon, 06.08.2007 at 00:14:17 +0200, Ronnie Garcia <[EMAIL PROTECTED]> wrote: > > I was observing this behiviour you are describing until yesterday, when > > i re-installed my two border routers to 4.1, then updated to 4.1-stable. > > hmmm... all affected machines on my side are 4.1-stable as of May 24th. > > > My two borders have now the full tables from each other (iBGP), plus the > > full route from the peer it's attached to (eBGP). > > > > [EMAIL PROTECTED]:~# bgpctl sh sum > > > > > > Neighbor ASMsgRcvdMsgSentOutQ Up/Down > > State/PrefixRcvd > > TRANSIT-11 99584 1212 0 20:09:29 222366 > > IBGP 7 91488 96015 0 20:09:29 223170 > > This I saw before the route flap. But perhaps I'll tour the CVS logs to > find out whether something was changed. > > > This is not a problem for me, but i had to let you know > > Yes, thank you! please go read claudio's explanation again. the behaviour you see is 100% correct, mandated by the RFCs and no sign of a problem at all. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: iBGP: losing routes after eBGP flap
Hi Ronnie, On Mon, 06.08.2007 at 00:14:17 +0200, Ronnie Garcia <[EMAIL PROTECTED]> wrote: > I was observing this behiviour you are describing until yesterday, when > i re-installed my two border routers to 4.1, then updated to 4.1-stable. hmmm... all affected machines on my side are 4.1-stable as of May 24th. > My two borders have now the full tables from each other (iBGP), plus the > full route from the peer it's attached to (eBGP). > > [EMAIL PROTECTED]:~# bgpctl sh sum > > > Neighbor ASMsgRcvdMsgSentOutQ Up/Down > State/PrefixRcvd > TRANSIT-11 99584 1212 0 20:09:29 222366 > IBGP 7 91488 96015 0 20:09:29 223170 This I saw before the route flap. But perhaps I'll tour the CVS logs to find out whether something was changed. > This is not a problem for me, but i had to let you know Yes, thank you! Best, --Toni++
Re: iBGP: losing routes after eBGP flap
Claudio Jeker a icrit : On Fri, Aug 03, 2007 at 07:56:02PM +0200, Toni Mueller wrote: Hi, I've got a setup on two i386 family PCs with 4.1-stable which includes the following: Internet 1 - p1 - r1 -- r2 - p2 - Internet 2 r1 and r2 have an iBGP session running, and the Internet connections go to different ISPs, running eBGP on each (r1-p1, r2-p2). I receive full routes from both ISPs mentioned, and have "announce all" in my iBGP configuration (this is the default, too, but anyway...). Today, I had to take one line down for testing, thus ending the corresponding eBGP session (r1-p1). When the line came back up, it was collecting starting to collect routes from p1 again, as one would expect, but at the same time dropping routes from r2, leaving some 300 routes from the iBGP peer (r2) left. On r2, everything looks normal, it receives a full table from both r1 and p2. So, on r1, I tried to "bgpctl nei r2 refresh", but to no avail. What gives? This is more or less expected. iBGP session only transmit eBGP pathes that are valid and best for the router. So on r2 you have all the iBGP routes from r1 and r2 has no reason to send something back to r1 because his routes are not better than the ones from r1. I was observing this behiviour you are describing until yesterday, when i re-installed my two border routers to 4.1, then updated to 4.1-stable. My two borders have now the full tables from each other (iBGP), plus the full route from the peer it's attached to (eBGP). [EMAIL PROTECTED]:~# bgpctl sh sum Neighbor ASMsgRcvdMsgSentOutQ Up/Down State/PrefixRcvd TRANSIT-11 99584 1212 0 20:09:29 222366 IBGP 7 91488 96015 0 20:09:29 223170 [EMAIL PROTECTED]:~# bgpctl sh sum Neighbor ASMsgRcvdMsgSentOutQ Up/Down State/PrefixRcvd TRANSIT-24 289859 4204 0 2d22h02m 223141 IBGP 7 192558 301618 0 20:17:45 222315 They both have two route to every network : *>3.0.0.0/8 149.6.80.149 100 94101 4 701 703 80 i I 3.0.0.0/8 85.31.195.9100 0 1 3356 701 703 80 i *>4.0.0.0/8 149.6.80.149 100 94001 3356 i I 4.0.0.0/8 85.31.195.9100 0 1 3356 i This is not a problem for me, but i had to let you know Best, -- Ronnie Garcia
Re: iBGP: losing routes after eBGP flap
Hi Claudio, On Fri, 03.08.2007 at 20:57:43 +0200, Claudio Jeker <[EMAIL PROTECTED]> wrote: > This is more or less expected. iBGP session only transmit eBGP pathes that > are valid and best for the router. So on r2 you have all the iBGP routes > from r1 and r2 has no reason to send something back to r1 because his > routes are not better than the ones from r1. thanks for the explanation, but I'm still confused because r1 held a full table from r2 before the flap (and for days), and was only starting to drop them after the session to p1 went up again. Shouldn't it then have only a few routes from r2 in the beginning? I thought that the oder in which sessions go up (or down) would (should) not matter... Best, --Toni++
Re: iBGP: losing routes after eBGP flap
On Fri, Aug 03, 2007 at 07:56:02PM +0200, Toni Mueller wrote: > Hi, > > I've got a setup on two i386 family PCs with 4.1-stable which includes > the following: > > Internet 1 - p1 - r1 -- r2 - p2 - Internet 2 > > r1 and r2 have an iBGP session running, and the Internet connections go > to different ISPs, running eBGP on each (r1-p1, r2-p2). I receive full > routes from both ISPs mentioned, and have "announce all" in my iBGP > configuration (this is the default, too, but anyway...). Today, I had > to take one line down for testing, thus ending the corresponding eBGP > session (r1-p1). When the line came back up, it was collecting starting > to collect routes from p1 again, as one would expect, but at the same > time dropping routes from r2, leaving some 300 routes from the iBGP > peer (r2) left. On r2, everything looks normal, it receives a full > table from both r1 and p2. So, on r1, I tried to "bgpctl nei r2 > refresh", but to no avail. > > What gives? > This is more or less expected. iBGP session only transmit eBGP pathes that are valid and best for the router. So on r2 you have all the iBGP routes from r1 and r2 has no reason to send something back to r1 because his routes are not better than the ones from r1. -- :wq Claudio
iBGP: losing routes after eBGP flap
Hi, I've got a setup on two i386 family PCs with 4.1-stable which includes the following: Internet 1 - p1 - r1 -- r2 - p2 - Internet 2 r1 and r2 have an iBGP session running, and the Internet connections go to different ISPs, running eBGP on each (r1-p1, r2-p2). I receive full routes from both ISPs mentioned, and have "announce all" in my iBGP configuration (this is the default, too, but anyway...). Today, I had to take one line down for testing, thus ending the corresponding eBGP session (r1-p1). When the line came back up, it was collecting starting to collect routes from p1 again, as one would expect, but at the same time dropping routes from r2, leaving some 300 routes from the iBGP peer (r2) left. On r2, everything looks normal, it receives a full table from both r1 and p2. So, on r1, I tried to "bgpctl nei r2 refresh", but to no avail. What gives? Best, --Toni++
Re: IBGP Problems
On 2007/03/28 17:52, rezidue wrote: > When the hosts connect to each other a full prefix table is sent but then > almost immediately it's neighbor starts withdrawing prefixes. On one host I > jump from 210k prefixes in the initial connection to only 59k after all of > the withdrawals. On the other host I go from 210k to 197k which isn't as > bad but I'm still unsure of why it does this. It's normal. Where I-BGP is concerned, when one router A sees a better route to a prefix from an internal peer B, it will withdraw that prefix because it knows all the other I-BGP routers must know about it (due to the requirement for full-mesh or RR). If that better route from B goes away, A will advertise the prefix again. `better' is defined by, in order: localpref, shortest AS path, origin, MEDs (for multiple routes through the same AS), then on OpenBGP there are some extensions: E-BGP is preferred over I-BGP, weight, optionally route age - then tiebreakers to make sure there's a definite choice e.g. router ID. (Some routers also consider distance to the nexthop by looking at igp metrics, this is done after evaluating MEDs). > ...just use carp for my gateway. take care with this if you're running PF on the routers, pfsync isn't fast enough to keep up if you have asymmetric routing, you may need to use stateless rulesets. (If you're not running PF and just using carp to provide a protected gateway address, this comment doesn't apply).
Re: IBGP Problems
* rezidue <[EMAIL PROTECTED]> [2007-03-29 01:10]:
> I guess I should start from the beginning. When I originally started this
> project my goal was to have two machines running carp between them and have
> the master connect to two different ISP's sending full routes. This was
> working fine and failover didn't cause any issues. At least I thought
> everything was fine until I rebooted the machine. For a reason I could not
> figure out, I would end up having a kernel panic if I didn't kill bgpd at
> startup. What was happening would be the machine would boot, become master
> of the carp interfaces, bgpd would connect to ebgp peers and fill the rib
> and then process and add to fib. After this occured the machine would look
> to itself and totally ignore the fib.
carp plays dirty games with routes, very very badly. can you try this?
Index: ip_carp.c
===
RCS file: /cvs/src/sys/netinet/ip_carp.c,v
retrieving revision 1.135
diff -u -p -r1.135 ip_carp.c
--- ip_carp.c 27 Mar 2007 21:58:16 - 1.135
+++ ip_carp.c 28 Mar 2007 23:18:51 -
@@ -368,15 +368,18 @@ carp_setroute(struct carp_softc *sc, int
struct ifaddr *ifa;
int s;
+ /* XXX this mess needs fixing */
+
s = splsoftnet();
TAILQ_FOREACH(ifa, &sc->sc_if.if_addrlist, ifa_list) {
switch (ifa->ifa_addr->sa_family) {
case AF_INET: {
- int count = 0;
+ int count = 0, error;
struct sockaddr sa;
struct rtentry *rt;
struct radix_node_head *rnh;
struct radix_node *rn;
+ struct rt_addrinfo info;
int hr_otherif, nr_ourif;
/*
@@ -395,9 +398,15 @@ carp_setroute(struct carp_softc *sc, int
}
/* Remove the existing host route, if any */
- rtrequest(RTM_DELETE, ifa->ifa_addr,
- ifa->ifa_addr, ifa->ifa_netmask,
- RTF_HOST, NULL, 0);
+ bzero(&info, sizeof(info));
+ info.rti_info[RTAX_DST] = ifa->ifa_addr;
+ info.rti_info[RTAX_GATEWAY] = ifa->ifa_addr;
+ info.rti_info[RTAX_NETMASK] = ifa->ifa_netmask;
+ info.rti_flags = RTF_HOST;
+ error = rtrequest1(RTM_DELETE, &info, NULL, 0);
+ rt_missmsg(RTM_DELETE, &info, info.rti_flags, NULL,
+ error, 0);
+
/* Check for our address on another interface */
/* XXX cries for proper API */
@@ -420,26 +429,39 @@ carp_setroute(struct carp_softc *sc, int
if (hr_otherif) {
ifa->ifa_rtrequest = NULL;
ifa->ifa_flags &= ~RTF_CLONING;
-
- rtrequest(RTM_ADD, ifa->ifa_addr,
- ifa->ifa_addr, ifa->ifa_netmask,
- RTF_UP | RTF_HOST, NULL, 0);
+ bzero(&info, sizeof(info));
+ info.rti_info[RTAX_DST] = ifa->ifa_addr;
+ info.rti_info[RTAX_GATEWAY] =
ifa->ifa_addr;
+ info.rti_info[RTAX_NETMASK] =
ifa->ifa_netmask;
+ info.rti_flags = RTF_UP | RTF_HOST;
+ error = rtrequest1(RTM_ADD, &info,
NULL, 0);
+ rt_missmsg(RTM_ADD, &info,
info.rti_flags, NULL,
+ error, 0);
}
if (!hr_otherif || nr_ourif || !rt) {
if (nr_ourif && !(rt->rt_flags &
- RTF_CLONING))
- rtrequest(RTM_DELETE, &sa,
- ifa->ifa_addr,
- ifa->ifa_netmask, 0, NULL,
- 0);
+ RTF_CLONING)) {
+ bzero(&info, sizeof(info));
+ info.rti_info[RTAX_DST] = &sa;
+ info.rti_info[RTAX_GATEWAY] =
ifa->ifa_addr;
+ info.rti_info[RTAX_NETMASK] =
ifa->ifa_netmask;
+ error = rtrequest1(RTM_DELETE,
&info, NULL, 0);
+ rt_missmsg(RT
IBGP Problems
I guess I should start from the beginning. When I originally started this
project my goal was to have two machines running carp between them and have
the master connect to two different ISP's sending full routes. This was
working fine and failover didn't cause any issues. At least I thought
everything was fine until I rebooted the machine. For a reason I could not
figure out, I would end up having a kernel panic if I didn't kill bgpd at
startup. What was happening would be the machine would boot, become master
of the carp interfaces, bgpd would connect to ebgp peers and fill the rib
and then process and add to fib. After this occured the machine would look
to itself and totally ignore the fib. While this goes on the host is not
having a problem receiving updates from it's peers right up until the kernel
panics. I even built 4.1 just to test and had the same problem. I didn't
have enough time to keep investigating so I plan on getting dumps to post
and hopefully aid with tracking down this problem, if it truly is one.
With that out of the way I can explain the problem I'm having now. Since I
was unable to get the previous solution working I decided to split the
peering between the two servers, not have bgpd rely on carp and just use
carp for my gateway. With this in place I started workign on ibgp between
the boxes to make sure that no matter where my default route went, the host
would send me through the best provider be it directly attached or off of
the other host. Right off the bat I started noticing a problem that I
thought was either a configuration error or a misunderstanding of IBGP.
When the hosts connect to each other a full prefix table is sent but then
almost immediately it's neighbor starts withdrawing prefixes. On one host I
jump from 210k prefixes in the initial connection to only 59k after all of
the withdrawals. On the other host I go from 210k to 197k which isn't as
bad but I'm still unsure of why it does this. I started to think that if
IBGP advertises a prefix that the other host is trying to advertise as well,
it just withdraws it from the neighbor since it already is announcing it but
the numbers just don't add up. I came to this conclusion because if I have
one of the hosts announce none, the IBGP neighbor doesn't start withdrawing
after it sends the entire prefix table. Hopefully someone has some ideas.
I also tried to convert ibgp to route-reflectors but I don't think removing
'announce all' and adding 'route-reflector' did anything because I saw the
same behavior.
Below is my config:
Host1
AS 111
router-id 172.16.1.1
listen on 172.16.1.1
listen on 172.16.2.1
network 192.168.10.0/24
network 192.168.11.0/24
neighbor 172.16.1.2 {
remote-as 6517
descr yipes-1
local-address 172.16.1.1
holdtime180
announceself
depend on trunk0
}
neighbor 172.16.1.3 {
remote-as 6517
descr yipes-2
local-address 172.16.1.1
holdtime180
announceself
depend on trunk0
}
neighbor 172.16.2.2 {
remote-as 111
descr dyno1
local-address 172.16.2.1
holdtime180
announceall
depend on trunk0
set nexthop self
}
host2
AS 111
router-id 172.16.3.1
listen on 172.16.3.1
listen on 172.16.2.2
network 192.168.10.0/24
network 192.168.11.0/24
neighbor 172.16.3.2 {
remote-as 174
descr cogent-1
local-address 172.16.3.1
holdtime180
announceself
depend on trunk0
}
neighbor 172.16.2.1 {
remote-as 111
descr dyno2
local-address 172.16.2.2
holdtime180
announceall
depend on trunk0
set nexthop self
}
Anyone have any ideas? Thanks for taking the time to read this.
Re: Nexthop changing in iBGP session using openbgpd against a Cisco
Claudio Jeker wrote: On Thu, Apr 27, 2006 at 04:24:57PM +0100, Dunc wrote: Hi all, I'm trying to configure an OpenBSD box as a BGP route reflector. I have an iBGP peer configured to one of our core routers which has an eBGP session to one of our providers. I have configured that neighbor with the "route-reflector" option in bgpd.conf. If I log updates, and watch the log as the session comes up, I see a lot of updates come in, with the next-hop attribute set to the IP of our provider, which is what I would expect as the next-hop should not be changed in iBGP. If I then show fib or show rib with bgpctl, the next-hop for all these routes is actually the IP of our core router, rather than that of our provider. I have configured a static route on the OpenBSD box to our provider's IP, so the problem isn't that it is an unreachable network. I think I must be missing something, because AFAIK, this isn't the correct behaviour for iBGP. Show rib and show fib shows the true nexthop and not the exit nexthop. The true nexthop is the one that is one hop from your router whereas the exit nexthop is the nexthop sent to you by the BGP update. Ok, I configured another router to have an iBGP peer, and set both neighbors to be route-reflector clients, and can see that it is indeed passing routes on with the exit nexthop set. This behaviour of putting the true next hop into the routing table seems weird to me though, surely it should be the job of whatever IGP one uses, or even just by using static routes, to decide how to get to the exit nexthop, rather than the true nexthop be entered into the routing tables? In any case, is there any way I can see the actual routes received from a peer? ( I've noticed that I can do this by logging updates, but is there a bgpctl command equivalent to "show ip bgp neighbors received-routes" ? ) Many thanks for replying to my original question, Regards, Dunc
Re: Nexthop changing in iBGP session using openbgpd against a Cisco
On Thu, Apr 27, 2006 at 04:24:57PM +0100, Dunc wrote: > Hi all, > > I'm trying to configure an OpenBSD box as a BGP route reflector. > > I have an iBGP peer configured to one of our core routers which has an eBGP > session to one of our providers. I have configured that neighbor with the > "route-reflector" option in bgpd.conf. If I log updates, and watch the log > as the session comes up, I see a lot of updates come in, with the next-hop > attribute set to the IP of our provider, which is what I would expect as > the next-hop should not be changed in iBGP. > > If I then show fib or show rib with bgpctl, the next-hop for all these > routes is actually the IP of our core router, rather than that of our > provider. > > I have configured a static route on the OpenBSD box to our provider's IP, > so the problem isn't that it is an unreachable network. > > I think I must be missing something, because AFAIK, this isn't the correct > behaviour for iBGP. > Show rib and show fib shows the true nexthop and not the exit nexthop. The true nexthop is the one that is one hop from your router whereas the exit nexthop is the nexthop sent to you by the BGP update. -- :wq Claudio
Nexthop changing in iBGP session using openbgpd against a Cisco
Hi all, I'm trying to configure an OpenBSD box as a BGP route reflector. I have an iBGP peer configured to one of our core routers which has an eBGP session to one of our providers. I have configured that neighbor with the "route-reflector" option in bgpd.conf. If I log updates, and watch the log as the session comes up, I see a lot of updates come in, with the next-hop attribute set to the IP of our provider, which is what I would expect as the next-hop should not be changed in iBGP. If I then show fib or show rib with bgpctl, the next-hop for all these routes is actually the IP of our core router, rather than that of our provider. I have configured a static route on the OpenBSD box to our provider's IP, so the problem isn't that it is an unreachable network. I think I must be missing something, because AFAIK, this isn't the correct behaviour for iBGP. Any help is greatly appreciated. Regards, Dunc -- Duncan Lockwood The Bunker,tel: +44 (1304) 814 800 Ash Radar Station, http://www.thebunker.net Marshborough Rd, Ash mailto:[EMAIL PROTECTED] Kent, CT13 0PL United Kingdom
bgpd, ibgp route-reflector routing loop
I'm testing in a network where every router peers only with physically
connected routers,
every peer is configured as a route-reflector client, every peering is
configured with
set next-hop self and set metric +100, all routers in the same AS.
Every router also peers with a route-server which runs quagga.
A config in a router looks like this:
cr203-STO# cat /etc/bgpd.conf
# $OpenBSD: bgpd.conf,v 1.7 2004/10/01 15:12:16 henning Exp $
# sample bgpd configuration file
# see bgpd.conf(5)
AS 65000
router-id 10.0.0.2
network connected
network static
network 10.0.0.2/32
group "ibgp" {
remote-as 65000
route-reflector
set metric +100
set nexthop self
holdtime 10
neighbor 172.16.1.5 {
local-address 172.16.1.6
}
neighbor 10.1.1.1 {
local-address 10.1.1.2
}
neighbor 10.1.1.14 {
local-address 10.1.1.13
}
}
neighbor 192.168.30.10 {
remote-as 65000
local-address 10.0.0.2
}
cr203-STO# ifconfig lo1
lo1: flags=8049 mtu 33224
groups: lo
inet 10.0.0.2 netmask 0x
cr203-STO#
With this setup I can introduce routing loops into the network by flapping
prefixes. Here flapped a prefix with an intervall of a few seconds:
cr203-STO# bgpctl network add 12.0.0.0/8
request sent.
cr203-STO# bgpctl network del 12.0.0.0/8
request sent.
cr203-STO# bgpctl network add 12.0.0.0/8
request sent.
cr203-STO# bgpctl network del 12.0.0.0/8
request sent.
cr203-STO# bgpctl network add 12.0.0.0/8
request sent.
cr203-STO# bgpctl network del 12.0.0.0/8
request sent.
cr203-STO# bgpctl network add 12.0.0.0/8
request sent.
cr203-STO# bgpctl network del 12.0.0.0/8
request sent.
cr203-STO# bgpctl network add 12.0.0.0/8
request sent.
cr203-STO# bgpctl network del 12.0.0.0/8
request sent.
cr203-STO#
After this every router in the network except cr203-STO which
originated it sees this prefix.
They all consider the 10.0.0.2 (cr203-STO) to be the originator.
A look from the route-server:
quagga-bgpd# sh ip bgp summary
BGP router identifier 192.168.30.10, local AS number 65000
1 BGP AS-PATH entries
0 BGP community entries
NeighborVAS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
10.0.0.14 650001185 897000 00:58:20 31
10.0.0.24 650001128 880000 00:56:51 30
10.0.0.34 650001142 899000 00:58:13 31
10.0.0.44 650001141 901000 00:57:58 31
10.0.0.54 650001179 901000 00:57:32 31
10.0.0.64 650001192 900000 00:57:19 31
10.0.0.74 650001182 916000 00:58:21 31
10.0.0.84 650001222 901000 00:58:09 31
172.16.0.1 4 650001256 898000 00:57:00 31
172.16.0.2 4 650001208 902000 00:57:46 31
172.16.0.3 4 6500014711107000 02:41:01 31
Total number of neighbors 11
quagga-bgpd#
quagga-bgpd# sh ip bgp 12.0.0.0
BGP routing table entry for 12.0.0.0/8
Paths: (10 available, best #6, table Default-IP-Routing-Table)
Not advertised to any peer
Local
172.16.1.2 from 172.16.0.1 (10.0.0.2)
Origin IGP, metric 500, localpref 100, valid, internal
Originator: 10.0.0.2, Cluster list: 172.16.0.1 10.0.0.1 10.0.0.3
172.16.0.2 10.0.0.4
Last update: Mon Apr 10 19:20:05 2006
Local
10.1.1.6 from 10.0.0.1 (10.0.0.2)
Origin IGP, metric 400, localpref 100, valid, internal
Originator: 10.0.0.2, Cluster list: 10.0.0.1 10.0.0.3 172.16.0.2
10.0.0.4
Last update: Mon Apr 10 19:20:05 2006
Local
10.1.1.17 from 10.0.0.5 (10.0.0.2)
Origin IGP, metric 400, localpref 100, valid, internal
Originator: 10.0.0.2, Cluster list: 10.0.0.5 10.0.0.3 172.16.0.2
10.0.0.4
Last update: Mon Apr 10 19:20:05 2006
Local
172.16.1.13 from 172.16.0.2 (10.0.0.2)
Origin IGP, metric 400, localpref 100, valid, internal
Originator: 10.0.0.2, Cluster list: 172.16.0.2 10.0.0.4 10.0.0.3
10.0.0.1
Last update: Mon Apr 10 19:20:04 2006
Local
10.1.1.21 from 10.0.0.6 (10.0.0.2)
Origin IGP, metric 500, localpref 100, valid, internal
Originator: 10.0.0.2, Cluster list: 10.0.0.6 10.0.0.5 10.0.0.3
172.16.0.2
10.0.0.4
Last update: Mon Apr 10 19:20:05 2006
Local
172.16.1.10 from 10.0.0.3 (10.0.0.2)
Origin IGP, metric 300, localpref 100, valid, internal, best
Originator: 10.0.0.2, Cluster list: 10.0.0.3 172.16.0.2 10.0.0.4
Last update: Mon Apr 10 19:20:05 2006
Local
10.1.1.9 from 10.0.0.4 (10.0.0.2)
Origin IGP, metric 300, localpref 100, valid, internal
Originator: 10.0.0.2, Cluster list: 10.0.0.4 10.0.0.3 10.0.0.1
Last update: Mon Apr 10 19:20:04 2006
Local
Re: bgpd.conf md5sig, iBGP and redistributing routes to/from ospf
Jesper Louis Andersen wrote: per engelbrecht wrote: Q: setting up iBGP I've used our own AS as 'remote-as' but can't find a 'no synchronization' option for this connection. Do I need it at all. Been poking around in /usr/src/usr.sbin/bgpd without solving it, but it's needed in zebra and Cisco IOS hence the question. A: ? Using your own AS as an remote ASn will, per definition, make your BGP session into an internal BGP session. In the Ciscoeee world, no synchronization means to begin announcing your networks before higher priority network protocols are up and stabilized. Without you will wait for OSPF/IS-IS to stabilize first (For OSPF, there is a certain state in its state machine it has to reach for all broadcast clouds etc). Hi jlouis It was more of a what_can_option_[a-z] from Zebra be put on par with in OpenBGPD and/or do I need these options at all (different implementation) but thank you for your explanation. However, in modern BGP setups, you screw OSPF/IS-IS royally and ignore the stabilization. This is viable, since you ``nail down'' your networks as CIDR aggregates (to minimize the number of BGP prefixes you announce) and give a heck about internal reachability. Screwing IGP's from whitin EGP's keep things apart, buy they are (conceptually, at least in my head) still manipulating the same routing table. And yes of course I only announce our own net. Returning 120.000+ prefixes (at that time) to a eBGP peer with inferior Cisco hw works like magic - the phone rings within minutes .. and they're not returning a call :) Oh, and while we are at Zebra: Its crap, kill it as soon as possible or install quagga. Case in point: .. install quagga ? Nooope. mirah% pwd /usr/ports/net/zebra/w-zebra-0.93ap3/zebra-0.93a/ospfd mirah% grep OSPF_LSA_HEADER ospf_lsa.c ospf_output_forward (s, OSPF_LSA_HEADER_SIZE); assert (l1->data->length > OSPF_LSA_HEADER_SIZE); if (memcmp (p1 + OSPF_LSA_HEADER_SIZE, p2 + OSPF_LSA_HEADER_SIZE, ntohs( l1->data->length ) - OSPF_LSA_HEADER_SIZE) != 0) mirah% Lets see... On the last line, we have identified that l1->data->length is in network byte order. But in the assert 2 lines up, we do _not_ have a ntohs() call. This took a medium sized ISP down in Denmark because Zebra suddenly died due to the fact, that certain packets, if certain size, will be caught by the assertion and ospfd gets to say hello to the kernel thread known as reaper man. Q: running ospf with all peers + carp intfaces in area 0.0.0.0 and internal intfaces in area 0.0.0.1 (and from ospfd.conf) [...] fib-update yes redistribute connected [...] This is about redistributing routes - will the above let BGP and OSPF "play along" in the same way a 'redistribute ospf' in Zebra/Cisco IOS A: ? It will push directly connected routes into OSPF. That is, if the machine has a network to which it has a direct connection in the routing table, then the rest of your OSPF speakers will learn that this network is reachable by going through this router. Which is also what I want. redistribute ospf in Ciscoee in the BGP section of the router configuration tells the IOS to take all OSPF learned routes and push them into BGP. This can be extremely dangerous to do, depending on the configuration. Yes that could easily have disaster written all over it. Q: default gateway is added to the routing table after all interfaces are configured. BGP is adding information into the routing table and so does OSPF (updates). That's 3 times "redistributing" of routes between different protocols and with 3 different administrative distances but still in/from the same table. Since directly connected (0) or static (1) connections are superior to e.g. eBGP (20) and OSPF (110) then should or shouldn't /etc/mygate be removed from a BGP router before putting it into production. Will it/can it mock the routing decision despite 'weight' in bgpd.conf due to the lower distance. A: ? A more specific route will always match. Normally, you do not need to redistribute routes between the protocols at all, considered all of your routers are running BGP as well as OSPF. BGP will then handle prefixes for external networks and OSPF will handle prefixes for internal ones in the case both BGP and OSPF have the route then BGP wins -- but note the note about specific matches ;) Thank you for joining in jlouis. /per [EMAIL PROTECTED]
Re: bgpd.conf md5sig, iBGP and redistributing routes to/from ospf
per engelbrecht wrote: Q: setting up iBGP I've used our own AS as 'remote-as' but can't find a 'no synchronization' option for this connection. Do I need it at all. Been poking around in /usr/src/usr.sbin/bgpd without solving it, but it's needed in zebra and Cisco IOS hence the question. A: ? Using your own AS as an remote ASn will, per definition, make your BGP session into an internal BGP session. In the Ciscoeee world, no synchronization means to begin announcing your networks before higher priority network protocols are up and stabilized. Without you will wait for OSPF/IS-IS to stabilize first (For OSPF, there is a certain state in its state machine it has to reach for all broadcast clouds etc). However, in modern BGP setups, you screw OSPF/IS-IS royally and ignore the stabilization. This is viable, since you ``nail down'' your networks as CIDR aggregates (to minimize the number of BGP prefixes you announce) and give a heck about internal reachability. Oh, and while we are at Zebra: Its crap, kill it as soon as possible or install quagga. Case in point: mirah% pwd /usr/ports/net/zebra/w-zebra-0.93ap3/zebra-0.93a/ospfd mirah% grep OSPF_LSA_HEADER ospf_lsa.c ospf_output_forward (s, OSPF_LSA_HEADER_SIZE); assert (l1->data->length > OSPF_LSA_HEADER_SIZE); if (memcmp (p1 + OSPF_LSA_HEADER_SIZE, p2 + OSPF_LSA_HEADER_SIZE, ntohs( l1->data->length ) - OSPF_LSA_HEADER_SIZE) != 0) mirah% Lets see... On the last line, we have identified that l1->data->length is in network byte order. But in the assert 2 lines up, we do _not_ have a ntohs() call. This took a medium sized ISP down in Denmark because Zebra suddenly died due to the fact, that certain packets, if certain size, will be caught by the assertion and ospfd gets to say hello to the kernel thread known as reaper man. Q: running ospf with all peers + carp intfaces in area 0.0.0.0 and internal intfaces in area 0.0.0.1 (and from ospfd.conf) [...] fib-update yes redistribute connected [...] This is about redistributing routes - will the above let BGP and OSPF "play along" in the same way a 'redistribute ospf' in Zebra/Cisco IOS A: ? It will push directly connected routes into OSPF. That is, if the machine has a network to which it has a direct connection in the routing table, then the rest of your OSPF speakers will learn that this network is reachable by going through this router. redistribute ospf in Ciscoee in the BGP section of the router configuration tells the IOS to take all OSPF learned routes and push them into BGP. This can be extremely dangerous to do, depending on the configuration. Q: default gateway is added to the routing table after all interfaces are configured. BGP is adding information into the routing table and so does OSPF (updates). That's 3 times "redistributing" of routes between different protocols and with 3 different administrative distances but still in/from the same table. Since directly connected (0) or static (1) connections are superior to e.g. eBGP (20) and OSPF (110) then should or shouldn't /etc/mygate be removed from a BGP router before putting it into production. Will it/can it mock the routing decision despite 'weight' in bgpd.conf due to the lower distance. A: ? A more specific route will always match. Normally, you do not need to redistribute routes between the protocols at all, considered all of your routers are running BGP as well as OSPF. BGP will then handle prefixes for external networks and OSPF will handle prefixes for internal ones in the case both BGP and OSPF have the route then BGP wins -- but note the note about specific matches ;)
Re: bgpd.conf md5sig, iBGP and redistributing routes to/from ospf [forgot to sign it]
* per engelbrecht <[EMAIL PROTECTED]> [2005-11-02 00:52]: > I've made a setup with two identical bgp routers. On each router there's > 3 peers (BGP and eBGP), one failover (carp/iBGP/ospf) interconnecting > these routers and finally pipes backwards to the internal nets. Part of > bgpd.conf further down. > I'm replacing a single router (no ospf) fbsd/zebra setup. should just work. > Q: setting up iBGP I've used our own AS as 'remote-as' but can't find a > 'no synchronization' option for this connection. Do I need it at all. > Been poking around in /usr/src/usr.sbin/bgpd without solving it, but > it's needed in zebra and Cisco IOS hence the question. not needed. retarded idea in the first place... I mean, you don't need "ip classless" on OpenBSD either to tell it we're not in the 80s any more :) > Q: adding md5sig password, how can I activate these stepwise without > having to take bgpd down/up and affecting all connections - ospfctl does > not seem have it as an option. Would like to add md5sig one carrier at a > time on a "live" system. # bgpctl reload next time the session(s) in question traverses IDLE the settings become active. you can force that using # bgpctl neighbor foo clear -- BS Web Services, http://www.bsws.de/ OpenBSD-based Webhosting, Mail Services, Managed Servers, ... Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: bgpd.conf md5sig, iBGP and redistributing routes to/from ospf [forgot to sign it]
* Claudio Jeker <[EMAIL PROTECTED]> [2005-11-02 12:04]: > If both bgpd and ospfd try to add the same route to the kernel routing table > it will result in undefined behaviour. (mostly the first one wins). that is not true. there is no undefined behaviour. first one wins. > Again this is on the todo list (even before the redistribute thing). yes. -- BS Web Services, http://www.bsws.de/ OpenBSD-based Webhosting, Mail Services, Managed Servers, ... Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: bgpd.conf md5sig, iBGP and redistributing routes to/from ospf [forgot to sign it]
Claudio Jeker wrote:
On Wed, Nov 02, 2005 at 12:34:29AM +0100, per engelbrecht wrote:
Hi all
[20051019 snap i386]
I've made a setup with two identical bgp routers. On each router there's
3 peers (BGP and eBGP), one failover (carp/iBGP/ospf) interconnecting
these routers and finally pipes backwards to the internal nets. Part of
bgpd.conf further down.
I'm replacing a single router (no ospf) fbsd/zebra setup.
That should be no problem.
Q: setting up iBGP I've used our own AS as 'remote-as' but can't find a
'no synchronization' option for this connection. Do I need it at all.
Been poking around in /usr/src/usr.sbin/bgpd without solving it, but
it's needed in zebra and Cisco IOS hence the question.
A: ?
There is no 'no synchronization' option. We never enforce the
synchronisation of iBGP with an IGP. That's retarded. Like pumping 170'000
routes into OSPF and thinking all will be fine. Sure you may get bitten if
you have routers that do not run iBGP in between the two iBGP routers but
that's more a design problem and is solvable.
Hi Claudio
Most documentation on BGP or OSPF is geared towards IOS systems or pro
ISO systems like Zebra, with whatever options and syntax that comes with
the territory. Finding alternatives for options like e.g. 'no
synchronization' and'no auto-summary' when changing from (in my case)
Zebra to OpenBGPD, is not covered too well in a otherwise fine
documentation, but thank you for clarifying.
A small paragraph in the bgpd.conf man page for people comming to
OpenBGPD dealing with this would be nice.
Q: adding md5sig password, how can I activate these stepwise without
having to take bgpd down/up and affecting all connections - ospfctl does
not seem have it as an option. Would like to add md5sig one carrier at a
time on a "live" system.
A: ?
Just add the 'tcp md5sig password "fluffy"' to a neighbor and
bgpctl reload. Afterwards a bgpctl neighbor clear will clear
the session and activate tcp md5. You can do that one peer at a time.
Check.
(thank you)
Q: running ospf with all peers + carp intfaces in area 0.0.0.0 and
internal intfaces in area 0.0.0.1 (and from ospfd.conf)
[...]
fib-update yes
redistribute connected
[...]
This is about redistributing routes - will the above let BGP and OSPF
"play along" in the same way a 'redistribute ospf' in Zebra/Cisco IOS
A: ?
"redistribute ospf" is currently not implemented. bgpd is currently not
able to redistribute routes added by ospfd. This is on the todo list.
Perfect.
Q: default gateway is added to the routing table after all interfaces
are configured. BGP is adding information into the routing table and so
does OSPF (updates). That's 3 times "redistributing" of routes between
different protocols and with 3 different administrative distances but
still in/from the same table. Since directly connected (0) or static (1)
connections are superior to e.g. eBGP (20) and OSPF (110) then should or
shouldn't /etc/mygate be removed from a BGP router before putting it
into production. Will it/can it mock the routing decision despite
'weight' in bgpd.conf due to the lower distance.
A: ?
Neither ospfd nor bgpd know about administrative distances. Currently it
is only save to use the two together if there are no equal routes. If
both bgpd and ospfd try to add the same route to the kernel routing table
it will result in undefined behaviour. (mostly the first one wins).
Again this is on the todo list (even before the redistribute thing).
I guess reading BGP from Cisco literature would match learning TCP/IP
with books from Microsoft ...
The BGP implementation in Cisco IOS uses a administrative distance,
hence the question.
I you mean equal routes from a 'weight' point of view, then I have a
problem. So fare all my peers have the same weight.
Part of bgpd.conf:
[...]
neighbor $peer0 {
remote-as ABCD
descr"ebgp sucks"
set nexthop aaa.aaa.aaa.aab
multihop 10
local-address aaa.aaa.aaa.aaa
announce self
announce IPv6 none
enforce neighbor-as yes
set weight 100
#tcp md5sig password HotPotatoes
}
...
...
neighbor $carp {
remote-as
descr"internal"
local-address 172.16.0.1
depend on em5
I think this is not doing what you think. depend on is only useful on
carp(4) interfaces. It does not make sense for physical interfaces.
I have carp1 on em5. I'll change em5 > carp1 right away. Thank you.
announce all
That's actually the default :)
I know. In every conf file I write what I want it to do (even defaults)
and remove anything else. Makes it easy to parse for !me without having
to know system 'default'.
announce IPv6 none
enforce neighbor-as no
That one as well.
Dit
Re: bgpd.conf md5sig, iBGP and redistributing routes to/from ospf [forgot to sign it]
On Wed, Nov 02, 2005 at 12:34:29AM +0100, per engelbrecht wrote:
> Hi all
>
> [20051019 snap i386]
>
> I've made a setup with two identical bgp routers. On each router there's
> 3 peers (BGP and eBGP), one failover (carp/iBGP/ospf) interconnecting
> these routers and finally pipes backwards to the internal nets. Part of
> bgpd.conf further down.
> I'm replacing a single router (no ospf) fbsd/zebra setup.
>
That should be no problem.
>
> Q: setting up iBGP I've used our own AS as 'remote-as' but can't find a
> 'no synchronization' option for this connection. Do I need it at all.
> Been poking around in /usr/src/usr.sbin/bgpd without solving it, but
> it's needed in zebra and Cisco IOS hence the question.
> A: ?
>
There is no 'no synchronization' option. We never enforce the
synchronisation of iBGP with an IGP. That's retarded. Like pumping 170'000
routes into OSPF and thinking all will be fine. Sure you may get bitten if
you have routers that do not run iBGP in between the two iBGP routers but
that's more a design problem and is solvable.
>
> Q: adding md5sig password, how can I activate these stepwise without
> having to take bgpd down/up and affecting all connections - ospfctl does
> not seem have it as an option. Would like to add md5sig one carrier at a
> time on a "live" system.
> A: ?
>
Just add the 'tcp md5sig password "fluffy"' to a neighbor and
bgpctl reload. Afterwards a bgpctl neighbor clear will clear
the session and activate tcp md5. You can do that one peer at a time.
>
> Q: running ospf with all peers + carp intfaces in area 0.0.0.0 and
> internal intfaces in area 0.0.0.1 (and from ospfd.conf)
> [...]
> fib-update yes
> redistribute connected
> [...]
> This is about redistributing routes - will the above let BGP and OSPF
> "play along" in the same way a 'redistribute ospf' in Zebra/Cisco IOS
> A: ?
>
"redistribute ospf" is currently not implemented. bgpd is currently not
able to redistribute routes added by ospfd. This is on the todo list.
>
> Q: default gateway is added to the routing table after all interfaces
> are configured. BGP is adding information into the routing table and so
> does OSPF (updates). That's 3 times "redistributing" of routes between
> different protocols and with 3 different administrative distances but
> still in/from the same table. Since directly connected (0) or static (1)
> connections are superior to e.g. eBGP (20) and OSPF (110) then should or
> shouldn't /etc/mygate be removed from a BGP router before putting it
> into production. Will it/can it mock the routing decision despite
> 'weight' in bgpd.conf due to the lower distance.
> A: ?
>
Neither ospfd nor bgpd know about administrative distances. Currently it
is only save to use the two together if there are no equal routes. If
both bgpd and ospfd try to add the same route to the kernel routing table
it will result in undefined behaviour. (mostly the first one wins).
Again this is on the todo list (even before the redistribute thing).
>
> Part of bgpd.conf:
>
> [...]
> neighbor $peer0 {
> remote-as ABCD
> descr"ebgp sucks"
> set nexthop aaa.aaa.aaa.aab
> multihop 10
> local-address aaa.aaa.aaa.aaa
> announce self
> announce IPv6 none
> enforce neighbor-as yes
> set weight 100
> #tcp md5sig password HotPotatoes
> }
> ...
> ...
> neighbor $carp {
> remote-as
> descr"internal"
> local-address 172.16.0.1
> depend on em5
I think this is not doing what you think. depend on is only useful on
carp(4) interfaces. It does not make sense for physical interfaces.
> announce all
That's actually the default :)
> announce IPv6 none
> enforce neighbor-as no
That one as well.
> set weight 200
> #tcp md5sig password NoPotatoes
> }
>
> I have a:
> deny from any prefix 172.16.0.0/12 prefixlen >= 12
> but the carp interface uses a /8 i.e. should be safe :)
>
Iick. That will cause troubles with everything in the 172/8 range.
You can add a rule like:
allow from $carp prefix 172.16.0.0/24
afterwards. That would be much nicer.
--
:wq Claudio
bgpd.conf md5sig, iBGP and redistributing routes to/from ospf [forgot to sign it]
Hi all
[20051019 snap i386]
I've made a setup with two identical bgp routers. On each router there's
3 peers (BGP and eBGP), one failover (carp/iBGP/ospf) interconnecting
these routers and finally pipes backwards to the internal nets. Part of
bgpd.conf further down.
I'm replacing a single router (no ospf) fbsd/zebra setup.
Q: setting up iBGP I've used our own AS as 'remote-as' but can't find a
'no synchronization' option for this connection. Do I need it at all.
Been poking around in /usr/src/usr.sbin/bgpd without solving it, but
it's needed in zebra and Cisco IOS hence the question.
A: ?
Q: adding md5sig password, how can I activate these stepwise without
having to take bgpd down/up and affecting all connections - ospfctl does
not seem have it as an option. Would like to add md5sig one carrier at a
time on a "live" system.
A: ?
Q: running ospf with all peers + carp intfaces in area 0.0.0.0 and
internal intfaces in area 0.0.0.1 (and from ospfd.conf)
[...]
fib-update yes
redistribute connected
[...]
This is about redistributing routes - will the above let BGP and OSPF
"play along" in the same way a 'redistribute ospf' in Zebra/Cisco IOS
A: ?
Q: default gateway is added to the routing table after all interfaces
are configured. BGP is adding information into the routing table and so
does OSPF (updates). That's 3 times "redistributing" of routes between
different protocols and with 3 different administrative distances but
still in/from the same table. Since directly connected (0) or static (1)
connections are superior to e.g. eBGP (20) and OSPF (110) then should or
shouldn't /etc/mygate be removed from a BGP router before putting it
into production. Will it/can it mock the routing decision despite
'weight' in bgpd.conf due to the lower distance.
A: ?
Part of bgpd.conf:
[...]
neighbor $peer0 {
remote-as ABCD
descr"ebgp sucks"
set nexthop aaa.aaa.aaa.aab
multihop 10
local-address aaa.aaa.aaa.aaa
announce self
announce IPv6 none
enforce neighbor-as yes
set weight 100
#tcp md5sig password HotPotatoes
}
...
...
neighbor $carp {
remote-as
descr"internal"
local-address 172.16.0.1
depend on em5
announce all
announce IPv6 none
enforce neighbor-as no
set weight 200
#tcp md5sig password NoPotatoes
}
I have a:
deny from any prefix 172.16.0.0/12 prefixlen >= 12
but the carp interface uses a /8 i.e. should be safe :)
/per
[EMAIL PROTECTED]
bgpd.conf md5sig, iBGP and redistributing routes to/from ospf
Hi all
[20051019 snap i386]
I've made a setup with two identical bgp routers. On each router there's
3 peers (BGP and eBGP), one failover (carp/iBGP/ospf) interconnecting
these routers and finally pipes backwards to the internal nets. Part of
bgpd.conf further down.
I'm replacing a single router (no ospf) fbsd/zebra setup.
Q: setting up iBGP I've used our own AS as 'remote-as' but can't find a
'no synchronization' option for this connection. Do I need it at all.
Been poking around in /usr/src/usr.sbin/bgpd without solving it, but
it's needed in zebra and Cisco IOS hence the question.
A: ?
Q: adding md5sig password, how can I activate these stepwise without
having to take bgpd down/up and affecting all connections - ospfctl does
not seem have it as an option. Would like to add md5sig one carrier at a
time on a "live" system.
A: ?
Q: running ospf with all peers + carp intfaces in area 0.0.0.0 and
internal intfaces in area 0.0.0.1 (and from ospfd.conf)
[...]
fib-update yes
redistribute connected
[...]
This is about redistributing routes - will the above let BGP and OSPF
"play along" in the same way a 'redistribute ospf' in Zebra/Cisco IOS
A: ?
Q: default gateway is added to the routing table after all interfaces
are configured. BGP is adding information into the routing table and so
does OSPF (updates). That's 3 times "redistributing" of routes between
different protocols and with 3 different administrative distances but
still in/from the same table. Since directly connected (0) or static (1)
connections are superior to e.g. eBGP (20) and OSPF (110) then should or
shouldn't /etc/mygate be removed from a BGP router before putting it
into production. Will it/can it mock the routing decision despite
'weight' in bgpd.conf due to the lower distance.
A: ?
Part of bgpd.conf:
[...]
neighbor $peer0 {
remote-as ABCD
descr "ebgp sucks"
set nexthop aaa.aaa.aaa.aab
multihop 10
local-address aaa.aaa.aaa.aaa
announce self
announce IPv6 none
enforce neighbor-as yes
set weight 100
#tcp md5sig password HotPotatoes
}
...
...
neighbor $carp {
remote-as
descr "internal"
local-address 172.16.0.1
depend on em5
announce all
announce IPv6 none
enforce neighbor-as no
set weight 200
#tcp md5sig password NoPotatoes
}
I have a:
deny from any prefix 172.16.0.0/12 prefixlen >= 12
but the carp interface uses a /8 i.e. should be safe :)
