Re: Problem with net.inet.tcp.path_mtu_discovery=1

> On 4. Jun 2025, at 19:29, Christos Chatzaras wrote: > > > >> On 4 Jun 2025, at 19:36, Dave Cottlehuber wrote: >> >> On Wed, 4 Jun 2025, at 16:36, Christos Chatzaras wrote: >>> Hello, >>> >>> I manage some servers hosting websites. >> >> What does tcpdump/wireshark show for traffic, partic

Re: Problem with net.inet.tcp.path_mtu_discovery=1

On Wed, Jun 4, 2025 at 3:58 PM Christos Chatzaras wrote: > > With these settings, is the connection supposed to work even if an > intermediate router is dropping the ICMP messages required for Path MTU > Discovery? I tried this configuration, but it didn’t resolve the issue. No. Path MTU Discov

Re: Problem with net.inet.tcp.path_mtu_discovery=1

> On 4 Jun 2025, at 22:06, Michael Tuexen > wrote: > >> On 4. Jun 2025, at 19:29, Christos Chatzaras wrote: >> >> >> >>> On 4 Jun 2025, at 19:36, Dave Cottlehuber wrote: >>> >>> On Wed, 4 Jun 2025, at 16:36, Christos Chatzaras wrote: Hello, I manage some servers hosting w

Re: Problem with net.inet.tcp.path_mtu_discovery=1

> On 4. Jun 2025, at 19:29, Christos Chatzaras wrote: > > > >> On 4 Jun 2025, at 19:36, Dave Cottlehuber wrote: >> >> On Wed, 4 Jun 2025, at 16:36, Christos Chatzaras wrote: >>> Hello, >>> >>> I manage some servers hosting websites. >> >> What does tcpdump/wireshark show for traffic, partic

Re: Problem with net.inet.tcp.path_mtu_discovery=1

> On 4 Jun 2025, at 19:36, Dave Cottlehuber wrote: > > On Wed, 4 Jun 2025, at 16:36, Christos Chatzaras wrote: >> Hello, >> >> I manage some servers hosting websites. > > What does tcpdump/wireshark show for traffic, particularly icmp? Wireshark is > very helpful in explaining some issues. >

Re: Problem with net.inet.tcp.path_mtu_discovery=1

On Wed, 4 Jun 2025, at 16:36, Christos Chatzaras wrote: > Hello, > > I manage some servers hosting websites. What does tcpdump/wireshark show for traffic, particularly icmp? Wireshark is very helpful in explaining some issues. What is the actual MTU on the working net vs the failing one? Is the

[Bug 186401] [re] Problem with RTL8111/8168B initialization

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186401 Mark Linimon changed: What|Removed |Added Status|Open|Closed Resolution|---

[Bug 186401] [re] Problem with RTL8111/8168B initialization

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186401 Mark Linimon changed: What|Removed |Added CC||bugmeis...@freebsd.org As

Re: Problem with Ethernet port BCM57416 NetXtreme-E Dual-Media 10G

> Hello, I have a problem with the installation of OPNSense 24.1. I am unable > to activate the Ethernet port BCM57416 NetXtreme-E Dual-Media 10G RDMA > Ethernet Controller. > > He doesn't recognize them, does anyone have a solution? > > The same problem with Realtek Semi conductor co. RTL8125

Re: Problem with Ethernet port BCM57416 NetXtreme-E Dual-Media 10G

Hi all! > Am 06.02.2024 um 11:14 schrieb Marcos Lage : > > PciConf : > [...] What about the other two pieces of information I asked for? >> Also please verify with >> >> kldstat >> >> that the if_bnxt.ko module is loaded and add the output of >> >> ifconfig -a Kind regards, Patrick

Re: Problem with Ethernet port BCM57416 NetXtreme-E Dual-Media 10G

PciConf : cibS@pcio: 0:28:0: vendor ＝ •Intel class=0x060400 rev=0x11 hdr=0x01 vendor=0x8086 device=0x7a38 class Corporation' subvendor=0×1043 ＝ bridge subdevice=0x8882 subclass = PCI-PCI cib6@pci0: 0:28:2: vendor = 'Intel Corporation' class class=0x060400 rev=0x11 hdr=0x01 vendor=0x8086 device=0x7

Re: Problem with Ethernet port BCM57416 NetXtreme-E Dual-Media 10G

Hello Marcos, > Am 06.02.2024 um 07:26 schrieb Marcos Lage : > > Hello, I have a problem with the installation of OPNSense 24.1. OPNsense 24.1 is based on FreeBSD 13.2-RELEASE-p9. > I am unable to activate the Ethernet port BCM57416 NetXtreme-E Dual-Media 10G > RDMA Ethernet Controller. Could

