Re: Bird 2.0.0 and reconfiguring

2017-12-17 Thread Miłosz Oller 
There is no way to setup two channels in one protocol definition? Or how 
can I do it?



inż. Miłosz Oller


W dniu 17.12.2017 o 21:55, Ondrej Zajicek pisze:

On Sun, Dec 17, 2017 at 01:41:44PM +0100, Miłosz Oller wrote:

Hi

How I must define bgp protocol as case 1?

There can be only one source/neighbor ip.

In case 1 there is only one BGP session / TCP connection and therefore one 
source/neighbor address.


W dniu 17.12.2017 o 03:26, Ondrej Zajicek pisze:


On Sat, Dec 16, 2017 at 04:25:50PM +0100, Miłosz Oller wrote:

Hi

I fix it. Please tell me how I must define ipv6 session. There must be two
bgp protocols definitions?

Hi

That depends if yo want one BGP session with both ipv4 and ipv6 AFIs, or
two independent BGP sessions, each for one AFI (like it was done with old
BIRD).

For the first case you need just one protocol (like in your example). For
the second case (which is drop-in replacement for old BIRD) you have to
define two BGP protocols, each with appropriate channel and
neighbor/source addresses.


Case 1:


protocol bgp bgp_cloudflare_waw {
      description "Cloudflare OpenPeering";
ipv4 { import all;
   export filter ipv4_export;
};
ipv6 { import all;
      export filter ipv6_export;
};
      local as 198611;
      neighbor 212.91.0.28 as 13335;
      source address 212.91.1.42;
   #   neighbor 2001:7f8:69::83 as 13335;
#    source address 2001:7f8:69::256;
}

Case 2:


protocol bgp bgp_cloudflare_waw_4 {
      description "Cloudflare OpenPeering";
  ipv4 { import all;
  export filter ipv4_export;
  };
      local as 198611;
      neighbor 212.91.0.28 as 13335;
      source address 212.91.1.42;
}

protocol bgp bgp_cloudflare_waw_6 {
      description "Cloudflare OpenPeering";
  ipv6 { import all;
      export filter ipv6_export;
  };
      local as 198611;
  neighbor 2001:7f8:69::83 as 13335;
      source address 2001:7f8:69::256;
}










smime.p7s
Description: Kryptograficzna sygnatura S/MIME

Re: Bird 2.0.0 -- unknown filter instructions

2017-12-17 Thread Jan Maria Matejka 
Hello!

