|based routing without pf or |routing without pf or ipfw
|ipfw|
Keywords||feature
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183407
Zhenlei Huang changed:
What|Removed |Added
Resolution|--- |Overcome By Events
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282982
--- Comment #2 from Quentin Thébault ---
Indeed.
Following the workaround you proposed in comment 7 of that bug
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280132#c7), the jail can
ping outside with no issue.
But the host is still
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282982
Zhenlei Huang changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282982
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255705
Mark Linimon changed:
What|Removed |Added
Assignee|n...@freebsd.org |a...@freebsd.org
Statu
)
status: active
nd6 options=23
root@vb-14-1:~ # route add default 192.168.77.2 -fib 1
add net default: gateway 192.168.77.2 fib 1
root@vb-14-1:~ # netstat -rnF 1
Routing tables (fib: 1)
Internet:
DestinationGatewayFlags Netif Expire
default
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282744
--- Comment #3 from Marek Zarychta ---
If interface em2 should or could be moved to fib 1, then a similar effect could
still be achievable with the following:
# ifconfig em2 inet 192.168.77.104/24 fib 1
# route add default 192.168.77.2 -fi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282744
Marek Zarychta changed:
What|Removed |Added
CC||zarych...@plan-b.pwste.edu.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282744
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
--- Comment #1 from Damjan Jovanovic ---
Doesn't support for multiple FIBs give you a way to route by source? For
example:
# Increase the number of routing tables (FIBs) to 2:
# sysctl net.fibs=2
# setfib 1 route add 192.168.0.0 -interface wlan0
# setfib 1 route add default 192.168.0.1
Then, f
] [patch] Routing |[rc.d] Routing restart
|restart returns non-zero|returns non-zero exitcode
|exitcode in case of no |in case of no extra routing
|extra routing parameter or |parameter or missing
|missing atm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258623
Mark Linimon changed:
What|Removed |Added
CC||bugmeis...@freebsd.org
t; fd00:a:a:a::254 link#4UH
> ipsec0
> fd00:b:b:b::250 link#3 UHS
> lo0
That has been a bit premature, because now, the IPv4 routing has been lost.
Because when having two ide
Marek Zarychta wrote:
> W dniu 15.01.2024 o 15:35, Michael Grimm pisze:
>> route_tunnel0="fd00:a:a:a::/64 fd00:a:a:a::254"
> Please try:
> route_tunnel0="-6 -net fd00:a:a:a::/64 fd00:a:a:a::254"
Bingo! That did the trick:
Internet6:
Destination Gateway
W dniu 15.01.2024 o 15:35, Michael Grimm pisze:
route_tunnel0="fd00:a:a:a::/64 fd00:a:a:a::254"
Please try:
route_tunnel0="-6 -net fd00:a:a:a::/64 fd00:a:a:a::254"
--
Marek Zarychta
Netif Expire
fd00:a:a:a::254 link#4UH
ipsec0
fd00:b:b:b::250 link#3 UHS
lo0
Thus, the IPv6 routing is still missing (error: "route: bad address:
fd00:a:a:a::").
Thank you very m
On 15.01.2024 16:09, Michael Grimm wrote:
Hi,
I do use an ipsec tunnel for routing local IPv4 traffic for years now
(/etc/rc.conf):
cloned_interfaces="ipsec0"
static_routes="tunnel0"
create_args_ipsec0="reqid 104"
ifconfig_ipsec0=&quo
Hi,
I do use an ipsec tunnel for routing local IPv4 traffic for years now
(/etc/rc.conf):
cloned_interfaces="ipsec0"
static_routes="tunnel0"
create_args_ipsec0="reqid 104"
ifconfig_ipsec0="inet 10.2.2.250 10.1.1.254 tunnel 1.2.3.4 10.20.30.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=172532
Graham Perrin changed:
What|Removed |Added
Priority|Normal |---
--
You are receiving this mai
Keywords|patch |
Summary|[rc] [patch] service|service routing restart
|routing restart always |always fails
|fails |
Assignee|b...@freebsd.org|n...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183407
Graham Perrin changed:
What|Removed |Added
Keywords||patch
--- Comment #9 from Graham P
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233283
Bjoern A. Zeeb changed:
What|Removed |Added
Assignee|n...@freebsd.org |melif...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233283
Sam Frenick changed:
What|Removed |Added
CC||jaunts_buys...@icloud.com
--- Commen
rtin Stiemerling
>>> wrote:
>>>> I am looking for a mechanism to get a notification from the OS when, for
>>>> instance, an IP address on an interface or a routing entry is being
>>>> changed.
>>>
>>> Assuming you are using the bas
for
>>> instance, an IP address on an interface or a routing entry is being
>>> changed.
>>
>> Assuming you are using the base OS version of dhclient, you could use
>> /etc/dhclient-exit-hooks, which is a shellscript documented in
>> dhclient-script(8).
Hi,
> Am 31.08.2022 um 11:00 schrieb Peter Jeremy :
>
> On 2022-Aug-31 10:18:44 +0200, Martin Stiemerling wrote:
>> I am looking for a mechanism to get a notification from the OS when, for
>> instance, an IP address on an interface or a routing entry is being changed.
On 2022-Aug-31 10:18:44 +0200, Martin Stiemerling wrote:
>I am looking for a mechanism to get a notification from the OS when, for
>instance, an IP address on an interface or a routing entry is being changed.
Assuming you are using the base OS version of dhclient, you could use
/etc/dh
Hi,
I am looking for a mechanism to get a notification from the OS when, for
instance, an IP address on an interface or a routing entry is being changed.
I came across devd, but this is AFAIK only for IFUP/IFDOWN/IFATTACH events but
not beyond.
Thanks in advance,
Martin
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258528
--- Comment #2 from Konrad ---
I haven't experienced it more times.
Only one time did something go wrong
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258528
--- Comment #1 from Alexander V. Chernikov ---
Sorry for the belated reply. Were there any other similar crashes after this
one?
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255705
--- Comment #7 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=17c9c2049004038ed6f2dc23a64cb9f74411ec52
commit 17c9c2049004038ed6f2dc23a64cb9f74411ec52
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255705
--- Comment #6 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=7d98cc096b995ca3bfd85277ed009b0f872c3e1b
commit 7d98cc096b995ca3bfd85277ed009b0f872c3e1b
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255705
Peter Much changed:
What|Removed |Added
CC||p...@citylink.dinoex.sub.org
--- Comm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255705
Andrey V. Elsukov changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
09.0.64.169.80 > 192.168.1.50.51537: tcp 0
> 13:04:28.982191 IP 192.168.1.50.51537 > 109.0.64.169.80: tcp 0
> 13:04:31.948459 IP 192.168.1.50.51537 > 109.0.64.169.80: tcp 449
> 13:04:36.982090 IP 109.0.64.169.80 > 192.168.1.50.51537: tcp 0
> 13:04:36.982207 IP 192.168.1.50.5
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258623
--- Comment #9 from Konrad ---
Currently I am not able to boot 14-CURRENT, but I did it in June. The results
were similar
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258623
--- Comment #8 from Kubilay Kocak ---
(In reply to Konrad from comment #7)
Are you able to boot a 14-CURRENT snapshot to attempt reproduction on that
version?
--
You are receiving this mail because:
You are the assignee for the bug.
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258623
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258623
--- Comment #7 from Konrad ---
I think is not related with cxgbe directly, I have achieved similar results on
mlx5en(4)
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258623
--- Comment #6 from Konrad ---
Created attachment 228048
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=228048&action=edit
customer kernel configuration
# uname -a
FreeBSD Thunder 13.0-STABLE FreeBSD 13.0-STABLE #5 stable/13-6d8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258623
--- Comment #5 from Konrad ---
Created attachment 228047
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=228047&action=edit
/boot/loader.conf
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258623
--- Comment #4 from Konrad ---
Created attachment 228046
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=228046&action=edit
dmesg.boot
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258623
--- Comment #3 from Kubilay Kocak ---
Created attachment 228045
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=228045&action=edit
single_16Mpps.svg
Attach flamegraph (#2) from comment 0
--
You are receiving this mail because:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258623
--- Comment #2 from Kubilay Kocak ---
Created attachment 228044
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=228044&action=edit
lagg0_16Mpps.svg
Attach flamegraph from comment 0
--
You are receiving this mail because:
You ar
||eeBSD.org), mfc-stable13?
CC||j...@freebsd.org,
||n...@freebsd.org
Summary|[routing] peformance - 2|cxgbe(4): Slow routing
|numa domains vs signale |performance: 2
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258623
Bug ID: 258623
Summary: [routing] peformance - 2 numa domains vs signale numa
domain
Product: Base System
Version: 13.0-STABLE
Hardware: amd64
OS
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258528
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258528
Bug ID: 258528
Summary: [fib_algo][routing] crash after switch algo
Product: Base System
Version: 13.0-STABLE
Hardware: Any
OS: Any
Status: New
Hello,
As I said on my previous message, with the configuration below, routing traffic
via ue0 (mobile data) works.
Once I delete ue0 routes (so using default routes for everything), I use the
adsl line and traffic from the jail do not works anymore. But ...
Le Thu, 9 Sep 2021 20:02:18 +0200
Hello,
Cross posting because I am not sure where I am wrong here.
I have a setup with some jails configured to use a dedicated virtual interface
and with alternate routing tables/fibs. This is running on FreeBSD 11.4 amd64.
The host has dual wan configuration. One adsl line via a router and one
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257499
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256882
Olivier Cochard changed:
What|Removed |Added
Assignee|n...@freebsd.org |melif...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256882
--- Comment #1 from Konrad ---
I also notice that before crash server route (affects several random prefixes)
to wrong interfaces, for example:
# route -vv -n get 8.8.8.8
RTA_DST: inet 8.8.8.8; RTA_IFP: link ; RTM_GET: Report Metrics: len
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256882
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
Keywords
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255705
Mark Linimon changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
Summary|Is 'ipfw fwd' completely |Routing does not honor
|broken now? |mbuf_tag
||PACKET_TAG_IPFORWARD
||correctly
--- Comment #4 from Lutz Donnerhacke ---
Fi
ng. AMD may have a variety of nice parts for this
> > application, although I don?t have any personal experience with routing on
> > such hardware.
>
> Thanks -- I searched for a pair of boxes in my infra with those
> specs, found them:
>
> Intel(R) Xeon(R) CPU E5-
f nice parts for this
> application, although I don’t have any personal experience with routing on
> such hardware.
Thanks -- I searched for a pair of boxes in my infra with those
specs, found them:
Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz
82599ES 10-Gigabit SFI/SFP+ Network Connection
a
application, although I don’t have any personal experience with routing on
such hardware. Probably equally important is the NICs, I’d go with Chelsio
T5 or Mellanox ConnectX 4 Lx or greater.
On Sat, Mar 27, 2021 at 1:08 PM Kurt Jaeger wrote:
> Hi!
>
> We currently operate routers (FreeBSD 1
Hi!
We currently operate routers (FreeBSD 12.x, frr7) with
Xeon(R) CPU E3-1230 v6 @ 3.50GHz CPUs and 10g links.
They get to around 5-6 gbit/s throughput.
What kind of hardware can you all suggest, if we stay
in the generic PC area, to improve the routing throughput ?
--
p...@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"
On Fri, Feb 12, 2021 at 4:14 PM Alexander V. Chernikov
wrote:
> The slightly different approach here: https://reviews.freebsd.org/D28629
> We indeed are running under epoch, so that prevents _immediate_ ifa
> destruction.
> However, we still can run into the situation when
> * in thread 1 we drop
___
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"
Thanks! For reference, I tried this patch and it did resolve my leak:
https://github.com/rysto32/freebsd/commit/73caa71c351c072d673d477972fda2aeb369eb3d
I haven't exhaustively tested the routing code, though, so I can't say
for certain that the assert will always be true, nor am I ce
at -m while I repeat this, I see
it increasing by one every time. Poking around with dtrace confirms
that it's an AF_INET address that's getting leaked. Looking at the
calls to ifa_ref and ifa_free, the routing code looks suspicious. I
see that the route add path takes one referen
___
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"
y imposed on me... So now I don't have this need
> anymore.
Ok. Glad you were able to solve your problem, though obviously not the way you
wanted to.
Just for the archives, this style of routing should work fine in FreeBSD.
> On Tue, 15 Sep 2020 12:10:52 -0700
> John-Mark Gurney
> > root@opnsense2:~ # ping $IP_NOT_IN_SUBNET
> > PING $IP_NOT_IN_SUBNET ($IP_NOT_IN_SUBNET): 56 data bytes
> > 36 bytes from $UPSTREAM_GW: Redirect Host(New addr: $PUBLIC_IP_OF_BCE0).
> >
> > Which doesn't seem appropriate at all wrt the routing table...
> >
F_BCE0 UHSbce0
>
>
> Which seem somehow appropriate, so I try to ping $IP_NOT_IN_SUBNET and I get:
>
> root@opnsense2:~ # ping $IP_NOT_IN_SUBNET
> PING $IP_NOT_IN_SUBNET ($IP_NOT_IN_SUBNET): 56 data bytes
> 36 bytes from $UPSTREAM_GW: Redirect Host(New addr: $PUBLIC_I
h seem somehow appropriate, so I try to ping $IP_NOT_IN_SUBNET and I get:
>
> root@opnsense2:~ # ping $IP_NOT_IN_SUBNET
> PING $IP_NOT_IN_SUBNET ($IP_NOT_IN_SUBNET): 56 data bytes
> 36 bytes from $UPSTREAM_GW: Redirect Host(New addr: $PUBLIC_IP_OF_BCE0).
>
> Which doesn't seem
OT_IN_SUBNET
PING $IP_NOT_IN_SUBNET ($IP_NOT_IN_SUBNET): 56 data bytes
36 bytes from $UPSTREAM_GW: Redirect Host(New addr: $PUBLIC_IP_OF_BCE0).
Which doesn't seem appropriate at all wrt the routing table...
Did I use "route add" wrong?
Also I want to keep the setup simple, going through priva
09.09.2020 21:42, Abelenda Diego wrote:
> I've got a FreeBSD installation in a DataCenter that provided me with a single
> address IPv4 with an upstream gateway (cidr is fine the upstream gateway works
> everything is nice and running). I use this machine for Masquerading an
> private
> infrastru
If it is possible, you can route via this private address on your FreeBSD
installation to the new one and assign a public/32 to the last.
Alternatively to doing routing like above, if you have a firewall enabled on the
first machine, you can do address forwarding between the first and the new one.
And l
Hello Cristian,
Thank you for your pointer, however if I quote part of my question:
> From my understanding in FreeBSD the route command is unable to perform this
> kind of configuration where you tell that the IPv4 /32 is available without
> next-hop (no via) on a specific link.
I imply there th
Hi
The equivalent command in FreeBSD for the ip route is the route,
follow manpage https://www.freebsd.org/cgi/man.cgi?route
Em qua., 9 de set. de 2020 às 11:43, Abelenda Diego
escreveu:
>
> Hello,
>
> I've got a FreeBSD installation in a DataCenter that provided me with a single
> address IPv4 w
Hello,
I've got a FreeBSD installation in a DataCenter that provided me with a single
address IPv4 with an upstream gateway (cidr is fine the upstream gateway works
everything is nice and running). I use this machine for Masquerading an private
infrastructure.
Now I need other machines with publi
Hi,
I would like to share the current state and the next steps for the
nhops/multipath project.
To recap: project is about modernising the current routing stack and
implementing scalable multipath routing.
Most changes are based on introduction of the concept of nexthops. Nexthops,
which
Hi,
I would like to share the current state and the next steps for the
nhops/multipath project.
To recap: project is about modernising the current routing stack and
implementing scalable multipath routing.
Most changes are based on introduction of the concept of nexthops. Nexthops,
which
I would like to introduce an implementation of scalable multipath routing.
Previous implementation (RADIX_MPATH) focused on a simpler case like having 2
defaults, with performance falling linearly proportional to the number of
paths. That implementation was also tightly coupled lookup algorithm
Hi!
> Am 08.01.2020 um 14:50 schrieb Bjoern A. Zeeb
> :
> Try replacing the
>
> # KEYWORD: nojail
>
> with
>
> # KEYWORD: nojailvnet
>
> in /etc/rc.d/netoptions.
Nailed it:
default fe80::e228:6dff:fe6f:5b%epair0b UGepair0b
I'll open a bug ticket for FreeBSD -
On 8 Jan 2020, at 14:08, Patrick M. Hausen wrote:
Hi,
Am 08.01.2020 um 14:50 schrieb Bjoern A. Zeeb
:
https://www.ixsystems.com/community/threads/ipv6_cpe_wanif-not-quite-working-in-iocage-jail.81341/
Try replacing the
# KEYWORD: nojail
with
# KEYWORD: nojailvnet
in /etc/rc.d/netoptions
Hi,
> Am 08.01.2020 um 14:50 schrieb Bjoern A. Zeeb
> :
>> https://www.ixsystems.com/community/threads/ipv6_cpe_wanif-not-quite-working-in-iocage-jail.81341/
>
> Try replacing the
>
> # KEYWORD: nojail
>
> with
>
> # KEYWORD: nojailvnet
>
> in /etc/rc.d/netoptions.
Found and understood - I
On 8 Jan 2020, at 11:57, Patrick M. Hausen wrote:
Hi all,
does anyone in this list have an idea if this behaviour is to be
expected?
I assume it is not in any way FreeNAS specific, of course. Might be an
iocage artefact, though.
https://www.ixsystems.com/community/threads/ipv6_cpe_wanif-not
Hi all,
does anyone in this list have an idea if this behaviour is to be expected?
I assume it is not in any way FreeNAS specific, of course. Might be an
iocage artefact, though.
https://www.ixsystems.com/community/threads/ipv6_cpe_wanif-not-quite-working-in-iocage-jail.81341/
Thanks and kind r
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210747
Michael Tuexen changed:
What|Removed |Added
Status|New |Closed
Resolution|---
Hi,
Looks like:
https://svnweb.freebsd.org/base?view=revision&revision=191942
I am wondering if it should also be removed from icmp6_notify_error?
##
/*
* XXX: cu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233283
--- Comment #17 from Jamie Landeg-Jones ---
ifconfig_vtnet0_ipv6="inet6 2001:19f0:300:2185::1:1 prefixlen 64 accept_rtadv"
ipv6_activate_all_interfaces="YES"
rtsold_enable="YES"
rtsold_flags="-Fa" # Flags to an IPv6 router solicitation
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233283
Jamie Landeg-Jones changed:
What|Removed |Added
CC||ja...@catflap.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233283
--- Comment #15 from Conrad Meyer ---
(In reply to Andrey V. Elsukov from comment #14)
I see, thanks for explaining Andrey.
--
You are receiving this mail because:
You are the assignee for the bug.
y cache should be sufficient — why don't we populate LLE cache with
> on-link off-prefix routers?
>
> It's not clear to me the exact ordering, but it seems somehow we get a
> router advertisement and insert it into our routing table without populating
> the LLE of the send
cache with on-link
off-prefix routers?
It's not clear to me the exact ordering, but it seems somehow we get a router
advertisement and insert it into our routing table without populating the LLE
of the sender in the LLE cache. I think we must be violating the following
somehow (or ignoring SHO
27;s no RFC that requires a
host to implement such a manual configuration. But supporting it may not be a
bad idea. And, if we add support for it, I'd do so by extending 'ndp' so that
it allows the user to manually create an entry that would be listed by 'ndp
-p', rather t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233283
--- Comment #11 from peos42 ---
(In reply to Conrad Meyer from comment #8)
RFC 4861 say:
--snip--
If the source address of the packet prompting the solicitation is the
same as one of the addresses assigned to the outgoing interface
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233283
--- Comment #10 from Conrad Meyer ---
Further (§8.3, Host Specification):
A host receiving a valid redirect SHOULD update its Destination Cache
accordingly so that subsequent traffic goes to the specified target.
...
If the Target
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233283
--- Comment #9 from Conrad Meyer ---
(In reply to peos42 from comment #6)
Maybe this part?
Router Advertisements contain a list of prefixes used for on-link
determination and/or autonomous address configuration; flags
associated w
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233283
--- Comment #8 from Conrad Meyer ---
(In reply to peos42 from comment #6)
Could they be more specific in how they think BSD is non-compliant with that
RFC? It's a large document and the critique is not specific.
--
You are receiving this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233283
--- Comment #7 from Andrey V. Elsukov ---
Created attachment 199377
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=199377&action=edit
Proposed patch
I just tried to patch, and it seems with this patch I can add on-link route to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233283
--- Comment #6 from peos42 ---
Maybe there is a reason why DragonflyBSD fixed it.
The cloud provider in the same support case I started this thread with said:
--snip--
Additionally, if BSD followed RFC compliance for neighbour table disc
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233283
Andrey V. Elsukov changed:
What|Removed |Added
CC||a...@freebsd.org,
1 - 100 of 1264 matches
Mail list logo