Re: problem with ixl(4) and vlans

Hi Santi, yes that was one of the first things i tried, disabling all the VLAN_HW* options on the interface, unfortunately without any change in the behavior. The pf module is loaded and some filters are active on another interface but no filtering happens on ixl3, ixl3.15 or bridge0. That w

Re: problem with ixl(4) and vlans

Hi Daniel, have you try disabling hardware vlan filtering?Also I guess there is not ipfw or pf modules loaded right?Best SantiOn 25 Jan 2024, at 10:07, Daniel wrote: Hi, thanks for your suggestion. Turns out, when i unplug the vlan interface from the bridge and put th

Re: problem with ixl(4) and vlans

Hi, thanks for your suggestion. Turns out, when i unplug the vlan interface from the bridge and put the ip address on the vlan interface, as you suggested, things start to work, e.g. arp resolves. as soon as i put the ip and the vlan interface back on the bridge, things stop again. so where

Re: problem with ixl(4) and vlans

> On Jan 23, 2024, at 11:03 PM, Daniel wrote: > > Hi List, > > > just recently I discovered a problem with the ixl(4) driver. Hopefully > someone here can help me. my setup is as follows: > > > Network - ixl3 interface - ixl3.15 vlan interface - bridge0 - > vnet0.1 to ja

Re: problem with ixl(4) and vlans

Hi List, because i've been asked, yes, the ixl3.15 interface is also UP (even my output in the last mail showed different, result of my desperate tries to make it work. One thing I didn't mention, this is an onboard ixl on a Intel S2600STB Board, is has this wired config, were the first two

Re: Problem with resolver/host

> On 20 April 2021, at 14:12, Doug Hardie wrote: > > I suspect this is an issue with the resolver, but it could also be in host. > I have the following in /etc/resolv.conf: > > # Generated by resolvconf > nameserver fe80::213:72ff:fec3:180f%bge0 > nameserver fe80::120c:6bff:fee9:cdf7%bge0 > >

Re: problem with carp on 11.3-RELEASE

On Thu, 29 Aug 2019 12:54:41 +0200 Patrick Lamaiziere wrote: Hello, > I've upgraded our two firewalls from 11.2-RELEASE-p11 to 11.3 release > p3 and I'm seeing a problem with carp, the carp slave becomes briefly > MASTER and returns to the slave state. This occurs often. ... I've made an othe

Re: Problem with igb NIC on fresh 11 Install

OCR conversion is why the text is garbled. It appears if the parent NIC has no address assigned to it, it remains in the DOWN state. Manually UP-ing the igb0 interface got the VLAN's working. Adding VLANs to an interface doesn't UP the NIC and it took me a long time to realize that. Apparently

Re: Problem with igb NIC on fresh 11 Install

On 09/30/2017 11:36, Lee Brown wrote: > It looks like the driver is not passing packets from the VLAN layer to the > NIC. Switch counters verify this and netstat seems to indicate the same. > ... > root@rtr-net-r1: - # ifconfig igb0 > igb0: flags=8c02 metric 0 mtu 1500 igb0 looks to be OACTIVE, (

Re: Problem with igb NIC on fresh 11 Install

It looks like the driver is not passing packets from the VLAN layer to the NIC. Switch counters verify this and netstat seems to indicate the same. Apologies for any mistakes in the text, i had to convert from an image (attached). I've tried toggling flags on the igb interface (txcsum, hwtag, et

Re: Problem with VLAN config and traffic after 10.1-R -> 10.3-R-p5 Upgrade?

On 06/23/16 14:04, Karl Pielorz wrote: > Any chance you can send us a snippet of how they're setup in > '/etc/rc.conf' if it's different. It's all in the PR Cheers, Matthew signature.asc Description: OpenPGP digital signature

Re: Problem with VLAN config and traffic after 10.1-R -> 10.3-R-p5 Upgrade?

Ok... --On 23 June 2016 13:32 +0100 Matthew Seaman wrote: I use a similar config with vlans over lagg. While I haven't seen exactly your problem, I did see one instance of the vlan interface coming up with an all-zero MAC address (out of about 10 systems upgraded to 10.3-RELEASE so far). Se

Re: Problem with VLAN config and traffic after 10.1-R -> 10.3-R-p5 Upgrade?

On Thu, 23 Jun 2016 14:04:13 +0100 Karl Pielorz wrote: > --On 23 June 2016 13:32 +0100 Matthew Seaman > wrote: > > > I use a similar config with vlans over lagg. While I haven't seen > > exactly your problem, I did see one instance of the vlan interface > > coming up with an all-zero MAC add

