> Using bird 2.0.2. Guess it does not include patch you mentioned
Yes, it is not released yet.
> The issue is that bird/bgp tries to resolve nexthops for all vrfs only in
default.
I think it depends on your configuration. Do you have separate tables for
protocols in different vrfs?
On Mon,
May be you have direct routes from different vrf somehow in this table?
On Mon, Nov 5, 2018 at 9:54 AM, Semion Lisyansky wrote:
> Yes, I have separate tables for each vrf
>
> --
> Semion Lisyansky
>
>
> On Mon, Nov 5, 2018 at 10:48 AM Alexander Zubkov wrote:
>
>> > Using bird 2.0.2. Guess it
Thanks, Alexander
Using bird 2.0.2. Guess it does not include patch you mentioned
Have another question:
Configured peers in vrf with different addresses but still in overlapping
subnets.
BGP session are established and some prefixes advertised.
The issue is that bird/bgp tries to resolve
Yes, I have separate tables for each vrf
--
Semion Lisyansky
On Mon, Nov 5, 2018 at 10:48 AM Alexander Zubkov wrote:
> > Using bird 2.0.2. Guess it does not include patch you mentioned
>
> Yes, it is not released yet.
>
> > The issue is that bird/bgp tries to resolve nexthops for all vrfs
On Mon, Nov 05, 2018 at 10:42:27AM +0200, Semion Lisyansky wrote:
> Thanks, Alexander
>
> Using bird 2.0.2. Guess it does not include patch you mentioned
>
> Have another question:
> Configured peers in vrf with different addresses but still in overlapping
> subnets.
> BGP session are
On Wed, Oct 31, 2018 at 06:21:15AM +, bbk bbk wrote:
> hi,
>
> Can the bird add two BFD sessions with same destination ip and different
> local ip?
>
> My testing is only one session can be added as if.
Hi
AFAIK it cannot, sessions are identified just by remote ip.
--
Elen sila lumenn'
On Sun, Nov 04, 2018 at 07:16:55PM +0100, Alexander Zubkov wrote:
> Hi,
>
> As far as I know, it is not possible to transform BGP routes (with gateway)
> into device routes in the bird itself. But may be somebody else knows the
> trick.
Hi
Yes, BIRD filters allow to set IP address of nexthop,
On Sat, Nov 03, 2018 at 08:31:09PM -0600, Grant Taylor wrote:
> Is it possible to (re)export unreachable routes via BGP?
>
> All attempts thus far have resulted in the BGP neighbor session with the 3rd
> test machine not (re)exporting any unreachable routes. I can (re)export
> other routes
On Mon, Nov 05, 2018 at 08:47:36AM +0700, Clemens Schrimpe wrote:
> Hello -
>
> just wanted to report a little (easily reproducable) problem: I’m
> experimenting with BIRD 2.0.2 on a lab-router (Ubiquiti Edgerouter, MIPS
> platform) and RPKI.
>
> In my attempts to examine ROA tables more
On Mon, Nov 05, 2018 at 03:05:17PM +0200, Semion Lisyansky wrote:
> Hi,
>
> Please find below requested info. Some omitted because of size
> You may clearly see the issue on 1st show
Thanks for info.
You are using single-hop EBGP, therefore next hop is not resolved
through a routing table, but
Hi,
Please find below requested info. Some omitted because of size
You may clearly see the issue on 1st show
bird> show route table table_vrf01
Table table_vrf01:
192.34.1.2/31unicast [direct_vrf01 15:43:55.271] * (240)
dev swp17.201
191.34.1.2/31unicast [direct_vrf01
On Sat, Nov 03, 2018 at 09:51:33PM +0100, Michael Schwartzkopff wrote:
> hi,
>
>
> I want to export a route learned from BGP to the kernel. but I want to
> modify the route while exporting because I want to use a VTI instead of
> the next hop route.
>
>
> So instead of 192.168.0.0/24 via
Am 05.11.18 um 16:24 schrieb Ondrej Zajicek:
> On Sat, Nov 03, 2018 at 09:51:33PM +0100, Michael Schwartzkopff wrote:
>> hi,
>>
>>
>> I want to export a route learned from BGP to the kernel. but I want to
>> modify the route while exporting because I want to use a VTI instead of
>> the next hop
Most chances that BGP session was initiated from BIRD
cat /etc/issue
Ubuntu 18.04 LTS \n \l
uname -r
4.19.0-041900rc7-generic
#VRF vrf01
ipv4 table table_vrf01;
protocol kernel kernel_vrf01 {
vrf "vrf01";
kernel table 101;
scan time 2;
ipv4 {
On 11/05/2018 04:55 AM, Ondrej Zajicek wrote:
Hi
Hi,
I do not see a reason why unreachable routes would not be exported,
works for me.
Okay.
Thank you for confirming that.
It is likely something completely different. Aren't both incoming and
outgoing (grant) sessions IBGP? In such case
Maria Jan Matějka writes:
> Just a side note, it would be better to consider next hop as an object
> which would be always set as a whole. It would also allow to change
> ecmp route gws. Anyway, it is still in plan with no concrete date when
> we will implement it.
There is also work underway
On Mon, Nov 05, 2018 at 04:48:10PM +0100, Alexander Zubkov wrote:
> Wow. This settings makes route via interface only? I.e. also undefines
> gateway?
Yes. Gateway and iface are interconnected, which has some minor weird
effects in filter language, like setting gw resets iface (to one
associated
Wow. This settings makes route via interface only? I.e. also undefines
gateway?
On Mon, Nov 5, 2018 at 4:25 PM, Michael Schwartzkopff wrote:
> Am 05.11.18 um 16:24 schrieb Ondrej Zajicek:
> > On Sat, Nov 03, 2018 at 09:51:33PM +0100, Michael Schwartzkopff wrote:
> >> hi,
> >>
> >>
> >> I want
Just a side note, it would be better to consider next hop as an object which
would be always set as a whole. It would also allow to change ecmp route gws.
Anyway, it is still in plan with no concrete date when we will implement it.
Maria
On November 5, 2018 5:05:28 PM GMT+01:00, Ondrej
Hey, thank you a lot for pointing this out. This is really something I would
like to see and maybe also comment on before it gets to kernel.
Maria
On November 5, 2018 5:41:16 PM GMT+01:00, "Toke Høiland-Jørgensen"
wrote:
>Maria Jan Matějka writes:
>
>> Just a side note, it would be better to
On Mon, Nov 05, 2018 at 05:28:44PM +0200, Semion Lisyansky wrote:
> protocol bgp bgp_vrf01_n2 {
> vrf "vrf01";
> local as 65034;
> bfd yes;
> graceful restart;
> neighbor 192.34.1.4 as 65001;
> ipv4 {
> table table_vrf01;
>
TL;DR: I got it working.
On 11/05/2018 09:15 AM, Grant Taylor wrote:
So I don't think my problem is that simple low hanging fruit.
Well, you got me on the proper path.
I did some more searching, found how to enable some more logging, and
discovered "rejected by protocol". Which ultimately
Thanks a lot
--
Semion Lisyansky
On Mon, Nov 5, 2018 at 5:37 PM Ondrej Zajicek
wrote:
> On Mon, Nov 05, 2018 at 05:28:44PM +0200, Semion Lisyansky wrote:
> > protocol bgp bgp_vrf01_n2 {
> > vrf "vrf01";
> > local as 65034;
> > bfd yes;
> > graceful restart;
> >
On 5 November 2018 18:23:01 CET, "Maria Jan Matějka" wrote:
>Hey, thank you a lot for pointing this out. This is really something I
>would like to see and maybe also comment on before it gets to kernel.
You're welcome! And please to weigh in on netdev. Don't think the patches have
been
On Tue, Nov 06, 2018 at 08:28:00AM +0700, Clemens Schrimpe wrote:
> > Currently ROA has to be specified as a whole, including maxlen and ASN,
> > not just its prefix. Confusingly, it uses slightly different syntax
> > to enter ROAs and to print ROAs:
> >
> > bird> show route 212.1.128.0/19 max 19
> You can use filters: show route table r4 where net.asn = 4711
That indeed works. And now I also found what I was looking for in the
documentation:
> NET_ROA4 and NET_ROA6 prefixes hold an IP prefix range together with an ASN.
> They support the same special operators as IP prefixes, and also
On November 6, 2018 7:52:09 AM GMT+01:00, Clemens Schrimpe
wrote:
>> You can use filters: show route table r4 where net.asn = 4711
>
>That indeed works. And now I also found what I was looking for in the
>documentation:
>
>> NET_ROA4 and NET_ROA6 prefixes hold an IP prefix range together with
27 matches
Mail list logo
