[Bug 269908] CARP feature breaks the network
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269908 --- Comment #6 from franklin.s...@gmail.com --- There appears to be another race condition and could be similar to one of the earlier issues fixed. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191832 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269908] CARP feature breaks the network
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269908 --- Comment #5 from franklin.s...@gmail.com --- Created attachment 240550 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=240550=edit tcpdump files from Machine2 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269908] CARP feature breaks the network
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269908 --- Comment #4 from franklin.s...@gmail.com --- Created attachment 240549 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=240549=edit tcpdump files from Machine1 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269908] CARP feature breaks the network
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269908 --- Comment #3 from franklin.s...@gmail.com --- Details: Machine 1: Physical MAC: 00:50:56:a7:0f:7f IP Address: 10.10.4.17 Machine 2: Physical MAC: 00:50:56:a7:e3:41 IP Address: 10.10.4.18 CARP: Virtual MAC: 00:00:5e:00:01:01 Virtual IP: 10.10.4.19 Steps followed: 1. Configure CARP on Machine 1. ifconfig nic0 vhid 1 pass testing alias 10.10.4.19/28 advskew 10 This box becomes the MASTER 2. Configure CARP on Machine 2. ifconfig nic0 vhid 1 pass testing alias 10.10.4.19/28 advskew 20 This box becomes the BACKUP 3. Re-configure CARP on Machine 1, to trigger a failover. ifconfig nic0 vhid 1 pass testing alias 10.10.4.19/28 advskew 30 Since now the advskew value of Machine 1 is higher than the Machine 2's value, Machine 1 will become the BACKUP and Machine 2 will become the MASTER. Observation / Failure. At step 3, the moment Machine 2 becomes the MASTER, it makes the ARP announcement. To this announcement when the Machine 1, who is in BACKUP state, which is supposed to be quiet, responds with "Duplicate use of detected" GARP message. Interestingly at this point, the Source MAC address is the physical MAC address and the Source IP address is the Virtual IP address. Please find the attached tcpdump files captured from both the machines. Due to this error, the CISCO ACI endpoint table messed up and is routing traffic to the wrong device. -- You are receiving this mail because: You are the assignee for the bug.
Completing removal of ATM support
Prior to FreeBSD 12, I removed most ATM support, but left NgATM and ng_atmllc. The time is to remove them is almost certainly past. I aim to commit deprecation notices shortly and follow up with removal after a week or so. If you find they are useful (in production) on systems without support for ATM NICs, please speak up so we can discuss a different timeline. The proposed big removal commit for NgATM is: https://reviews.freebsd.org/D38879 ng_atmllc is removed in https://reviews.freebsd.org/D38880 Deprecations and a few cleanups are linked in the stack of commits. Thanks, Brooks
[Bug 269908] CARP feature breaks the network
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269908 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
Re: BPF to filter/mod ARP
> On 2. Mar 2023, at 18:20, Rodney W. Grimes
> wrote:
>
>>> On 2. Mar 2023, at 02:24, Rodney W. Grimes
>>> wrote:
>>>
Hi group,
Maybe someone can help me with this question - as I am usually only
looking at L4 and the top side of L3 ;)
In order to validate a peculiar switches behavior, I want to adjust some
fields in gracious arps sent out by an interface, after a new IP is
assigned or changed.
>>>
>>> Gracious or Gratuitous?
>>>
I believe BPF can effectively filter on arbitrary bit patterns and
modify packets on the fly.
>>>
>>> It can.
>>>
However, as ARP doesn't seem to be accessible in the ipfw
infrastructure, I was wondering how to go about setting up an BPF to
tweak (temporarily) some of these ARPs to validate how the switch will
behave.
>>>
>>> ipfw is IP firewall, a layer 3 function. Arp is a layer 2 protocol,
>>> so very hard to do much with it in ipfw, but perhaps the layer2
>>> keyword, and some use of mac-type can get it to match an arp
>>> packet. Arp is ethernet type 0x806.
>>>
>>> ipfw add 111 count log all from any to any layer2 mac-type arp
>>> That does seem to work
>>> ipfw -a list 111
>>> 001114 0 count log ip from any to any layer2 mac-type 0x0806
>>>
>>> Also normally ipfw does NOT pick packets up early enough to see
>>> them, to get the layer2 option to work you need:
>>> sysctl net.link.ether.ipfw=1 so that the filters at ether_demux
>>> get turned on.
>>>
>>> So perhaps use a divert rule and send them to a socket where
>>> a program can mangle them, and then return them to ipfw
>>> and hopefully the kernel does what you want after that...
>> I thought that you receive/send an IP packet on a divert socket, not
>> an ethernet frame. Am I wrong?
>
> That is unclear to me, technically it should just be a binary
> blob and the kernel and userland just have to agree as to
> what it is. Understand that ipfw originally only had IP layer
> functionality. The ability to muck with layer2 was added
> later, so I suspect the documentation about what is sent
> over the divert socket may be out of date. Simple enough
> to test though, just setup as I show above only change
> to:
> ipfw add 111 divert all from any to any layer2 mac-type arp
> and write a program to dump what you get on the divert socket.
> I suspect you get an ethernet frame.
>
> And finally divert(4) says: NAME: divert kernel packet diversion mechanism
> That says packet, so again, IMHO, it should be arbitrary to what layer.
> It also later says "Divert sockets are similar to raw IP sockets",
> I think similar is the key aspect here, they are not identical.
I can confirm that using
sudo sysctl net.link.ether.ipfw=1
sudo ipfw add 111 count log all from any to any layer2 mac-type arp
... wait some time and observe ARP traffic via tcpdump
sudo ipfw show
00111 22 0 count log logamount 5 ip from any to any layer2 mac-type
0x0806
65535 7892 849004 allow ip from any to any
So the rule is hit.
However, now doing
sudo ipfw delete 111
sudo ipfw add 111 divert 1234 all from any to any layer2 mac-type arp
... wait some time and observe ARP traffic via tcpdump
tuexen@head:~ % sudo ipfw show
00111 0 0 divert 1234 ip from any to any layer2 mac-type 0x0806
65535 10048 1000948 allow ip from any to any
So this time, rule 111 is not hit. I also ran
#include
#include
#include
#include
#include
#include
#define BUFFER_SIZE (1<<16)
#define PORT1234
int
main(void)
{
char buffer[BUFFER_SIZE];
struct sockaddr_in addr;
ssize_t n;
int fd;
if ((fd = socket(PF_DIVERT, SOCK_RAW, 0)) < 0) {
perror("socket()");
}
bzero(, sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_len = sizeof(struct sockaddr_in);
addr.sin_addr.s_addr = INADDR_ANY;
addr.sin_port= htons(PORT);
if (bind(fd, (struct sockaddr *), (socklen_t)sizeof(struct
sockaddr_in)) < 0) {
perror("bind()");
}
for (;;) {
n = recv(fd, buffer, sizeof(buffer), 0);
printf("Received %zd bytes.\n", n);
}
if (close(fd) < 0) {
perror("close()");
}
return (0);
}
but nothing was printed...
Best regards
Michael
>
>>
>> Best regards
>> Michael
>>>
(I need to validate, if there is some difference when the target
hardware address doesn't conform to RFC5227 - which states it SHOULD be
zero and is ignored on the receiving side; i have reasons to believe
that the switch needs either a target hardware address of
ff:ff:ff:ff:ff:ff or the local interface MAC, to properly update it's
entries.)
Thanks a lot!
Richard
>>>
>>> --
>>> Rod Grimes
>>> rgri...@freebsd.org
>>>
>>
>>
>>
>
> --
> Rod Grimes
[Bug 237477] kernel option PF_DEFAULT_TO_DROP breaks rdr rules with pass keyword.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237477 --- Comment #3 from Kristof Provost --- (In reply to p5B2EA84B3 from comment #2) When someone cares enough to fix it. My todo list is endless, and I don't consider this to be a priority. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 237477] kernel option PF_DEFAULT_TO_DROP breaks rdr rules with pass keyword.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237477 --- Comment #2 from p5b2ea8...@t-online.de --- Almost four (4) years later: When will this be fixed? -- You are receiving this mail because: You are the assignee for the bug.
Re: ECMP, DF-bit and ICMP "Fragmentation needed"
On Mon, 27 Feb 2023 at 13:57, Alexander Chernikov wrote: > > > > On 26 Feb 2023, at 12:07, Victor Gamov wrote: > > > > Hi All > > > > I have following scheme: > > - LAN segment 10.5.8.0/24 with router1 (10.5.8.1) and MTU=1500 > > - two hosts at LAN segment host21 (10.5.8.21) and host22 (10.5.8.22) > > - host21 and host22 has VIP=172.16.110.30 configured as LAN-interface > alias > > - host21 and host22 ha BGP peering with router1 and announce VIP to > router1 > > - hostX somewhere at intranet > > - ipsec-tunnel with MTU=1400 > > > > ECMP works fine and traffic from other segments to VIP is balanced > between host21+host22 by router1. > > > > The problem is: > > when host21 and/or host22 send large packet with DF-bit using VIP as > source then ipsec-router sends ICMP "Fragmentation needed" and then this > ICMP is _always_ sent to only host22 by router1. > > > > I think it may be hard or impossible to find proper VIP-owner to send > this ICMP. Is it possible to propagate such ICMP to all VIP-owners in > router1 routing-table? Or may some data from ICMP message be used to > properly calculate ECMP-hash to find a real VIP-owner which must receive > this ICMP? > Generally it’s pretty hard to do. The path may go through the multiple > routers which has it own hash calculation + seed to avoid the traffic > polarisation. Personally I’d suggest doing some sort of ICMP replication on > either the source node or the hosts. > Hi Alexander! Thanks for your reply. In my scheme router1 can replicate such ICMP to all VIP-owners. And only router1 knows about both host21+host22 peers -- for all other network devices this VIP is behind router1. -- CU, Victor Gamov
Re: BPF to filter/mod ARP
> > On 2. Mar 2023, at 02:24, Rodney W. Grimes > > wrote: > > > >> Hi group, > >> > >> Maybe someone can help me with this question - as I am usually only > >> looking at L4 and the top side of L3 ;) > >> > >> In order to validate a peculiar switches behavior, I want to adjust some > >> fields in gracious arps sent out by an interface, after a new IP is > >> assigned or changed. > > > > Gracious or Gratuitous? > > > >> > >> I believe BPF can effectively filter on arbitrary bit patterns and > >> modify packets on the fly. > > > > It can. > > > >> > >> However, as ARP doesn't seem to be accessible in the ipfw > >> infrastructure, I was wondering how to go about setting up an BPF to > >> tweak (temporarily) some of these ARPs to validate how the switch will > >> behave. > > > > ipfw is IP firewall, a layer 3 function. Arp is a layer 2 protocol, > > so very hard to do much with it in ipfw, but perhaps the layer2 > > keyword, and some use of mac-type can get it to match an arp > > packet. Arp is ethernet type 0x806. > > > > ipfw add 111 count log all from any to any layer2 mac-type arp > > That does seem to work > > ipfw -a list 111 > > 001114 0 count log ip from any to any layer2 mac-type 0x0806 > > > > Also normally ipfw does NOT pick packets up early enough to see > > them, to get the layer2 option to work you need: > > sysctl net.link.ether.ipfw=1 so that the filters at ether_demux > > get turned on. > > > > So perhaps use a divert rule and send them to a socket where > > a program can mangle them, and then return them to ipfw > > and hopefully the kernel does what you want after that... > I thought that you receive/send an IP packet on a divert socket, not > an ethernet frame. Am I wrong? That is unclear to me, technically it should just be a binary blob and the kernel and userland just have to agree as to what it is. Understand that ipfw originally only had IP layer functionality. The ability to muck with layer2 was added later, so I suspect the documentation about what is sent over the divert socket may be out of date. Simple enough to test though, just setup as I show above only change to: ipfw add 111 divert all from any to any layer2 mac-type arp and write a program to dump what you get on the divert socket. I suspect you get an ethernet frame. And finally divert(4) says: NAME: divert kernel packet diversion mechanism That says packet, so again, IMHO, it should be arbitrary to what layer. It also later says "Divert sockets are similar to raw IP sockets", I think similar is the key aspect here, they are not identical. > > Best regards > Michael > > > >> (I need to validate, if there is some difference when the target > >> hardware address doesn't conform to RFC5227 - which states it SHOULD be > >> zero and is ignored on the receiving side; i have reasons to believe > >> that the switch needs either a target hardware address of > >> ff:ff:ff:ff:ff:ff or the local interface MAC, to properly update it's > >> entries.) > >> > >> Thanks a lot! > >> > >> Richard > >> > > > > -- > > Rod Grimes > > rgri...@freebsd.org > > > > > -- Rod Grimes rgri...@freebsd.org
Re: mlx5en & tcpdump -Q
El 1/3/23 a las 22:08, Scheffenegger, Richard escribió: Does anyone know if this functionality is available already, or any plans to implement this for mlx5en ? It works here, tried -Q in, out and inout, on '13.2-BETA3 releng/13.2-d0e8ce556' [] $ dmesg | grep Mell mlx5: Mellanox Core driver 3.7.1 (November 2021) $ pciconf -l | grep core0 mlx5_core0@pci0:9:0:0: class=0x02 rev=0x00 hdr=0x00 vendor=0x15b3 device=0x1017 subvendor=0x15b3 subdevice=0x0020 [] Regards, Raúl
[Bug 268246] crash and panic using pfsync on 13.1-RELEASE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246 Kristof Provost changed: What|Removed |Added Status|In Progress |Closed Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.
[Bug 268246] crash and panic using pfsync on 13.1-RELEASE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246 --- Comment #91 from commit-h...@freebsd.org --- A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3dec62eded04eaf431bf0948f4e6412deede87d5 commit 3dec62eded04eaf431bf0948f4e6412deede87d5 Author: Kristof Provost AuthorDate: 2023-02-14 06:11:38 + Commit: Kristof Provost CommitDate: 2023-03-02 16:21:59 + pfsync: support deferring IPv6 packets When we send out a deferred packet we must make sure to call ip6_output() for IPv6 packets. If not we might end up attempting to ip_fragment() an IPv6 packet, which could lead to us reading outside of the mbuf. PR: 268246 Reviewed by:melifaro, zlei MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D38586 (cherry picked from commit 9a1cab6d79b7286e5f650f57ed95625e6ddb8e4b) sys/netpfil/pf/if_pfsync.c | 71 -- 1 file changed, 56 insertions(+), 15 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 268246] crash and panic using pfsync on 13.1-RELEASE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268246 --- Comment #90 from commit-h...@freebsd.org --- A commit in branch stable/12 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=dacffdd4dc511ae73e8fd3eb19f9efe4ecb26ba1 commit dacffdd4dc511ae73e8fd3eb19f9efe4ecb26ba1 Author: Kristof Provost AuthorDate: 2023-02-14 06:11:38 + Commit: Kristof Provost CommitDate: 2023-03-02 11:15:28 + pfsync: support deferring IPv6 packets When we send out a deferred packet we must make sure to call ip6_output() for IPv6 packets. If not we might end up attempting to ip_fragment() an IPv6 packet, which could lead to us reading outside of the mbuf. PR: 268246 Reviewed by:melifaro, zlei MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D38586 (cherry picked from commit 9a1cab6d79b7286e5f650f57ed95625e6ddb8e4b) sys/netpfil/pf/if_pfsync.c | 71 -- 1 file changed, 56 insertions(+), 15 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 257709] netinet6: Set net.inet6.icmp6.nodeinfo default to 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257709 --- Comment #5 from Pawel Biernacki --- Making it into 13.2-R is out of question because it: 1) changes default in minor release 2) it's too late as the RC1 is behind the corner 14.0 is a good target release for this change. It'd require RELNOTES entry though. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
Re: BPF to filter/mod ARP
> On 2. Mar 2023, at 02:24, Rodney W. Grimes > wrote: > >> Hi group, >> >> Maybe someone can help me with this question - as I am usually only >> looking at L4 and the top side of L3 ;) >> >> In order to validate a peculiar switches behavior, I want to adjust some >> fields in gracious arps sent out by an interface, after a new IP is >> assigned or changed. > > Gracious or Gratuitous? > >> >> I believe BPF can effectively filter on arbitrary bit patterns and >> modify packets on the fly. > > It can. > >> >> However, as ARP doesn't seem to be accessible in the ipfw >> infrastructure, I was wondering how to go about setting up an BPF to >> tweak (temporarily) some of these ARPs to validate how the switch will >> behave. > > ipfw is IP firewall, a layer 3 function. Arp is a layer 2 protocol, > so very hard to do much with it in ipfw, but perhaps the layer2 > keyword, and some use of mac-type can get it to match an arp > packet. Arp is ethernet type 0x806. > > ipfw add 111 count log all from any to any layer2 mac-type arp > That does seem to work > ipfw -a list 111 > 001114 0 count log ip from any to any layer2 mac-type 0x0806 > > Also normally ipfw does NOT pick packets up early enough to see > them, to get the layer2 option to work you need: > sysctl net.link.ether.ipfw=1 so that the filters at ether_demux > get turned on. > > So perhaps use a divert rule and send them to a socket where > a program can mangle them, and then return them to ipfw > and hopefully the kernel does what you want after that... I thought that you receive/send an IP packet on a divert socket, not an ethernet frame. Am I wrong? Best regards Michael > >> (I need to validate, if there is some difference when the target >> hardware address doesn't conform to RFC5227 - which states it SHOULD be >> zero and is ignored on the receiving side; i have reasons to believe >> that the switch needs either a target hardware address of >> ff:ff:ff:ff:ff:ff or the local interface MAC, to properly update it's >> entries.) >> >> Thanks a lot! >> >> Richard >> > > -- > Rod Grimes rgri...@freebsd.org >
[Bug 257709] netinet6: Set net.inet6.icmp6.nodeinfo default to 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257709 --- Comment #4 from Zhenlei Huang --- RFC 4620 is still experimental then I thinks it is safe to set `net.inet6.icmp6.nodeinfo` default to 0 . -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