Re: Problem with VLAN config and traffic after 10.1-R -> 10.3-R-p5 Upgrade?

--On 23 June 2016 13:32 +0100 Matthew Seaman wrote: I use a similar config with vlans over lagg. While I haven't seen exactly your problem, I did see one instance of the vlan interface coming up with an all-zero MAC address (out of about 10 systems upgraded to 10.3-RELEASE so far). See PR207

Re: Problem with VLAN config and traffic after 10.1-R -> 10.3-R-p5 Upgrade?

--On 23 June 2016 14:30 +0200 Michael Gmelin wrote: I don't think having an IP address on an interface that also has vlan interfaces is a good idea. What kind of traffic are you expecting on lagg1? Hi, This has worked for 'quite a while' (i.e. >year). lagg1 is connected to an HP switch th

Re: Problem with VLAN config and traffic after 10.1-R -> 10.3-R-p5 Upgrade?

> On 23 Jun 2016, at 14:14, Karl Pielorz wrote: > > > --On 23 June 2016 11:53 +0100 Karl Pielorz wrote: > >> This gets increasingly weird if I run tcpdump on the 10.3 box. The act of >> running 'tcpdump -i lagg1.30 -n' actually fixes the problem: > > As a follow up - running 'ifconfig lagg1

Re: Problem with VLAN config and traffic after 10.1-R -> 10.3-R-p5 Upgrade?

On 06/23/16 13:14, Karl Pielorz wrote: > > --On 23 June 2016 11:53 +0100 Karl Pielorz wrote: > >> This gets increasingly weird if I run tcpdump on the 10.3 box. The act of >> running 'tcpdump -i lagg1.30 -n' actually fixes the problem: > > As a follow up - running 'ifconfig lagg1 promisc' fixes

Re: Problem with VLAN config and traffic after 10.1-R -> 10.3-R-p5 Upgrade?

