Re: very very simple bird.conf
On Mon, Sep 19, 2011 at 03:47:31PM -0300, Virgilio Pavel wrote: >Hello folks, > >I'm not have experience to work with bird.conf, but I have two questions: >1) How can I do a loopback with my neighbor? >2) How can I configure a static route? For simple examples, you can check wiki, for example: https://git.nic.cz/redmine/projects/bird/wiki/OSPF_example bird.conf provided by default is more like example of all possible options than a useful default config. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@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." signature.asc Description: Digital signature
very very simple bird.conf
Hello folks,
I'm not have experience to work with bird.conf, but I have two questions:
1) How can I do a loopback with my neighbor?
2) How can I configure a static route?
They are so basic question, but I'm not find documentation about this.
Look my bird.conf
-
# Configuração do bird
# Turn on global debugging of all protocols
#debug protocols all;
# Configure logging
log syslog { debug, trace, info, remote, warning, error, auth, fatal, bug };
log stderr all;
log "/usr/local/bird/log/bird.log" all;
# Override router ID
router id 189.53.248.214;
# Override router ID
listen bgp address 189.53.248.214 port 179;
# Define a route filter...
#filter test_filter {
# if net ~ 10.0.0.0/16 then accept;
# else reject;
#}
#filter sink { reject; }
#filter okay { accept; }
# Define another routing table
#table testable;
# The direct protocol automatically generates device routes to
# all network interfaces. Can exist in as many instances as you wish
# if you want to populate multiple routing tables with device routes.
#protocol direct {
# interface "-eth*", "*"; # Restrict network interfaces it works with
#}
# This pseudo-protocol performs synchronization between BIRD's routing
# tables and the kernel. If your kernel supports multiple routing tables
# (as Linux 2.2.x does), you can run multiple instances of the kernel
# protocol and synchronize different kernel tables with different BIRD
tables.
protocol kernel {
# learn; # Learn all alien routes from the kernel
persist;# Don't remove routes on bird shutdown
scan time 20; # Scan kernel routing table every 20 seconds
# import none;# Default is import all
export all; # Default is export none
# kernel table 5; # Kernel table to synchronize with (default:
main)
}
# This pseudo-protocol watches all interface up/down events.
protocol device {
scan time 10; # Scan interfaces every 10 seconds
}
# Static routes (again, there can be multiple instances, so that you
# can disable/enable various groups of static routes on the fly).
protocol static {
# disabled; # Disable by default
# table testable; # Connect to a non-default table
# preference 1000;# Default preference of routes
# debug { states, routes, filters, interfaces, events, packets };
# debug all;
# route 0.0.0.0/0 via 62.168.0.13;
# route 62.168.0.0/25 reject;
# route 10.0.0.0/8 reject;
# route 10.1.1.0:255.255.255.0 via 62.168.0.3;
# route 10.1.2.0:255.255.255.0 via 62.168.0.3;
# route 10.1.3.0:255.255.255.0 via 62.168.0.4;
# route 10.2.0.0/24 via "arc0";
}
protocol bgp {
import none;
export where proto = "static_bgp";
local as 262774;
neighbor 189.53.248.213 as 4230;
}
-
[]'s Virgilio Pavel
Re: Very simple bird.conf
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.
Re: Very simple bird.conf
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 /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 /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: santi...@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."
signature.asc
Description: Digital signature
Re: Very simple bird.conf
On 14.4.2010 15:30, Chris Webb wrote:
> Ondrej Zajicek 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 /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.
Re: Very simple bird.conf
Ondrej Zajicek 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.
Re: Very simple bird.conf
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: > Routes: 311380 imported, 1 exported, 311380 preferred > Route change stats: received rejected filteredignored > 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: santi...@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." signature.asc Description: Digital signature
Very simple bird.conf
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:
Routes: 311380 imported, 1 exported, 311380 preferred
Route change stats: received rejected filteredignored 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.
