Re: FRR + OSPF/BGP ECMP

[Oleksandr Kryvulia]

09.12.22 21:50, Cristian Cardoso пише:

Hi

I'm using FRR without compiling and ECMP is up and running, I haven't 
turned on any flags for this to happen.


Em sex., 9 de dez. de 2022 às 07:23, Olivier Cochard-Labbé 
 escreveu:


On Fri, Dec 9, 2022 at 10:59 AM Victor Gamov  wrote:

Hi All

Does FreeBSD support ECMP while using FRR + OSPF/BGP?


If compiled with MULTIPATH option, yes it should work.
This option isn't enabled by default, I should enable it.

Old example of a setup here:
https://bsdrp.net/documentation/examples/ecmp



It is enabled by default since eb0b1b33d5af 

Re: Which EtherTypes are recognized for 802.1AD / QinQ ?

[Oleksandr Kryvulia]

13.05.22 12:14, I.C.H пише:


Hi all,

i allready asked the question in the FreeBSD Forums, but i was told to 
better aks this question in the mailing list to be sure.


You can find my question and all the answers given in this topic here: 
https://forums.freebsd.org/threads/which-ethertypes-are-recognized-for-802-1ad-qinq.85152/


I will also quote the initial question at the end of this email.

Thanks for clarify my question.

Kind regards
I.C.H


Hi all,

802.1AD defines the EtherType / TPID as 0x88A8.
FreeBSD supports 802.1AD (QinQ tagging), see 
https://www.freebsd.org/cgi/man.cgi?ifconfig(8) 
 -> vlanproto


Before IEEE passed 802.1AD , there were proprietary standards for VLAN 
stacking, often called 802.1QinQ or similar. Sometimes, vendors used 
0x9100, 0x9200 or 0x9300 as EtherType for the "outer" tag, but some 
switches can also insert 0x8100 into another 0x8100.


Today, its still possible to buy switches with QinQ-capability with 
proprietary QinQ implementation which uses some non-802.1AD-compliant 
EtherTypes. Not all offer the ability to change the EtherType to 
0x88A8 or define it by your own, so you have to deal with it.


I am wondering, which EtherTypes are assigned internally in FreeBSD to 
be handled as QinQ ?


I googled a bit and found this, but i am not sure if it will answer my 
question: https://reviews.freebsd.org/D21846 



Thanks for helping to clarify this topic.

Kind regards




Brifely reading sources I can tell that non-802.1ad tags supported only 
by ng_vlan(4).

Re: netmask for loopback interfaces

[Oleksandr Kryvulia]

04.11.21 01:01, Mike Karels пишет:

I have a pending change to stop using class A/B/C netmasks when setting
an interface address without an explicit mask, and instead to use a default
mask (24 bits).  A question has arisen as to what the default mask should
be for loopback interfaces.  The standard 127.0.0.1 is added with an 8 bit
mask currently, but additions without a mask would default to 24 bits.
There is no warning for missing masks for loopback in the current code.
I'm not convinced that the mask has any meaning here; only a host route
to the assigned address is created.  Does anyone know of any meaning or
use of the mask on a loopback address?

Thanks,
Mike



/8 mask on loopback prevetnts using of 127.x.x.x network anywhere 
outside of the localhost. This described in RFC 5735 [1] and 1122 [2]


[1] https://datatracker.ietf.org/doc/html/rfc5735
[2] https://datatracker.ietf.org/doc/html/rfc1122

Re: net.add_addr_allfibs - alternative usecases

[Oleksandr Kryvulia]

04.10.21 10:33, Volodymyr Kostyrko пишет:
> Hello.
>
> First of all, I came here not to agitate for any change, I want to
> understand how my configuration is inefficient and how I can do that
> better.
>
> I have two outgoing interfaces, if0 and if0. Those are different
> internet providers, I even get ipv6 through second one, and that's
> nice. I want to automatically fallback to the interface that is
> working in case of outage. Also, I want some traffic only on one of
> those interfaces. So I got 3 fibs:
>
> fib 0: default route
> fib 1: default route is if0
> fib 2: default route is if1
>
> Fibs 1-2 are used for traffic that should only pass through exactly
> that interface. Traffic pinning is done with PF:
>
> pass out on $outside2 inet from ($outside2) queue(in_std2, in_priv2)
> modulate state rtable 2
>
> For example, I can test connectivity to both sides via:
>
> setfib 1 ping -qc 5 8.8.8.8
> setfib 2 ping -qc 5 8.8.8.8
>
> And in case one of them doesn't work I can switch to other one by
> changing routing on fib 0.
>
> Everything seems to work fine with net.add_addr_allfibs enabled. But
> once it was disabled I started wondering whether I'm using the right
> tools to solve my problem, or this can be done easier. Disabling
> net.add_addr_allfibs means that only assigned interface will provide
> default route for correspondent fib, and you can't manually add them
> to the other fib. Or maybe I got that part totally wrong?
>
> Thanks in advance, any bit of knowledge would be appreciated.
>

Hi
Yes, in your current scheme you need net.add_addr_allfibs enabled.
As for me fibs are useful when you need to run jails or other local
processes with different routing tables. To do PBR you can use pf's
route-to/reply-to instead.