--On 23 June 2016 11:53 +0100 Karl Pielorz wrote: This gets increasingly weird if I run tcpdump on the 10.3 box. The act of running 'tcpdump -i lagg1.30 -n' actually fixes the problem: As a follow up - running 'ifconfig lagg1 promisc' fixes the issue as well (as you'd kind of expect if tcpd

Re: Problem with ipfw, in-kernel NAT and port redirection to jails

On 8/02/2016 9:27 PM, Alexey Roslyakov via freebsd-net wrote: 08.02.2016 12:30, Kiryanov Vassily пишет: Hello Alexey, Thank you for this information, I have thoughts about using pf nat as an alternative way and your example will be useful for me. But Eugene Grosbein adviced me to turn off tso4

Re: Problem with ipfw, in-kernel NAT and port redirection to jails

08.02.2016 12:30, Kiryanov Vassily пишет: Hello Alexey, Thank you for this information, I have thoughts about using pf nat as an alternative way and your example will be useful for me. But Eugene Grosbein adviced me to turn off tso4 on network card underlaying my VLANs and it was enough to solv

Re: Problem with ipfw, in-kernel NAT and port redirection to jails

Hello. I have same problem when I'm trying redirect incoming traffic into the jailed web server. I repeated my installation few times on different releases - problem with redirected ports was here all time (except 9.3 - there was random result). As a temporary solution am using pf nat for redi

Re: problem with tcpdump/netmap

Well, it seems the netmap integration with libpcap is only available for FreeBSD-11-CURRENT ? is that correct ? Thanks, On 12/10/2015 23:28, Hadi Rezaee wrote: > Hey there, > > I rebuild my box (FreeBSD 10.2R amd64) with netmap support. > Just to check if everything going well, I connected my la

Re: Problem with receiving packets right after remote-interface is up

Hi guys, On Sun, 9/6/15, Artem Belevich wrote: > While you can indeed set speed/duplex manually, you will also need > to make sure both have have proper clock master/slave >  selection  which is normally done via autonegotiation. On > Freebsd some interfaces support "mediaopt master" > option ..

Re: Problem with receiving packets right after remote-interface is up

On Sun, Sep 6, 2015 at 2:31 PM, M. V. wrote: > > About disabling auto-negotiation and media options: > My interfaces didn't support master/slave option. I changed interface > media to both "1000BASET" and "100BASETX" instead of auto, but problem was > still there. but interestingly, when I change

Re: Problem with receiving packets right after remote-interface is up

Thank you guys for your answers. On Sat, Sep 5, 2015 at 2:44 PM, Luigi Rizzo wrote: > You may be able to avoid the issue if you avoid autonegotiation > and manually set the media type, speed and duplex. On Sun, 9/6/15, Artem Belevich wrote: > While you can indeed set speed/duplex manually, you

Re: Problem with receiving packets right after remote-interface is up

On Sat, Sep 5, 2015 at 2:44 PM, Luigi Rizzo wrote: > You may be able to avoid the issue if you avoid autonegotiation and > manually set the media type, speed and duplex. > Technically, 1G ethernet *requires* autonegotiation. http://standards.ieee.org/findstds/interps/IEEE802.3af-2003interp-6.pdf

Re: Problem with receiving packets right after remote-interface is up

You may be able to avoid the issue if you avoid autonegotiation and manually set the media type, speed and duplex. Cheers Luigi On Saturday, September 5, 2015, M. V. via freebsd-net < freebsd-net@freebsd.org> wrote: > Hi, > > Our product is being tested with Spirent TestCenter, and we're facing

Re: problem with 9k jumbo clusters

I tried to understand the code ixgbe, but I did not succeed. If anybody could, make patch for me, please. 05.12.2014 00:49, Jack Vogel пишет: I had wanted to remove the larger cluster sizes from the driver a while back, but for reasons I don't remember that code change didn't happen. The new 4

Re: problem with 9k jumbo clusters

I would be grateful if you could make patch. 05.12.2014 00:49, Jack Vogel пишет: I had wanted to remove the larger cluster sizes from the driver a while back, but for reasons I don't remember that code change didn't happen. The new 40G ixl driver does this, it only uses standard clusters for an

Re: problem with 9k jumbo clusters

I had wanted to remove the larger cluster sizes from the driver a while back, but for reasons I don't remember that code change didn't happen. The new 40G ixl driver does this, it only uses standard clusters for anything under 2K, and above that everything uses 4K. I would be curious to see if thi

Re: problem with 9k jumbo clusters

On 04.12.2014 13:50, Yuriy Tabolin wrote: Hi All. I have a server with two Intel 10G NIC. OS FreeBSD 10.1-Release amd64. Server works like NFS, samba-server and iSCSI target. Both NICs aggregated into lagg device and set MTU 9014 to them. There are some tuning sysctl.conf: kern.maxfiles=62896

Re: Problem with ipfw table add 0.0.0.0/8

Hi all, Already exists MFC available to fix this problem in 10-STABLE? # ipfw table 99 add 0.0.0.0/8 # ipfw table 99 list ::/8 0 Cheers, Gondim Em 17/05/2014 20:37, Marcelo Gondim escreveu: Em 17/05/14 20:28, Marcelo Gondim escreveu: Em 17/05/14 10:44, Alexander V. Chernikov escreveu: On 13

Re: Problem with ipfw table add 0.0.0.0/8

Em 17/05/14 12:23, Alexander V. Chernikov escreveu: On 17.05.2014 19:14, Andreas Nilsson wrote: On Sat, May 17, 2014 at 3:44 PM, Alexander V. Chernikov mailto:melif...@freebsd.org>> wrote: On 13.05.2014 16:05, Dennis Yusupoff wrote: I think that universal table for all kind of

Re: problem of netmap running on PowerPC platform board

On Sunday, June 1, 2014, dongshan wrote: > Hi, > > > > very good work you have done, thank you for sharing the source code of > netmap. > > > > These days I am trying to test netmap performance on PowerPC 32 bit board, > followed the guide, I rebuilt the kernel and netmap modules, then I tested >

Re: Problem: no locking around IPv6 prefix structures in prelist_remove

OK, thanks. -- Steve Read On 26.05.2014 11:24, Bjoern A. Zeeb wrote: On 26 May 2014, at 09:11 , Steve Read wrote: I have recently encountered an interesting double-free crash in prelist_remove() (management of IPv6 prefixes used by interface addresses) using a modified version of 9.2. We'

Re: Problem: no locking around IPv6 prefix structures in prelist_remove

On 26 May 2014, at 09:11 , Steve Read wrote: > I have recently encountered an interesting double-free crash in > prelist_remove() (management of IPv6 prefixes used by interface addresses) > using a modified version of 9.2. We've seen this once. > > It appears that two userland threads tried

Re: Problem with ipfw table add 0.0.0.0/8

On 19.05.2014 17:12, bycn82 wrote: On 5/19/14 21:00, Alexander V. Chernikov wrote: On 19.05.2014 11:51, Bill Yuan wrote: Hi Alex, Hello Bill! You guys are chatting here! I agree with you, the table is the place should be enhanced, and I am working in this way as described below 1. Support

Re: Problem with ipfw table add 0.0.0.0/8

On 5/19/14 21:00, Alexander V. Chernikov wrote: On 19.05.2014 11:51, Bill Yuan wrote: Hi Alex, Hello Bill! You guys are chatting here! I agree with you, the table is the place should be enhanced, and I am working in this way as described below 1. Support more types. ip : cidr ipv4 : sa

Re: Problem with ipfw table add 0.0.0.0/8

On 19.05.2014 11:51, Bill Yuan wrote: Hi Alex, Hello Bill! You guys are chatting here! I agree with you, the table is the place should be enhanced, and I am working in this way as described below 1. Support more types. ip : cidr ipv4 : same as ip ipv6 : ip addr v6 mac : mac address if

Re: Problem with ipfw table add 0.0.0.0/8

Hi Alex, You guys are chatting here! I agree with you, the table is the place should be enhanced, and I am working in this way as described below 1. Support more types. ip : cidr ipv4 : same as ip ipv6 : ip addr v6 mac : mac address iface : interface name interface : same as iface por

Re: Problem with ipfw table add 0.0.0.0/8

> On May 18, 2014, at 0:12, Julian Elischer wrote: >> 2) Table type/name can be specified explicitly via one of the following >> commands: >> * ipfw table 1 create [type ] [name "table_name"] > type "ports" would be nice but tricky to do right. That . . . would be a great addition and have m

