I'm trying to replace a quagga daemon doing an extremely simple bgp peering with an upstream with bird 1.2.2. I have it working, but I'm not sure it's quite set up correctly. My config is router id 91.203.57.1; protocol device { } protocol direct { } protocol kernel { import all; export all; } protocol bgp { local as 44934; neighbor 84.45.39.149 as 25577; import all; export where net = 91.203.56.0/23; } I'll need additional internal peerings later, but I just want to get the simplest possible config correct first! When I do birdc show protocols all, it includes: bgp1 BGP master up 10:56 Established Preference: 100 Input filter: ACCEPT Output filter: <NULL> Routes: 311380 imported, 1 exported, 311380 preferred Route change stats: received rejected filtered ignored accepted Import updates: 334136 0 0 7828 326308 Import withdraws: 1756 0 --- 0 1756 Export updates: 326310 326308 1 --- 1 Export withdraws: 1756 --- --- --- 0 BGP state: Established Session: external Neighbor AS: 25577 Neighbor ID: 84.45.90.246 Neighbor address: 84.45.39.149 Nexthop address: 84.45.39.149 Source address: 84.45.39.150 Neighbor caps: refresh Hold timer: 153/180 Keepalive timer: 33/60 I think this means I've got the export filter wrong somehow and am trying to re-export the routes I get in from my upstream. (Perhaps they're going bgp -> kernel -> bgp?) Best wishes, Chris.
On Wed, Apr 14, 2010 at 11:33:31AM +0100, Chris Webb wrote:
When I do birdc show protocols all, it includes:
bgp1 BGP master up 10:56 Established Preference: 100 Input filter: ACCEPT Output filter: <NULL> Routes: 311380 imported, 1 exported, 311380 preferred Route change stats: received rejected filtered ignored accepted Import updates: 334136 0 0 7828 326308 Import withdraws: 1756 0 --- 0 1756 Export updates: 326310 326308 1 --- 1 Export withdraws: 1756 --- --- --- 0 BGP state: Established Session: external Neighbor AS: 25577 Neighbor ID: 84.45.90.246 Neighbor address: 84.45.39.149 Nexthop address: 84.45.39.149 Source address: 84.45.39.150 Neighbor caps: refresh Hold timer: 153/180 Keepalive timer: 33/60
I think this means I've got the export filter wrong somehow and am trying to re-export the routes I get in from my upstream. (Perhaps they're going bgp -> kernel -> bgp?)
You mean because of this:
Export updates: 326310 326308 1 --- 1
? No, it is OK. BIRD just internally tried to export every route in the table to every protocol and the BGP protocol internally rejects all routes that were generated by the protocol itself (this is the counter named 'rejected'). One route is filtered by the filter and one route is finally exported to the BGP neighbor (assume it is from direct protocol). One thing that is a bit strange on your setting is that you export a prefix from a local interface (from a direct protocol) to a BGP neighbor. Usually, there are configured static routes (from a static protocol) containing aggregated prefixes which are exported to a BGP neighbor. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Ondrej Zajicek <santiago@crfreenet.org> writes:
No, it is OK. BIRD just internally tried to export every route in the table to every protocol and the BGP protocol internally rejects all routes that were generated by the protocol itself (this is the counter named 'rejected'). One route is filtered by the filter and one route is finally exported to the BGP neighbor (assume it is from direct protocol).
Ah, great, okay. You're right that I was worried that 'rejected' was telling me that they were being exported over BGP and rejected by the remote peer. I presume that even if I had lots of other routes coming in from another BGP peer, they wouldn't have been exported anyway because I export filtered out everything except 91.203.56.0/23 with the export where net=91.203.56.0/23 line in the bgp protocol block?
One thing that is a bit strange on your setting is that you export a prefix from a local interface (from a direct protocol) to a BGP neighbor. Usually, there are configured static routes (from a static protocol) containing aggregated prefixes which are exported to a BGP neighbor.
Yes, would replacing direct { } with static { route 0.0.0.0/0 via 84.45.39.149; route 91.203.56.0/23 via "eth0"; } be more idiomatic here? Cheers, Chris.
On 14.4.2010 15:30, Chris Webb wrote:
Ondrej Zajicek <santiago@crfreenet.org> writes:
No, it is OK. BIRD just internally tried to export every route in the table to every protocol and the BGP protocol internally rejects all routes that were generated by the protocol itself (this is the counter named 'rejected'). One route is filtered by the filter and one route is finally exported to the BGP neighbor (assume it is from direct protocol).
Ah, great, okay. You're right that I was worried that 'rejected' was telling me that they were being exported over BGP and rejected by the remote peer.
I presume that even if I had lots of other routes coming in from another BGP peer, they wouldn't have been exported anyway because I export filtered out everything except 91.203.56.0/23 with the export where net=91.203.56.0/23 line in the bgp protocol block?
Yes, that is true.
One thing that is a bit strange on your setting is that you export a prefix from a local interface (from a direct protocol) to a BGP neighbor. Usually, there are configured static routes (from a static protocol) containing aggregated prefixes which are exported to a BGP neighbor.
Yes, would replacing direct { } with
static { route 0.0.0.0/0 via 84.45.39.149; route 91.203.56.0/23 via "eth0"; }
be more idiomatic here?
Sure that would work. It really depends what you are trying to achieve. I often use a configuration with: static { route XXXX/YY drop; } So this route is exported to BGP, but it is not used for forwarding and I expect to get more specific routes from IGP. But if you want to use the whole range 91.203.56.0/23 on this host than your configuration is OK. Feela
Cheers,
Chris.
On Wed, Apr 14, 2010 at 07:09:17PM +0200, Ondrej Filip wrote:
Yes, would replacing direct { } with
static { route 0.0.0.0/0 via 84.45.39.149; route 91.203.56.0/23 via "eth0"; }
be more idiomatic here?
The second route has one side-effect - it is exported to the kernel as a device route. If you really have prefix 91.203.56.0/23 on eth0, it is definitely better to use direct route, if 91.203.56.0/23 is an aggregate of your internal routes, i would suggest to use drop route (route XXXX/YY drop), as suggested by Ondrej Filip. The drop route is also exported to the kernel routing table, which has a slight benefit that every destination (from XXXX/YY) that is not covered by more specific (IGP) route is dropped and not send through the default route. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Thanks for both of your detailed advice. I do just have the single /23 on eth0 to advertise in this test setup, but it's useful to know the idiomatic configuration for an aggregate of internal routes too as that's what I'll want when I come to run bird on other routers. Best wishes, Chris.
participants (3)
-
Chris Webb -
Ondrej Filip -
Ondrej Zajicek