On 12/16/2017 04:10 PM, Luis Ressel wrote:
> I've been experimenting with bird 2.0.0 for a few days now. Apart from
> the memory leak (which Ondrej's patch appears to fix), the most serious
> issue I've run into is a spurious bird crash caused by the filter code.
> Twice so far, bird died when I ran 'birdc configure', with the messages
> " Unknown instruction 26912" and " Unknown instruction 0",
> respectively.
> 
> I haven't been able to reliably reproduce these crashes, though. If
> someone has an idea how to do this, or at least how to narrow down
> which part of my lengthy filter config is causing it, that'd be much
> appreciated!
This seems to be some bad memory access. Please, if you can, send me
your binary, config and coredump, off-list please as it may contain
sensitive data.

There is no code setting these instruction codes intentionally.

Thanks!
Maria

Re: Bird 2.0.0 and reconfiguring

2017-12-17 Thread Ondrej Zajicek 
On Sun, Dec 17, 2017 at 01:41:44PM +0100, Miłosz Oller wrote:
> Hi
> 
> How I must define bgp protocol as case 1?
> 
> There can be only one source/neighbor ip.

In case 1 there is only one BGP session / TCP connection and therefore one 
source/neighbor address.

> W dniu 17.12.2017 o 03:26, Ondrej Zajicek pisze:
> 
> > On Sat, Dec 16, 2017 at 04:25:50PM +0100, Miłosz Oller wrote:
> > > Hi
> > > 
> > > I fix it. Please tell me how I must define ipv6 session. There must be two
> > > bgp protocols definitions?
> > Hi
> > 
> > That depends if yo want one BGP session with both ipv4 and ipv6 AFIs, or
> > two independent BGP sessions, each for one AFI (like it was done with old
> > BIRD).
> > 
> > For the first case you need just one protocol (like in your example). For
> > the second case (which is drop-in replacement for old BIRD) you have to
> > define two BGP protocols, each with appropriate channel and
> > neighbor/source addresses.
> > 
> > 
> > Case 1:
> > 
> > > protocol bgp bgp_cloudflare_waw {
> > >      description "Cloudflare OpenPeering";
> > > ipv4 { import all;
> > >   export filter ipv4_export;
> > > };
> > > ipv6 { import all;
> > >      export filter ipv6_export;
> > > };
> > >      local as 198611;
> > >      neighbor 212.91.0.28 as 13335;
> > >      source address 212.91.1.42;
> > >   #   neighbor 2001:7f8:69::83 as 13335;
> > > #    source address 2001:7f8:69::256;
> > > }
> > 
> > Case 2:
> > 
> > > protocol bgp bgp_cloudflare_waw_4 {
> > >      description "Cloudflare OpenPeering";
> > >  ipv4 { import all;
> > >  export filter ipv4_export;
> > >  };
> > >      local as 198611;
> > >      neighbor 212.91.0.28 as 13335;
> > >      source address 212.91.1.42;
> > > }
> > > 
> > > protocol bgp bgp_cloudflare_waw_6 {
> > >      description "Cloudflare OpenPeering";
> > >  ipv6 { import all;
> > >      export filter ipv6_export;
> > >  };
> > >      local as 198611;
> > >  neighbor 2001:7f8:69::83 as 13335;
> > >      source address 2001:7f8:69::256;
> > > }
> 
> 



-- 
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: PGP signature

Bird 2.0.0 & VRF & Best Practices

2017-12-17 Thread Tim Weippert 
Hi List, 

i tried Bird 2.0.0, Kernel 4.14.6, Archlinux, VRF separated BGP Peerings.

I get an Config running, where i had an BGP Peering in Global Space and
one in a VRF. As the VRF Config seems "complex" i though maybe i do
something wrong or even more complex as really needed.

I had the following setup:

VM1 - ens10 <> ens10 - VM2 (Global Space, BGP Peering)
VM1 - VRF RED - ens11 <> ens11 - VRF RED VM2 ( VRF Peering)

The following is my working config for the Peering "inside" the VRF:

# VRF RED Tests
ipv4 table T_VRF_RED;

protocol kernel K_VRF_RED {
vrf "red";
kernel table 100;
scan time 20;

ipv4 {
table T_VRF_RED;
import all;
export all;
};
}

protocol direct C_VRF_RED {
vrf "red";
ipv4 { table T_VRF_RED; };

interface "ens11";
interface "red"; # Think this can be ommitted ...
}

protocol static S_VRF_RED {
vrf "red";
ipv4 { table T_VRF_RED; };

route 10.10.1.0/24 blackhole;
}

protocol bgp B_VRF_RED {
vrf "red";
local 172.16.10.[1|2] as 65100;
neighbor 172.16.10.[2|1] as 65100;
multihop;

# regular IPv4 unicast (1/1)
ipv4 {
table T_VRF_RED;
import all;
export where source ~ [ RTS_STATIC, RTS_BGP ];
};
}

I tried several configs (with protocol direct, without) but this seems
the only one, i get working Peerings with resolveable next hops.

Is this as intended? Per VRF Kernel, Direct, BGP (Static only in my
test) Protocol to get an working VRF aware / separated routing 
instance? 

Or is there something i misunderstand or can be simplified?

Thanks for comments.

regards, 
tim

-- 
Tim Weippert
http://weiti.org - we...@weiti.org
GPG Fingerprint - E704 7303 6FF0 8393 ADB1  398E 67F2 94AE 5995 7DD8

Re: Bird 2.0.0 and (filter) code deduplication

2017-12-17 Thread Luis Ressel 
On Sun, 17 Dec 2017 13:43:03 +0100
Clemens Schrimpe  wrote:

> > You can use ‘net.type = NET_IP4', 'net.type = NET_IP6'.  
> 
> Nice …
> 
> And you can also „just“ mix IPv6 and legacy IPv4 matches in
> prefix-lists, etc.:

Thanks to both of you! The mixed sets are a nice trick which will take
care of parts of my AFI-dependant configs, and for the rest (ROA, for
example), I'll use Ondrej's suggestion.

Cheers,
Luis Ressel

Re: Bird 2.0.0 and reconfiguring

2017-12-17 Thread Miłosz Oller 

Hi

How I must define bgp protocol as case 1?

There can be only one source/neighbor ip.


inż. Miłosz Oller

W dniu 17.12.2017 o 03:26, Ondrej Zajicek pisze:


On Sat, Dec 16, 2017 at 04:25:50PM +0100, Miłosz Oller wrote:

Hi

I fix it. Please tell me how I must define ipv6 session. There must be two
bgp protocols definitions?

Hi

That depends if yo want one BGP session with both ipv4 and ipv6 AFIs, or
two independent BGP sessions, each for one AFI (like it was done with old
BIRD).

For the first case you need just one protocol (like in your example). For
the second case (which is drop-in replacement for old BIRD) you have to
define two BGP protocols, each with appropriate channel and
neighbor/source addresses.


Case 1:


protocol bgp bgp_cloudflare_waw {
     description "Cloudflare OpenPeering";
ipv4 { import all;
  export filter ipv4_export;
};
ipv6 { import all;
     export filter ipv6_export;
};
     local as 198611;
     neighbor 212.91.0.28 as 13335;
     source address 212.91.1.42;
  #   neighbor 2001:7f8:69::83 as 13335;
#    source address 2001:7f8:69::256;
}


Case 2:


protocol bgp bgp_cloudflare_waw_4 {
     description "Cloudflare OpenPeering";
 ipv4 { import all;
 export filter ipv4_export;
 };
     local as 198611;
     neighbor 212.91.0.28 as 13335;
     source address 212.91.1.42;
}

protocol bgp bgp_cloudflare_waw_6 {
     description "Cloudflare OpenPeering";
 ipv6 { import all;
     export filter ipv6_export;
 };
     local as 198611;
     neighbor 2001:7f8:69::83 as 13335;
     source address 2001:7f8:69::256;
}





smime.p7s
Description: Kryptograficzna sygnatura S/MIME

Re: Bird 2.0.0 and (filter) code deduplication

2017-12-17 Thread Clemens Schrimpe 
> You can use ‘net.type = NET_IP4', 'net.type = NET_IP6'.

Nice …

And you can also „just“ mix IPv6 and legacy IPv4 matches in prefix-lists, etc.:

if net ~ [
2001:db8::/32+, # doc

fc00::/15+, # ULAs
fe80::/16+  # link locals

192.168.0.0/16+,# RFC1918
172.16.0.0/24+, # RFC1918
10.0.0.0/8+,# RFC1918
] then {


Works just fine with 2.0.0 …

-c