Re: Problem with ipfw table add 0.0.0.0/8

On 5/17/14, 9:44 PM, Alexander V. Chernikov wrote: On 13.05.2014 16:05, Dennis Yusupoff wrote: I think that universal table for all kind of data (ipv4, ipv6, ports, etc) is a bad idea by design. At least unless you haven't any ability to It is not always "universal" in kernel. Actually, differ

Re: Problem with ipfw table add 0.0.0.0/8

Em 17/05/14 20:28, Marcelo Gondim escreveu: Em 17/05/14 10:44, Alexander V. Chernikov escreveu: On 13.05.2014 16:05, Dennis Yusupoff wrote: I think that universal table for all kind of data (ipv4, ipv6, ports, etc) is a bad idea by design. At least unless you haven't any ability to It is not

Re: Problem with ipfw table add 0.0.0.0/8

Em 17/05/14 10:44, Alexander V. Chernikov escreveu: On 13.05.2014 16:05, Dennis Yusupoff wrote: I think that universal table for all kind of data (ipv4, ipv6, ports, etc) is a bad idea by design. At least unless you haven't any ability to It is not always "universal" in kernel. Actually, differ

Re: Problem with ipfw table add 0.0.0.0/8

On 17.05.2014 23:57, Barney Wolff wrote: On Sat, May 17, 2014 at 05:44:37PM +0400, Alexander V. Chernikov wrote: On 13.05.2014 16:05, Dennis Yusupoff wrote: I think that universal table for all kind of data (ipv4, ipv6, ports, etc) is a bad idea by design. At least unless you haven't any abilit

Re: Problem with ipfw table add 0.0.0.0/8

On Sat, May 17, 2014 at 05:44:37PM +0400, Alexander V. Chernikov wrote: > On 13.05.2014 16:05, Dennis Yusupoff wrote: > > I think that universal table for all kind of data (ipv4, ipv6, ports, > > etc) is a bad idea by design. At least unless you haven't any ability to > It is not always "universal"

Re: Problem with ipfw table add 0.0.0.0/8

On 17.05.2014 19:14, Andreas Nilsson wrote: On Sat, May 17, 2014 at 3:44 PM, Alexander V. Chernikov mailto:melif...@freebsd.org>> wrote: On 13.05.2014 16:05, Dennis Yusupoff wrote: I think that universal table for all kind of data (ipv4, ipv6, ports, etc) is a b

Re: Problem with ipfw table add 0.0.0.0/8

On Sat, May 17, 2014 at 3:44 PM, Alexander V. Chernikov < melif...@freebsd.org> wrote: > On 13.05.2014 16:05, Dennis Yusupoff wrote: > >> I think that universal table for all kind of data (ipv4, ipv6, ports, >> etc) is a bad idea by design. At least unless you haven't any ability to >> > It is not

Re: Problem with ipfw table add 0.0.0.0/8

On 13.05.2014 16:05, Dennis Yusupoff wrote: I think that universal table for all kind of data (ipv4, ipv6, ports, etc) is a bad idea by design. At least unless you haven't any ability to It is not always "universal" in kernel. Actually, different radix tables are used to store both IPv4 and IPv6

Re: Problem with ipfw table add 0.0.0.0/8

I think that universal table for all kind of data (ipv4, ipv6, ports, etc) is a bad idea by design. At least unless you haven't any ability to specify address family on add, to avoid attempts to guess what user meant. Something like "ipfw table X add DEEF.DE ipv6". 13.05.2014 14:32, Alexander V.

Re: Problem with ipfw table add 0.0.0.0/8

