On 29/07/2019 15:59, Hansen, Christoffer wrote:
> https://datatracker.ietf.org/doc/draft-sa-grow-maxprefix/?include_text=1
>
> Do the current bird 1.6.4 and 2.0.4 releases *not* support any of these
> mentioned scenarios?
Forget I asked. I overlooked section 9. Implement
bird-users@,
https://datatracker.ietf.org/doc/draft-sa-grow-maxprefix/?include_text=1
Do the current bird 1.6.4 and 2.0.4 releases *not* support any of these
mentioned scenarios?
Christoffer
"""
2.1. Type A: Pre-Policy Inbound Maximum Prefix Limits
The Adj-RIBs-In stores routing
Ondrej: Possible bird is checking for an NEXT_HOP field to be present in
the mentioned BGP Update Message?
Hansen, Christoffer wrote on 11/07/2019 15:34:
Derrick,
Possible a missing next-hop attribute can be the case?
From [0]:
attribute EBGP IBGP
Derrick,
Possible a missing next-hop attribute can be the case?
From [0]:
attribute EBGPIBGP
ORIGIN mandatory mandatory
AS_PATHmandatory mandatory
NEXT_HOP mandatory
On 14/06/2019 14:06, Robert Sander wrote:
> This does not work neither:
Could you post a copy of the the full relevant sections of the BIRD
configuration?
Is easier to give you pointers that way. Of e.g. an alternative way to
implement the logic you are looking for.
Christoffer
On 14/06/2019 12:58, Robert Sander wrote:
> according to the documentation for BIRD 1.6 it should be possible to use
> "shell patterns" with the ~ operator on strings:
If you look here: [0] & note the description in the docs you referred to
before. It should be clear enough the operators is
amphineko,
On 02/05/2019 09:00, amphineko wrote:
> I'm wondering if I can invoke other filters inside a filter, so the
> is_asxxx can also used as an filter. I can't find an example to
> achieve this.
I can recommend taking at least one look at the following links for
reference purposes. If they
On 26/01/2019 21:14, Ondrej Zajicek wrote:
> Agree, i already thought about making them separate chapters/pages,
> as protocol documentation is about 2/3 of whole documentation. OTOH,
> most other protocols have just short documentation, so perhaps only
> 'big' protocols should get separate
