Re: sshd on two fibs
On 21/09/2020 07:35, Eugene Grosbein wrote: 21.09.2020 14:21, Grzegorz Junka wrote: All you need is telling kernel to use right gateway based on source IP address despite of default route, this is called policy-based routing and you can achieve that with single ipfw rule: ipfw add 2000 fwd $gateway2 ip from $wan2ip to any out xmit $wan1 That is: redirect IP packets with source of second WAN interface ($wan2ip) to right gateway of that WAN ($gateway2) if they are going using (wrong) route to WAN1. That's all. Thanks Eugene. I am reluctant to add firewall rules because the second interface is configured as being in fib 1. Existance of the fib 1 does not matter for your case, at all. This is so that jails, which are also started with fib 1, can use the proper routing table. Exactly. I don't want to add complexity where it isn't necessary, unless there is no other option. Me too. And single ipfw rule is minimal possible addition, all other solutions are more complex. Is it possible to somehow configure sshd to use the proper routing table? It is possible but it won't help you because every routing table contains routes that do NOT depend on source IP address of the packet and you need such policy-based routing. Standard routing tables do not offer policy-based routing, so they are useless for you. You could read rc.conf(5) manual page to learn about _fib knob (f.e. sshd_fib="1") but it won't solve your problem. You could also add your own startup script to run second copy of sshd with its own PID file and listening IP address and FIB but that would be much more complex solution. Just tell kernel you need policy-based routing with ipfw. This just works. No need to utilize second FIB just because you already have it. OK, yeah, sounds reasonable. Thanks for explaining! GrzegorzJ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: sshd on two fibs
On 21/09/2020 06:58, Eugene Grosbein wrote: 21.09.2020 6:20, Grzegorz Junka wrote: I have two WANs and a server with two interfaces, each interface reaching different WAN. The server is configured with two routing tables, fib0 and fib1, one per the corresponding interface. I would like sshd to listen on both interfaces but on different fibs, so that returning packets are sent to the proper gateway. Can I do it with one sshd? Do I need to run two separate sshd's? Can I run two separate sshd's on the same box? sshd listens for all IPs by default. Also, sshd runs over TCP and this guarantees that it responds from same IP address which was used by initial client's request, too. You need not worry about that. Also, you already have static link between source IP address of sshd response, corresponding WAN interface and gateway IP address of that WAN interface. All you need is telling kernel to use right gateway based on source IP address despite of default route, this is called policy-based routing and you can achieve that with single ipfw rule: ipfw add 2000 fwd $gateway2 ip from $wan2ip to any out xmit $wan1 That is: redirect IP packets with source of second WAN interface ($wan2ip) to right gateway of that WAN ($gateway2) if they are going using (wrong) route to WAN1. That's all. Thanks Eugene. I am reluctant to add firewall rules because the second interface is configured as being in fib 1. This is so that jails, which are also started with fib 1, can use the proper routing table. I don't want to add complexity where it isn't necessary, unless there is no other option. Is it possible to somehow configure sshd to use the proper routing table? ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: sshd on two fibs
On 21/09/2020 00:35, Doug Hardie wrote: On 20 September 2020, at 16:20, Grzegorz Junka wrote: I have two WANs and a server with two interfaces, each interface reaching different WAN. The server is configured with two routing tables, fib0 and fib1, one per the corresponding interface. I would like sshd to listen on both interfaces but on different fibs, so that returning packets are sent to the proper gateway. Can I do it with one sshd? Do I need to run two separate sshd's? Can I run two separate sshd's on the same box? I have sshd running on two interfaces by using pf to handle the situation. /etc/rc.conf contains sshd_enable="YES" pf.conf contains ext_if = "em0" back_if = "em1" set skip on lo0 SSH = "nn" pass in all pass out all pass in log on $back_if proto tcp from any to any port $SSH pass in log on $back_if reply-to ($back_if 192.168.1.254) proto tcp from any to any port $SSH keep state where: nn is the non-standard port I use for ssh 192.168.1.254 is the router for the second interface. I don't use fibs at all for this, although I do have them setup for when I want to check out the second port connections. Thanks for your response. I don't use fibs to handle this. I have fibs configured for jails and because of that I already have the proper gateways configured there, so I thought I can reuse. The pf solution is of course good but this is not a public facing server and I don't have pf setup on it. Which is not a big problem, just wondering if pf is the right solution to handle this? ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
sshd on two fibs
I have two WANs and a server with two interfaces, each interface reaching different WAN. The server is configured with two routing tables, fib0 and fib1, one per the corresponding interface. I would like sshd to listen on both interfaces but on different fibs, so that returning packets are sent to the proper gateway. Can I do it with one sshd? Do I need to run two separate sshd's? Can I run two separate sshd's on the same box? GrzegorzJ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: net.add_addr_allfibs=1 behaviour deprecation
On 18/08/2020 19:27, Alexander V. Chernikov wrote: 18.08.2020, 09:17, "Grzegorz Junka" : On 18/08/2020 07:54, Julian Elischer wrote: No objections has been received. Next steps: * Switch net.add_addr_allfibs to 0 ( https://reviews.freebsd.org/D26076 ) * Provide an ability to use nexthops from different fibs * Remove net.add_addr_allfibs Timeline: Aug 1: summarising feedback and the usecases, decision on proceeding further Aug 20 (tentative): patches for supported usecases Sep 15 (tentative): net.add_addr_allfibs removal. [1]: [base Contents of /head/sys/net/route.c](https://svnweb.freebsd.org/base/head/sys/net/route.c?revision=17&view=markup) [2]: [base Diff of /head/sys/net/route.c](https://svnweb.freebsd.org/base/head/sys/net/route.c?r1=180839&r2=180840&;) /Alexander Agree completely, defaulting "add_addr_allfibs" to 1 broke many existing installations, which goes against the least surprise principle so many times advocated on FreeBSD lists. This is just one example: https://forums.freebsd.org/threads/strange-behavior-of-setfib-since-freebsd-12-0.73348/ Now, changing the default again might again break existing installations, which shouldn't be a reason for not doing it, but might be a reason to better communicate it this time around. I plan to communicate it the following way: 1) this thread 2) GONE_IN13 in the sysctl (which will print console message when set to 1) 3) Release notes Do you think there are other communication channels one should try to use? When I was looking for information about why the routing doesn't work as expected I didn't know about this settings but couldn't find anything relevant in the Handbook, so would really love to see this somehow mentioned and explained how to use it in the Handbook if possible. Thanks GrzegorzJ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: net.add_addr_allfibs=1 behaviour deprecation
On 18/08/2020 07:54, Julian Elischer wrote: The reason for the two behaviours is that there are two ways that the previous behaviour of "add addresses to the only FIB" could be interpreted and extended once multiple fibs became available. The single fib case could be interpreted as either of: "Add to All N fibs where N == 1" or "add to the first (of 1) fibs". I decided to do both :-) At Ironport where I wrote it we had a scenario where I didn't want to have wrong entries in all the fibs when a new interface was brought up. Even for a moment. An other scenarios where for example a tunnel uses fib 1 but the rest of the system uses fib0 (which points through the tunnel) The addition of new routes into the tunnel's route when a new virtual interface is brought up pointing through the tunnel to the same address, leads in the tunnel immediately redirecting packets through itself which ends in tears. SO the obvious thing to do was to make it possible to only add the entry in the fib that was the default fib or in the case of Ironport, the fib that was the default fib of the process adding the interface. If you had to make a choice I think the '0' choice is the way to go. All other fibs need to be populated deliberately.. On 8/15/20 4:24 AM, Alexander V. Chernikov wrote: 18.07.2020, 14:22, "Alexander V. Chernikov" : Dear FreeBSD users, I would like to make net.add_addr_allfibs=0 as the default system behaviour and remove net.add_addr_allfibs. To do so, I would like to collect use cases with net.add_addr_allfibs=1 and multiple fibs, to ensure they can still be supported after removal. Background: Multi-fib support was added in r17 [1], 12 years ago. Addition of interface addresses to all fibs was a feature from day 1. The `net.add_addr_allfibs` sysctl was added in r180840 [2], 12 years ago. Problem: The goal of the fib support is to provide multiple independent routing tables, isolated from each other. `net.add_addr_allfibs` default tries to shift gears in the opposite direction, unconditionally inserting all addresses to all of the fibs. It complicates the logic, kernel code and makes control plane performance decrease with the number of fibs. It make impossible to use the same prefixes in multiple fibs, which may be desired given shortage of IPv4 address space. I do understand that there are some cases where such behaviour is desired. For example, it can be used to achieve VRF route leaking or binding on address from different fibs. I would like to collect such cases to consider supporting them in a different way. The goal is to make net.add_addr_allfibs=0 default behaviour and remove net.add_addr_allfibs. It will simplify kernel fib-related code and allow bringing more fib-related features. It will also improve fib scaling. No objections has been received. Next steps: * Switch net.add_addr_allfibs to 0 ( https://reviews.freebsd.org/D26076 ) * Provide an ability to use nexthops from different fibs * Remove net.add_addr_allfibs Timeline: Aug 1: summarising feedback and the usecases, decision on proceeding further Aug 20 (tentative): patches for supported usecases Sep 15 (tentative): net.add_addr_allfibs removal. [1]: [base Contents of /head/sys/net/route.c](https://svnweb.freebsd.org/base/head/sys/net/route.c?revision=17&view=markup) [2]: [base Diff of /head/sys/net/route.c](https://svnweb.freebsd.org/base/head/sys/net/route.c?r1=180839&r2=180840&;) /Alexander Agree completely, defaulting "add_addr_allfibs" to 1 broke many existing installations, which goes against the least surprise principle so many times advocated on FreeBSD lists. This is just one example: https://forums.freebsd.org/threads/strange-behavior-of-setfib-since-freebsd-12-0.73348/ Now, changing the default again might again break existing installations, which shouldn't be a reason for not doing it, but might be a reason to better communicate it this time around. GrzegorzJ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
No connection between jails
I have two jails in the same subnet on two different hosts: HOST1 -- jail1 | | HOST2 - jail2 HOST1: 10.70.7.13/16 HOST2: 10.70.70.2/16 jail1: 10.70.5.2/32 jail2: 10.70.7.50/32 Default gateway in the network is 10.70.70.1 but I don't think it matters in this issue. There is network connection between HOST1 and jail2, or HOST 2 and jail1, or between any other host in the network and either jail1 or jail2, however there is no network connection between jail1 and jail2. By network connection I mean exchange of packets, e.g. "telnet destination port". Both hosts and the default gateway are connected to the same psychical switch. There is actually more jails on HOST1 but the situation is analogous - no connection between jails on HOST1 and any jails on HOST2. What am I missing? Both hosts have gateway_enable="YES" in rc.conf (net.inet.ip.forwarding: 1). I am not using VNET, jails are aliased directly in host's network interfaces (lagg0 for HOST1 and em0 for HOST2). Thanks GrzegorzJ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Qualcom Atheros QCA6174 802.11ac
On 01/03/2020 16:37, pepe wrote: Just a quick question. Is there drivers for that wlan chip in topic? FreeBSD 12.1 in use. Or if there are not drivers, any idea if they're coming in any near future? I asked the same question about 6 month ago and was pointed to this thread: https://lists.freebsd.org/pipermail/freebsd-current/2019-February/072769.html The repo is here: https://github.com/erikarn/athp/ Doesn't look like there is going to be support for it anytime soon. GrzegorzJ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
exec.fib and a jail in two subnets
Hi,
I am not sure if this question fits better to net or jail list so please
delete one crosspost when replying.
I have two routers in separate subnets (say 10.0.0.0/16 and
172.16.0.0/16). I have enabled multiple fibs on the host and I am trying
to setup a jail so that packets from one router are returned to the same
router. The second subnet is configured like this:
setfib 1 route add -net 172.16.0.0/16 -iface lagg0
setfib 1 route add default 172.16.0.1
When the jail configuration is (differences in red):
mta {
exec.fib=1;
ip4.addr = 172.16.0.2;
interface = lagg0;
}
router 172.16.0.1 is able to send to and receive packets from the jail
as expected.
When the jail configuration is:
mta {
ip4.addr = 10.0.0.2,172.16.0.2;
interface = lagg0;
}
then router 10.0.0.1 is also able to send and receive packets from the
jail as expected.
However, when the configuration is:
mta {
exec.fib=1;
ip4.addr = 10.0.0.2,172.16.0.2;
interface = lagg0;
}
then router 172.16.0.1 is no longer able to receive a response from the
jail. The router's event log shows entry similar to the following two
about 2 minutes apart:
IN: ACCEPT [54] Connection opened (Port Forwarding: TCP [172.16.0.2]:80
<--> [212.159.95.213]:80 - - - [111.202.101.2]:34172
CLOSED/SYN_SENT ppp3 NAPT)
IN: ACCEPT [57] Connection closed (Port Forwarding: TCP [172.16.0.2]:80
<--> [212.159.95.213]:80 - - - [111.202.101.2]:34172
CLOSED/SYN_SENT ppp3 NAPT)
My question is why the 10.0.0.1 router is able to communicate with the
jail in the second configuration but 172.16.0.1 is not able to
communicate with the jail in the third configuration. Is it because of
order of IPs in ip4.addr?
When the jail is started jls shows only the first IP from either of the
configuration list above (i.e. 10.0.0.2 even if exec.fib is set to 1).
So my guess is that the first IP is somehow a default IP?
Then my additional question is if it's possible for a jail to be in two
subnets at the same time, i.e. so that when the jail responds to a
packet received from router 10.0.0.1 it sends it to the default route
from fib0 and when it responds to a packet received from 172.16.0.1 it
sends it to the default route from fib1. What exec.fib should be in such
a case?
Any help would be greatly appreciated. Thanks!
GrzegorzJ
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Killer E2500 network driver
On 25/06/2018 15:00, Glen Barber wrote: On Mon, Jun 25, 2018 at 07:31:53AM -0700, Rodney W. Grimes wrote: On 24/06/2018 22:29, Rodney W. Grimes wrote: On 24/06/2018 17:16, Rodney W. Grimes wrote: Hi All, This list states that 10-Stable supports Killer E2500 Gigabit Ethernet controller: https://www.freebsd.org/relnotes/10-STABLE/hardware/support.html However, similar list for 11-Stable doesn't list that driver: https://www.freebsd.org/relnotes/11-STABLE/hardware/support.html Does it mean that the driver has been removed, and if yes then why? I believe it was a "added" feature in 10 stable, my 11 stable alc(4) man page lists the E2500 as supported. The alc device driver provides support for the following Ethernet controllers: o Atheros AR8131 PCI Express Gigabit Ethernet controller o Atheros AR8132 PCI Express Fast Ethernet controller o Atheros AR8151 v1.0 PCI Express Gigabit Ethernet controller o Atheros AR8151 v2.0 PCI Express Gigabit Ethernet controller o Atheros AR8152 v1.1 PCI Express Fast Ethernet controller o Atheros AR8152 v2.0 PCI Express Fast Ethernet controller o Atheros AR8161 PCI Express Gigabit Ethernet controller o Atheros AR8162 PCI Express Fast Ethernet controller o Atheros AR8171 PCI Express Gigabit Ethernet controller o Atheros AR8172 PCI Express Fast Ethernet controller o Killer E2200 Gigabit Ethernet controller o Killer E2400 Gigabit Ethernet controller o Killer E2500 Gigabit Ethernet controller Yeah, listing drivers in alc shows support for that card. But the whole alc driver isn't listed on the hardware support page for 11-Stable. So wanted to check if it's an omission or it was removed deliberately. Which page are you looking at, it needs fixed. @x230a:/ # ls -lag /boot/kernel/if_alc.ko -r-xr-xr-x 1 root wheel 84912 Jul 21 2017 /boot/kernel/if_alc.ko @x230a:/ # uname -UK 1101001 1101001 The one listed in my email: https://www.freebsd.org/relnotes/11-STABLE/hardware/support.html alc(4) isn't listed there. Thank you, I should of reread the whole of the message before I asked you to repeat your self. I have checked the 11.0R 11.1R release notes at: https://www.freebsd.org/releases/11.0R/relnotes.html https://www.freebsd.org/releases/11.1R/relnotes.html and the infact do list alc(4) correctly, so I have sent an internal mail to Release Engineering so that we can track down why the release notes at https://www.freebsd.org/relnotes/11-STABLE/hardware/support.html are not reflecting this. I suspect this happened in a transition that recently occured to the repository location that the release notes are stored in/ generated from. For 11.x, no, this is not the case. That change was only in 12-CURRENT, and was not retroactively applied to stable branches due to a problem that is outstanding with the hardware page generation for 12. That said, I'll try to track down where exactly this driver went missing from the hardware page, but it is too late to fix it for the 11.2 release. It can be noted in an errata entry, however, and a link to the 11-STABLE page once it is fixed there. Glen Great, thanks Glen and Rodney. Am I then to understand that this is a documentation issue, rather than the actual driver being removed? ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Killer E2500 network driver
On 24/06/2018 22:29, Rodney W. Grimes wrote: On 24/06/2018 17:16, Rodney W. Grimes wrote: Hi All, This list states that 10-Stable supports Killer E2500 Gigabit Ethernet controller: https://www.freebsd.org/relnotes/10-STABLE/hardware/support.html However, similar list for 11-Stable doesn't list that driver: https://www.freebsd.org/relnotes/11-STABLE/hardware/support.html Does it mean that the driver has been removed, and if yes then why? I believe it was a "added" feature in 10 stable, my 11 stable alc(4) man page lists the E2500 as supported. The alc device driver provides support for the following Ethernet controllers: o Atheros AR8131 PCI Express Gigabit Ethernet controller o Atheros AR8132 PCI Express Fast Ethernet controller o Atheros AR8151 v1.0 PCI Express Gigabit Ethernet controller o Atheros AR8151 v2.0 PCI Express Gigabit Ethernet controller o Atheros AR8152 v1.1 PCI Express Fast Ethernet controller o Atheros AR8152 v2.0 PCI Express Fast Ethernet controller o Atheros AR8161 PCI Express Gigabit Ethernet controller o Atheros AR8162 PCI Express Fast Ethernet controller o Atheros AR8171 PCI Express Gigabit Ethernet controller o Atheros AR8172 PCI Express Fast Ethernet controller o Killer E2200 Gigabit Ethernet controller o Killer E2400 Gigabit Ethernet controller o Killer E2500 Gigabit Ethernet controller Yeah, listing drivers in alc shows support for that card. But the whole alc driver isn't listed on the hardware support page for 11-Stable. So wanted to check if it's an omission or it was removed deliberately. Which page are you looking at, it needs fixed. @x230a:/ # ls -lag /boot/kernel/if_alc.ko -r-xr-xr-x 1 root wheel 84912 Jul 21 2017 /boot/kernel/if_alc.ko @x230a:/ # uname -UK 1101001 1101001 The one listed in my email: https://www.freebsd.org/relnotes/11-STABLE/hardware/support.html alc(4) isn't listed there. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Killer E2500 network driver
On 24/06/2018 17:16, Rodney W. Grimes wrote: Hi All, This list states that 10-Stable supports Killer E2500 Gigabit Ethernet controller: https://www.freebsd.org/relnotes/10-STABLE/hardware/support.html However, similar list for 11-Stable doesn't list that driver: https://www.freebsd.org/relnotes/11-STABLE/hardware/support.html Does it mean that the driver has been removed, and if yes then why? I believe it was a "added" feature in 10 stable, my 11 stable alc(4) man page lists the E2500 as supported. The alc device driver provides support for the following Ethernet controllers: o Atheros AR8131 PCI Express Gigabit Ethernet controller o Atheros AR8132 PCI Express Fast Ethernet controller o Atheros AR8151 v1.0 PCI Express Gigabit Ethernet controller o Atheros AR8151 v2.0 PCI Express Gigabit Ethernet controller o Atheros AR8152 v1.1 PCI Express Fast Ethernet controller o Atheros AR8152 v2.0 PCI Express Fast Ethernet controller o Atheros AR8161 PCI Express Gigabit Ethernet controller o Atheros AR8162 PCI Express Fast Ethernet controller o Atheros AR8171 PCI Express Gigabit Ethernet controller o Atheros AR8172 PCI Express Fast Ethernet controller o Killer E2200 Gigabit Ethernet controller o Killer E2400 Gigabit Ethernet controller o Killer E2500 Gigabit Ethernet controller Yeah, listing drivers in alc shows support for that card. But the whole alc driver isn't listed on the hardware support page for 11-Stable. So wanted to check if it's an omission or it was removed deliberately. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Killer E2500 network driver
Hi All, This list states that 10-Stable supports Killer E2500 Gigabit Ethernet controller: https://www.freebsd.org/relnotes/10-STABLE/hardware/support.html However, similar list for 11-Stable doesn't list that driver: https://www.freebsd.org/relnotes/11-STABLE/hardware/support.html Does it mean that the driver has been removed, and if yes then why? Thanks GrzegorzJ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
AQtion AQC107 driver status
Hello, As far as I could check FreeBSD doesn't yet support this card. It's supported in Linux kernel though. I heard somewhere that the Linux driver doesn't contain any binary blobs and could be ported to FreeBSD. Has anyone been looking into this? Or do you know if anyone is planning to work on the driver for this card? https://www.aquantia.com/products/client-connectivity/aqtion-aqc107/ Thanks GrzegorzJ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Unrecognized Inifiniband HCA
On 10/05/2018 15:35, Justin Clift wrote: On 2018-05-10 10:21, Grzegorz Junka wrote: On 08/05/2018 23:41, Justin Clift wrote: That's probably a ConnectX (series 1) Mellanox card. Those can operate in either Infiniband mode, or Ethernet mode. Which mode are you wanting it to run in? :) As a thought, the FreeBSD wiki page has a bit of info: https://wiki.freebsd.org/InfiniBand For that card to be recognised at all, it'll need the mlx4 driver(s) to load. I don't remember the exact one off hand (it's been a while), but some searching online for mlx4 and FreeBSD should turn up the right bits. Many thanks Justin. This is the first time I am hearing about an Infiniband card operating in Ethernet mode. These cards come with two CX4/SFF 8470 ports. It's not possible to connect standard Ethernet cables that I know of (not even SFP modules). Do you mean that they can operate in Ethernet mode over the CX4 cable? Yep. :) Back in the day when these cards were current tech, CX4 was an acceptable connector for 10GbE. The Infiniband switches from that era (that I had access to) were mostly Infiniband only though. But 10GbE CX4 switches did exist, and can still be found reasonably cheaply on Ebay. eg: * HP ProCurve 6 port CX4 10GBe switch https://www.ebay.com/itm/152232294328 * HP ProCurve 48 port 1GbE switch, with 2x 10GbE CX4 ports on the back https://www.ebay.com/itm/281899832599 One of the good things about those HP ProCurve switches... being enterprise gear they just keep working. For Years. From memory, HP still releases firmware security updates for them (for free) to this day. Unlike (say) Cisco. ;) Note - As a data point, FreeNAS (based on FreeBSD) includes the 10/40GbE driver for these cards by default. With FreeNAS they work as 10GbE "out of the box". :D Hopefully that helps. :) Thanks Justin. That's an amazing piece of tech history :) GrzegorzJ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Unrecognized Inifiniband HCA
On 08/05/2018 23:41, Justin Clift wrote: On 2018-05-08 21:59, Grzegorz Junka wrote: Hi All, pciconf -lv gives me none1@pci0:3:0:0: class=0x0c0600 card=0x000315b3 chip=0x634015b3 rev=0xa0 hdr=0x00 vendor = 'Mellanox Technologies' device = 'MT25408 [ConnectX VPI - IB SDR / 10GigE]' class = serial bus Does it mean that my card is unrecognized? It supposed to be 10GB x 2 Infiniband PCI-E HCA 500EX-D Dual-Port Card Mellanox Firmware. Currently the card doesn't show when doing ifconfig. What should I do to have the proper device name instead of none1 or for the card to appear in ifconfig? # kldstat Id Refs Address Size Name 1 28 0x8020 1f67a88 kernel 2 1 0x82169000 316708 zfs.ko 3 2 0x8248 cb78 opensolaris.ko 4 1 0x8248d000 42c28 mps.ko 5 1 0x82621000 bdb0 if_lagg.ko 6 1 0x8262d000 3650 ums.ko 7 1 0x82631000 6679 nullfs.ko 8 1 0x82638000 bdfe unionfs.ko 9 2 0x82644000 2094f mlx5.ko 10 2 0x82665000 103e1 linuxkpi.ko 11 1 0x82676000 15965 mlx5en.ko That's probably a ConnectX (series 1) Mellanox card. Those can operate in either Infiniband mode, or Ethernet mode. Which mode are you wanting it to run in? :) As a thought, the FreeBSD wiki page has a bit of info: https://wiki.freebsd.org/InfiniBand For that card to be recognised at all, it'll need the mlx4 driver(s) to load. I don't remember the exact one off hand (it's been a while), but some searching online for mlx4 and FreeBSD should turn up the right bits. Many thanks Justin. This is the first time I am hearing about an Infiniband card operating in Ethernet mode. These cards come with two CX4/SFF 8470 ports. It's not possible to connect standard Ethernet cables that I know of (not even SFP modules). Do you mean that they can operate in Ethernet mode over the CX4 cable? GrzegorzJ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Missing mlx4, was Re: Unrecognized Inifiniband HCA
On 10/05/2018 09:06, Ben RUBSON wrote: On 10 May 2018 10:36, Grzegorz Junka wrote: Does it mean, that mlx4 is no longer compiled in the default kernel It has never been, but I think modules have been added recently, I can remember HPS did it :) Right, I meant that they are not being build as modules along with the default kernel, unlike mx5/en currently for example (which are available with the default FreeBSD installation) :) Can I just compile the mlx4/en/ib kernel module without having to compile the whole kernel? Yes, here are at least the instructions for FreeBSD 11.0 which could help you : cd /usr/src/sys/modules/mlx4 make make install make clean cd /usr/src/sys/modules/mlxen make make install make clean That looks easy, will give it a try. Thanks! GrzegorzJ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Missing mlx4, was Re: Unrecognized Inifiniband HCA
On 09/05/2018 00:39, Rodney W. Grimes wrote: On Tue, May 08, 2018 at 08:59:20PM +, Grzegorz Junka wrote: Hi All, pciconf -lv gives me none1@pci0:3:0:0: class=0x0c0600 card=0x000315b3 chip=0x634015b3 rev=0xa0 hdr=0x00 ?? vendor = 'Mellanox Technologies' ?? device = 'MT25408 [ConnectX VPI - IB SDR / 10GigE]' ?? class?? = serial bus Does it mean that my card is unrecognized? It supposed to be 10GB x 2 Infiniband PCI-E HCA 500EX-D Dual-Port Card Mellanox Firmware. Currently the card doesn't show when doing ifconfig. What should I do to have the proper device name instead of none1 or for the card to appear in ifconfig? # kldstat Id Refs Address?? Size Name ??1 28 0x8020 1f67a88?? kernel ??2?? 1 0x82169000 316708 zfs.ko ??3?? 2 0x8248 cb78 opensolaris.ko ??4?? 1 0x8248d000 42c28?? mps.ko ??5?? 1 0x82621000 bdb0 if_lagg.ko ??6?? 1 0x8262d000 3650 ums.ko ??7?? 1 0x82631000 6679 nullfs.ko ??8?? 1 0x82638000 bdfe unionfs.ko ??9?? 2 0x82644000 2094f?? mlx5.ko 10?? 2 0x82665000 103e1?? linuxkpi.ko 11?? 1 0x82676000 15965?? mlx5en.ko mlx5en is for ConnectX-4. I think that's an older card. Try mlx4en, which supports ConnectX-2 and ConnectX-3. From a quick grep this infact should be supported by the mlx4/mlx5en drivers: net/mlx4/main.c:/* MT25408 "Hermon" SDR */ net/mlx4/main.c:/* MT25408 "Hermon" DDR */ net/mlx4/main.c:/* MT25408 "Hermon" QDR */ net/mlx4/main.c:/* MT25408 "Hermon" DDR PCIe gen2 */ net/mlx4/main.c:/* MT25408 "Hermon" QDR PCIe gen2 */ net/mlx4/main.c:/* MT25408 "Hermon" EN 10GigE */ net/mlx4/main.c:/* MT25408 "Hermon" EN 10GigE PCIe gen2 */ Thank you Gary and Rod for your quick reply. I don't seem to have mlx4 in my /boot/kernel. I unloaded mlx5 and mlx5en and tried to load mlx instead, but strangely, it says mlx is already loaded. How? # kldload mlx kldload: can't load mlx: module already loaded or in kernel # kldstat Id Refs Address Size Name 1 22 0x8020 1f67a88 kernel 2 1 0x82169000 316708 zfs.ko 3 2 0x8248 cb78 opensolaris.ko 4 1 0x8248d000 42c28 mps.ko 5 1 0x82621000 bdb0 if_lagg.ko 6 1 0x8262d000 3650 ums.ko 7 1 0x82631000 6679 nullfs.ko 8 1 0x82638000 bdfe unionfs.ko # ls -l /boot/kernel/mlx mlx.ko* mlx5.ko* mlx5en.ko* Anyways, mlx seems to be rather unrelated to this problem: https://www.freebsd.org/cgi/man.cgi?query=mlx Looks like mlx4 is available in the kernel: https://github.com/freebsd/freebsd/tree/master/sys/modules/mlx4 However, it seems that it may not compile: https://forums.freebsd.org/threads/mellanox-mt26448.64350/ Does it mean, that mlx4 is no longer compiled in the default kernel and I would need to compile the kernel manually? Can I just compile the mlx4/en/ib kernel module without having to compile the whole kernel? Thanks GrzegorzJ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Unrecognized Inifiniband HCA
Hi All, pciconf -lv gives me none1@pci0:3:0:0: class=0x0c0600 card=0x000315b3 chip=0x634015b3 rev=0xa0 hdr=0x00 vendor = 'Mellanox Technologies' device = 'MT25408 [ConnectX VPI - IB SDR / 10GigE]' class = serial bus Does it mean that my card is unrecognized? It supposed to be 10GB x 2 Infiniband PCI-E HCA 500EX-D Dual-Port Card Mellanox Firmware. Currently the card doesn't show when doing ifconfig. What should I do to have the proper device name instead of none1 or for the card to appear in ifconfig? # kldstat Id Refs Address Size Name 1 28 0x8020 1f67a88 kernel 2 1 0x82169000 316708 zfs.ko 3 2 0x8248 cb78 opensolaris.ko 4 1 0x8248d000 42c28 mps.ko 5 1 0x82621000 bdb0 if_lagg.ko 6 1 0x8262d000 3650 ums.ko 7 1 0x82631000 6679 nullfs.ko 8 1 0x82638000 bdfe unionfs.ko 9 2 0x82644000 2094f mlx5.ko 10 2 0x82665000 103e1 linuxkpi.ko 11 1 0x82676000 15965 mlx5en.ko Thanks GrzegorzJ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Default network device
Hi, In my laptop I have both, wlan0 and ue0 (ethernet). When both are connected, FreeBSD chooses to use wlan0 by default. Only when I disable wlan0 it switches to use ue0. Since ue0 is ethernet it's obviously much faster than wlan0. Why FreeBSD is selecting wlan rather than ue? How to configure the network so that wlan0 is only used when ue0 isn't available? Thanks GrzegorzJ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Incorrect route interface
On 12/03/2018 20:13, Rodney W. Grimes wrote:
On 12/03/2018 18:04, Rodney W. Grimes wrote:
On 11/03/2018 20:57, Marek Zarychta wrote:
On Sun, Mar 11, 2018 at 05:46:52PM +, Grzegorz Junka wrote:
On 11/03/2018 06:04, Eugene Grosbein wrote:
11.03.2018 7:01, Grzegorz Junka wrote:
Just do not assign addresses from same network 10.20.0.0/16 to different
network interfaces
and you will be fine. Assign them all to right interface:
ifconfig_em0="inet 10.20.2.14 netmask 255.255.0.0"
ifconfig_em0_alias0="inet 10.20.2.15/32"
ifconfig_igb0_alias0="inet 10.20.2.16/32"
Interfaces meant to be all equal, last line should be:
ifconfig_em0_alias1="inet 10.20.2.16/32"
OK, I see. So this is in case I want many IPs assigned to the same
interface. What if I want one IP assigned to multiple interfaces (i.e.
so that the additional igb0-3 effectively work as a 4-port switch)?
Please consider bonding all NICs as one bridge(4) interface. Then
multiple IPs could be assigned to such interface.
Many thanks Eugene and Marek for your suggestions. I will now need to
decide if I want to fragment the network into subnets or bridge the
interfaces.
GregJ
I believe some of the problem you are experincing is addressed
in this differential:
https://reviews.freebsd.org/D14547
Your original configuration was(is) valid, just not common,
and I have not seen this done in more than a decade, but it
seems as if rstone@ also has someone doing this "multiple IP's
into same subnet on seperate interfaces".
Thanks for the link. That's interesting. According to this post that
configuration shouldn't be valid:
https://forums.freenas.org/index.php?threads/multiple-network-interfaces-on-a-single-subnet.20204/
I'll disagree with the claims it is not valid. I shall however support
the claims that it is non-standard, and non-trivial to understand just
what it is that occurs in *BSD when you do this. I have seen this
"claimed to be invalid" coniguration in use several times over the
past 30 years.
Where people seem to get this "invalid" from is expecting the traffic
to be bound to an IP to go both in and OUT that interface is what is
not invalid, but a wrong assertion. Traffic WELL come in that interface,
as that is how ethernet macs, arp's an IP work. However it WELL go
out the interface that is selected by the routing table. If you
can seperate in your mind that this is how IN and OUT interfaces
are decided the rest becomes simply mechanical.
Simple typical *BSD installs end up with all traffic going out just
one of the interfaces, but I can write route rules that change that
artifact. And this is where the usage of this odd configuration
sometimes comes about.
With modern implimentations of *BSD that now have multiple fib's,
and things like netgraph, and ipfw one can get very creative in
what actually happens. And none of it is invalid, just often
miss understood. I can actually casue that traffic bound to
a specific IP to go in and out that specific interface. Ipfw's
ability to cause a packet to use an alternate fib is how.
ipfw add allow ip from ${ip_of_nicX} to any setfib ${fib_for_nicX}
I don't know much about the network stack in FreeBSD but I would assume
that I should be able to configure specific traffic (based on the
destination subnet, so nothing fancy) to go out of a specific interface.
Not only I wasn't able to do that, I was told my approach was wrong. So
I think I agree with you.
GregJ
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Incorrect route interface
On 12/03/2018 18:04, Rodney W. Grimes wrote: On 11/03/2018 20:57, Marek Zarychta wrote: On Sun, Mar 11, 2018 at 05:46:52PM +, Grzegorz Junka wrote: On 11/03/2018 06:04, Eugene Grosbein wrote: 11.03.2018 7:01, Grzegorz Junka wrote: Just do not assign addresses from same network 10.20.0.0/16 to different network interfaces and you will be fine. Assign them all to right interface: ifconfig_em0="inet 10.20.2.14 netmask 255.255.0.0" ifconfig_em0_alias0="inet 10.20.2.15/32" ifconfig_igb0_alias0="inet 10.20.2.16/32" Interfaces meant to be all equal, last line should be: ifconfig_em0_alias1="inet 10.20.2.16/32" OK, I see. So this is in case I want many IPs assigned to the same interface. What if I want one IP assigned to multiple interfaces (i.e. so that the additional igb0-3 effectively work as a 4-port switch)? Please consider bonding all NICs as one bridge(4) interface. Then multiple IPs could be assigned to such interface. Many thanks Eugene and Marek for your suggestions. I will now need to decide if I want to fragment the network into subnets or bridge the interfaces. GregJ I believe some of the problem you are experincing is addressed in this differential: https://reviews.freebsd.org/D14547 Your original configuration was(is) valid, just not common, and I have not seen this done in more than a decade, but it seems as if rstone@ also has someone doing this "multiple IP's into same subnet on seperate interfaces". Thanks for the link. That's interesting. According to this post that configuration shouldn't be valid: https://forums.freenas.org/index.php?threads/multiple-network-interfaces-on-a-single-subnet.20204/ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Incorrect route interface
On 11/03/2018 20:57, Marek Zarychta wrote: On Sun, Mar 11, 2018 at 05:46:52PM +, Grzegorz Junka wrote: On 11/03/2018 06:04, Eugene Grosbein wrote: 11.03.2018 7:01, Grzegorz Junka wrote: Just do not assign addresses from same network 10.20.0.0/16 to different network interfaces and you will be fine. Assign them all to right interface: ifconfig_em0="inet 10.20.2.14 netmask 255.255.0.0" ifconfig_em0_alias0="inet 10.20.2.15/32" ifconfig_igb0_alias0="inet 10.20.2.16/32" Interfaces meant to be all equal, last line should be: ifconfig_em0_alias1="inet 10.20.2.16/32" OK, I see. So this is in case I want many IPs assigned to the same interface. What if I want one IP assigned to multiple interfaces (i.e. so that the additional igb0-3 effectively work as a 4-port switch)? Please consider bonding all NICs as one bridge(4) interface. Then multiple IPs could be assigned to such interface. Many thanks Eugene and Marek for your suggestions. I will now need to decide if I want to fragment the network into subnets or bridge the interfaces. GregJ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Incorrect route interface
On 11/03/2018 06:04, Eugene Grosbein wrote: 11.03.2018 7:01, Grzegorz Junka wrote: Just do not assign addresses from same network 10.20.0.0/16 to different network interfaces and you will be fine. Assign them all to right interface: ifconfig_em0="inet 10.20.2.14 netmask 255.255.0.0" ifconfig_em0_alias0="inet 10.20.2.15/32" ifconfig_igb0_alias0="inet 10.20.2.16/32" Interfaces meant to be all equal, last line should be: ifconfig_em0_alias1="inet 10.20.2.16/32" OK, I see. So this is in case I want many IPs assigned to the same interface. What if I want one IP assigned to multiple interfaces (i.e. so that the additional igb0-3 effectively work as a 4-port switch)? ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Incorrect route interface
On 10/03/2018 22:43, Eugene Grosbein wrote: 11.03.2018 5:01, Grzegorz Junka wrote: In rc.conf I have: hostname="some.server.com" ifconfig_em0="inet 10.20.2.14 netmask 255.255.0.0" ifconfig_em1="inet 10.20.2.15 netmask 255.255.0.0" ifconfig_igb0="inet 10.20.2.16 netmask 255.255.0.0" Just do not assign addresses from same network 10.20.0.0/16 to different network interfaces and you will be fine. Assign them all to right interface: ifconfig_em0="inet 10.20.2.14 netmask 255.255.0.0" ifconfig_em0_alias0="inet 10.20.2.15/32" ifconfig_igb0_alias0="inet 10.20.2.16/32" Do not try to use several physical network cards to connect hosts using just one IP network as generally each card/interface needs distinct IP network to work flawlessly. Did you mean: ifconfig_em1_alias0="inet 10.20.2.15/32" I don't quite understand how you can assign an alias to an interface (igb0 in this case) without configuring it with an IP first? According to the documentation an alias is an additional network address, not the only one? ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Incorrect route interface
Hi All, I have 2 NICs, one built-in with two ports em0 and em1 and one PCI card with 4 ports igb0-3. Only em0 is connected to the router. Then igb0 is connected to another system which isn't connected anywhere. FreeBSD somehow insists on directing all traffic through igb0 rather than em0. netstat -rn gives me: Destination Gateway Flags Netif Expire default 10.20.2.1 UGS em0 10.20.0.0/16 link#1 U igb0 10.20.2.14 link#5 UHS lo0 10.20.2.15 link#6 UHS lo0 ... And so on, links 1-6 are then listed similarly to link5 and 6. In rc.conf I have: hostname="some.server.com" ifconfig_em0="inet 10.20.2.14 netmask 255.255.0.0" ifconfig_em1="inet 10.20.2.15 netmask 255.255.0.0" ifconfig_igb0="inet 10.20.2.16 netmask 255.255.0.0" ... defaultrouter="10.20.2.1 -ifp em0" static_routes="lan" route_lan="-net 10.20.0.0/16 -interface em0 -fib 0" In dmesg I am getting warnings: add host 127.0.0.1: gateway lo0 fib 0: route already in the table add net 10.20.0.0: gateway em0 fib 0: route already in the table add net default: gateway 10.20.2.1 Additional inet routing options: gateway=YES. add host ::1: gateway lo0 fib 0: route already in the table ... I actually don't know if all traffic goes through igb0, I assumed so looking at this position in the table: 10.20.0.0/16 link#1 U igb0 Why default 10.20.2.1 UGS em0 10.20.0.0/16 link#1 U igb0 have different interfaces and how can I configure the network to direct all traffic through em0? ping 10.20.2.1 doesn't work, it says: ping: sendto: Host is down Can anyone please help? GregJ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: WiFi and NFS
On 13/08/2017 12:42, Andrea Venturoli wrote: On 08/13/17 13:47, Grzegorz Junka wrote: On my laptop I have two interfaces, wlan0 (WiFi) and ue0 (LAN). Obviously LAN is faster but not always connected. Is there any way to tell the system to use LAN interface in preference to the other? You mean: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-aggregation.html#networking-lagg-wired-and-wireless ? Thanks a lot! That looks exactly like what I need. However, when I was checking the lagg configuration a few years ago, at that time it wasn't possible to set up a lagg with WiFi. Has anything changed (fairly) recently? GrzegorzJ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
WiFi and NFS
On my laptop I have two interfaces, wlan0 (WiFi) and ue0 (LAN). Obviously LAN is faster but not always connected. Is there any way to tell the system to use LAN interface in preference to the other? When mounting NFS it uses the WiFi interface rather than LAN. Maybe there is an option to tell NFS to bind to a specific interface (if available)? GrzegorzJ ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: A web server behind two gateways?
On 17/07/2017 18:22, Eugene Grosbein wrote: 18.07.2017 1:19, Eugene Grosbein пишет: 18.07.2017 0:48, Alan Somers wrote: Not answering any particular email in this thread, many thanks for your help. That;s plenty of ideas to try so may take some time! Just one more question, since VNET was mentioned. Is it production ready now? I remember there used to be problems with memory leaks. And why isn't it the kernel, yet? Any plans for that? Grzegorz J ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
A web server behind two gateways?
Hello, I have a jail running a web server in LAN. There are two routers/WANs that can connect LAN to the internet. I enabled NAT and port forwarding to the web server on both routers. The problem is that the web server responds to requests only from one router at a time depending on the default gateway set on the jail's host. If the default gateway is set as router 1 then the web page can be opened only through WAN1 and vice versa. Can I configure either router/host/jail so that the web server sends the response back to the IP that sent the request packet rather than to the default gateway? And a bonus question, how can I configure two jails so that each jail sends packets to a different gateway (which may or may not be the same as the jails' host's default gateway)? Thanks Grzegorz ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: memory leaks in 11.0?
On 11/07/2017 13:56, Kajetan Staszkiewicz wrote: Hello, I finally upgraded one of many of my routers to 11.0. Unfortunately after running fine for a month it ran out of memory. "wired" memory slowly grows up to allocating all memory in system when no more memory is left for other programs. Things first get swapped and eventually die. The router runs BIRD which has not much to do, it is for internal networks only, pf, pfsync (currently disabled via `ifconfig pfsync0 down`), filebeat, smokeping, ntp, nrpe and custom python cron job for sending data to Graphite. `vmstat -z` shows constantly increasing allocation of "512" and "UMA Slabs". Memory allocated for all pf-related things seems fine. I have graphite graps for every `vmstat -z` and the icrease on "512" grows in similar way as "wired" memory. "512" has 2 917 392 used objects allocated at this moment, "UMA Slabs" is 379 006, there is 2636MiB "wired" memory. How can I debug which part of kernel is responsible for this? I run GENERIC kernel with ixl driver 1.7.11 from Intel, as the one in GENERIC had issues detecting links on my x710 NIC. I ask here, because it is a router, mostly being busy with his network cards, routing and pf. Please direct me to a better group if you can. I can crash this system if needed and dump memory (I hope that is possible on GENERIC) for analysis. That's interesting. Are those ARM-based routers or x86/amd64? This my server: Mem: 48M Active, 190M Inact, 28G Wired, 3075M Free ARC: 26G Total, 6118M MFU, 18G MRU, 32K Anon, 184M Header, 1294M Other Swap: 48G Total, 20M Used, 48G Free % uptime 5:12PM up 93 days, 1:58, 1 users, load averages: 0.23, 0.20, 0.16 uname -r 11.0-RELEASE-p8 vmstat -z 512:512, 0,2921,1703,505278087, 0, 0 UMA Slabs: 80, 0, 551576, 51574, 1716599, 0, 0 It looks like the memory allocations for '512' constantly go up but I didn't check if they go down again at some point. However, 'UMA Slabs' seems to be not changing much. I believe the Wired memory as shown in top includes ZFS which the server is installed on? If that's the case then it's probably ZFS filling up the free memory with ZFS cache? Grzegorz ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Blank Emails (example: D6689: tcp/lro: Implement hash table for LRO entries.)
I am. I am also new here so I thought they are expected. Grzegorz On 02/06/2016 16:45, David DeSimone wrote: I keep receiving blank emails like this one. Is everyone else? Is there something wrong with the bug tracking system? -Original Message- From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org] On Behalf Of sepherosa_gmail.com (Sepherosa Ziehau) Sent: Thursday, June 02, 2016 11:23 AM To: freebsd-net@freebsd.org Subject: [Differential] D6689: tcp/lro: Implement hash table for LRO entries. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. makes no warranty that this email is error or virus free. Thank you. This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. NTT America makes no warranty that this email is error or virus free. Thank you. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