On 13.05.2014 13:46, Dennis Yusupoff wrote: May be this will help? See answer on http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/189471 I'll try to fix it within a few days. The problem itself happens due to the fact that every CIDR table address is packed into IPv6 address and IPv4 ones are en

Re: Problem with ipfw table add 0.0.0.0/8

May be this will help? See answer on http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/189471 12.05.2014 22:21, Marcelo Gondim пишет: > Hi Jason, > > Same problem. > > Em 12/05/14 15:02, Jason Hellenthal escreveu: >> Cute. Same this happen when there are paren around the quad ? >> > -- Jason Hellenth

Re: Problem with ipfw table add 0.0.0.0/8

Hi Jason, Same problem. Em 12/05/14 15:02, Jason Hellenthal escreveu: Cute. Same this happen when there are paren around the quad ? -- Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN On May 12, 2014, at 13:43, Marcelo Gondim wrote: Hi all, Today I discovered a likely problem: # ipfw t

Re: Problem with ipfw table add 0.0.0.0/8

Cute. Same this happen when there are paren around the quad ? -- Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On May 12, 2014, at 13:43, Marcelo Gondim wrote: > > Hi all, > > Today I discovered a likely problem: > > # ipfw table 99 add 0.0.0.0/8 > > # ipfw table 99 list > ::/8 0 >

Re: Problem with removing mac address from arptable on 10-stable

Em 07/05/14 23:05, Alan Somers escreveu: On Wed, May 7, 2014 at 5:43 PM, Marcelo Gondim wrote: Em 07/05/14 15:57, Marcelo Gondim escreveu: Em 07/05/14 15:18, Alan Somers escreveu: On Wed, May 7, 2014 at 9:47 AM, Marcelo Gondim wrote: Hi all, I'm having this problemon my FreeBSD 10-STABLE:

Re: Problem with removing mac address from arptable on 10-stable

On Wed, May 7, 2014 at 5:43 PM, Marcelo Gondim wrote: > Em 07/05/14 15:57, Marcelo Gondim escreveu: > >> Em 07/05/14 15:18, Alan Somers escreveu: >>> >>> On Wed, May 7, 2014 at 9:47 AM, Marcelo Gondim >>> wrote: Hi all, I'm having this problemon my FreeBSD 10-STABLE:

Re: Problem with removing mac address from arptable on 10-stable

Em 07/05/14 15:57, Marcelo Gondim escreveu: Em 07/05/14 15:18, Alan Somers escreveu: On Wed, May 7, 2014 at 9:47 AM, Marcelo Gondim wrote: Hi all, I'm having this problemon my FreeBSD 10-STABLE: (root@rt01)[~]# arp -an|grep 187.xxx.216.252 ? (187.xxx.216.252) at 5c:e0:f6:00:11:29 on vlan4 pe

Re: Problem with removing mac address from arptable on 10-stable

Em 07/05/14 15:18, Alan Somers escreveu: On Wed, May 7, 2014 at 9:47 AM, Marcelo Gondim wrote: Hi all, I'm having this problemon my FreeBSD 10-STABLE: (root@rt01)[~]# arp -an|grep 187.xxx.216.252 ? (187.xxx.216.252) at 5c:e0:f6:00:11:29 on vlan4 permanent [vlan] (root@rt01)[~]# arp -d 187.xx

Re: Problem with removing mac address from arptable on 10-stable

On Wed, May 7, 2014 at 9:47 AM, Marcelo Gondim wrote: > Hi all, > > I'm having this problemon my FreeBSD 10-STABLE: > > (root@rt01)[~]# arp -an|grep 187.xxx.216.252 > ? (187.xxx.216.252) at 5c:e0:f6:00:11:29 on vlan4 permanent [vlan] > > (root@rt01)[~]# arp -d 187.xxx.216.252 > delete: cannot loca

Re: Problem with Lenovo SL500

Wow. What a rookie mistake. :( 'ifconfig re0 up' brought it right up. I'll add that line to rc.conf as 'ifconfig_re0="UP"' Thanks, Kurt On Mon, Oct 7, 2013 at 5:33 PM, Yonghyeon PYUN wrote: > On Mon, Oct 07, 2013 at 03:14:58PM -0700, Kurt Buff wrote: >> All, >> >> This machine has for its wi

Re: Problem with Lenovo SL500

On Mon, Oct 07, 2013 at 03:14:58PM -0700, Kurt Buff wrote: > All, > > This machine has for its wired port a RealTek unit: > > re0: port > 0xe800-0xe8ff mem 0xfcfff000-0xfcff,0xfcfe-0xfcfe irq 19 > at device 0.0 on pci12 > re0: Using 1 MSI-X message > re0: ASPM disabled > re0: Chip re

Re: Problem with fwip(4) and limited size ll_addr in the struct llentry

On 01.07.2013 16:26, Vijay Singh wrote: > If you enable OFED, then the llentry size is expanded to store IB addresses > as well. Code should be in 9.x. Yes, but this isn't solution. -- WBR, Andrey V. Elsukov ___ freebsd-net@freebsd.org mailing list htt

Re: Problem with fwip(4) and limited size ll_addr in the struct llentry

If you enable OFED, then the llentry size is expanded to store IB addresses as well. Code should be in 9.x. -vijay On Mon, Jul 1, 2013 at 4:49 PM, Andrey V. Elsukov wrote: > Hi, > > In the kern/176596 described the easy repeatable panic. > I found that it occurs, because struct llentry by defa

Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

On Tue, 18 Sep 2012, David DeSimone wrote: Daniel Eischen wrote: My rc.conf is something like this: # # For now, force ath0 to use the same MAC address as xl0. # This works around a bug where lagg is unable to set the # MAC address of the underlying wlan0 interface. # ifconfig_ath0="ether 01

Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

Daniel Eischen wrote: > > My rc.conf is something like this: > > # > # For now, force ath0 to use the same MAC address as xl0. > # This works around a bug where lagg is unable to set the > # MAC address of the underlying wlan0 interface. > # > ifconfig_ath0="ether 01:02:03:04:05:06" > wlans_ath0=

Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

On 09/12/2012 10:51 PM, Freddie Cash wrote: On Wed, Sep 12, 2012 at 1:48 PM, Jack Vogel wrote: On Wed, Sep 12, 2012 at 12:40 PM, Freddie Cash wrote: Thanks for checking. I've used lagg(4) with igb, just not on 9.x. You're right, it seems to be pointing to the igb(4) driver in 9.x compared t

Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

> > igb+lagg worked for us on 8.3. Haven't tried it since moving to 9.0 > > and 9-STABLE on those three boxes. > > > > igb+lagg doesn't work for him on 9.0. Although, I don't recall if > > non-LACP options were tried earlier in this thread, or if it's just > > the LACP mode that's failing. If o

Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

On Wed, Sep 12, 2012 at 1:51 PM, Freddie Cash wrote: > On Wed, Sep 12, 2012 at 1:48 PM, Jack Vogel wrote: > > On Wed, Sep 12, 2012 at 12:40 PM, Freddie Cash > wrote: > >> Thanks for checking. I've used lagg(4) with igb, just not on 9.x. > >> > >> You're right, it seems to be pointing to the ig

Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

On Wed, Sep 12, 2012 at 1:48 PM, Jack Vogel wrote: > On Wed, Sep 12, 2012 at 12:40 PM, Freddie Cash wrote: >> Thanks for checking. I've used lagg(4) with igb, just not on 9.x. >> >> You're right, it seems to be pointing to the igb(4) driver in 9.x >> compared to < 9.0. >> > How do you determine

Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

On Wed, Sep 12, 2012 at 12:40 PM, Freddie Cash wrote: > On Wed, Sep 12, 2012 at 12:22 PM, Giulio Ferro > wrote: > > On 09/11/2012 11:34 PM, Freddie Cash wrote: > >> > >> On Sep 11, 2012 2:12 PM, "Giulio Ferro" >> > wrote: > >> > > >> > Well, there definitely seems

Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

On Wed, Sep 12, 2012 at 12:22 PM, Giulio Ferro wrote: > On 09/11/2012 11:34 PM, Freddie Cash wrote: >> >> On Sep 11, 2012 2:12 PM, "Giulio Ferro" > > wrote: >> > >> > Well, there definitely seems to be a problem with igb and lagg. >> > >> > igb alone works as it sh

Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

On 09/11/2012 11:34 PM, Freddie Cash wrote: On Sep 11, 2012 2:12 PM, "Giulio Ferro" mailto:au...@zirakzigil.org>> wrote: > > Well, there definitely seems to be a problem with igb and lagg. > > igb alone works as it should, but doesn't seem to work properly in lagg. > > To be sure I started

Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

On 11/09/2012 22:03, Giulio Ferro wrote: > Well, there definitely seems to be a problem with igb and lagg. > > igb alone works as it should, but doesn't seem to work properly in lagg. > > To be sure I started from scratch from a 9.0 release with nothing but: > > /etc/rc.conf > -

Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

On Tue, 11 Sep 2012, Freddie Cash wrote: On Sep 11, 2012 2:12 PM, "Giulio Ferro" wrote: cloned_interfaces="lagg0" ifconfig_lagg0="laggproto lacp laggport igb1 laggport igb2 laggport igb3 192.168.x.x/24" sshd_enable="YES" --- This doesn't eve

Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

On Tue, 11 Sep 2012, Giulio Ferro wrote: Well, there definitely seems to be a problem with igb and lagg. igb alone works as it should, but doesn't seem to work properly in lagg. To be sure I started from scratch from a 9.0 release with nothing but: /etc/rc.conf ---

Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

On Sep 11, 2012 2:12 PM, "Giulio Ferro" wrote: > > Well, there definitely seems to be a problem with igb and lagg. > > igb alone works as it should, but doesn't seem to work properly in lagg. > > To be sure I started from scratch from a 9.0 release with nothing but: > > /etc/rc.conf >

Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

Well, there definitely seems to be a problem with igb and lagg. igb alone works as it should, but doesn't seem to work properly in lagg. To be sure I started from scratch from a 9.0 release with nothing but: /etc/rc.conf --- ifconfig_igb0="inet ..

Re: Problem with link aggregation + sshd

We've had similar problems with lagg at work, each lagg is made up of one igb and one em port, sometimes for no apparent reason they seem to stop passing through traffic. The easiest way we've found to get it working again is ifconfig down and up on one of the physical interfaces. This is on 8.1 O

Re: Problem with link aggregation + sshd

No idea anybody why this bug happens? Patches? On 08/29/2012 10:22 PM, Giulio Ferro wrote: On 08/28/2012 11:12 AM, Damien Fleuriot wrote: Hi Giulio, Just to clear things up: igb0: 192.168.9.60/24 lagg0: 192.168.12.21/24 Yes. Actually I notice now that the lagg0 address is different from

Re: Problem with link aggregation + sshd

On 08/28/2012 11:12 AM, Damien Fleuriot wrote: Hi Giulio, Just to clear things up: igb0: 192.168.9.60/24 lagg0: 192.168.12.21/24 Yes. Actually I notice now that the lagg0 address is different from what I wrote below in my rc.conf (192.168.12.7). I've just made many test with different confi

Re: Problem with link aggregation + sshd

Pete French wrote: > > Actually I went and looked out my old emails - Cisco 3750 switches > worked as a pair with LACP, Cisco 3560 ones didn't. Whatever the > difference is between those two, thats the difference between working > and not working :) Is that real stacking vs virtual stacking by any

Re: Problem with link aggregation + sshd

On Aug 29, 2012, at 1:18 PM, Harald Schmalzbauer wrote: > schrieb Pete French am 29.08.2012 11:38 (localtime): >>> Link aggregation can never work with two separate switches! LACP and >>> static trunking require both sides to bundle the same trunk. which is >>> impossible for two separate switc

Re: Problem with link aggregation + sshd

> Have you checked that Windows really did LACP in your case? Sounds like > it was no real hardware stack, so probably Windos just activated RSTP. > FreeBSD doesn't detect any LACP/RSTP configuration features, but windows > does with some NIC verndor's drivers. That is quite possible - I didnt set

Re: Problem with link aggregation + sshd

schrieb Harald Schmalzbauer am 29.08.2012 12:18 (localtime): > schrieb Pete French am 29.08.2012 11:38 (localtime): >>> Link aggregation can never work with two separate switches! LACP and >>> static trunking require both sides to bundle the same trunk. which is >>> impossible for two separate sw

Re: Problem with link aggregation + sshd

schrieb Pete French am 29.08.2012 11:38 (localtime): >> Link aggregation can never work with two separate switches! LACP and >> static trunking require both sides to bundle the same trunk. which is >> impossible for two separate switches. > These switches had a port where you could connect them to

Re: Problem with link aggregation + sshd

> Link aggregation can never work with two separate switches! LACP and > static trunking require both sides to bundle the same trunk. which is > impossible for two separate switches. These switches had a port where you could connect them together and then configure each to know about the other swi

Re: Problem adding more than 8 network adapters

Al 29/08/2012 11:02, En/na Peter Jeremy ha escrit: On 2012-Aug-28 11:44:44 +0200, Gustau Pérez i Querol wrote: I'm running FreeBSD 9.1 RC1/AMD64 with VirtualBox. The problem I'm facing is that I can't use more than 8 network adapters plugged to the virtual machine. ... I don't know if

Re: Problem adding more than 8 network adapters

On 2012-Aug-28 11:44:44 +0200, Gustau Pérez i Querol wrote: > I'm running FreeBSD 9.1 RC1/AMD64 with VirtualBox. The problem I'm >facing is that I can't use more than 8 network adapters plugged to the >virtual machine. ... >I don't know if it's a net@ problem or maybe it is a problem with

  1   2   3   4   5   >