Re: ping -R output?

[Julian Elischer]

thanks! that's really interesting. Different from what I was expecting 
but what I'd expect from

the code dropping into Fuchsia.

It's such a pity our ping doesn't support ping -T (timestamps)
but Linux does and I'd love to see [(Linux) 'ping -T tsandaddr 
{machine B}'] >[FreeBSD  A] -> [FreeBSD B]


If anyone can do that, I'd really appreciate it..
Actually all three machines as Linux would be an interesting 
comparison as well (for both -T and -R).


Linux adds an entry for both reception and transmission on the far end 
and the sender..
FreeBSD only does sender on the intermediate and far end, and receiver 
on the local.
I don't know what Linux does on the intermediate hosts. My reading of 
the RFC agrees with BSD for RR.
but you only get 9 slots so Linux is limited to a full distance of 2 
(and return) if they use 2 slots for each hop.

I can't say if we get Timestamp right as we can't do it.

J


On 10/14/20 1:25 AM, Peter Libassi wrote:
like this? ( ping from 192.168.3.1 -> (192.168.3.2/172.16.42.1) -> 
172.16.42.2


root@bsd1:~ # ping -R 172.16.42.2
PING 172.16.42.2 (172.16.42.2): 56 data bytes
64 bytes from 172.16.42.2: icmp_seq=0 ttl=63 time=1.280 ms
RR: 172.16.42.1
172.16.42.2
192.168.3.2
192.168.3.1
64 bytes from 172.16.42.2: icmp_seq=1 ttl=63 time=1.238 ms(same route)
64 bytes from 172.16.42.2: icmp_seq=2 ttl=63 time=1.100 ms(same route)
64 bytes from 172.16.42.2: icmp_seq=3 ttl=63 time=1.210 ms(same route)
64 bytes from 172.16.42.2: icmp_seq=4 ttl=63 time=1.156 ms(same route)

/Peter

14 okt. 2020 kl. 09:05 skrev Julian Elischer <mailto:jul...@freebsd.org>>:


Can someone send me the output of a ping -R , starting with FreeBSD 
machine, through a second FreeBSD machine and bouncing back from a 
third FreeBSD machine?  I don't have three in a row like that 
anywhere. Probably best to send it back through the list so I 
people can see if i get an answer.



Thanks, Julian



___
freebsd-net@freebsd.org <mailto: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"

ping -R output?

[Julian Elischer]

Can someone send me the output of a ping -R , starting with FreeBSD 
machine, through a second FreeBSD machine and bouncing back from a 
third FreeBSD machine?  I don't have three in a row like that 
anywhere. Probably best to send it back through the list so I people 
can see if i get an answer.



Thanks, Julian



___
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: Is anybody using ng_pipe?

[Julian Elischer]

Writing a new netgraph node is relatively simple. Take ng_sample.c and
ng_sample.h and copy them.
Change names to suit, and add your own code in the middle. use one of 50
other nodes as examples.
No matter what you want to do one of them already does it.

-- 

+--\  _  __

|   __--_|\  Julian Elischer\   \\   U \/ / On assignment

|  /   \ jul...@elischer.org \   \ USA\ in a very strange

| (   OZ) \-->x   ___ | country !

+- X_.---._/ Mountain View, California \_/   \\

  v

sp; \\

  v
___
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

[Julian Elischer]

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=markup)
[2]: [base Diff of 
/head/sys/net/route.c](https://svnweb.freebsd.org/base/head/sys/net/route.c?r1=180839=180840;)

/Alexander

___
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"

Re: On Netgraph

[Julian Elischer]

On 6/8/20 7:03 AM, Marko Zec wrote:

On Mon, 8 Jun 2020 15:36:42 +0200
Tom Marcoen  wrote:


Hey Jan,

I know about the vast performance improvements with if_bridge(4)
(Thank you, Kristof Provost), the problem with using it for jails is
that once you have a lot of jails, your hosts gets way too many epair
interfaces in its ifconfig, which I really do not like. So I would
prefer using Netgraph.

I don't understand why is everythin doing everything they can _not_
to use Netgraph?

Netgraph is very cool and underrated indeed.  A part of the problem
might be that people may find it easier to construct if_bridge
configurations, than to spend some time learning how to establish the
same functionality using netgraph, which requires a few more steps.  I
was one of such lazy persons myself...

But a more down-to-the-earth problem with ng_bridge may be that it is
single-threaded (look around line 319 in sys/netgraph/ng_bridge.c),
which most likely is going to make it less performant than if_bridge
(after recent improvements)

Since netgraph was written in 1996 it as required only one rework to
add some support for multi-threading so possibly after 24 years we
may need to change a few lines... :-)

On Mon, 8 Jun 2020 at 13:47, Jan Bramkamp  wrote:


On 27.05.20 10:06, Tom Marcoen wrote:

Hey all,

I'm new to this mailing list and also quite new to FreeBSD
(huray,

welcome

to me!) so bare with me, please.

I'm reading up on Netgraph on how I can integrate it with FreeBSD
jails

and

I was looking at some of the examples provided in
/usr/share/examples/netgraph and now have the following question.
The udp.tunnel example shows an iface point-to-point connection
but it is unencrypted. Of course I could encrypt it with an IPsec
tunnel on the

host

or tunnel it through SSH, but I was wondering whether there
exists a nice Netgraph solution, e.g. a node with two hooks,
receiving unencrypted traffic on the inside hook and sending out
encrypted traffic on the

outside

hook.

Netgraph is a very flexible tool, but not needed for this. First of
all if_bridge(4) just got a massive throughput gain by at least a
factor of 5 in 13-current and 12-stable. Next you would be
reinventing the wheel with ng_bridge and ng_ksocket to tunnel
ethernet in UDP. As soon as you have more than two jail hosts
you'll run into new problems.

The canonical solution to your problem is VXLAN. This allows you to
learn traffic to the unicast tunnel endpoint address for unicast
cast traffic and multicast the rest. These encapsulations have been
invented to allow emulate a shared layer 2 Ethernet networks per
tennant. Unless your jails are VNET enabled and your jail admins
require a shared layer 2 network you can avoid most of this
overhead with dynamic routing. I know this sounds a lot like
"your're holding it wrong". Your approach would work, but it would
cripple performance unless you can wait for FreeBSD 12.2 and switch
from netgraph to if_bridge(4). Routing is fast (enough) in the
existing FreeBSD releases and in my opinion the cleaner solution,
but it complicates hosting services expecting a shared layer 2 e.g.
mDNS and DLNA require either multicast routing or proxies.

___
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"

___
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"

Re: On Netgraph

[Julian Elischer]

On 5/27/20 4:20 AM, Eugene Grosbein wrote:

27.05.2020 15:06, Tom Marcoen wrote:


Hey all,

I'm new to this mailing list and also quite new to FreeBSD (huray, welcome
to me!) so bare with me, please.

I'm reading up on Netgraph on how I can integrate it with FreeBSD jails and
I was looking at some of the examples provided in
/usr/share/examples/netgraph and now have the following question.
The udp.tunnel example shows an iface point-to-point connection but it is
unencrypted. Of course I could encrypt it with an IPsec tunnel on the host
or tunnel it through SSH, but I was wondering whether there exists a nice
Netgraph solution, e.g. a node with two hooks, receiving unencrypted
traffic on the inside hook and sending out encrypted traffic on the outside
hook.

There is ng_mppc(4) netgraph node capable to perform relatively weak MPPE 
encryption
(and/or compression) but it is designed to work with ng_ppp(4) node 
encapsulating IP packets into PPP frames.
I doubt it's very efficient for inter-jail traffic.

Why do you need encryption for inter-jails traffic in first place?
Encryption is needed for traffic passing untrusted channels where data 
interception is possible
but inter-jail traffic does not leave the kernel at all until it hits 
destination jail.
Once you have a udp tunnel set up you just need to set up an IPSEC SA 
to to encrypt just that tunnel.

It's not required to do the encryption in netgraph.
there is a script to make the tunnel in 
/usr/share/examples.netgraph/udp.tunnel

you just need to set up the SA to catch it..
you can also if you desire you can also put a netgraph bridge at both
ends of the tunnel and have a single subnet connected by the link. The
bridge nodes are "learning" so they will learn when to send packets over
the link and when not to.
You can also play tricks with FIBs so that tunnel envelope packets and all
other packets use different routing tables.




___
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"

Re: On Netgraph

[Julian Elischer]

On 6/5/20 12:13 PM, Tom Marcoen wrote:

Hey Eugen,

For some reason I did not receive your email. But I found your reply in the
archives.

Anyway, the goal is to have two computers, each with a Netgraph bridge node
and jails connecting to these bridges. I want to connect both bridges over
the Internet securely. Using a UDP tunnel and encrypting that with IPsec or
wireguard or  would be an option, but it would be nicer if I could use
a Netgraph-native option.



In years past I used netgraph ksocket nodes to generate a udp tunnel 
and then set up IPSEC to encrypt it.


can be done from the command line with about 10 lines from memory.

Unfortunately I don't have those 10 line at hand as it was at 
JOB[current - 5]


Julian



Regards,
Tom

On Wed, 27 May 2020 at 10:06, Tom Marcoen  wrote:


Hey all,

I'm new to this mailing list and also quite new to FreeBSD (huray, welcome
to me!) so bare with me, please.

I'm reading up on Netgraph on how I can integrate it with FreeBSD jails
and I was looking at some of the examples provided in
/usr/share/examples/netgraph and now have the following question.
The udp.tunnel example shows an iface point-to-point connection but it is
unencrypted. Of course I could encrypt it with an IPsec tunnel on the host
or tunnel it through SSH, but I was wondering whether there exists a nice
Netgraph solution, e.g. a node with two hooks, receiving unencrypted
traffic on the inside hook and sending out encrypted traffic on the outside
hook.

Regards,
Tom


___
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"

Re: IPSec transport mode, mtu, fragmentation...

[Julian Elischer]

On 1/17/20 1:51 AM, Eugene Grosbein wrote:

17.01.2020 16:36, Victor Sudakov пишет:


Back to the point. I've figured out that both encrypted (in transport
mode) and unencrypted TCP segments have the same MSS=1460. Then I'm
completely at a loss how the encrypted packets avoid being fragmented.
TCP has no way to know in advance that encryption overhead will be
added.

Using multiple routing tables we could add a mechanism to the ipsec
code so that encapsulated sessions are referred to one routing table
and that the "envelope" routes are referencing another (specified in
ipsec setup) routing table.  The two routing tables would have different
MTUs.  This mechanism/framework would also be useful for other
tunneling protocols in general.

If outgoing route (f.e. default route) has lower MTU, kernel should respond 
with EMSGSIZE
to TCP's attempt to send oversized packet when PMTUD is enabled.

If PMTUD discovers that path mtu is low, it should store this information in 
the hostcache
(see sysctl net.inet.tcp.hostcache.list) and use hostcache's MTU for same goal.

___
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"

Re: Continuing problems in a bridged VNET setup

[Julian Elischer]

On 12/20/19 10:09 AM, Nick Wolff wrote:

Marko,

Are you aware of any write ups for using ng_eiface and ng_bridge instead of
if_bridge?
look in /usr/share/examples/netgraph here are a couple of examples of 
exactly what you ask for.

Thanks,

Nick Wolff

On Fri, Dec 20, 2019 at 6:22 AM Marko Zec  wrote:


Perhaps you could ditch if_bridge(4) and epair(4), and try ng_eiface(4)
with ng_bridge(4) instead?  Works rock-solid 24/7 here on 11.2 / 11.3.

Marko

On Fri, 20 Dec 2019 11:19:24 +0100
"Patrick M. Hausen"  wrote:


Hi all,

we still experience occasional network outages in production,
yet have not been able to find the root cause.

We run around 50 servers with VNET jails. some of them with
a handful, the busiest ones with 50 or more jails each.

Every now and then the jails are not reachable over the net,
anymore. The server itself is up and running, all jails are
up and running, one can ssh to the server but none of the
jails can communicate over the network.

There seems to be no pattern to the time of occurrance except
that more jails on one system make it "more likely".
Also having more than one bridge, e.g. for private networks
between jails seems to increase the probability.
When a server shows the problem it tends to get into the state
rather frequently, a couple of hours inbetween. Then again
most servers run for weeks without exhibiting the problem.
That's what makes it so hard to reproduce. The last couple of
days one system was failing regularly until we reduced the number
of jails from around 80 to around 50. Now it seems stable again.

I have a test system with lots of jails that I work with gatling
that did not show a single failure so far :-(


Setup:

All jails are iocage jails with VNET interfaces. They are
connected to at least one bridge that starts with the
physical external interface as a member and gets jails'
epair interfaces added as they start up. All jails are managed
by iocage.

ifconfig_igb0="-rxcsum -rxcsum6 -txcsum -txcsum6 -vlanhwtag
-vlanhwtso up" cloned_interfaces="bridge0"
ifconfig_bridge0_name="inet0"
ifconfig_inet0="addm igb0 up"
ifconfig_inet0_ipv6="inet6 /64 auto_linklocal"

$ iocage get interfaces vpro0087
vnet0:inet0

$ ifconfig inet0
inet0: flags=8843 metric 0
mtu 1500 ether 90:1b:0e:63:ef:51
   inet6 fe80::921b:eff:fe63:ef51%inet0 prefixlen 64 scopeid 0x4
   inet6  prefixlen 64
   nd6 options=21
   groups: bridge
   id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
   maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
   root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
   member: vnet0.4 flags=143
   ifmaxaddr 0 port 7 priority 128 path cost 2000
   member: vnet0.1 flags=143
   ifmaxaddr 0 port 6 priority 128 path cost 2000
   member: igb0 flags=143
   ifmaxaddr 0 port 1 priority 128 path cost 200


What we tried:

At first we suspected the bridge to become "wedged" somehow. This was
corroborated by talking to various people at devsummits and EuroBSDCon
with Kristof Provost specifically suggesting that if_bridge was
still under giant lock and there might be a problem here that the
lock is not released under some race condition and then the entire
bridge subsystem would be stalled. That sounds plausible given the
random occurrance.

But I think we can rule out that one, because:

- ifconfig up/down does not help
- the host is still communicating fine over the same bridge interface
- tearing down the bridge, kldunload (!) of if_bridge.ko followed by
   a new kldload and reconstructing the members with `ifconfig addm`
   does not help, either
- only a host reboot restores function

Finally I created a not iocage managed jail on the problem host.
Please ignore the `iocage` in the path, I used it to populate the
root directory. But it is not started by iocage at boot time and
the manual config is this:

testjail {
 host.hostname = "testjail";   # hostname
 path = "/iocage/jails/testjail/root"; # root directory
 exec.clean;
 exec.system_user = "root";
 exec.jail_user = "root";
 vnet;
   vnet.interface = "epair999b";
 exec.prestart += "ifconfig epair999 create; ifconfig
epair999a inet6 2A00:B580:8000:8000::1/64 auto_linklocal";
exec.poststop += "sleep 2; ifconfig epair999a destroy; sleep 2";
 # Standard stuff
 exec.start += "/bin/sh /etc/rc";
 exec.stop = "/bin/sh /etc/rc.shutdown";
 exec.consolelog = "/var/log/jail_testjail_console.log";
 mount.devfs;  #mount devfs
 allow.raw_sockets;#allow ping-pong
 devfs_ruleset="4";#devfs ruleset for this jail
}

$ cat /iocage/jails/testjail/root/etc/rc.conf
hostname="testjail"

ifconfig_epair999b_ipv6="inet6 2A00:B580:8000:8000::2/64
auto_linklocal"

When I do `service jail onestart testjail` I can then ping6 the jail
from the host and the host from the jail. As you can see the
if_bridge is 

geo blocking with ipfw ... the easy way

[Julian Elischer]

just in case someone wants to do this:
The following script sets up a table (which can be
used for blocking or allowing) in ipfw so that it holds
nets assigned to the USA and Australia.
You may select your own nets of course:
It uses the ipdbtools package.


(I run this from cron)

#!/bin/sh
ALLOWFILE=/root/AU+USA-GEOIPS.ipfw
MAILTABLE=20
ALT_MAILTABLE=21
AU_VAL=1
US_VAL=10200
set -x

#fetch latest geo-ip ranges and set AU and USA into table ${MAILTABLE}
ipdb-update.sh
ipup -t AU=${AU_VAL}:US=${US_VAL} -n ${ALT_MAILTABLE} > ${ALLOWFILE}
ipfw table ${ALT_MAILTABLE} flush
ipfw -q -f ${ALLOWFILE}
ipfw table ${MAILTABLE} swap ${ALT_MAILTABLE}
___
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: SOCK_RAW && SO_DONTROUTE doesn't work

[Julian Elischer]

On 11/25/19 12:02 PM, Colin Percival wrote:

Hi networky people,

I'm not sure if this was deliberate or if it's a bug.

If you create a raw IP socket, turn on IP_HDRINCL and SO_DONTROUTE, and
then use sendto(2) to send a packet, the destination address provided to
sendto(2) is ignored; instead, the destination is taken from the packet's
ip_dst field.

It looks like this happens because rip_output calls ip_output with a NULL
value for ro, prompting ip_output to look up the destination from the IP
packet, rather than the destination passed to sendto (which never made its
way out of rip_output).

I tripped over this because I was trying to have a userland process which
routes (some) packets differently from how the routing tables specify; but
my "no really, go out THAT interface" wasn't being respected. :-(

(Full background: I want to make a transparent proxy which intercepts
outgoing connections to 169.254.169.254, allowing some of them through and
redirecting others for special handling.  I created a tun which outgoing
packets get routed into; but I ran into problems when I wanted to forward
some of the packets out of the external interface since they ignored my
attempts to route them and came straight back into the tun instead.)


I have always achieved this sort of thing using ipfw fwd rules, rather
than trying to bend the IP stack to do it.


___
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: CARP and NAT question

[Julian Elischer]

On 10/9/19 12:57 PM, Matthew Grooms wrote:

On 10/9/2019 2:50 PM, Julian Elischer wrote:

On 10/9/19 2:34 AM, Julien Cigar wrote:

On Tue, Oct 08, 2019 at 01:05:37PM -0700, Julian Elischer wrote:

On 10/8/19 8:58 AM, Julien Cigar wrote:

On Tue, Oct 08, 2019 at 10:20:34AM -0500, Matthew Grooms wrote:

Hi Julien,

Hi Matthew,

It's not clear why you are trying to assign multiple carp IP 
address to
two different interfaces from within the same IP subnet. Are 
you trying

to fail over a 2nd carp address or are you trying to improve
throughput/redundancy? If you just want to fail over a 2nd carp 
address,
assign a 2nd alias to your first interface. If your trying to 
improve
throughput/redundancy, assign both interfaces to a lagg and 
build your

carp interfaces on top of that instead.

Currently outbound traffic from $net1 and $net2 (two private 
networks)
pass through the same network interface (igb0) (as you can see 
in (1)

in my previous post) on the router. I'd like to prevent that
$net2 saturates the interface and slow down traffic from $net1 
(which is

more important). I could lagg and build CARP on top of that but it
wouldn't prevent $net2 to saturate the interface (unless I'm 
plugin ALTQ

of course, which I'd like to avoid).


-Matthew

On 10/8/2019 8:48 AM, Julien Cigar wrote:

Hello,

I'd like to NAT outbound traffic from two different private 
networks
through two different interfaces, with CARP on top. I have 4 
public IPS

available (193.x.x.89, 193.x.x.90, 193.x.x.91, 193.x.x.92).

I have two redundant router/firewall running FreeBSD 12 with 
CARP and

PF with the following: (1) which works well, but all traffic
goes through the same interface.

So I'd like to switch to something like (2), which will not 
work (lines
5 and 13 are not valid) and I'm wondering if I could use 
something like

(3) ..?

Thank you!
Julien

(1) 
https://gist.github.com/silenius/4f6173a9b6690292c2174ab3bb89d292
(2) 
https://gist.github.com/silenius/da9be7e74e9861fa55f927d194e3e410
(3) 
https://gist.github.com/silenius/b237565b0d181248ff80ea296e5537db



___
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"

can you draw it?

yes, see https://ibb.co/mv5RPM9


so, you have several ways of doing this:

one is to assign a different routing table to each class of traffic.

Each table has  a different default route, sending data out to a 
different external interface.


Each interface out is NAT'd so that the return packets will come 
back the same way.


How do you classify the traffic based on the source address when 
using multiple route tables?


use ipfw to set the fib number based on some bits in the address of 
the internal machine.


e.g. ipfw setfib 1 tcp from (some internal pattern) to (the outside) 
in recv (internal interface) keep_state


There are several ways to do this.. this is just one... The above will 
assign a dynamic rule for all packets between the  two machines and 
the table in question will be always used. for that tupple.





But you only have a single pipe to the internet, So one wonders how 
that helps with redundancy?


I asked a similar question. He believe he mentioned that he was 
trying to get around the 1Gbit limit of each interface. WRT 
redundancy, he probably means the use of a backup firewall, carp and 
probably pfsync.


-Matthew

___
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"

Re: CARP and NAT question

[Julian Elischer]

On 10/9/19 2:34 AM, Julien Cigar wrote:

On Tue, Oct 08, 2019 at 01:05:37PM -0700, Julian Elischer wrote:

On 10/8/19 8:58 AM, Julien Cigar wrote:

On Tue, Oct 08, 2019 at 10:20:34AM -0500, Matthew Grooms wrote:

Hi Julien,

Hi Matthew,


It's not clear why you are trying to assign multiple carp IP address to
two different interfaces from within the same IP subnet. Are you trying
to fail over a 2nd carp address or are you trying to improve
throughput/redundancy? If you just want to fail over a 2nd carp address,
assign a 2nd alias to your first interface. If your trying to improve
throughput/redundancy, assign both interfaces to a lagg and build your
carp interfaces on top of that instead.


Currently outbound traffic from $net1 and $net2 (two private networks)
pass through the same network interface (igb0) (as you can see in (1)
in my previous post) on the router. I'd like to prevent that
$net2 saturates the interface and slow down traffic from $net1 (which is
more important). I could lagg and build CARP on top of that but it
wouldn't prevent $net2 to saturate the interface (unless I'm plugin ALTQ
of course, which I'd like to avoid).


-Matthew

On 10/8/2019 8:48 AM, Julien Cigar wrote:

Hello,

I'd like to NAT outbound traffic from two different private networks
through two different interfaces, with CARP on top. I have 4 public IPS
available (193.x.x.89, 193.x.x.90, 193.x.x.91, 193.x.x.92).

I have two redundant router/firewall running FreeBSD 12 with CARP and
PF with the following: (1) which works well, but all traffic
goes through the same interface.

So I'd like to switch to something like (2), which will not work (lines
5 and 13 are not valid) and I'm wondering if I could use something like
(3) ..?

Thank you!
Julien

(1) https://gist.github.com/silenius/4f6173a9b6690292c2174ab3bb89d292
(2) https://gist.github.com/silenius/da9be7e74e9861fa55f927d194e3e410
(3) https://gist.github.com/silenius/b237565b0d181248ff80ea296e5537db


___
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"

can you draw it?

yes, see https://ibb.co/mv5RPM9


so, you have several ways of doing this:

one is to assign a different routing table to each class of traffic.

Each table has  a different default route, sending data out to a 
different external interface.


Each interface out is NAT'd so that the return packets will come back 
the same way.


But you only have a single pipe to the internet, So one wonders how 
that helps with redundancy?









___
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"

Re: VLAN+bridge problem [was: no network between jails and host with VNET on same interface]

[Julian Elischer]

try use netgraph bridge and interfaces

On 10/9/19 11:38 AM, Alexander Lunev via freebsd-net wrote:

07.10.2019 8:21, Alexander N. Lunev via freebsd-net пишет:

I've tested with tcpdump, and here's what i found:


> Host interfaces:
> em0 up
> vlan22 10.15.15.1/24 vlandev em0 vlan22
> epair0a - part of epair for jail foo
> bridge0 addm epair0 addm em0

> Jail foo interfaces:
> epair0b up (vnet interface)
> vlan22 10.15.15.2/24 vlandev epair0b vlan22

I found that there's already reported a bug 240106.

Just to spread the word - I've added comment about my situation with 
some more test with tcpdump:


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240106#c3

To make it short here: if I add static ARP entries for IPs on host's 
and jail's vlan interfaces, then ICMP requests reach host's vlan 
interface, but replies doesn't return to jail. All tcpdump output is 
in my comment in PR, see link.




___
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: CARP and NAT question

[Julian Elischer]

On 10/8/19 8:58 AM, Julien Cigar wrote:

On Tue, Oct 08, 2019 at 10:20:34AM -0500, Matthew Grooms wrote:

Hi Julien,

Hi Matthew,


It's not clear why you are trying to assign multiple carp IP address to
two different interfaces from within the same IP subnet. Are you trying
to fail over a 2nd carp address or are you trying to improve
throughput/redundancy? If you just want to fail over a 2nd carp address,
assign a 2nd alias to your first interface. If your trying to improve
throughput/redundancy, assign both interfaces to a lagg and build your
carp interfaces on top of that instead.


Currently outbound traffic from $net1 and $net2 (two private networks)
pass through the same network interface (igb0) (as you can see in (1)
in my previous post) on the router. I'd like to prevent that
$net2 saturates the interface and slow down traffic from $net1 (which is
more important). I could lagg and build CARP on top of that but it
wouldn't prevent $net2 to saturate the interface (unless I'm plugin ALTQ
of course, which I'd like to avoid).


-Matthew

On 10/8/2019 8:48 AM, Julien Cigar wrote:

Hello,

I'd like to NAT outbound traffic from two different private networks
through two different interfaces, with CARP on top. I have 4 public IPS
available (193.x.x.89, 193.x.x.90, 193.x.x.91, 193.x.x.92).

I have two redundant router/firewall running FreeBSD 12 with CARP and
PF with the following: (1) which works well, but all traffic
goes through the same interface.

So I'd like to switch to something like (2), which will not work (lines
5 and 13 are not valid) and I'm wondering if I could use something like
(3) ..?

Thank you!
Julien

(1) https://gist.github.com/silenius/4f6173a9b6690292c2174ab3bb89d292
(2) https://gist.github.com/silenius/da9be7e74e9861fa55f927d194e3e410
(3) https://gist.github.com/silenius/b237565b0d181248ff80ea296e5537db


___
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"


can you draw it?


___
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: DHCPv6 client in base

[Julian Elischer]

On 10/7/19 12:05 PM, Roy Marples wrote:

On 07/10/2019 19:45, Julian Elischer wrote:
I'm not HRS, but as it uses netlink, how does NetBSD use it?  (i.e. 
how do we simulate that?)


dhcpcd has a driver per OS:
BSD == route(4)


though sometimes I wonder if that could not be improved.. it's now 
what? 35 years old?




Linux == netlink(3)
Solaris == route(4) along with an unholy mashup of streamio(7)

I try and keep OS specific defines out of the main code.

dhcpcd is also in the FreeBSD ports tree and is currently up to date.

Nice to know.

I guess the question is really "How compatible with ISC/dhclient is it 
(seems somewhat so), does it give us advantages over staying with the 
current tools, and how supported are the other tools, vs these?


Every tool set comes with advocates and someone is sure to be upset if 
we choose one. :-)


A dhcp Client is a necessary part of the OS (though a bit less so with 
IPV6) but the serer side can be a port. (as it is).




Roy



___
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: DHCPv6 client in base

[Julian Elischer]

On 10/6/19 5:53 PM, Ben Woods wrote:

On Thu, 16 May 2019 at 2:25 am, Hiroki Sato  wrote:


 wrote
   in <001e01d50b49$176104d0$46230e70$@gmail.com>:

dr> Has anyone ever thought or considered integrating an IPv6 DHCP client
in
dr> base?

  I have a plan to import wide-dhcp6 into the base system because it is
  simple enough.

dr> net/dhcp6 isn't really maintained anymore from the KAME days it works
for
dr> basic functionality but fails when a more complex config is required.

  More specifics about the complex configuration?

-- Hiroki


I would like to discuss whether dhcpcd is a better option to import into
FreeBSD base, rather than wide-dhcp6.

dhcpcd has the following benefits that I can see:
- Actively maintained [1] (wide-dhcp6 seems to be stale for 11 years?)
- Used in NetBSD and DragonflyBSD (code sharing amongst the BSDs will
facilitate collective progress and lesson sharing). Roy, the upstream
maintainer, has committer on both NetBSD and DragonFlyBSD.
- more feature rich [2]

[1] https://roy.marples.name/projects/dhcpcd/history
[2] https://roy.marples.name/projects/dhcpcd/features

hrs - what are your thoughts?
I'm not HRS, but as it uses netlink, how does NetBSD use it?  (i.e. 
how do we simulate that?)


Regards,
Ben



___
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: radiotap header bit definition allocation has changed ...

[Julian Elischer]

Hi Richard.  I’m not the person but I will forward on to the next person in the 
“May know more” chain and we can see if we can home in on the right person.   

Julian

Sent from my iPhone

> On Aug 11, 2019, at 10:57 AM, Richard Sharpe  
> wrote:
> 
> Hi Julian,
> 
> I dunno if you care about this, so maybe you can point me at who cares.
> 
> I have just posted a change to Wireshark letting people know that
> there are no more bit numbers available for new radiotap headers and
> that radiotap has switched to using TLVs from now on.
> 
> I did this because I am working with the S1G (has the stupid marketing
> name of Halow, 802.11ah) folks and we needed a new radiotap header,
> and they stupidly used a bit that is not available.
> 
> Anyway, is S1G adapters get released (maybe next year) I imagine
> people will want to support them on FreeBSD and capture software will
> be needed ...
> 
> so, someone needs to be aware of this.
> 
> -- 
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)
> 

___
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: freebsd stack in user space

[Julian Elischer]

On 6/9/18 6:56 pm, Julian Elischer wrote:

I know some people have done this..  anyone have pointers?


thanks to all who responded.


Julian


___
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"

freebsd stack in user space

[Julian Elischer]

I know some people have done this..  anyone have pointers?

Julian


___
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: In-kernel NAT [ipfw] dropping large UDP return packets

[Julian Elischer]

On 14/6/18 7:44 am, Jeff Kletsky wrote:



On 6/13/18 1:28 PM, Andrey V. Elsukov wrote:

On 13.06.2018 23:04, Jeff Kletsky wrote:

The kernel version of libalias uses m_megapullup() function to make
single contiguous buffer. m_megapullup() uses m_get2() function to
allocate mbuf of appropriate size. If size of packet greater than 
4k it

will fail. So, if you use MTU greater than 4k or if after fragments
reassembly you get a packet with length greater than 4k, ipfw_nat()
function will drop this packet.


Thanks!!

Mystery solved...

/usr/src/sys/netinet/libalias/alias.c

#ifdef _KERNEL
/*
  * m_megapullup() - this function is a big hack.
  * Thankfully, it's only used in ng_nat and ipfw+nat.

suggests that the "old school" approach of natd might resolve 
this. I'll
give it a try when I'm close enough to the box to resolve it when 
I make

a configuration error.

I didn't look at the rest of libalias, but you, probably, can improve
this hack to use 9k or 16k mbufs. You can replace m_get2() call in
m_megapullup() with the following code:

if (len <= MJUMPAGESIZE)
mcl = m_get2(len, M_NOWAIT, MT_DATA, M_PKTHDR);
else if (len <= MJUM9BYTES)
mcl = m_getjcl(M_NOWAIT, MT_DATA, M_PKTHDR, MJUM9BYTES);
else if (len <= MJUM16BYTES)
mcl = m_getjcl(M_NOWAIT, MT_DATA, M_PKTHDR, MJUM16BYTES);
else
goto bad;



Tested and "works for me" on 11.1-RELEASE-p10 with GENERIC kernconf

8<
--- alias.c.orig    2017-07-20 16:42:02.0 -0700
+++ alias.c    2018-06-13 15:41:46.862121000 -0700
@@ -1758,7 +1758,14 @@
 if (m->m_next == NULL && M_WRITABLE(m))
     return (m);

-    mcl = m_get2(len, M_NOWAIT, MT_DATA, M_PKTHDR);
+    if (len <= MJUMPAGESIZE)
+        mcl = m_get2(len, M_NOWAIT, MT_DATA, M_PKTHDR);
+    else if (len <= MJUM9BYTES)
+        mcl = m_getjcl(M_NOWAIT, MT_DATA, M_PKTHDR, MJUM9BYTES);
+    else if (len <= MJUM16BYTES)
+        mcl = m_getjcl(M_NOWAIT, MT_DATA, M_PKTHDR, MJUM16BYTES);
+    else
+        goto bad;
 if (mcl == NULL)
     goto bad;
 m_align(mcl, len);
>8

Thanks again!


Hi Andey,  please commit..


Jeff

___
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"

Re: In-kernel NAT [ipfw] dropping large UDP return packets

[Julian Elischer]

On 14/6/18 3:01 am, Andrey V. Elsukov wrote:

On 13.06.2018 20:16, Jeff Kletsky wrote:

When a T-Mobile "femto-cell" is trying to establish its IPv4, IPSEC
tunnel to the T-Mobile provisioning servers, the reassembled, 4640-byte
return packet is silently dropped by the in-kernel NAT, even though it
"matches" the outbound packet from less than 100 ms prior.
Are there known causes and/or resolutions for this behavior?

Is there a way to be able to "monitor" the NAT table?

(I didn't see anything obvious in the ipfw, natd, or libalias man pages.)

The kernel version of libalias uses m_megapullup() function to make
single contiguous buffer. m_megapullup() uses m_get2() function to
allocate mbuf of appropriate size. If size of packet greater than 4k it
will fail. So, if you use MTU greater than 4k or if after fragments
reassembly you get a packet with length greater than 4k, ipfw_nat()
function will drop this packet.


hmmm that sounds like a bug to me..

why does it fail?


___
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: In-kernel NAT [ipfw] dropping large UDP return packets

[Julian Elischer]

On 14/6/18 1:41 am, Michael Sierchio wrote:

I see you have a case of Netgraph. Perhaps Julian will chime in.


well I'm reading but not got any specific ideas at the moment..
Netgraph itself has no requirements on packet size or even contents.
a node may however have some.



On Wed, Jun 13, 2018 at 10:32 AM, Jeff Kletsky  wrote:


On 6/13/18 10:22 AM, Michael Sierchio wrote:

On Wed, Jun 13, 2018 at 10:16 AM, Jeff Kletsky  wrote:

When a T-Mobile "femto-cell" is trying to establish its IPv4, IPSEC tunnel


to the T-Mobile provisioning servers, the reassembled, 4640-byte return
packet is silently dropped by the in-kernel NAT, even though it "matches"
the outbound packet from less than 100 ms prior.



Do you have a 'reass' rule before applying nat on inbound traffic?

- M


Yes, at the start of the rule set.

Reassembly confirmed to be working by wireshark examination of the ngtee
"taps" shown

$ sudo ipfw list
1 deny ip from any to any recv ng*
4 ngtee 100 ip from any to any proto udp dst-port 500,4500 in
4 ngtee 100 ip from any to any proto udp frag in
4 ngtee 110 ip from any to any proto udp dst-port 500,4500 out
4 ngtee 110 ip from any to any proto udp frag out
5 reass ip from any to any
6 ngtee 101 ip from any to any proto udp dst-port 500,4500 in //
reassembled in
6 ngtee 101 ip from any to any proto udp frag in // never should be
frags after reass
6 ngtee 111 ip from any to any proto udp dst-port 500,4500 out //
reass out
6 ngtee 111 ip from any to any proto udp frag out // never should be
frage after reass
[...]


___
freebsd-i...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-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"

Re: NETGRAPH- bridge vlans using netgraph help

[Julian Elischer]

On 9/5/18 11:24 pm, Abdullah Tariq wrote:


a picture would do wonders to understand what he wants.


 Apologies for being AWOL
 Attaching an image link: https://ibb.co/nt1s4S


Ok so, it looks like there i a problem in concepts.
FreeBSD doesn't really know about tags inside the machine..

It only has the ability to make a separate interface that multiplexes 
(on output)
and demultiplexes (on input) packets going onto a single link by 
assigning/creating

a virtual sub-interface for each active vlan on that real interface.

(well that's 100% true, but it doesn't use the tags for anything real 
internally.)


If you add the tag for a packet coming in and then remove it as it 
goes out, what

is the point in having it?
FreeBSD does not have a vlan switch internally.

That is not to say that we can not MAKE one,
but the whole aim of FreeBSD's vlan support is to allow it to send 
packets out that are

tagged for different vlans depending on which 'sub interface'
the packet was routed to, not to send unmarked packets internally 
routed via

some mythical internal vlan switch.

iface0.1][iface0]--wire
      /
iface0.2]/

packets sent out via iface0.1 will appear on the wire with vlan1 headers
packates sent out through iface0.2 will appear on the wire with vlan2 
headers


Inside the system however the vlan headers have been stripped off. 
They DO still have some vlan

information tagged on them but it is not used generally.

I still don't fully understand the aim of the exercise.


Julian






On Tue, May 1, 2018 at 8:39 PM, Julian Elischer <jul...@freebsd.org 
<mailto:jul...@freebsd.org>> wrote:


On 1/5/18 11:16 pm, Freddie Cash wrote:

On Tue, May 1, 2018 at 6:08 AM, Julian Elischer
<jul...@freebsd.org <mailto:jul...@freebsd.org>>wrote:

On 1/5/18 2:08 am, Eugene Grosbein wrote:

01.05.2018 1:03, Freddie Cash wrote:

On Mon, Apr 30, 2018 at 10:59 AM, Eugene Grosbein
<eu...@grosbein.net <mailto:eu...@grosbein.net>
<mailto:eu...@grosbein.net
<mailto:eu...@grosbein.net>>>wrote:

     > What the OP is trying to do is have PC1 send
untagged packets to igb0 on FreeBSD which is
configured for tagged vlan 5.
     > Then bridge the packets to igb1 which is
also configured for tagged vlan 5.  Then send the
packets out, untagged, to PC2.

     Why would one want to "configure igb0 for
tagged vlan 5" when igb0 supposed to receive
untagged frames?
     This does not make any sense. One should just
bridge igb0 as is, without creation vlan on it and
problem's solved.

​Yes, agree.  What the OP wants to do can't be
done.  :)​

Perhaps, you missed a message from him when he states
that configuration style does no matter for him really.
So, what he wants can be done, just using different style.


a picture would do wonders to understand what he wants
​.


​A FreeBSD system with multiple NICs, with separate vlans
internally to separate untagged traffic between PCs.​

https://forums.freebsd.org/threads/bridge-with-vlans-not-working.65592/
<https://forums.freebsd.org/threads/bridge-with-vlans-not-working.65592/>

​​https://forums.freebsd.org/attachments/capture-png.4744/
<https://forums.freebsd.org/attachments/capture-png.4744/>


​https://forums.freebsd.org/threads/bridge-with-vlans-not-working.65592/#lg=post-385584=0

<https://forums.freebsd.org/threads/bridge-with-vlans-not-working.65592/#lg=post-385584=0>

​The "easy" solution is to just bridge together the interfaces
you want to be part of the same "virtual lan", thus allowing
traffic between those stations only.  Want PC1 and PC2 to be
part of one vlan?  Then bridge together igb0 and igb1.  Want
PC3, connected to igb2, and PC4, connected to igb3, to be part
of a separate "virtual lan"?  Then create a separate bridge
between igb2 and igb3. No vlan tags required anywhere.


ok so does he want to have those vlans terminated at his box or
just pass them through?
and if they are untagged,  why is it being called a vlan?
untagged vlan is what we call "ethernet".

if it's untagged then only the internal state of the switches
decides which "virtual network" it is on..





But, the OP (in the forum thread and here) keeps getting hung
up on "needing" vlan tags on the NICs, trying to treat the
FreeBSD box like a switch with hybrid ports and PVIDs set on
the ports.

-- 
Freddie Cash

fjwc...@gmail.com <mailto:fjwc...@gmail.com&g

Re: multiple if_ipsec

[Julian Elischer]

On 8/5/18 9:51 pm, Andrey V. Elsukov wrote:

On 08.05.2018 14:03, peter.b...@bsd4all.org wrote:

Hi Victor,

I’m struggling wit the same issue. My sainfo doesn’t match unless I
use anonymous.

Hi Andrey,

What I don’t understand is why a “catchall” policy is added instead
of the policy that matches the inner tunnel.

This is because the how IPsec works in BSD network stack.

In simple words - outbound traffic is matched by security policy,
inbound is matched by security association.

When a packet is going to be send from a host, the kernel checks
security policies for match. If it is matched, a packet goes into IPsec
processing. Then IPsec code using given security policy does lookup for
matched security association. And some IPsec transform happens.

When a host receives a packet, it handled by network stack first. And
if it has corresponding IPsec inner protocol (ESP, AH), it will be
handled by IPsec code. A packet has embedded SPI, it is used for
security association lookup. If corresponding SA is found, the IPsec
code will apply revers IPsec transform to the packet. Then the kernel
checks, that there is some security policy for that packet.

Now how if_ipsec(4) works. Security policies associated with interface
have configured requirements for tunnel mode with configured addresses.
Interfaces are designed for route based VPN, and when a packet is going
to be send through if_ipsec interface, its "output" routine uses
security policy associated with interface and with configured "reqid".

If there are no SAs configured with given reqid, the IPsec code will
send ACQUIRE message to IKE and it should install SAs, that will be used
for IPsec transforms.

When a host receives a packet, it handled by network stack, then by
IPsec code and when reverse transform is finished, IPsec code checks, if
packet was matched by tunnel mode SA it will be checked by if_ipsec
input routine. If addresses and reqid from SA matched to if_ipsec
configuration, it will be taken by if_ipsec interface.



What is supposed to happen here? Is the IKE daemon supposed to update
the policy once started.

In my understanding IKE is only supposed to install SAs for if_ipsec.
It can't change these policies, because they are immutable.

I think for proper support of several if_ipsec interfaces racoon needs
some patches. But I have not spare time to do this job.
I recommend to use strongswan, it has active developers that are
responsive and may give some help at least.

There was the link with example, but it also uses only one interface:
https://genneko.github.io/playing-with-bsd/networking/freebsd-vti-ipsec

my answer was to create a jail to act as the endpoint of each vpn 
using VIMAGE and then allow each jail to run its own raccoon.



___
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: ipfw -- selecting locally generated packets

[Julian Elischer]

On 5/5/18 1:33 am, Jeff Kletsky wrote:



On 5/3/18 6:35 AM, Julian Elischer wrote:

On 3/5/18 12:08 am, Michael Sierchio wrote:
On Mon, Apr 30, 2018 at 10:48 AM, Jeff Kletsky 
<free...@wagsky.com> wrote:



"not recv any" doesn't seem to be helpful either

 $ sudo ipfw add 64000 count ip from any to any out xmit any 
not recv

any


The loopback interface, lo0 ?
___
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"



As was pointed out a selector might be

add 100 ip from me to any out not recv *

one wonders if that would work or maybe

skipto {line x) any from any to any out recv *

followed by lines htat are for locally generated.

these not tested..


Looks like

 [not] recv *

is going to work.

Part of my refactor is to do "dispatch" with call/skipto (as Julian 
Elischer noted above), so the potential inefficiencies of what I'm 
guessing is a string glob only happen "once" per packet (per pass), 
rather than on dozens of rules. Rule 16, below, could probably skip 
the test, but for the likely tiny performance impact, readability 
and maintainability have me leaving it in.



I took a *quick* look on a "live" routing system (standard ipfw 
points; no bridging, no ether) with


sudo ipfw add 13 set 5 drop all from any to any via ng*    # Kill 
packet clones
sudo ipfw add 14 set 5 ngtee 100 ip4 from any to any in    # 
incoming packets
sudo ipfw add 15 set 5 ngtee 200 ip4 from any to any out recv \* # 
forwarded packets
sudo ipfw add 16 set 5 ngtee 300 ip4 from any to any out not recv 
\*    # locally generated packets

I'd skip it as 'interface = *' takes some time to evaluate.
if you want to be readable. add comments.
e.g.

fb10-cc01# ipfw add count ip from any to any // test comments
05300 count ip from any to any // test comments
fb10-cc01# ipfw list 5000-6000
05000 allow tcp from any to me via em0 frag
05100 allow ip from me to me via lo0
05200 allow udp from me to any out via em0
05300 count ip from any to any // test comments

also I've


$ sudo ngctl

mkpeer ipfw: iface 100 inet
mkpeer ipfw: iface 200 inet
mkpeer ipfw: iface 300 inet

and bringing up those new interfaces and using tcpdump.

Took a brief bit to figure out how to get around the lack of 
link-level headers on ng_ipfw output for tcpdump (documented in 
ng_tag, of all places) as "mkpeer ipfw: eiface NNN ether" and 
"tcpdump -ni ngX" doesn't know what to make of things.


It feels like something of a hack-ish approach using ng_iface to 
wrap the "bare" packet with a link-level header, especially as it 
appears to be injecting a second copy of the packet into the stack 
(hence rule 13, above). Figuring out a "better" way to "monitor" 
packet flow through ipfw may be on my list in the future, but that 
was sufficient to let me go ahead with further config/test.



Thanks for all the help!

After so many years with FreeBSD and ipfw, eyes with a different 
perspective can reveal new tricks to this old dog.


Jeff




___
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"

Re: ipfw -- selecting locally generated packets

[Julian Elischer]

On 3/5/18 12:08 am, Michael Sierchio wrote:

On Mon, Apr 30, 2018 at 10:48 AM, Jeff Kletsky  wrote:


"not recv any" doesn't seem to be helpful either

 $ sudo ipfw add 64000 count ip from any to any out xmit any not recv
any


The loopback interface, lo0 ?
___
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"


As was pointed out a selector might be

add 100 ip from me to any out not recv *

one wonders if that would work or maybe

skipto {line x) any from any to any out recv *

followed by lines htat are for locally generated.

these not tested..


___
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: NETGRAPH- bridge vlans using netgraph help

[Julian Elischer]

On 1/5/18 11:16 pm, Freddie Cash wrote:
On Tue, May 1, 2018 at 6:08 AM, Julian Elischer <jul...@freebsd.org 
<mailto:jul...@freebsd.org>>wrote:


On 1/5/18 2:08 am, Eugene Grosbein wrote:

01.05.2018 1:03, Freddie Cash wrote:

On Mon, Apr 30, 2018 at 10:59 AM, Eugene Grosbein
<eu...@grosbein.net <mailto:eu...@grosbein.net>
<mailto:eu...@grosbein.net
<mailto:eu...@grosbein.net>>>wrote:

     > What the OP is trying to do is have PC1 send
untagged packets to igb0 on FreeBSD which is configured
for tagged vlan 5.
     > Then bridge the packets to igb1 which is also
configured for tagged vlan 5.  Then send the packets
out, untagged, to PC2.

     Why would one want to "configure igb0 for tagged
vlan 5" when igb0 supposed to receive untagged frames?
     This does not make any sense. One should just
bridge igb0 as is, without creation vlan on it and
problem's solved.

​Yes, agree.  What the OP wants to do can't be done. :)​

Perhaps, you missed a message from him when he states that
configuration style does no matter for him really.
So, what he wants can be done, just using different style.


a picture would do wonders to understand what he wants
​.


​A FreeBSD system with multiple NICs, with separate vlans internally 
to separate untagged traffic between PCs.​


https://forums.freebsd.org/threads/bridge-with-vlans-not-working.65592/

​​https://forums.freebsd.org/attachments/capture-png.4744/

​https://forums.freebsd.org/threads/bridge-with-vlans-not-working.65592/#lg=post-385584=0

​The "easy" solution is to just bridge together the interfaces you 
want to be part of the same "virtual lan", thus allowing traffic 
between those stations only.  Want PC1 and PC2 to be part of one 
vlan?  Then bridge together igb0 and igb1.  Want PC3, connected to 
igb2, and PC4, connected to igb3, to be part of a separate "virtual 
lan"?  Then create a separate bridge between igb2 and igb3. No vlan 
tags required anywhere.


ok so does he want to have those vlans terminated at his box or just 
pass them through?

and if they are untagged,  why is it being called a vlan?
untagged vlan is what we call "ethernet".

if it's untagged then only the internal state of the switches decides 
which "virtual network" it is on..






But, the OP (in the forum thread and here) keeps getting hung up on 
"needing" vlan tags on the NICs, trying to treat the FreeBSD box 
like a switch with hybrid ports and PVIDs set on the ports.


--
Freddie Cash
fjwc...@gmail.com <mailto:fjwc...@gmail.com>



___
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: NETGRAPH- bridge vlans using netgraph help

[Julian Elischer]

On 1/5/18 2:08 am, Eugene Grosbein wrote:

01.05.2018 1:03, Freddie Cash wrote:


On Mon, Apr 30, 2018 at 10:59 AM, Eugene Grosbein >wrote:

 > What the OP is trying to do is have PC1 send untagged packets to igb0 on 
FreeBSD which is configured for tagged vlan 5.
 > Then bridge the packets to igb1 which is also configured for tagged vlan 
5.  Then send the packets out, untagged, to PC2.

 Why would one want to "configure igb0 for tagged vlan 5" when igb0 
supposed to receive untagged frames?
 This does not make any sense. One should just bridge igb0 as is, without 
creation vlan on it and problem's solved.

​Yes, agree.  What the OP wants to do can't be done.  :)​

Perhaps, you missed a message from him when he states that configuration style 
does no matter for him really.
So, what he wants can be done, just using different style.
  


a picture would do wonders to understand what he wants.



___
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"

Re: ipfw -- selecting locally generated packets

[Julian Elischer]

On 1/5/18 2:02 am, Eugene Grosbein wrote:

01.05.2018 0:48, Jeff Kletsky wrote:


 From time to time, I rewrite my firewall rules to take advantages of the 
ever-improving set of features that ipfw provides. One of the challenges I have 
faced in the past was selecting packets that are generated on the firewall host 
itself, as opposed to those that it received through an interface.

While I find most of the Linux firewall implementations untenable for a variety of reasons, it does provide 
differentiation between what they call "OUTPUT" and "FORWARD". I'm looking to see if 
there is a "better" way to implement this kind of selection with the 11.1 version of ipfw.

"out and not in" may years ago seemed an obvious selector, and it's good to see that it is now 
clearly documented that it doesn't work in "man ipfw" with "(in fact, out is implemented as 
not in)".

"not recv any" doesn't seem to be helpful either

 $ sudo ipfw add 64000 count ip from any to any out xmit any not recv any
 64000 count ip from any to any out

In the past, I've tagged all incoming packets and used that tag to 
differentiate between the two.

Is there something "cleaner" (or perhaps clearer) that using a tag in that way?

I have been using "from me" for years and it works.
If you have NAT, process "from me" packets before translating outgoing packets
and process "to me" after translating incoming packet

On a host with two interfaces you can use subtraction..
i.e in the outgoing part of the rules you can test on recv xxx0 and if 
it doesn't match it must be locally generated.
 I've also used the uid rule, which can only match on local packets 
ut it only works if you only have a single 'user' on an appliance.





___
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"

Re: NETGRAPH- bridge vlans using netgraph help

[Julian Elischer]

On 28/4/18 8:28 pm, Eugene Grosbein wrote:

28.04.2018 19:10, Abdullah Tariq wrote:


   However, we still have several ways to bridge tagged traffic
 by means of creation multiple bridges (one per vlan) or using 
ng_vlan+ng_bridge to do the same.

bridge1 will contain vlan 1
bridge2 will containn vlan2

and bridge3 should have bridge1 and bridge2?

No, its simplier: single bridge contains all interfaces corresponting to ports 
of single vlan.
You can bridge plain igb* interfaces for untagged ports; or bridge interface 
igbX with interface vlanY
when one port carries untagged frames of vlan and another ports carries tagged 
frames of the same vlan;
or bridge interface vlans together when all of them carry tagged frames of the 
vlan.


If not, can you please give some instructions/guidelines for   
ng_vlan+ng_bridge?

I still think you should not dive into building complex netgraph structures
while the task can be solved simplier. But if you want to take that path, start 
by
reading man ng_vlan, man ng_ether, man ng_bridge and man ng_eiface and try 
examples therein.


and read this:
https://people.freebsd.org/~julian/netgraph.html



___
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"

Re: kldload ibcore.ko fails in snapshot: FreeBSD-12.0-CURRENT-amd64-20180329-r331740-disc1

[Julian Elischer]

On 24/4/18 3:15 pm, Hans Petter Selasky wrote:

On 04/24/18 01:33, Somayajulu, David wrote:

Hi All,
kldload ibcore.ko
fails in the above snapshot with the following error.

# kldload -v /usr/obj/usr/src/amd64.amd64/sys/modules/ibcore/ibcore.ko
kldload: an error occurred while loading module 
/usr/obj/usr/src/amd64.amd64/sys/modules/ibcore/ibcore.ko. Please 
check dmesg(8) for more details.


/var/log/messages indicates the following.

Apr 23 16:28:07 bsd25_12 kernel: link_elf_obj: symbol if_index 
undefined
Apr 23 16:28:07 bsd25_12 kernel: linker_load_file: 
/usr/obj/usr/src/amd64.amd64/sys/modules/ibcore/ibcore.ko - 
unsupported file type


What am I missing?



Hi,

It looks like ibcore.ko was built w/o DEBUG_FLAGS="-DVIMAGE=1"


that shouldn't be in debug flags..   Not sure WHERE it should be, but 
I think that isn't it.

(may work though)




--HPS

___
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"

Re: Need Netgraph Help [fixed]

[Julian Elischer]

On 24/4/18 12:11 am, John Lyon wrote:

If you found that thread, you found my answer. :-)  I'm one of the posters
on that particular PFSense thread.

In short summary, I have a theory that should work but I haven't tested it
yet due to a lack of opportunity.  The netgraph code that forwards the
EAP-OL traffic works.  The problem is handling the fact that ATT tags all
traffic as VLAN ID 0, which FreeBSD's vlan interface does not support.  I
filed a bug report on the matter, but was told "use Netgraph".  Basically,
you either have to add/remove the vlan 0 tag since you can't create a
virtual interface on vlan 0 like you can in Linux.


ok so here's what you need to do
disable hw vlan so that vlan headers are visible to netgraph
pass BOTH interfaces directly into a vlan0 netgraph node, oriented so 
the tagged side faces the interface and teh untagged side faces the  
(single) eap filter.
The NON eap traffic is sent to the "upper" hook of the main 
interface..  The second interface has nothing attached to its upper 
hook  (as in teh diagram  sent).
The question is whether ALL traffic is vlan 0 or just traffic direct 
to the RG?


As I said it may be a neat feature to teach the etf node about vlans 
and even Q-in-Q.






John L. Lyon
PGP Key Available At:
https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc

On Sun, Apr 22, 2018 at 12:52 AM, GPz1100a  wrote:


@John

Did you ever get this fully figured out?  I'm trying to do what I think is
the same thing with my fiber internet connection - eliminate the need to
use
the isp provided gateway (or at least reduce its function). I'm running
*opnsense*.   This thread
https://forum.pfsense.org/index.php?topic=111043.msg793292#msg793292 is
what
led me here.

Three nics correspond to the following

em0 - ONT (WAN)
xl0 - 3com pci - isp provided residential gateway (RG)
ue0 - usb nic - LAN

Using Julian's code from Jan 06, 2018; 1:39pm,

  ngctl mkpeer em0: etf lower downstream
  ngctl name em0:lower waneapfilter
  ngctl connect waneapfilter: em0: nomatch upper

  ngctl mkpeer xl0: etf lower downstream
  ngctl name  xl0:lower laneapfilter
  ngctl connect laneapfilter:  xl0: nomatch upper

*ngctl connect waneapfilter laneapfilter eapout eapout*

  ngctl msg waneapfilter: 'setfilter { matchhook="eapout"
ethertype=0x888e }'
  ngctl msg laneapfilter: 'setfilter { matchhook="eapout"
ethertype=0x888e }'

When I get to the command in bold it comes back with this error:

root@OPNsense:~ #  ngctl connect waneapfilter laneapfilter eapout
eapout
ngctl: send msg: No such file or directory

I'm not sure how to proceed from here.

Thanks for any help you (or others) can offer.

--J




--
Sent from: http://freebsd.1045724.x6.nabble.com/freebsd-net-f4005075.html
___
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"



___
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: Need Netgraph Help [fixed]

[Julian Elischer]

On 23/4/18 6:11 pm, Julian Elischer wrote:

On 23/4/18 5:55 pm, Julian Elischer wrote:

On 22/4/18 12:52 pm, GPz1100a wrote:

@John

Did you ever get this fully figured out?  I'm trying to do what I 
think is
the same thing with my fiber internet connection - eliminate the 
need to use
the isp provided gateway (or at least reduce its function). I'm 
running

*opnsense*.   This thread
https://forum.pfsense.org/index.php?topic=111043.msg793292#msg793292 
is what

led me here.

Three nics correspond to the following

em0 - ONT (WAN)
xl0 - 3com pci - isp provided residential gateway (RG)
ue0 - usb nic - LAN

Using Julian's code from Jan 06, 2018; 1:39pm,

  ngctl mkpeer em0: etf lower downstream
  ngctl name em0:lower waneapfilter
  ngctl connect waneapfilter: em0: nomatch upper

  ngctl mkpeer xl0: etf lower downstream
  ngctl name  xl0:lower laneapfilter
  ngctl connect laneapfilter:  xl0: nomatch upper

*    ngctl connect waneapfilter laneapfilter eapout eapout*

  ngctl msg waneapfilter: 'setfilter { matchhook="eapout"
ethertype=0x888e }'
  ngctl msg laneapfilter: 'setfilter { matchhook="eapout"
ethertype=0x888e }'

When I get to the command in bold it comes back with this error:

root@OPNsense:~ #  ngctl connect waneapfilter laneapfilter 
eapout eapout

ngctl: send msg: No such file or directory

I'm not sure how to proceed from here.

Thanks for any help you (or others) can offer.

--J



I wish I had known the full picture before..
then I could have added the required bits:

So  think you need this:

ONT]em0]lower---downstream[eapfilter:]nomatchvlan0[VLAN]downstreamupper[em0... 


                                         eapout
                                             |
                                             |
                 |
RG]--em1]lower---/


the following line is no longer true of course

  ie. use an etf node on each interface.




ngctl mkpeer igb0: etf lower downstream
ngctl name igb0:lower eapfilter
    ngctl mkpeer igb0: vlan upper downstream
    ngctl name igb0:upper vlanheader
    ngctl msg vlanheader: addfilter '{ vlan=0 hook="vlan0" }'
ngctl connect vlanheader: eapfilter: vlan0 nomatch
    ngctl connect eapfilter: igb1: eapout lower
ngctl msg waneapfilter: 'setfilter { matchhook="eapout" 
ethertype=0x888e }'


however having sent this I realise it may not work.. because the etf 
node doesn't take into account vlan labels, because vlan labels are 
them selvesm in fact a special case of ethertype.. (0x8100)


so to know if this will work I need to know what a packet at the 
netgraph insertion point looks like:


to find this out, attach the nghook program to an inserted ngtee 
node (inserted somewhere in your current graph) and see what comes 
out. (with -a ).


so we can see what the packets look like.


see 
https://forum.pfsense.org/index.php?action=post;topic=111043.30;last_msg=798618









note the vlan node is inserted "backwards"..




--
Sent from: 
http://freebsd.1045724.x6.nabble.com/freebsd-net-f4005075.html

___
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"




___
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"

Re: Need Netgraph Help [fixed]

[Julian Elischer]

On 23/4/18 5:55 pm, Julian Elischer wrote:

On 22/4/18 12:52 pm, GPz1100a wrote:

@John

Did you ever get this fully figured out?  I'm trying to do what I 
think is
the same thing with my fiber internet connection - eliminate the 
need to use
the isp provided gateway (or at least reduce its function). I'm 
running

*opnsense*.   This thread
https://forum.pfsense.org/index.php?topic=111043.msg793292#msg793292 
is what

led me here.

Three nics correspond to the following

em0 - ONT (WAN)
xl0 - 3com pci - isp provided residential gateway (RG)
ue0 - usb nic - LAN

Using Julian's code from Jan 06, 2018; 1:39pm,

  ngctl mkpeer em0: etf lower downstream
  ngctl name em0:lower waneapfilter
  ngctl connect waneapfilter: em0: nomatch upper

  ngctl mkpeer xl0: etf lower downstream
  ngctl name  xl0:lower laneapfilter
  ngctl connect laneapfilter:  xl0: nomatch upper

*    ngctl connect waneapfilter laneapfilter eapout eapout*

  ngctl msg waneapfilter: 'setfilter { matchhook="eapout"
ethertype=0x888e }'
  ngctl msg laneapfilter: 'setfilter { matchhook="eapout"
ethertype=0x888e }'

When I get to the command in bold it comes back with this error:

root@OPNsense:~ #  ngctl connect waneapfilter laneapfilter 
eapout eapout

ngctl: send msg: No such file or directory

I'm not sure how to proceed from here.

Thanks for any help you (or others) can offer.

--J



I wish I had known the full picture before..
then I could have added the required bits:

So  think you need this:

ONT]em0]lower---downstream[eapfilter:]nomatchvlan0[VLAN]downstreamupper[em0... 


                                         eapout
                                             |
                                             |
                 |
RG]--em1]lower---/


the following line is no longer true of course

  ie. use an etf node on each interface.




ngctl mkpeer igb0: etf lower downstream
ngctl name igb0:lower eapfilter
    ngctl mkpeer igb0: vlan upper downstream
    ngctl name igb0:upper vlanheader
    ngctl msg vlanheader: addfilter '{ vlan=0 hook="vlan0" }'
ngctl connect vlanheader: eapfilter: vlan0 nomatch
    ngctl connect eapfilter: igb1: eapout lower
ngctl msg waneapfilter: 'setfilter { matchhook="eapout" 
ethertype=0x888e }'


however having sent this I realise it may not work.. because the etf 
node doesn't take into account vlan labels, because vlan labels are 
them selvesm in fact a special case of ethertype.. (0x8100)


so to know if this will work I need to know what a packet at the 
netgraph insertion point looks like:


to find this out, attach the nghook program to an inserted ngtee node 
(inserted somewhere in your current graph) and see what comes out. 
(with -a ).


so we can see what the packets look like.






note the vlan node is inserted "backwards"..




--
Sent from: 
http://freebsd.1045724.x6.nabble.com/freebsd-net-f4005075.html

___
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"




___
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: Need Netgraph Help [fixed]

[Julian Elischer]

On 22/4/18 12:52 pm, GPz1100a wrote:

@John

Did you ever get this fully figured out?  I'm trying to do what I think is
the same thing with my fiber internet connection - eliminate the need to use
the isp provided gateway (or at least reduce its function). I'm running
*opnsense*.   This thread
https://forum.pfsense.org/index.php?topic=111043.msg793292#msg793292 is what
led me here.

Three nics correspond to the following

em0 - ONT (WAN)
xl0 - 3com pci - isp provided residential gateway (RG)
ue0 - usb nic - LAN

Using Julian's code from Jan 06, 2018; 1:39pm,

  ngctl mkpeer em0: etf lower downstream
  ngctl name em0:lower waneapfilter
  ngctl connect waneapfilter: em0: nomatch upper

  ngctl mkpeer xl0: etf lower downstream
  ngctl name  xl0:lower laneapfilter
  ngctl connect laneapfilter:  xl0: nomatch upper

*ngctl connect waneapfilter laneapfilter eapout eapout*

  ngctl msg waneapfilter: 'setfilter { matchhook="eapout"
ethertype=0x888e }'
  ngctl msg laneapfilter: 'setfilter { matchhook="eapout"
ethertype=0x888e }'

When I get to the command in bold it comes back with this error:

root@OPNsense:~ #  ngctl connect waneapfilter laneapfilter eapout eapout
ngctl: send msg: No such file or directory

I'm not sure how to proceed from here.

Thanks for any help you (or others) can offer.

--J



I wish I had known the full picture before..
then I could have added the required bits:

So  think you need this:

ONT]em0]lower---downstream[eapfilter:]nomatchvlan0[VLAN]downstreamupper[em0... 


                                         eapout
                                             |
                                             |
                 |
RG]--em1]lower---/

  ie. use an etf node on each interface.

ngctl mkpeer igb0: etf lower downstream
ngctl name igb0:lower eapfilter
    ngctl mkpeer igb0: vlan upper downstream
    ngctl name igb0:upper vlanheader
    ngctl msg vlanheader: addfilter '{ vlan=0 hook="vlan0" }'
ngctl connect vlanheader: eapfilter: vlan0 nomatch
    ngctl connect eapfilter: igb1: eapout lower
ngctl msg waneapfilter: 'setfilter { matchhook="eapout" 
ethertype=0x888e }'


note the vlan node is inserted "backwards"..




--
Sent from: http://freebsd.1045724.x6.nabble.com/freebsd-net-f4005075.html
___
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"

Re: Need Netgraph Help [fixed]

[Julian Elischer]

On 22/4/18 12:52 pm, GPz1100a wrote:

@John

Did you ever get this fully figured out?  I'm trying to do what I think is
the same thing with my fiber internet connection - eliminate the need to use
the isp provided gateway (or at least reduce its function). I'm running
*opnsense*.   This thread
https://forum.pfsense.org/index.php?topic=111043.msg793292#msg793292 is what
led me here.

Three nics correspond to the following

em0 - ONT (WAN)
xl0 - 3com pci - isp provided residential gateway (RG)
ue0 - usb nic - LAN

Using Julian's code from Jan 06, 2018; 1:39pm,

  ngctl mkpeer em0: etf lower downstream
  ngctl name em0:lower waneapfilter
  ngctl connect waneapfilter: em0: nomatch upper

  ngctl mkpeer xl0: etf lower downstream
  ngctl name  xl0:lower laneapfilter
  ngctl connect laneapfilter:  xl0: nomatch upper

*ngctl connect waneapfilter laneapfilter eapout eapout*


missing colon after waneapfilter



  ngctl msg waneapfilter: 'setfilter { matchhook="eapout"
ethertype=0x888e }'
  ngctl msg laneapfilter: 'setfilter { matchhook="eapout"
ethertype=0x888e }'

When I get to the command in bold it comes back with this error:

root@OPNsense:~ #  ngctl connect waneapfilter laneapfilter eapout eapout
ngctl: send msg: No such file or directory

I'm not sure how to proceed from here.

Thanks for any help you (or others) can offer.

--J




--
Sent from: http://freebsd.1045724.x6.nabble.com/freebsd-net-f4005075.html
___
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"

Re: Default network device

[Julian Elischer]

On 25/3/18 12:21 am, Grzegorz Junka wrote:

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.

It's decided by the routing table
if you can get the routing table to reflect what you want it should work.



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"



___
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: Diagnosing terrible ixl performance

[Julian Elischer]

On 20/4/18 12:03 pm, Garrett Wollman wrote:

I'm commissioning a new NFS server with an Intel dual-40G XL710
interface, running 11.1.  I have a few other servers with this
adapter, although not running 40G, and they work fine so long as you
disable TSO.  This one ... not so much.  On the receive side, it gets
about 600 Mbit/s with lots of retransmits.  On the *sending* side,
though, it's not even able to sustain 10 Mbit/s -- but there's no
evidence of retransmissions, it's just sending really really slowly.
(Other machines with XL710 adapters are able to sustain full 10G.)
There is no evidence of any errors on either the adapter or the switch
it's connected to.

So far, I've tried:

- Using the latest Intel driver (no change)
- Using the latest Intel firmware (breaks the adapter)
- Disabling performance tweaks in loader.conf and sysctl.conf
- Changing congestion-control algorithms

replacing  card?  obvious but you don't list it...



Anyone have suggestions while I still have time to test this?  (My
plan B is to fall back to an X520 card that I have in my spares kit,
because I *know* those work great with no faffing about.)  Any
relevant MIBs to inspect?

The test I'm doing here is simple iperf over TCP, with MTU 9120.  It
takes about 10 seconds for the sending side to complete, but buffers
are severely constipated for 20 seconds after that (delaying all
traffic, including ssh connections).

I'm at the point of trying different switch ports just to eliminate
that as a possibility.

that is also a possibility, as well as swap cables with a good machine...



-GAWollman
___
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"

Re: Bridging a vlan trunk with a gif tunnel?

[Julian Elischer]

On 1/4/18 11:58 pm, Eugene Grosbein wrote:

01.04.2018 21:42, Hauke Fath wrote:


I am trying to network a remote site with a main site through a bridged
gif tunnel, and it doesn't work for me.

gif(4) supports only untagged frames when added to a bridge.
You need to create gif-per-vlan or switch to newer vxlan(4).


I have in the past implemented this using netgraph and vnet
but it was quite a log time ago and I forget many of the details
The vnet jail was so that the gif tunnel effectively left from
"another machine" (it was the same machine with a vnet jail)
The reason was so that net failures were "one hop away" and
therefore not so hard to work around.


In the past, I have set up a similar link by tunneling ip over gif, but
routing turned out to be intricate

what problems do you have with routing over gif? It works just fine for me.


and I figured just bridging the exclave with the main site would save me 
routing issues,

And bring in bridging issues that are more severe.


plus I could  stick with the existing subnets.

And have extra overhead to pass +14 bytes of headers of MAC addresses per frame.

Single gif+bridge does not support trunks.


___
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"

Re: Same host or different? How can you tell "over the wire"?

[Julian Elischer]

On 22/3/18 7:30 am, Ronald F. Guilmette wrote:

In message <5ab2d11a.6060...@grosbein.net>,
Eugene Grosbein  wrote:


If they respond truly identically, there are no reasons to treat them like
distinct hosts
despite of different IP addresses.

are you on the same segment as them?

___
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: Raw Sockets: Two Questions

[Julian Elischer]

On 22/3/18 3:08 am, Eugene Grosbein wrote:

22.03.2018 1:08, Ronald F. Guilmette wrote:


OK, so, if I have understood all that has been said in this thread so
far, then I would assert that, from the perspective of a simple-minded
and naive end user (e.g. me), the assertion that I originally quoted
-is- in fact correct, i.e. one -cannot- just simply do sendto/recvfrom
(and expect to get back responses) if the raw packets that one sends out
happen to be, for example, well formed TCP or UDP packets.

Not exactly. You can't use raw sockets to receive but that does not mean
you cannot use sendto/recvfrom (or similar calls) at all: there are
libpcap, libdnet and NETGRAPH allowing to send requests and receive answers.


If I have correctly understood Matt Joras, there -are- ways to get hold
of such reply packets, under FreeBSD, but those require getting a bit more
"under the hood" in order to actually get hold of them... more than just
a simple recvfrom on the RAW socket.

Why should you concentrate on RAW sockets?

I have small perl script that sends manually crafted PPPoE frames
and receives replies using simple libpcap interface:

use Net::Pcap qw(:DEFAULT :functions);

use constant V8021Q => 0x8100;
use constant ETHERTYPE_PPPOEDISC=> 0x8863;
use constant PPPOE_VER  => 1;
use constant PPPOE_TYPE => 1;
use constant PADO_CODE  => 7;
use constant PADI_CODE  => 9;
use constant TAG_END_OF_LIST=> 0x;
use constant TAG_SERVICE_NAME   => 0x0101;
use constant TAG_AC_NAME=> 0x0102;
use constant TAG_HOST_UNIQ  => 0x0103;

$packet =
 # Ethernet header: dst MAC, src MAC, TYPE
 ether_aton('ff:ff:ff:ff:ff:ff') . $bmac . pack('n', ETHERTYPE_PPPOEDISC) .
 # PPPoE PADI: VER, TYPE, CODE, SESSION_ID=0
 pack('C', (PPPOE_VER<<4) + PPPOE_TYPE) . pack('C', PADI_CODE) . pack('n', 
0)
 # LENGTH, tags
 pack('n', $tlen) . $tags;
# zero padding upto 60 bytes ethernet frame length (without checksum)
$packet .= pack('a' . (40-$tlen) , '') if $tlen < 40;

err("cannot open interface $interface: $err")
 unless $pcap = pcap_open_live($interface, $snaplen, 0, 0, \$err);
err("could not send PADI")
   if pcap_sendpacket($pcap, $packet) != 0;

$filter = "ether proto " . ETHERTYPE_PPPOEDISC . " and ether dst $mac";
err("cannot compile filter: $filter")
   if pcap_compile($pcap, \$bpf, $filter, 1, 0) < 0;
pcap_setfilter($pcap, $bpf);

$ec = 0;
while($ec == 0) {
   $ec = pcap_loop($pcap, -1, \, undef);
}
pcap_close($pcap);
exit(0);

sub callback($$$) {
   return if $_[1]->{'len'} < 20;# sanity check: short frame
   my ($dst, $src, $ftype, $ftag, $fp) = unpack('a6a6na4a*' , $_[2]);
   ...
}

why not just use the ng-pppoe node? :-)

___
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"

Re: Need Netgraph Help [fixed]

[Julian Elischer]

Hi John, did you ever try out my version?

Julian

On 7/1/18 4:06 am, Julian Elischer wrote:

On 7/1/18 4:02 am, John Lyon wrote:

Thanks for the clarification and all the help.

After Marko clarified that that edges/hooks are bidirectional, I 
was able to get it working WAN to LAN and LAN to WAN by using a 
pair of one2many and ETF nodes.


The commands were (from memory):

#Create Unfiltered WAN Path
ngctl mkpeer igb0: one2many lower one
ngctl name igb0:lower wanmux
ngctl mkpeer wanmux: etf many0 downstream
ngctl name wanmux:many0 wanfilter
ngctl connect wanfilter: igb0: nomatch upper

#Create Unfilter LAN Path
ngctl mkpeer igb1: one2many lower one
ngctl name igb1:lower lanmux
ngctl mkpeer lanmux: etf many0 downstream
ngctl name lanmux:many0 lanfilter
ngctl connect lanfilter: igb1 nomatch upper

#Cross Connect Two Paths
ngctl connect wanfilter wanmux waneapout many1
ngctl connect lanfilter lanmux laneapout many1

#Filter Cross Connections
ngctl msg wanfilter: 'setfilter { matchhook="waneapout" 
ethertype=0x888e }'
ngctl msg lanfilter: 'setfilter { matchhook="laneapout" 
ethertype=0x888e }'


The graph looks like this:

igb0] <> [mux0] <---> [etf0] <> [igb0
                               \       /
                                  X
                               /      \
igb1] <> [mux1] <---> [etf1] <> [igb1


It was conceptually easier for me to wrap my head around and it 
appears to work (somewhat).  But if I can get it to work, I like 
Julian's approach better as it is simpler and uses fewer nodes.


etf includes a mux/demux..  the link is bidirectional.




Thanks again for all the help!


John L. Lyon
PGP Key Available At:
https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc

On Sat, Jan 6, 2018 at 2:39 PM, Julian Elischer <jul...@freebsd.org 
<mailto:jul...@freebsd.org>> wrote:




___
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: Need Netgraph Help [fixed]

[Julian Elischer]

On 7/1/18 4:02 am, John Lyon wrote:

Thanks for the clarification and all the help.

After Marko clarified that that edges/hooks are bidirectional, I was 
able to get it working WAN to LAN and LAN to WAN by using a pair of 
one2many and ETF nodes.


The commands were (from memory):

#Create Unfiltered WAN Path
ngctl mkpeer igb0: one2many lower one
ngctl name igb0:lower wanmux
ngctl mkpeer wanmux: etf many0 downstream
ngctl name wanmux:many0 wanfilter
ngctl connect wanfilter: igb0: nomatch upper

#Create Unfilter LAN Path
ngctl mkpeer igb1: one2many lower one
ngctl name igb1:lower lanmux
ngctl mkpeer lanmux: etf many0 downstream
ngctl name lanmux:many0 lanfilter
ngctl connect lanfilter: igb1 nomatch upper

#Cross Connect Two Paths
ngctl connect wanfilter wanmux waneapout many1
ngctl connect lanfilter lanmux laneapout many1

#Filter Cross Connections
ngctl msg wanfilter: 'setfilter { matchhook="waneapout" 
ethertype=0x888e }'
ngctl msg lanfilter: 'setfilter { matchhook="laneapout" 
ethertype=0x888e }'


The graph looks like this:

igb0] <> [mux0] <---> [etf0] <> [igb0
                               \       /
                                  X
                               /      \
igb1] <> [mux1] <---> [etf1] <> [igb1


It was conceptually easier for me to wrap my head around and it 
appears to work (somewhat).  But if I can get it to work, I like 
Julian's approach better as it is simpler and uses fewer nodes.


etf includes a mux/demux..  the link is bidirectional.




Thanks again for all the help!


John L. Lyon
PGP Key Available At:
https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc

On Sat, Jan 6, 2018 at 2:39 PM, Julian Elischer <jul...@freebsd.org 
<mailto:jul...@freebsd.org>> wrote:


On 6/1/18 9:22 pm, John Lyon wrote:

I just woke up with a follow-up question that may be my aha
moment.  Are Netgraph edges between nodes always bidirectional?
I have been treating all of the edges as unidirectional,
requiring me to create two separate Netgraphs.  But if they are
bidirectional, that would explain some things.


yes edges are bidirectional

see the following paragraph from the ng_etf man page:
-
     Packets traveling in the other direction (towards the
downstream hook)
 are also examined and filtered.  If a packet has an
ethertype that
 matches one of the values configured into the node, it must
have arrived
 in on the hook for which that value was configured,
otherwise it will be
 discarded.  Ethertypes of values other than those
configured by the con-
 trol messages must have arrived via the nomatch hook.
-

here is the picture of what you need,
You will see this below in the old emails:

so you need this:

em0]lower---downstream[ETF0]nomatch---upper[em0...
   eapout
   |
   |
   eapout
em1]lower---downstream[ETF1]nomatch---upper[em1...

  ie. use an etf node on each interface.

    ngctl mkpeer igb0: etf lower downstream
    ngctl name igb0:lower waneapfilter
    ngctl connect waneapfilter: igb0: nomatch upper

    ngctl mkpeer igb1: etf lower downstream
    ngctl name igb1:lower laneapfilter
    ngctl connect laneapfilter: igb1: nomatch upper

    ngctl connect waneapfilter laneapfilter eapout eapout

    ngctl msg waneapfilter: 'setfilter { matchhook="eapout"
ethertype=0x888e }'
    ngctl msg laneapfilter: 'setfilter { matchhook="eapout"
ethertype=0x888e }'



Thanks.

Sent from my iPhone

On Jan 5, 2018, at 11:16 PM, John Lyon <johnll...@gmail.com
<mailto:johnll...@gmail.com>> wrote:


Julian,

So this didn't work when I tried to implement it on hardware
in real life and I can't figure out why.  I am sure it's
really basic, but the error message is not very descriptive.

I use the following script to create a graph that filters the
EAP traffic and forwards directly from the first Ethernet
interface to the second.  It works perfectly.

    kldload ng_etf
    ngctl mkpeer igb0: etf lower downstream
    ngctl name igb0:lower waneapfilter
    ngctl connect waneapfilter: igb0: nomatch upper
    ngctl connect wanfilter: igb1: waneapout lower
    ngctl msg wanfilter: 'setfilter { matchhook="waneapout"
ethertype=0x888e }'

The end result is that EAPOL frames are forwarded directly
from igb0 (WAN) to igb1 (LAN).  Graphically, it looks like
(arrows indicating flow of traffic):
igb0]lower--->>downstream[ETF0]nomatch--->>upper[igb0...
waneapout
|
|-->>lower[igb1

Re: Need Netgraph Help [fixed]

[Julian Elischer]

On 6/1/18 9:22 pm, John Lyon wrote:
I just woke up with a follow-up question that may be my aha moment. 
 Are Netgraph edges between nodes always bidirectional? I have been 
treating all of the edges as unidirectional, requiring me to create 
two separate Netgraphs.  But if they are bidirectional, that would 
explain some things.


yes edges are bidirectional

see the following paragraph from the ng_etf man page:
-
     Packets traveling in the other direction (towards the downstream 
hook)

 are also examined and filtered.  If a packet has an ethertype that
 matches one of the values configured into the node, it must have 
arrived
 in on the hook for which that value was configured, otherwise it 
will be
 discarded.  Ethertypes of values other than those configured by 
the con-

 trol messages must have arrived via the nomatch hook.
-

here is the picture of what you need,
You will see this below in the old emails:

so you need this:

em0]lower---downstream[ETF0]nomatch---upper[em0...
   eapout
   |
   |
   eapout
em1]lower---downstream[ETF1]nomatch---upper[em1...

  ie. use an etf node on each interface.

    ngctl mkpeer igb0: etf lower downstream
    ngctl name igb0:lower waneapfilter
    ngctl connect waneapfilter: igb0: nomatch upper

    ngctl mkpeer igb1: etf lower downstream
    ngctl name igb1:lower laneapfilter
    ngctl connect laneapfilter: igb1: nomatch upper

    ngctl connect waneapfilter laneapfilter eapout eapout

    ngctl msg waneapfilter: 'setfilter { matchhook="eapout" 
ethertype=0x888e }'
    ngctl msg laneapfilter: 'setfilter { matchhook="eapout" 
ethertype=0x888e }'




Thanks.

Sent from my iPhone

On Jan 5, 2018, at 11:16 PM, John Lyon <johnll...@gmail.com 
<mailto:johnll...@gmail.com>> wrote:



Julian,

So this didn't work when I tried to implement it on hardware in 
real life and I can't figure out why.  I am sure it's really basic, 
but the error message is not very descriptive.


I use the following script to create a graph that filters the EAP 
traffic and forwards directly from the first Ethernet interface to 
the second.  It works perfectly.


    kldload ng_etf
    ngctl mkpeer igb0: etf lower downstream
    ngctl name igb0:lower waneapfilter
    ngctl connect waneapfilter: igb0: nomatch upper
    ngctl connect wanfilter: igb1: waneapout lower
    ngctl msg wanfilter: 'setfilter { matchhook="waneapout" 
ethertype=0x888e }'


The end result is that EAPOL frames are forwarded directly from 
igb0 (WAN) to igb1 (LAN).  Graphically, it looks like (arrows 
indicating flow of traffic):

igb0]lower--->>downstream[ETF0]nomatch--->>upper[igb0...
waneapout
|
|-->>lower[igb1
However, I also need to do the reverse and forward EAPOL frames in the opposite 
direction from igb1 (LAN) to igb0 (WAN).  Graphically, I want (arrows 
indicating flow):
igb1]lower--->>downstream[ETF1]nomatch--->>upper[igb1... laneapout | 
|-->>lower[igb0

So I try a mirror image of my first script.  However, when I type the first 
line of:
 ngctl mkpeer igb1: etf lower downstream
I get the following error message:
 ngctl: send msg: File exists.
My guess (based on an earlier email in this thread) is that because I've already 
connected my first NG_ETF node to the lower hook of igb1 (in order to forward traffic out 
that interface), I am getting the error that the "File exists" when I try to 
connect a second ETF node to igb1 lower.  If this is the case, how can I write traffic 
out the interface, while filtering incoming traffic on the same interface? I tried to 
used two different ETF nodes, as suggested, but get an error message when I try.
Thanks for any help.  I feel like I am so close.  At this point, I probably 
should have just jumped ship and tried an alternate solution, but I just can't 
allow the machine to win. :-)  I have to get this working!


John L. Lyon
PGP Key Available At:
https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc

On Fri, Dec 29, 2017 at 4:06 AM, Julian Elischer 
<jul...@freebsd.org <mailto:jul...@freebsd.org>> wrote:


On 29/12/17 10:52 am, John Lyon wrote:

It works!!!  In virtual machine land at least, it works!  It
will be interesting to see what happens when the rubber meets
the road and I actually test it "in the field."

The issue was a missing single line that was not obvious from
the man pages:

    sudo ngctl connect eapfilter: ix1: eapout lower

your next issue will be that you can only attach em1:lower to a
single peer at a time. So return packets can not DTRT.

You will need to either put a multiplexing node in each
interface, OR if I wrote it correctly, use the fact that

Re: VLANing between jails not segmenting traffic

[Julian Elischer]

On 31/10/17 5:26 am, Eugene Grosbein wrote:

31.10.2017 4:08, Farhan Khan пишет:

Hi all,

I am trying to experiment with setting up two jails on different VLANs, but 
have not been able to segment traffic.

My configuration was to create vlan1 for jail1 and vlan2 for jail2.

I did the following commands:
ifconfig vlan1 create vlan 1 vlandev em0
ifconfig vlan1 10.1.0.1/24
ifconfig vlan2 create vlan 2 vlandev em0
ifconfig vlan2 10.2.0.1/24

Within each jail, I set the interface to be vlan1 and vlan2 and assigned them 
the IP addresses 10.1.0.2/24 and 10.2.0.2/24, respectively.

I can still have connectivity between the two VLANs.

Oddly enough, jail1 with IP 10.1.0.2 does not even have a static route outbound at all. 
An `ifconfig` shows 0xff00 (/24) so my expected behavior would be to say "unable 
to route". It can even connect to the external interface's IP address. At a minimum 
it should not even know how to connect to the 10.2.0.0/24 network at all.

I was advised that its connectivity is because Jails use the base system's 
routing table. If so, how could one possibly separate network traffic? That's 
the entire purpose of VLANing.

I have been advised to use pf to prevent that, but shouldn't VLANing provide 
that separation mechanism? I do not know what I might be doing wrong here.

It seems you are looking for isolated network stacks for jails each having 
distinct route table etc.
You need options VIMAGE for your kernel and create jails with vnet option (man 
jail)
to obtain this feature.

so, a couple of months later, did you try  out VIMAGE?
it's designed to give you EXACTLY what you are looking for.




___
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"

Re: Need Netgraph Help [fixed]

[Julian Elischer]

On 29/12/17 10:52 am, John Lyon wrote:
It works!!!  In virtual machine land at least, it works!  It will be 
interesting to see what happens when the rubber meets the road and I 
actually test it "in the field."


The issue was a missing single line that was not obvious from the 
man pages:


    sudo ngctl connect eapfilter: ix1: eapout lower
your next issue will be that you can only attach em1:lower to a single 
peer at a time. So return packets can not DTRT.


You will need to either put a multiplexing node in each interface, OR 
if I wrote it correctly, use the fact that packets fed into an etf 
match hook will feed back out the input hook.


so you need this:

em0]lower---downstream[ETF0]nomatch---upper[em0...
   eapout
   |
   |
   eapout
em1]lower---downstream[ETF1]nomatch---upper[em1...

  
ie. use an etf node on each interface.



 





Apparently, I had not created an alias for the connection between 
the ETF and the ether nodes.  Once this connect command was issued, 
the connection to the lower hook of the ether node was ready to be 
connected to the ETF.


Thanks _so much_ for your help.



John L. Lyon
PGP Key Available At:
https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc

On Thu, Dec 28, 2017 at 9:48 AM, Julian Elischer <jul...@freebsd.org 
<mailto:jul...@freebsd.org>> wrote:


    On 28/12/17 9:59 pm, Julian Elischer wrote:

On 28/12/17 1:37 am, John Lyon wrote:

Julian,

Unfortunately, this issue remains unresolved.  I would
like to think that this is just a PEBKAC issue, but I
have tried every permutation of escape characters in
case it's an issue with my syntax and I get the same set
of errors.  No matter what I do, I can't connect the no
match hook of an ETF node to the upper hook of an
ng_ether node.  Do you have any insights into why this
might be occurring?

By the way, thanks for reaching out to me!  I was going
to email you directly after the holidays since your name
and email address are at the bottom of the relevant
Netgraph man pages.  I figured that must mean if you
didn't know the answer, no one does. :-)


what is EAP?
what about return EAP packets? (are there any?)


oops left out a line from the cut-n-paste...


I think this is what you want:
$ sudo ngctl list
There are 7 total nodes:
  Name: igb0    Type: ether   ID: 0001  
Num hooks: 0
  Name: igb1    Type: ether   ID: 0002  
Num hooks: 0
  Name: ix0 Type: ether   ID: 0003  
Num hooks: 0
  Name: ix1 Type: ether   ID: 0004  
Num hooks: 0
  Name: tap0    Type: ether   ID: 0005  
Num hooks: 0
  Name: bridge3 Type: ether   ID: 0006  
Num hooks: 0
  Name: ngctl7372   Type: socket  ID: 0007  
Num hooks: 0
$ sudo kldload ng_etf

$ sudo ngctl mkpeer ix0: etf lower downstream

$ sudo ngctl name ix0:lower eapfilter
$ sudo ngctl connect eapfilter: ix0: nomatch upper
$ sudo ngctl connect eapfilter: ix1: eapout lower
$ sudo ngctl show eapfilter:
  Name: eapfilter   Type: etf ID: 0021  
Num hooks: 3
  Local hook  Peer name   Peer type    Peer ID Peer hook
  --  -   - --- -
  eapout  ix1 ether 0004 lower
  nomatch ix0 ether 0003 upper
  downstream  ix0 ether 0003 lower
$ sudo ngctl msg eapfilter: 'setfilter { matchhook="eapout"
ethertype=0x888e }'
$



Thanks.



John L. Lyon
PGP Key Available At:
https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc
<https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc>

On Wed, Dec 27, 2017 at 10:32 AM, Julian Elischer
<jul...@freebsd.org <mailto:jul...@freebsd.org>
<mailto:jul...@freebsd.org <mailto:jul...@freebsd.org>>>
wrote:

    John did you get a resolution to this issue?


    On 16/12/17 2:59 am, John Lyon wrote:

    Harry and Eugene (and others),

    I appreciate all of your help.  It's been really
    insightful.  Although I
    feel like I'm getting much closer to the
solution, I don't
    think my pro

Re: Need Netgraph Help [fixed]

[Julian Elischer]

On 29/12/17 10:52 am, John Lyon wrote:
It works!!!  In virtual machine land at least, it works!  It will be 
interesting to see what happens when the rubber meets the road and I 
actually test it "in the field."


The issue was a missing single line that was not obvious from the 
man pages:


    sudo ngctl connect eapfilter: ix1: eapout lower

Apparently, I had not created an alias for the connection between 
the ETF and the ether nodes.  Once this connect command was issued, 
the connection to the lower hook of the ether node was ready to be 
connected to the ETF.


The  shown line assigns a linkage for matching frames to use.
Until it exists, you can not use it in a rule.
Match rules can only reference existing hooks.



Thanks _so much_ for your help.



John L. Lyon
PGP Key Available At:
https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc

On Thu, Dec 28, 2017 at 9:48 AM, Julian Elischer <jul...@freebsd.org 
<mailto:jul...@freebsd.org>> wrote:


    On 28/12/17 9:59 pm, Julian Elischer wrote:

On 28/12/17 1:37 am, John Lyon wrote:

Julian,

Unfortunately, this issue remains unresolved.  I would
like to think that this is just a PEBKAC issue, but I
have tried every permutation of escape characters in
case it's an issue with my syntax and I get the same set
of errors.  No matter what I do, I can't connect the no
match hook of an ETF node to the upper hook of an
ng_ether node.  Do you have any insights into why this
might be occurring?

By the way, thanks for reaching out to me!  I was going
to email you directly after the holidays since your name
and email address are at the bottom of the relevant
Netgraph man pages.  I figured that must mean if you
didn't know the answer, no one does. :-)


what is EAP?
what about return EAP packets? (are there any?)


oops left out a line from the cut-n-paste...


I think this is what you want:
$ sudo ngctl list
There are 7 total nodes:
  Name: igb0    Type: ether   ID: 0001  
Num hooks: 0
  Name: igb1    Type: ether   ID: 0002  
Num hooks: 0
  Name: ix0 Type: ether   ID: 0003  
Num hooks: 0
  Name: ix1 Type: ether   ID: 0004  
Num hooks: 0
  Name: tap0    Type: ether   ID: 0005  
Num hooks: 0
  Name: bridge3 Type: ether   ID: 0006  
Num hooks: 0
  Name: ngctl7372   Type: socket  ID: 0007  
Num hooks: 0
$ sudo kldload ng_etf

$ sudo ngctl mkpeer ix0: etf lower downstream

$ sudo ngctl name ix0:lower eapfilter
$ sudo ngctl connect eapfilter: ix0: nomatch upper
$ sudo ngctl connect eapfilter: ix1: eapout lower
$ sudo ngctl show eapfilter:
  Name: eapfilter   Type: etf ID: 0021  
Num hooks: 3
  Local hook  Peer name   Peer type    Peer ID Peer hook
  --  -   - --- -
  eapout  ix1 ether 0004 lower
  nomatch ix0 ether 0003 upper
  downstream  ix0 ether 0003 lower
$ sudo ngctl msg eapfilter: 'setfilter { matchhook="eapout"
ethertype=0x888e }'
$



Thanks.



John L. Lyon
PGP Key Available At:
https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc
<https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc>

On Wed, Dec 27, 2017 at 10:32 AM, Julian Elischer
<jul...@freebsd.org <mailto:jul...@freebsd.org>
<mailto:jul...@freebsd.org <mailto:jul...@freebsd.org>>>
wrote:

    John did you get a resolution to this issue?


    On 16/12/17 2:59 am, John Lyon wrote:

    Harry and Eugene (and others),

    I appreciate all of your help.  It's been really
    insightful.  Although I
    feel like I'm getting much closer to the
solution, I don't
    think my problem
    has been diagnosed.  I've outlined my thought
process
    below.  Can you
    please tell me if I am misunderstanding something?
    Admittedly, I am not a
    kernel developer and my C language skills have
atrophied the
    last few
    years.  However, I've reviewed my s

Re: Need Netgraph Help

[Julian Elischer]

On 29/12/17 12:36 am, John Lyon wrote:
The netgraph bridge would probably forward the 802.1x frames, but 
the man page says that firewalling on the netgraph bridge is not 
supported.  I need to process with the firewall all of the other 
traffic that is not EAPOL frames.

ok







John L. Lyon
PGP Key Available At:
https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc

On Thu, Dec 28, 2017 at 11:10 AM, Julian Elischer 
<jul...@freebsd.org <mailto:jul...@freebsd.org>> wrote:


On 28/12/17 11:58 pm, John Lyon wrote:

Julian,

That looks exactly like what I want!  It also looks like what I
thought I was doing.  I have no idea why it worked for you and
not for me.  :-(

I will copy and paste tonight after work (making changes for
em0 and em1 on my own test system) and see if I can get it to
work.  If it works, I will figure out what I was doing wrong
and let the world know in case anyone wants to Google it in the
future. If it doesn't work -- I'll be back. :-)

To answer your other questions:

(1) EAP (or more accurately in this case EAPOL) is the
extensible authentication protocol over LAN and is used for
802.1X port authentication.  The authentication frames are
marked with the ethertype 0x888e to distinguish them from other
Ethernet frames. They are also assigned the broadcast MAC
address of 01:80:c2:00:00:03. Because 802.1D states that a
standard compliant switch or bridge cannot forward frames with
a MAC address inthe range of 01:80:c2:00:00:00 to
01:80:c2:00:00:0f, you can't just create a bridge in FreeBSD
between the two interfaces since the FreeBSD bridge code is
standard compliant.  So I have to process and forward the
frames another way and it looks like Netgraph will let me do
it.  Otherwise, I'm going to have to patch the bridge code in
the kernel to include a sysctl variable that enables or
disables this compliance.

or use the netgraph bridge. ng_bridge. it doesn't care as far as
I know. it's job it to produce "bump in the wire" devices.
see /usr/share/examples/netgraph.




(2) You are correct that there are return frames (not packets
as this all occurs at layer 2).  However, the graph to handle
the return frames is going to just be a mirror of the the graph
for processing the outgoing frames.  So if I can get it working
in one direction, it's trivial to create a mirror image graph
for the reverse direction.

Thanks!






John L. Lyon
PGP Key Available At:
https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc
<https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc>

On Thu, Dec 28, 2017 at 8:59 AM, Julian Elischer
<jul...@freebsd.org <mailto:jul...@freebsd.org>> wrote:

On 28/12/17 1:37 am, John Lyon wrote:

Julian,

Unfortunately, this issue remains unresolved.  I would
like to think that this is just a PEBKAC issue, but I have
tried every permutation of escape characters in case it's
an issue with my syntax and I get the same set of errors. 
No matter what I do, I can't connect the no match hook of
an ETF node to the upper hook of an ng_ether node.  Do you
have any insights into why this might be occurring?

By the way, thanks for reaching out to me!  I was going to
email you directly after the holidays since your name and
email address are at the bottom of the relevant Netgraph
man pages.  I figured that must mean if you didn't know
the answer, no one does. :-)


what is EAP?
what about return EAP packets? (are there any?)

I think this is what you want:
$ sudo ngctl list
There are 7 total nodes:
  Name: igb0    Type: ether   ID:
0001   Num hooks: 0
  Name: igb1    Type: ether   ID:
0002   Num hooks: 0
  Name: ix0 Type: ether   ID:
0003   Num hooks: 0
  Name: ix1 Type: ether   ID:
0004   Num hooks: 0
  Name: tap0    Type: ether   ID:
0005   Num hooks: 0
  Name: bridge3 Type: ether   ID:
0006   Num hooks: 0
  Name: ngctl7372   Type: socket  ID:
0007   Num hooks: 0
$ sudo kldload ng_etf
$ sudo ngctl name ix0:lower eapfilter
$ sudo ngctl connect eapfilter: ix0: nomatch upper
$ sudo ngctl connect eapfilter: ix1: eapout lower
$ sudo ngctl show eapfilter:
  Name: eapfilter   Type: etf ID:
0021   Num hooks: 3
  Local hook  Peer name Peer t

Re: Need Netgraph Help

[Julian Elischer]

On 28/12/17 11:58 pm, John Lyon wrote:

Julian,

That looks exactly like what I want! It also looks like what I 
thought I was doing.  I have no idea why it worked for you and not 
for me.  :-(


I will copy and paste tonight after work (making changes for em0 and 
em1 on my own test system) and see if I can get it to work.  If it 
works, I will figure out what I was doing wrong and let the world 
know in case anyone wants to Google it in the future. If it doesn't 
work -- I'll be back. :-)


To answer your other questions:

(1) EAP (or more accurately in this case EAPOL) is the extensible 
authentication protocol over LAN and is used for 802.1X port 
authentication.  The authentication frames are marked with the 
ethertype 0x888e to distinguish them from other Ethernet frames.  
They are also assigned the broadcast MAC address of 
01:80:c2:00:00:03. Because 802.1D states that a standard compliant 
switch or bridge cannot forward frames with a MAC address inthe 
range of 01:80:c2:00:00:00 to 01:80:c2:00:00:0f, you can't just 
create a bridge in FreeBSD between the two interfaces since the 
FreeBSD bridge code is standard compliant.  So I have to process and 
forward the frames another way and it looks like Netgraph will let 
me do it.  Otherwise, I'm going to have to patch the bridge code in 
the kernel to include a sysctl variable that enables or disables 
this compliance.
or use the netgraph bridge. ng_bridge. it doesn't care as far as I 
know. it's job it to produce "bump in the wire" devices.

see /usr/share/examples/netgraph.



(2) You are correct that there are return frames (not packets as 
this all occurs at layer 2). However, the graph to handle the return 
frames is going to just be a mirror of the the graph for processing 
the outgoing frames.  So if I can get it working in one direction, 
it's trivial to create a mirror image graph for the reverse direction.


Thanks!






John L. Lyon
PGP Key Available At:
https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc

On Thu, Dec 28, 2017 at 8:59 AM, Julian Elischer <jul...@freebsd.org 
<mailto:jul...@freebsd.org>> wrote:


On 28/12/17 1:37 am, John Lyon wrote:

Julian,

Unfortunately, this issue remains unresolved. I would like to
think that this is just a PEBKAC issue, but I have tried every
permutation of escape characters in case it's an issue with my
syntax and I get the same set of errors.  No matter what I do,
I can't connect the no match hook of an ETF node to the upper
hook of an ng_ether node.  Do you have any insights into why
this might be occurring?

By the way, thanks for reaching out to me!  I was going to
email you directly after the holidays since your name and email
address are at the bottom of the relevant Netgraph man pages. 
I figured that must mean if you didn't know the answer, no one
does. :-)


what is EAP?
what about return EAP packets? (are there any?)

I think this is what you want:
$ sudo ngctl list
There are 7 total nodes:
  Name: igb0    Type: ether   ID: 0001   Num
hooks: 0
  Name: igb1    Type: ether   ID: 0002   Num
hooks: 0
  Name: ix0 Type: ether   ID: 0003   Num
hooks: 0
  Name: ix1 Type: ether   ID: 0004   Num
hooks: 0
  Name: tap0    Type: ether   ID: 0005   Num
hooks: 0
  Name: bridge3 Type: ether   ID: 0006   Num
hooks: 0
  Name: ngctl7372   Type: socket  ID: 0007   Num
hooks: 0
$ sudo kldload ng_etf
$ sudo ngctl name ix0:lower eapfilter
$ sudo ngctl connect eapfilter: ix0: nomatch upper
$ sudo ngctl connect eapfilter: ix1: eapout lower
$ sudo ngctl show eapfilter:
  Name: eapfilter   Type: etf ID: 0021   Num
hooks: 3
  Local hook  Peer name   Peer type Peer ID Peer
hook
  --  -   - ---
-
  eapout  ix1 ether 0004    lower
  nomatch ix0 ether 0003    upper
  downstream  ix0 ether 0003    lower
$ sudo ngctl msg eapfilter: 'setfilter { matchhook="eapout"
ethertype=0x888e }'
$





Thanks.



John L. Lyon
PGP Key Available At:
https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc
<https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc>

On Wed, Dec 27, 2017 at 10:32 AM, Julian Elischer
<jul...@freebsd.org <mailto:jul...@freebsd.org>> wrote:

John did you get a resolution to this issue?


On 16/12/17 2:59 am, John Lyon wrote:

Harry and Eugene (and others),

I appreciate all of your help.  It's been really
insight

Re: Need Netgraph Help [fixed]

[Julian Elischer]

On 28/12/17 9:59 pm, Julian Elischer wrote:

On 28/12/17 1:37 am, John Lyon wrote:

Julian,

Unfortunately, this issue remains unresolved.  I would like to 
think that this is just a PEBKAC issue, but I have tried every 
permutation of escape characters in case it's an issue with my 
syntax and I get the same set of errors.  No matter what I do, I 
can't connect the no match hook of an ETF node to the upper hook of 
an ng_ether node.  Do you have any insights into why this might be 
occurring?


By the way, thanks for reaching out to me!  I was going to email 
you directly after the holidays since your name and email address 
are at the bottom of the relevant Netgraph man pages.  I figured 
that must mean if you didn't know the answer, no one does. :-)


what is EAP?
what about return EAP packets? (are there any?)


oops left out a line from the cut-n-paste...


I think this is what you want:
$ sudo ngctl list
There are 7 total nodes:
  Name: igb0    Type: ether   ID: 0001   Num 
hooks: 0
  Name: igb1    Type: ether   ID: 0002   Num 
hooks: 0
  Name: ix0 Type: ether   ID: 0003   Num 
hooks: 0
  Name: ix1 Type: ether   ID: 0004   Num 
hooks: 0
  Name: tap0    Type: ether   ID: 0005   Num 
hooks: 0
  Name: bridge3 Type: ether   ID: 0006   Num 
hooks: 0
  Name: ngctl7372   Type: socket  ID: 0007   Num 
hooks: 0

$ sudo kldload ng_etf

$ sudo ngctl mkpeer ix0: etf lower downstream

$ sudo ngctl name ix0:lower eapfilter
$ sudo ngctl connect eapfilter: ix0: nomatch upper
$ sudo ngctl connect eapfilter: ix1: eapout lower
$ sudo ngctl show eapfilter:
  Name: eapfilter   Type: etf ID: 0021   Num 
hooks: 3

  Local hook  Peer name   Peer type    Peer ID Peer hook
  --  -   - --- -
  eapout  ix1 ether 0004    lower
  nomatch ix0 ether 0003    upper
  downstream  ix0 ether 0003    lower
$ sudo ngctl msg eapfilter: 'setfilter { matchhook="eapout" 
ethertype=0x888e }'

$




Thanks.



John L. Lyon
PGP Key Available At:
https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc

On Wed, Dec 27, 2017 at 10:32 AM, Julian Elischer 
<jul...@freebsd.org <mailto:jul...@freebsd.org>> wrote:


    John did you get a resolution to this issue?


    On 16/12/17 2:59 am, John Lyon wrote:

    Harry and Eugene (and others),

    I appreciate all of your help.  It's been really
    insightful.  Although I
    feel like I'm getting much closer to the solution, I don't
    think my problem
    has been diagnosed.  I've outlined my thought process
    below.  Can you
    please tell me if I am misunderstanding something?
    Admittedly, I am not a
    kernel developer and my C language skills have atrophied the
    last few
    years.  However, I've reviewed my script and I looked in the
    code for
    ng_etf.c and I don't think I am violating any of the
    requirements for
    linking a hook for no match.

    As Eugene stated:

    1) referenced "matchook" exists and you should not
    use "indirect name"

    here,

    only hook own name, or else you get error ENOENT (No
    such file or

    directory);

    This does not seem to be a problem as the upper and lower
    hooks for the em1
    already exist (I can confirm this).

    2) referenced "matchook" is *not* downstream hook,
    or else you get error
    EINVAL (Invalid argument);

    I read the ng_etf.c file in the source tree and found this
    little snippet:

    /* and is not the downstream hook */
    if (hook == etfp->downstream_hook.hook) {
         error = EINVAL;
         break;
    }

    This appears to be an error check to make sure you are not
    creating a cycle
    in the graph by referencing the ETF node's own downstream
    hook (i.e.
    filtering incoming traffic and circularly feeding
    non-matching frames back
    into the ETF's own filter).  I'm not doing this.  I am
    feeding non-matching
    packets into the *lower* hook of another ether node and not
    back into the
    *downstream* hook of the etf node I am creating.  As a
    result, my netgraph
    should not be triggering this error condition.

    3) it was not already configured, or else you get
    error EEXIST (File

    exists).

    I am not getting this error, so it appears not to be an
    issue in my case.

    What am I missing here?  The man page states that "*any
    other *hook" can be

Re: Need Netgraph Help

[Julian Elischer]

On 28/12/17 1:37 am, John Lyon wrote:

Julian,

Unfortunately, this issue remains unresolved.  I would like to think 
that this is just a PEBKAC issue, but I have tried every permutation 
of escape characters in case it's an issue with my syntax and I get 
the same set of errors.  No matter what I do, I can't connect the no 
match hook of an ETF node to the upper hook of an ng_ether node.  Do 
you have any insights into why this might be occurring?


By the way, thanks for reaching out to me!  I was going to email you 
directly after the holidays since your name and email address are at 
the bottom of the relevant Netgraph man pages.  I figured that must 
mean if you didn't know the answer, no one does. :-)


what is EAP?
what about return EAP packets? (are there any?)

I think this is what you want:
$ sudo ngctl list
There are 7 total nodes:
  Name: igb0    Type: ether   ID: 0001   Num hooks: 0
  Name: igb1    Type: ether   ID: 0002   Num hooks: 0
  Name: ix0 Type: ether   ID: 0003   Num hooks: 0
  Name: ix1 Type: ether   ID: 0004   Num hooks: 0
  Name: tap0    Type: ether   ID: 0005   Num hooks: 0
  Name: bridge3 Type: ether   ID: 0006   Num hooks: 0
  Name: ngctl7372   Type: socket  ID: 0007   Num hooks: 0
$ sudo kldload ng_etf
$ sudo ngctl name ix0:lower eapfilter
$ sudo ngctl connect eapfilter: ix0: nomatch upper
$ sudo ngctl connect eapfilter: ix1: eapout lower
$ sudo ngctl show eapfilter:
  Name: eapfilter   Type: etf ID: 0021   Num hooks: 3
  Local hook  Peer name   Peer type    Peer ID Peer hook
  --  -   - --- -
  eapout  ix1 ether 0004    lower
  nomatch ix0 ether 0003    upper
  downstream  ix0 ether 0003    lower
$ sudo ngctl msg eapfilter: 'setfilter { matchhook="eapout" 
ethertype=0x888e }'

$




Thanks.



John L. Lyon
PGP Key Available At:
https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc

On Wed, Dec 27, 2017 at 10:32 AM, Julian Elischer 
<jul...@freebsd.org <mailto:jul...@freebsd.org>> wrote:


John did you get a resolution to this issue?


On 16/12/17 2:59 am, John Lyon wrote:

Harry and Eugene (and others),

I appreciate all of your help.  It's been really
insightful.  Although I
feel like I'm getting much closer to the solution, I don't
think my problem
has been diagnosed.  I've outlined my thought process
below.  Can you
please tell me if I am misunderstanding something?
Admittedly, I am not a
kernel developer and my C language skills have atrophied the
last few
years.  However, I've reviewed my script and I looked in the
code for
ng_etf.c and I don't think I am violating any of the
requirements for
linking a hook for no match.

As Eugene stated:

1) referenced "matchook" exists and you should not
use "indirect name"

here,

only hook own name, or else you get error ENOENT (No
such file or

directory);

This does not seem to be a problem as the upper and lower
hooks for the em1
already exist (I can confirm this).

2) referenced "matchook" is *not* downstream hook,
or else you get error
EINVAL (Invalid argument);

I read the ng_etf.c file in the source tree and found this
little snippet:

/* and is not the downstream hook */
if (hook == etfp->downstream_hook.hook) {
     error = EINVAL;
     break;
}

This appears to be an error check to make sure you are not
creating a cycle
in the graph by referencing the ETF node's own downstream
hook (i.e.
filtering incoming traffic and circularly feeding
non-matching frames back
into the ETF's own filter).  I'm not doing this.  I am
feeding non-matching
packets into the *lower* hook of another ether node and not
back into the
*downstream* hook of the etf node I am creating.  As a
result, my netgraph
should not be triggering this error condition.

3) it was not already configured, or else you get
error EEXIST (File

exists).

I am not getting this error, so it appears not to be an
issue in my case.

What am I missing here?  The man page states that "*any
other *hook" can be

used for the non-matching packets.  So the man page says
this should work,
and there's no explicit error condition that I 

Re: Need Netgraph Help

[Julian Elischer]

John did you get a resolution to this issue?

On 16/12/17 2:59 am, John Lyon wrote:

Harry and Eugene (and others),

I appreciate all of your help.  It's been really insightful.  Although I
feel like I'm getting much closer to the solution, I don't think my problem
has been diagnosed.  I've outlined my thought process below.  Can you
please tell me if I am misunderstanding something?  Admittedly, I am not a
kernel developer and my C language skills have atrophied the last few
years.  However, I've reviewed my script and I looked in the code for
ng_etf.c and I don't think I am violating any of the requirements for
linking a hook for no match.

As Eugene stated:


1) referenced "matchook" exists and you should not use "indirect name"

here,

only hook own name, or else you get error ENOENT (No such file or

directory);

This does not seem to be a problem as the upper and lower hooks for the em1
already exist (I can confirm this).


2) referenced "matchook" is *not* downstream hook, or else you get error
EINVAL (Invalid argument);

I read the ng_etf.c file in the source tree and found this little snippet:

/* and is not the downstream hook */
if (hook == etfp->downstream_hook.hook) {
 error = EINVAL;
 break;
}

This appears to be an error check to make sure you are not creating a cycle
in the graph by referencing the ETF node's own downstream hook (i.e.
filtering incoming traffic and circularly feeding non-matching frames back
into the ETF's own filter).  I'm not doing this.  I am feeding non-matching
packets into the *lower* hook of another ether node and not back into the
*downstream* hook of the etf node I am creating.  As a result, my netgraph
should not be triggering this error condition.


3) it was not already configured, or else you get error EEXIST (File

exists).

I am not getting this error, so it appears not to be an issue in my case.

What am I missing here?  The man page states that "*any other *hook" can be
used for the non-matching packets.  So the man page says this should work,
and there's no explicit error condition that I see (caveat, I have not
written in C for at least 10 years  - PEBKAC is entirely possible) that
would be triggered in the ng_etf code.  So what is going wrong?

Thanks for all of your help, patience, and understanding.



John L. Lyon
PGP Key Available At:
https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc

On Fri, Dec 15, 2017 at 3:48 AM, Harry Schmalzbauer 
wrote:


Bezüglich Eugene Grosbein's Nachricht vom 14.12.2017 23:07 (localtime):

15.12.2017 4:27, John Lyon wrote:


I'm a new Netgraph user, but am having some problems with a simple
Netgraph
script I have written.  Unfortunately, the error message is cryptic

and I

can't tell what I am doing wrong since my script closely follows the
example provided in the ng_etf man page.

For some context, I'm trying to filter EAP traffic coming in on my LAN
interface.  Any ethernet frames that correspond to EAP traffic need

to be

immediately forwarded from the LAN interface to my WAN interface.  All
other ethernet frames coming in on my LAN interface need to be

handled by

the kernel's network stack.  A (horrid) ASCII art representation of my
desired netgraph would look like this:

lower -> em0 -> downstream -> ETF -> no match -> upper em0
-> match ->
lower em1

The script I have written is this:

 #! /bin/sh
 ngctl mkpeer em0: etf lower downstream
 ngctl name em0:lower lan_filter
 ngctl connect em0: lan_filter: upper nomatch
 ngctl msg lan_filter: setfilter { matchhook="em1:lower"
ethertype=0x888e }

Unfortunately, the last line of my script generates the following

error

message:

 ngctl: send msg: Invalid Argument

For "setfilter" command to work, ng_etf requires that:

1) referenced "matchook" exists and you should not use "indirect name"

here,

only hook own name, or else you get error ENOENT (No such file or

directory);

2) referenced "matchook" is *not* downstream hook, or else you get error
EINVAL (Invalid argument);
3) it was not already configured, or else you get error EEXIST (File

exists).

Eugene kindly looked into the code and found that the error is due to
wrong matchhook definition.
I've never had any contact with ng_etf yet, but according to the man
page, you need to set the (additional) filter hook by 'nghook -a
lan_filter: mydrain' and use 'matchhook=mydrain' for the 'msg' command.

Do idea about the intention, so for the rest you have to tweak as needed.

-harry



___
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 

Re: setfib (ez)jails and wierd routing

[Julian Elischer]

On 18/10/17 3:30 am, Marek Zarychta wrote:

On Tue, Oct 17, 2017 at 08:28:16PM +0200, Marko Cupać wrote:

On Mon, 16 Oct 2017 20:07:28 +0200
Marek Zarychta  wrote:


Hi,

try after to set "ifconfig bce1 fib 2" after disabling PF.
This  should do the work.

Hi Marek,

thank you for your advice, it seems to be getting me closer to the
solution.

PF is not enabled on this host. I've set `ifconfig bce1 fib 2'
interactively, and packets with source address of DMZ net disappeared
from LAN NIC (bce0 / fib 1).

I wanted of course to have this automated, so I changed my rc.conf line
for bce1:
ifconfig_bce1="inet 193.53.106.7 netmask 255.255.255.0 fib 2"

However, after restart I observed another undesirable situation -
packets with source address 193.53.106.7 leaving bce0 interface. I
found out those are generated by sysutils/py-salt master service
running directly on host (fib 0), bound to 193.53.106.7 (on interface
bce1, which is now set as fib 2 at boot time).

Why is outcome different when bce1 is set with fib 2 at the boot time
from rc.conf from setting it at runtime?

If setting bce1 with fib2 at the boot time from rc.conf, should I also
start services running directly on host and bound to bce1 in fib 2?
Would this be the correct rc.conf syntax for starting services in other
fibs (for salt):

salt_master_enable="YES"
salt_master_fib="2"
salt_minion_enable="YES"
salt_minion_fib="2"

Hi Marko,
  
bounding interface with FIB applies only to packets received on that

interface (ifconfig(8)). IMHO py-salt works as expected and as before.

If you wish to apply FIB to packets belonging to the connections
originating from the host, you should either start service with
setfib(1) or use appropriate firewall rules to assist this. With PF(4)
it could be route-to or rtable options, see pf.conf(5)

Best regards,


TO me it sounds a bit like what you want to do is better achieved 
using Vimage/Vnet on your jail.



As for using Fibs, you can make sure that the jail is started with 
setfib, and that you always use setfib with jexec to ensure that all 
processes in hte jail inherit the correct fib setting.. The Fib on an 
interface just assignes that as a default fib for incoming packets. no 
more..  We did have a set of changes that allowd an incoming packet to 
attach to a  socket that had no fib and set its fib to that socket. 
Thet set was never really committed.


(basically the server socket would take on the fib for the interface 
on which the packet had arrived)


I still hope to get that change in one day.

Julian



___
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: Only last IP frag sent if ARP entry absent

[Julian Elischer]

On 18/8/17 12:36 pm, Gopakumar Pillai wrote:

Thank You Bjoern and Mike.

While I agree with you Mike that ping can fail, a UDP application could also be 
affected – if its sending >MTU data and if ARP entry is absent. And 
ether_output wouldn’t even tell the app if the sending failed or not (as per 
existing code). Agree that badly written applications would suffer the most. My 
fix only helps applications.

I guess I am not totally out of line.

But not sure whether I should checkin this fix or not! ☺

Thank You again.

--Gopu



From: Mike Karels 
Date: Thursday, August 17, 2017 at 8:33 PM
To: Gopakumar Pillai 
Cc: "Bjoern A. Zeeb" , "freebsd-net@FreeBSD.org" 

Subject: Re: Only last IP frag sent if ARP entry absent


Another $.02 (inline):

On 17 Aug 2017, at 18:39, Gopakumar Pillai wrote:

Thank You Bjoern. Could you please point me to the RFC?

I don’t know if there is anything more recent than RFC1122 on this. IIRC, it 
requires queuing at least one packet. Queing one packet is what BSD has done 
essentially since ARP was implemented.

If this is not a MUST behavior in RFC, would my fix be good? I agree that this 
would affect only ICMP/UDP traffic.

People have been asking for queuing of multiple packets for years. That is a 
more general change. Consider another dumb application that starts out by 
sending multiple UDP packets back-to-back. However, well-designed application 
protocols don’t experience problems like this. I’ll quickly note that ping 
isn’t an application, but a network measuring tool. If you ask the question 
“what happens if I start off a session with a single large packet and I don’t 
support retransmission”, ping answers that question correctly.

If badly-designed protocols get bad performance, that doesn’t seem like a bug 
to me, but a feature.

On 8/17/17, 2:40 PM, "Bjoern A. Zeeb"  wrote:

On 17 Aug 2017, at 21:16, Gopakumar Pillai wrote:


Hi FreeBSD Networking Gurus,
I came across an issue with an old version of FreeBSD and looking at
the latest FreeBSD code, seems it exists even now. I am assuming that
this issue is not reported.

Observation:
When a ping was performed with larger payload than MTU, the first ping
failed when the ARP entry was absent for that IP.

That is because ping/ICMP has no retransmit.



Noticed on the wire that the last IP fragment was sent for the first
request and then the subsequent requests were fine.

Root Cause:
* ip_output fragments the packets and loops through the fragments to
send them to ether_output.
* ether_output does an arpresolve and if there is no existing ARP
entry it'll return EWOULDBLOCK after sending ARP Request.
* ether_output ignores the error and propagates success to ip_output
and it continues to send the remaining fragments.
* llentry keeps only one mbuf and the last fragment is retained when
the ARP Reply comes and the fragment is sent.

Yes, according to the spec (RFC) we are supposed to throw the packet
away entirely and simply report that to the next upper layer. However
over the years people realised that this sucks for a TCP SYN packet with
a retransmit timer and hence we store one of them.
The canonical example of this was always NFS over UDP, where after 
sitting idle for  a while, the
first NFS packet would need to be retransmitted because the first part 
of the 8K NFS packet went AWOL.


A large UDP packet would btw see the same behaviour to your ping.
There’s no guarantee any of these packets will not be dropped anywhere
on the network, so we can as well.

Just my 2ct

/bz

 Mike
___
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"

Re: Only last IP frag sent if ARP entry absent

[Julian Elischer]

On 18/8/17 11:33 am, Mike Karels wrote:

Another $.02 (inline):

On 17 Aug 2017, at 18:39, Gopakumar Pillai wrote:


Thank You Bjoern. Could you please point me to the RFC?


I don’t know if there is anything more recent than RFC1122 on this.  
IIRC, it requires queuing at least one packet.  Queing one packet is 
what BSD has done essentially since ARP was implemented.


This asks the question:  One physical packet or one logical packet?
Gopakumar's change effectively changes the queuing from one physical 
packet to the logical one.
The next question becomes "how much extra work do we do to achieve 
this and does it affect anything else"?


If this is not a MUST behavior in RFC, would my fix be good? I 
agree that this would affect only ICMP/UDP traffic.


People have been asking for queuing of multiple packets for years.  
That is a more general change.  Consider another dumb application 
that starts out by sending multiple UDP packets back-to-back.  
However, well-designed application protocols don’t experience 
problems like this.  I’ll quickly note that ping isn’t an 
application, but a network measuring tool.  If you ask the question 
“what happens if I start off a session with a single large packet 
and I don’t support retransmission”, ping answers that question 
correctly.


If badly-designed protocols get bad performance, that doesn’t seem 
like a bug to me, but a feature.


On 8/17/17, 2:40 PM, "Bjoern A. Zeeb" 
 wrote:


On 17 Aug 2017, at 21:16, Gopakumar Pillai wrote:

> Hi FreeBSD Networking Gurus,
> I came across an issue with an old version of FreeBSD and 
looking at
> the latest FreeBSD code, seems it exists even now. I am 
assuming that

> this issue is not reported.
>
> Observation:
> When a ping was performed with larger payload than MTU, the 
first ping

> failed when the ARP entry was absent for that IP.

That is because ping/ICMP has no retransmit.


> Noticed on the wire that the last IP fragment was sent for 
the first

> request and then the subsequent requests were fine.
>
> Root Cause:
>   * ip_output fragments the packets and loops through the 
fragments to

> send them to ether_output.
>   * ether_output does an arpresolve and if there is no 
existing ARP

> entry it'll return EWOULDBLOCK after sending ARP Request.
>   * ether_output ignores the error and propagates success to 
ip_output

> and it continues to send the remaining fragments.
>   * llentry keeps only one mbuf and the last fragment is 
retained when

> the ARP Reply comes and the fragment is sent.

Yes, according to the spec (RFC) we are supposed to throw the 
packet
away entirely and simply report that to the next upper layer.  
However
over the years people realised that this sucks for a TCP SYN 
packet with

a retransmit timer and hence we store one of them.

A large UDP packet would btw see the same behaviour to your ping.
There’s no guarantee any of these packets will not be dropped 
anywhere

on the network, so we can as well.

Just my 2ct

/bz


Mike
___
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"

Re: May I ask where could I find the TCP BBR patches?

[Julian Elischer]

On 21/7/17 1:23 pm, Jov wrote:

Maybe you are also interested in kcp/kcptun:
https://github.com/xtaci/kcptun


looks to me like kcp might be implemented pretty easily as a netgraph 
module,


BBR looks like it would be relatively simple to port and I look 
forward to seeing it.


There is also a FreeBSD new ports PR：
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219449

Jov

2017-07-21 10:30 GMT+08:00 Kuankuan Yang :

Hi Hiren,

Thanks a lot for your reply, this helps a lot. I’m looking forward to 
BBR/FreeBSD feature very much, wish to see that great job soon :P

Best regards,
- Kuankuan


在 2017年7月21日，上午2:54，hiren panchasara  写道：

On 07/19/17 at 12:26P, Kuankuan Yang wrote:

Dear All,

I?m a newbie for FreeBSD development. May I ask a stupid question where could I 
find the TCP BBR patches  :P

Hi! Thanks for your interest in BBR/FreeBSD. Other than what you listed, nothing
is public yet.

Cheers,
Hiren

___
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"



___
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?

[Julian Elischer]

On 18/7/17 11:50 am, Grzegorz Junka wrote:


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?


Vnet is in production use in quite a lot of places.
becasue it is a very complicated concept to implement there are 
sometimes corner cases that produce issues but most people never hit them.

Especially in a machine that has a single purpose.


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"




___
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: Sporadic TCP/RST sent to client

[Julian Elischer]

On 28/6/17 2:31 am, Youssef GHORBAL wrote:

[...]


Further, I would argue that round robin is not a valid 802.3ad/802.1AX
algorithm, per how it defines a frame distributor:

"This standard does not mandate any particular distribution
algorithm(s); however, any distribution algorithm shall ensure that,
when frames are received by a Frame Collector as specified in 5.2.3,
the algorithm shall not cause:
a) Misordering of frames that are part of any given conversation, or
b) Duplication of frames.

The above requirement to maintain frame ordering is met by ensuring
that all frames that compose a given conversation are transmitted on a
single link in the order that they are generated by the MAC Client;
hence, this requirement does not involve the addition (or
modification) of any information to the MAC frame, nor any buffering
or processing on the part of the corresponding Frame Collector in
order to reorder frames."

I tend to agree with you on this point.


Sure, I was just wondering if the FreeBSD network stack was built with the fact 
that each flow needs to arrive on the same NIC and the system was designed with 
this assumption in mind or not.

I reported it here, thinking that maybe it's a subtle buggy corner case and 
maybe the community was interesting to know about and maybe fix :

- If the stack is working as expected and was built with the assumption that 
each incoming flow needs to stick to a NIC during it's lifetime, maybe 
documentation needs to be more explicit regarding this situation. In that case 
I'll file documentation enhancement bug report.
- If the stack is misbehaving, maybe help the community identify the root cause 
and help fixing it


As far as I can tell, as Navdeep noted, there's no unexpected
behaviour in your case. "Flows" are a concept that the protocols, in
this case TCP, knows about. The devices themselves (Ethernet cards)
usually have mechanics to make packet delivery decisions based on flow
information (e.g. RSS hashing), but as far as I know that is generally
limited within a single port, so it doesn't really help in the general
case of a lagg.

So the fact that it works most of the time is just a "happy" coincidence. But 
it's not a behaviour to relay on. Right ?

Anyway, thank you very much for your help and the clarification on this issue.


Basically, while the packets are "on the wire" anything could happen.

It would be theoretically possible for a lagg interface to do packet 
inspection and to not deliver (for some small amount of time) packets 
which showed sign of a missing earlier packet, but this is the job of 
other layers (e.g. tcp) and it would have negative impacts on 
performance of otherwise well behaved flows as well.
It would have to actually look at tcp headers and that is WAY out of 
scope for lagg. !t would also need a lot of state to be stored if it 
were to hold state for all recent sessions, and make the code MUCH 
more complicated.

Let tcp be tcp and push the linux owner to use something better.



Youssef
___
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"

Re: The fate of ngatm

[Julian Elischer]

On 28/4/17 2:00 am, Brooks Davis wrote:

As previous threatened, I've removed support for NATM (as well as a
remarkable number of remnants of the old ATM framework).  One piece
that still remains is the ngatm framework in netgraph.  This includes
the ng_ccatm(4), ng_sscfu(4), ng_sscop(4), and ng_uni(4) nodes.

These don't attach to physical interfaces and didn't depend on the NATM
interface code so I left them alone in the first cut.  My question
is, are they useful without physical interfaces?  If so, keeping them
doesn't appear to have a high support burden.  If not, we should remove
them.

-- Brooks


I don't know if people are using these now, but at one stage people 
were using them to decode/encode atm higher level protocols over an 
ethernet transport to implement a PPPoA infrastructure.



No idea if it's still being used .

___
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: VNET / netgraph jails -- Locking down?

[Julian Elischer]

many good questions but looking at what you are doing, maybe we should 
be asking you the questions.
Certainly firewalling on the outside of the jail makes sense. I've not 
used ng_ipfw but it would make sense to do a quick santity check for 
every packet leaving each jail.



On 14/2/17 9:47 am, Jeff Kletsky wrote:
For several years I've been using netgraph to provide connectivity 
for "service hosts" in jails on a "jail server"


Since I'm finally getting the jail server off FreeBSD 9 and solidly 
onto 11, I've got the chance to rewrite the scripting of how I'm 
handling jail connectivity and am hoping that I can lock things down 
a bit better than what I have presently.



The approach I use looks similar to that now in the jail examples. 
Basically


  /---> ng_eiface_jail1
real_interface = ng_ether <---> ng_bridge <---> ng_eiface_jail2
  \---> ng_eiface_jail3

While this works well, it concerns me that the real interface has to 
be in promiscuous mode (and have autosrc off).


If one of the service jails is "taken over" then there isn't a way 
that I know of to lock out changing the IP address of the interface 
it has, or potentially gaining access to another VLAN through 
creation of a cloned interface, especially if the bridge is off the 
parent interface, not off a VLAN interface.



How do people manage this in practice when the jail has the risk of 
compromise?



I prefer approaches where the jail's notion of it's own IP address 
is the same as that of other hosts connecting to it, at least within 
my own little private-address-space world.



One thing that I've been considering is:
* Configure the jail's IP on the real interface (or appropriate VLAN 
interface) as an alias
* Send packets through ng_ipfw to an ng_eiface that the jail gets, 
using ipfw and a lookup table
* Tag the packets on return with ng_tag with a unique identifier for 
that jail's interface so ipfw can tell the only acceptable source IP

* Deny any so-tagged packets that don't have the proper source address

(jail ID by itself is not enough for the outbound packets, as some 
of the jails are dual homed.)



Has anyone tried this kind of method? Any other/better suggestions?


Would ng_ip_input be the appropriate way to "send" the packets 
coming from the jail?



Thanks!


Jeff




___
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"

Re: NETGRAPH's ng_cisco and IPv6 support

[Julian Elischer]

On 24/2/17 3:03 am, Łukasz Wójcik wrote:

Hello everyone,

I've recently started to develop certain driver that uses 'ng_cisco' 
netgraph module for CHDLC en-/de-capsulation.
When it connects with ng_cisco node via 'inet' hook, everything 
works fine, but there is an issue when trying to
use 'inet6' node. cisco_notify() routine only sends flow control 
messages to nodes connected via 'inet' hook,
completely ignoring those connected via 'inet6'. This poses some 
problem if peer node relies on link status information
passed from ng_cisco. I'd therefore like to suggest/discuss a patch 
(attached to this email). All it does is to make ng_cisco node
pass flow control messages to *both* 'inet' and 'inet6' peers. It 
seems to me that it is both possible and sensible to

expect both mentioned hooks to be connected at the same time.

I would appreciate any feedback.


ipv6 was still a "some time in the future" thing when I wrote the 
ng_cisco node (or did archie do that one.?)
I'm pretty sire someone who knows IPv6 needs to go through the entire 
suite with a broom.




Best regards,
-ŁW


___
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"

all network people please review this proposal: because someone is going to commit it soon. D5017

[Julian Elischer]

Unless eri gets to it first I will.

see https://reviews.freebsd.org/D5017

If you have a server, you can put an arbitrary number of clients on 
the same port number because they all have different addresses.


However in the case of a client accessing multiple servers we are 
limited to 65535 sessions because we strictly don't allow the same 
port to be used more than once. This is silly because TCP is a 
symmetrical protocol and of it works for the server it should work for 
the client.


So this patch changes the allocation of ports to allow the client to 
use a port that has been used before as long as the previous port user 
is not talking to the same host/port. This removes the limitation of a 
freebsd machine being only capable of contacting 65000 hosts in a 
single port shutdown timeout period. With modern machines capable of 
initiating  MILLIONS of sessions per second, having a limitation of 
65000 per 2 minutes is a bit silly.



Please read the patch if you suspect this will have a bad effect of 
any sort.  Once the session is started there is no record as to who 
started it so any issues would have to be in the startup phase.



Julian

___
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: FreeBSD10.3-RELEASE. Kernel panic.

[Julian Elischer]

On 11/10/2016 8:56 PM, Donald Baud via freebsd-net wrote:

I've been plagued with these =daily= panics until I tried the following recipes 
and the server has been up for 30 days so far:

Normally I should expermient more to see which one of the receipes is really 
the fix, but I'm just glad that the server is stable for now.


this is really great information.
It makes debugging a lot more possible.
I know it is a hard question, but do you have a way to simulate this 
workload?


I have no real way to simulate this kind of workload



recipe-1: Don't let mpd5 start automatically when server boots:
i.e. in: /etc/rc.conf
mpd5_enable="NO"
and wait about 5 minutes after server boots then issue:
/usr/local/etc/rc.d/mpd5 onestart


recipe-2: recompile the kernel with the NETGRAPH_DEBUG option:
options NETGRAPH
options NETGRAPH_DEBUG
options NETGRAPH_KSOCKET
options NETGRAPH_L2TP
options NETGRAPH_SOCKET
options NETGRAPH_TEE
options NETGRAPH_VJC
options NETGRAPH_PPP
options NETGRAPH_IFACE
options NETGRAPH_MPPC_COMPRESSION
options NETGRAPH_MPPC_ENCRYPTION
options NETGRAPH_TCPMSS
options IPFIREWALL

recipe-3: recompile the kernel and disable the IPv6 and SCTP options:
nooptions   INET6
nooptions   SCTP

recipe-4: Don't use any of the sysctl optimizations
in other words I commented out all values in sysctl.conf:
# net.graph.maxdgram=20480  (this is the default)
# net.graph.recvspace=20480  (this is the default)

recipe-5: Don't use any of the loader.conf optimizations
in other words I commented out all values in loader.conf
# net.graph.maxdata=4096  (this is the default)
# net.graph.maxalloc=4096 (this is the default)


In my case, I had the panics with 10.3 and 11-PRERELEASE
11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #2 r305587

With those recipes, I have been running without any crash for a month and 
counting.  Thats' 300 l2tp tunnels and 1400 l2tp sessions generating 700Mbit/s.


-DBaud


On Tuesday, October 11, 2016 7:30 AM, Cassiano Peixoto 
 wrote:
Hi,

There are many users complaining about this:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186114

I've been dealing with this issue for one year with no solution. mpd5 as
pppoe server on FreeBSD is useless with this bug.

I really would like to see it working again, i think it's quite important
to both project and many users.

Thanks.

On Tue, Oct 11, 2016 at 3:24 AM, Eugene Grosbein  wrote:


11.10.2016 11:02, Андрей Леушкин пишет:


Hello. I have problem with "FreeBSD nas 10.3-RELEASE FreeBSD 10.3-RELEASE
#0: Fri Oct  7 21:12:56 YEKT 2016nas@nas:/usr/obj/usr/src/sys/nasv3
   amd64"

Kernel panic is repeated at intervals of 2-3 days. At first I thought that
the problem is in the hardware, but the problem did not go away after
replacing the server platform.

Coredumps and more info on link
https://drive.google.com/open?id=0BxciMy2q7ZjTTkIxem9wTE1tM2M

Sorry for my english.
I'll wait for an answer.


This is known and long-stanging problem in the FreeBSD network stack.
It shows up when you have lots of network interfaced created/removed
frequently
like in your case of Network Access Server (PPtP, PPPoE etc).

Generally, people run into this problem using mpd5 network daemon.
mpd5 uses NETGRAPH kernel subsystem to process traffic and
if an interface disappears (f.e., ,user disconnected)
while kernel still processes traffic obtained from this interface, it
panices.

There were lots of reports of this problem. Noone seems to be working on
it at the moment.
You should fill a PR using Bugzilla and attach your logs to it.

Eugene Grosbein


___
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"
___
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"

Re: Strange issue with scp performance

[Julian Elischer]

On 3/10/2016 12:22 AM, Achilleas Mantzios wrote:

On 01/10/2016 03:55, John-Mark Gurney wrote:
Achilleas Mantzios wrote this message on Wed, Sep 28, 2016 at 13:26 
+0300:
We have a weird situation here. We just made a clone of a virtual 
image running Linux and sent it over to some could provider. The 
problem is that the scp performance to *many* hosts in our office

center has worsened considerably, including one freebsd box.

In this freebsd box I run also a jail, and a linux ubuntu image 
with bhyve. The crazy thing here is that :


1) scp from the original (local office center) linux image to the 
host FreeBSD, its jailed FreeBSD and its bhyve linux is 2.7 MB/s
2) scp from the cloud linux image to the host FreeBSD is slow 
(~300KB/s)
3) scp from the cloud linux image to the above FreeBSD's jail is 
slow(~300KB/s)
4) scp from the cloud linux image to the above FreeBSD's bhyve 
ubuntu is fast(~1->1.5MB/s)


What can cause this behavior?

PS
Please answer to me directly as I am not subscribed to -net.
Thanks a lot for any ideas.

I worked on this last year a bit, but was never able to track it down.

It may be an issue w/ internal SSH's buffering not growing properly to
handle the latency.

I posted some info on the wiki about this:
https://wiki.freebsd.org/SSHPerf


Thanks tons!
In this case of mine, just playing around with HPN:

HPNDisabled no
HPNBufferSize 8192

of course we just removed the HPN option for FreebSD's ssh/scp
what version are you using?



in sshd_config was enough to bring it on par with linux.








___
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: SO_BINDANY in FreeBSD 10.3

[Julian Elischer]

On 12/08/2016 11:37 PM, Adrian Chadd wrote:

Yeah, I integrated them from you like 10 years ago. It's in there somewhere. :-)

(IP_BINDANY?)

https://groups.google.com/forum/#!topic/mailing.freebsd.ipfw/L8lzLmG05WE

.. poke me to write up some documentation. :)

-adrian

On 12 August 2016 at 08:29, Julian Elischer <jul...@freebsd.org> wrote:

On 12/08/2016 8:00 PM, Alex Povolotsky wrote:

Hello

Is SO_BINDANY supported in FreeBSD 10.3? If not, do any patches exists?

I'm certain that it is, somehow, but I'll be damned if I can remember how to
do it..
There were patches for it in the 90s and early 2000s but I seem to remember
they were integrated into the system.
I think it had a different name though.


AH adrian to the rescue...

be aware there are ticks and traps to using it
e.g.
https://lists.freebsd.org/pipermail/freebsd-net/2011-March/028225.html





Alex
___
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"



___
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: SO_BINDANY in FreeBSD 10.3

[Julian Elischer]

On 12/08/2016 8:00 PM, Alex Povolotsky wrote:

Hello

Is SO_BINDANY supported in FreeBSD 10.3? If not, do any patches exists?
I'm certain that it is, somehow, but I'll be damned if I can remember 
how to do it..
There were patches for it in the 90s and early 2000s but I seem to 
remember they were integrated into the system.

I think it had a different name though.



Alex
___
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"

Re: Is there a way to keep an account of which processes generate how much network traffic?

[Julian Elischer]

On 30/05/2016 5:07 PM, Ben Woods wrote:

On Monday, 30 May 2016, Yuri > wrote:


There is vnstat that does this by interface.

But is there a way to do this by the application? This is because nearly
every packet that is sent through the system is sent on behalf of some
process running on the system.

It would be nice to be able to see which applications (in general sense)
generate most traffic.

I am fully aware that the link between pid and an "application" is vague
because some processes are run through some cryptic command lines. I am
just interested if anything exists in this area at all.


Yuri


Hi Yuri,

There is an application called nethogs which does this on Linux, but the
website says it makes heavy use of Linuxisms so won't work on BSD. I had a
quick look at the code and couldn't immediately recognise the Linuxisms in
question, but haven't done a thorough look.

On FreeBSD, I tend to filter traffic by src and destination ip/port to
determine how much traffic an application is using.

Easiest solution I can think of: Use net-mgmt/darkstat.
https://unix4lyfe.org/darkstat/

Slightly more complicated solution, but with potentially more power for
filtering the data: Netflow/NfDump/NfSen
https://forums.freebsd.org/threads/49724/


at $JOB we had to do this for outgoing sessions of one particular app.
The answer was to make that app run as a special group and use teh 
'gid' match for the outgoing SYN packets from that process to run a 
keep-state rule to make all packets from that session go through a 
particular counting rule..


it was something like:
ipfw add 10 skipto 15 tcp from any to any not layer 2 setup gid 
${SPECIAL_GID} out xmit ${EXTERNAL} keep-state

ipfw add 11 skipto 20 ip from any to any
ipfw add 15 count ip from any to any in
ipfw add 16 count ip from any to any out
ipfw add 20 

since keep-state as an implicit check-state before evaluation, all 
session packets from sessions initiate by that process.


the not-layer2 was needed in our case to stop a kernel panic,  we had 
bridging ipfw as well and it caused problems.


I have considered adding a feature where sockets opened by a partuclar 
process would generate packets with a particular tag

which could be detected in the firewall
it would be a bit like using the 'setfib' command.. the property would 
be inherrited.


so setsockflag -4 ssh foo.com would make all ssh's packet be marked 
with a tag of 4.

there is already a rule in ipfw to detect these tags.
I did consider using setfib and setting up a separate fib for that app 
to use.  Fib associations can also be detected in the firewall.






Good luck!

Regards,
Ben




___
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: Bridge interface and ARP traffic

[Julian Elischer]

On 27/05/2016 1:13 AM, John Nielsen wrote:

On May 20, 2016, at 12:30 AM, Aqz  wrote:

Hello,

I have a very strange issue with passing ARP traffic through bridge
interface.
I'm using FreeBSD 10.3-REL VMWare virtual machine as bridge between two
networks using the same IP address space. Bridge interface doesn't have IP
address assigned so it acts more like a switch between those two virtual
networks - let's call them NET and PUB.
Gateway for our network is in NET vlan, all the virtual machines are in the
PUB vlan.

Traffic passes through this bridge, but there are few problems.

I have to manually add static ARP table entries for gateway on all the
machines in PUB network - I can see ARP broadcasts from machines asking
where's the gateway, and the reply but only on one of bridged interfaces -
the one from NET side. The response is not visible on bridge interface, nor
the PUB vlan interface.

Also, when I try to ping a machine that's in NET network from PUB network
all network traffic suddenly stops, even when I'm pinging some nonexistent
host. I have to use virtual console and ping for ex. DNS server, or any
internet host to make traffic start again.

I'm not sure what I'm doing wrong - I've been using a similar configuration
before (with physical machines).

Here's my ifconfig output http://aquaz.eu/bridgeifconfig.txt

The first thing to check is the hypervisor. Do you have your VM configured to 
allow the NICs to use promiscuous mode? Is there any kind of IP/MAC matching or 
filtering going on?

Next thing to check is firewall in the VM. Is IPFW or PF enabled? What is the output of 
"sysctl net.link.bridge" ?

The ping problems are definitely weird, not sure what to think about that.


try the netgraph bridge for a comparison
there is a sample implementation in /usr/share/examples/netgraph I 
think under virtual.lan




JN
___
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"

Re: How to use pf with vimage jails?

[Julian Elischer]

On 4/05/2016 11:59 PM, Shawn Debnath wrote:

On 05/04, Alan Somers wrote:

Then maybe it's the bridged aspect that's screwing me up.  Is there a guide
for using pf on bridged interfaces?  All I can find is this guide for ipfw.

I ran into a similar issue recently  and decided to write up an article on
my site that documents how to set up jails with VNET/VIMAGE using a bridge
on the host. This might help you:

   
http://shawndebnath.com/articles/2016/03/27/freebsd-jails-with-vlan-howto.html

If you see any errors, do let me know and I will get those fixed up.


devin just committed some sample code to share/examples

https://svnweb.freebsd.org/base/head/share/examples/jails/

there is also some code in
https://svnweb.freebsd.org/base/head/share/examples/netgraph/

that may be relevant, but uses netgraph bridging.




Thanks,
Shawn
___
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"

Re: Assigning same ip address to different interfaces with different FIBs

[Julian Elischer]

On 20/04/2016 5:58 PM, M. V. via freebsd-net wrote:

Hello guys,
I have a problem with having multiple FIBs in FreeBSD-9.2. I've already setup 4 
FIBs in kernel, and everything is OK. I assigned each interface to one FIB and 
I can add routes to any of FIBs I want, and everything works fine.But my 
problem is, I want to assign same IP address to multiple interfaces. for 
example:
interface em1 (in FIB-1) : 100.100.100.1/24interface em2 (in FIB-2) : 
100.100.100.1/24
this should work, bacause I want each FIB's interfaces and routes to be 
completely separate from other FIBs' interfaces and routes. for this I do:# 
sysctl net.add_addr_allfibs = 0

I think you are using the wrong tool to do this job.
Fibs will "kind-of" allow you to do some of this but all fibs still 
'see' all interfaces, Even if you don't set routes to them.

What you want is VIMAGE/VNET
Even though we've made vnet a characteristic of a jail (it wasn't 
always), you can still use it in the way you want if done right.

Write a "how-to" when you've got it worked out :-)



# ifconfig em1 fib 1# ifconfig em2 fib 2# setfib 1 ifconfig em1 
100.100.100.1/24# setfib 2 ifconfig em2 100.100.100.1/24
but this doesn't work as expected, and 100.100.100.0/24 route is only being added to 
FIB-1 (second IP assignment command doesn't work, though it returns no error).# 
setfib 1 netstat -rn ==> this fib has 100.100.100.0/24 entry added in it# setfib 2 
netstat -rn ==> nothing is added here.


there are some sysctls that control some of this. have you 
investigated them?


Though, as I say, you really want to structure your problem around 
using vimage.  Each vimage instance can have identical interfaces etc, 
becasue they are effectively separate machines.  You can route between 
them internally to the machine and at one stage you could have a 
process with sockets on each net but I"m not sure if you can still do 
that easily.





Is there any way I can do this in FreeBSD?
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"

tcp guys: please look at this one

[Julian Elischer]

https://reviews.freebsd.org/D5872

This one needs more scrutiny.  The cure may be worse than the problem, 
but it needs more eyes on it..

___
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: routing issue

[Julian Elischer]

On 3/03/2016 2:38 AM, Pakhom Golynga wrote:

Hello all!

Please help me to investigate this issue.
I have problem on 10.2-RELEASE-p12 with multiple network interfaces 
and PF (rules, NAT)

# ifconfig
<--cut-->
em0: flags=8843 metric 0 mtu 
1500
options=4209b 


ether 00:25:90:64:14:50
inet 172.27.27.254 netmask 0xff00 broadcast 172.27.27.255
inet 172.27.27.240 netmask 0x broadcast 172.27.27.240
inet 172.27.27.252 netmask 0x broadcast 172.27.27.252
inet 172.27.27.251 netmask 0x broadcast 172.27.27.251
inet 172.27.27.250 netmask 0x broadcast 172.27.27.250
inet 172.27.27.249 netmask 0x broadcast 172.27.27.249
inet 172.27.27.248 netmask 0x broadcast 172.27.27.248
inet 172.27.27.247 netmask 0x broadcast 172.27.27.247
inet 172.27.27.246 netmask 0x broadcast 172.27.27.246
inet 172.27.27.245 netmask 0x broadcast 172.27.27.245
inet 172.27.27.244 netmask 0x broadcast 172.27.27.244
inet 172.27.27.243 netmask 0x broadcast 172.27.27.243
inet 172.27.27.242 netmask 0x broadcast 172.27.27.242
inet 172.27.27.241 netmask 0x broadcast 172.27.27.241
inet 172.27.27.239 netmask 0x broadcast 172.27.27.239
inet 172.27.27.238 netmask 0x broadcast 172.27.27.238
inet 172.27.27.237 netmask 0x broadcast 172.27.27.237
inet 172.27.27.236 netmask 0x broadcast 172.27.27.236
inet 172.27.27.235 netmask 0x broadcast 172.27.27.235
media: Ethernet autoselect (1000baseT )
status: active
em1: flags=8943 
metric 0 mtu 1500
options=4209b 


ether 00:25:90:64:14:51
inet 10.24.44.50 netmask 0xfc00 broadcast 10.24.47.255
media: Ethernet autoselect (100baseTX )
status: active
<--cut-->

em0 - local network. Aliases on em0 for Jail's
em1 - connected to ISP

This configuration successfully operate a long time but recently 
(for no apparent reason) suddenly became manifest bug with routing.
Regardless from uptime (sometimes 12 hours, and maybe a couple of 
days) after a certain time the traffic running between jails begins 
to route via em1 (instead lo0 (net.link.ether.inet.useloopback=1)):


this sounds much like another report we have seen.
you may be able to fix it by re-adding your routes..

The report  I have seen suggested that some routes seem to stop being 
effective after some period.

It's  still not understood.


# tcpdump -n -e -ttt -i em1 host 172.27.27.252 or host 172.27.27.247 
or host 172.27.27.248
00:00:00.054989 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype 
IPv4 (0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: 
Flags [S], seq 2075254199, win 65535, options [mss 16344,nop,wscale 
6,sackOK,TS val 161568673 ecr 0], length 0
00:00:00.318036 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype 
IPv4 (0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.60176: 
Flags [.], ack 772660872, win 1275, options [nop,nop,TS val 
1737287913 ecr 161568991], length 0
00:00:00.036971 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype 
IPv4 (0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.33080: 
Flags [.], ack 1, win 1275, options [nop,nop,TS val 1701623130 ecr 
161568238], length 0
00:00:00.050001 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype 
IPv4 (0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.40200: 
Flags [.], ack 1, win 1275, options [nop,nop,TS val 1477098721 ecr 
161568288], length 0
00:00:02.794992 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype 
IPv4 (0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: 
Flags [S], seq 2075254199, win 65535, options [mss 16344,nop,wscale 
6,sackOK,TS val 161571873 ecr 0], length 0
00:00:03.312026 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype 
IPv4 (0x0800), length 74: 172.27.27.247.29581 > 172.27.27.252.25: 
Flags [S], seq 1217253021, win 65535, options [mss 16344,nop,wscale 
6,sackOK,TS val 161575185 ecr 0], length 0
00:00:02.887982 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype 
IPv4 (0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: 
Flags [S], seq 2075254199, win 65535, options [mss 16344,nop,wscale 
6,sackOK,TS val 161578073 ecr 0], length 0
00:00:00.111989 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype 
IPv4 (0x0800), length 74: 172.27.27.247.29581 > 172.27.27.252.25: 
Flags [S], seq 1217253021, win 65535, options [mss 16344,nop,wscale 
6,sackOK,TS val 161578185 ecr 0], length 0
00:00:03.471007 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype 
IPv4 (0x0800), length 108: 172.27.27.247.80 > 172.27.27.248.26056: 
Flags [FP.], seq 1448:1490, ack 1, win 1275, options [nop,nop,TS 

Re: gateway machine port redirect question

[Julian Elischer]

On 21/02/2016 4:48 PM, Gary Corcoran wrote:

On 2/20/2016 9:22 PM, Valeri Galtsev wrote:

Dear Experts,

I'm one of Linux refugees who several years ago migrated majority of
servers from Linux to FreeBSD and is happy since. When recently I 
needed
to set up gateway (Firewall + NAT) machine, I set up FreeBSD 10.2 
on it,
used ipwf and natd, and all works well, machines behind gateway on 
LAN can
happily reach real network. I hit one snag later though: When I 
tried to
redirect TCP traffic on some port to machine on internal private 
network

behind gateway, whatever I do doesn't work.

Could somebody point to simple example (it doesn't matter which 
components
are involved, I don't feel married to ipfw and natd) for FreeBSD 
10.2 that

makes the machine gateway, and one of the ports of traffic coming from
public network is redirected to machine on private network behind 
gateway.
Something I can reproduce that works, which I then will gradually 
convert
into what I need. Other way around: adding redirection to already 
working
(and a bit sophisticated) gateway I set up appears to be beyond my 
mental

abilities: a couple of weeks of frustration confirm it to me.

I really do not want to go back to Linux to do this, even though I 
feel I
can do it based on Linux in a course of an hour or two - I've set 
up a few

of them in the past using Linux, that's the longest it took me in my
recollection.

Thanks in advance for all your answers and pointers!

Valeri


Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
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"

Something like this?  It redirects external port 1234 to a machine 
on the internal

network at port 80.  In your natd.conf, put something like this:
redirect_port tcp 10.12.34.56:80 1234


yes but he wants this to be activated for sessions from the inside 
too, from hosts thinking that they are accessing some external host, 
(maybe for testing?)


Gary

___
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"

Re: gateway machine port redirect question

[Julian Elischer]

On 22/02/2016 4:03 AM, Ian Smith wrote:

On Sun, 21 Feb 2016 16:32:53 -0800, Julian Elischer wrote:
  > On 20/02/2016 6:22 PM, Valeri Galtsev wrote:
  > > Dear Experts,
  > >
  > > I'm one of Linux refugees who several years ago migrated majority of
  > > servers from Linux to FreeBSD and is happy since. When recently I needed
  > > to set up gateway (Firewall + NAT) machine, I set up FreeBSD 10.2 on it,
  > > used ipwf and natd, and all works well, machines behind gateway on LAN can
  > > happily reach real network. I hit one snag later though: When I tried to
  > > redirect TCP traffic on some port to machine on internal private network
  > > behind gateway, whatever I do doesn't work.
  > >
  > > Could somebody point to simple example (it doesn't matter which components
  > > are involved, I don't feel married to ipfw and natd) for FreeBSD 10.2 that
  > > makes the machine gateway, and one of the ports of traffic coming from
  > > public network is redirected to machine on private network behind gateway.
  > > Something I can reproduce that works, which I then will gradually convert
  > > into what I need. Other way around: adding redirection to already working
  > > (and a bit sophisticated) gateway I set up appears to be beyond my mental
  > > abilities: a couple of weeks of frustration confirm it to me.
  > >
  > > I really do not want to go back to Linux to do this, even though I feel I
  > > can do it based on Linux in a course of an hour or two - I've set up a few
  > > of them in the past using Linux, that's the longest it took me in my
  > > recollection.
  > >
  > > Thanks in advance for all your answers and pointers!
  > >
  > > Valeri

  > this CAN be done but it gets tricky.
  >
  > usually we do NAT on the external interface. the trouble is that you don't
  > want that traffic to go through the external interface, but to get routed
  > back in.

Well if it's internal address to another internal address, if on the
same switch it may not need to even hit the router, and if on another
segment, the router will naturally route it internally anyway, as long
as you make sure you DON't perform NAT on those packets, neither from
client to (internal) server destination, nor on responses in return.

  > you really should add a special rule group that traps the packets as they
  > come in on the internal interface and send them to nat if they are destined
  > for the other internal machine. (and the return packets).

Yes, but don't you rather mean only send them to nat if they are NOT
destined for the other (here server) internal machine/s?

  > I have never done this so when you work it out let us know :-)

Paraphrasing an old maxim of yours, "Don't send packets to NAT that it
doesn't care about", ie don't gratuitously NAT every packet out from the
internal machines, unless they're definitely bound for the outside,
which can readily be done with something like, for outbound NAT:

wow someone listened to something I said!   :-)


  add skipto $pastnatrule ip4 from $server:$port to $internalnet out
  add $natrule nat N ip4 from any to any out xmit $extif recv $intif

whereby outbound packets are only NAT'd if routed to the $extif
(and in fact, on that basis, the first rule is likely redundant)

Of course the ACLs for the internal server:port need to accept packets
from the internal network, and return packets sent by that server also
need to NOT do NAT on the way out, again best to specifically skip NAT
for packets clearly destined for the LAN, as above.  I have done this.

DNS may be an issue; if you need internal clients to be able to access
the internal, normally redirected address:port by its externally-known
name, eg www.myserver.net:port/ then you could use split DNS, like bind
views.  If you don't control DNS, LAN clients may instead need an entry
in /etc/hosts, which may or may not be inconvenient, depending on scale.

That said, I'n mot really sure I'm addressing the correct problem :)

cheers, Ian

I Believe the problem is as follows:

there are two machines inside the NAT'd lan,  A and B, (local addresses) .
The NAT machine is X on the outside and Y on the inside.
B is also visible to the outside world as the Nat'd address C (which 
may or may not be the same as X).


A wants to be able to send a request to address C and have it bounce 
back to B, (with a source address of Y).

The reply to Y should in turn be bounced back to A.

This is quite complicated and while I am sure we could work out how it 
should be done I can't just rattle off an answer.
It probably requires two instances of NAT a regular NAT on the 
external interface,
and a reverse nat on the inside interface, triggering on outgoing 
packets. turning them around




___
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: gateway machine port redirect question

[Julian Elischer]

On 20/02/2016 6:22 PM, Valeri Galtsev wrote:

Dear Experts,

I'm one of Linux refugees who several years ago migrated majority of
servers from Linux to FreeBSD and is happy since. When recently I needed
to set up gateway (Firewall + NAT) machine, I set up FreeBSD 10.2 on it,
used ipwf and natd, and all works well, machines behind gateway on LAN can
happily reach real network. I hit one snag later though: When I tried to
redirect TCP traffic on some port to machine on internal private network
behind gateway, whatever I do doesn't work.

Could somebody point to simple example (it doesn't matter which components
are involved, I don't feel married to ipfw and natd) for FreeBSD 10.2 that
makes the machine gateway, and one of the ports of traffic coming from
public network is redirected to machine on private network behind gateway.
Something I can reproduce that works, which I then will gradually convert
into what I need. Other way around: adding redirection to already working
(and a bit sophisticated) gateway I set up appears to be beyond my mental
abilities: a couple of weeks of frustration confirm it to me.

I really do not want to go back to Linux to do this, even though I feel I
can do it based on Linux in a course of an hour or two - I've set up a few
of them in the past using Linux, that's the longest it took me in my
recollection.

Thanks in advance for all your answers and pointers!

Valeri


Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
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 CAN be done but it gets tricky.

usually we do NAT on the external interface. the trouble is that you 
don't want that traffic to go through the external interface, but to 
get routed back in.
you really should add a special rule group that traps the packets as 
they come in on the internal interface and send them to nat if they 
are destined for the other internal machine. (and the return packets).


I have never done this so when you work it out let us know :-)

___
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: ifconfig with quoted arguments

[Julian Elischer]

On 10/02/2016 5:51 AM, Jeremy Boy wrote:

Hello list,

please CC me in replies to this mail, since I am no subscriber to this list.

For safety reasons, we enclose user input to shell commands in quotes. Until 
today, the resulting command for ifconfig(8) looked like this:


ifconfig ue0 inet "192.168.2.176 netmask 255.255.255.0"


As we figured out, this means that ifconfig sometimes doesn't set the netmask 
as we expect it to do:


root@csbuild:~ # ifconfig ue0
ue0: flags=8843 metric 0 mtu 1500
 options=80001
 ether b8:27:eb:fd:58:69
 inet 192.168.2.176 netmask 0x broadcast 192.168.255.255
 media: Ethernet autoselect (100baseTX )
 status: active
 nd6 options=29
root@csbuild:~ # ifconfig ue0 inet "192.168.2.176 netmask 255.0.0.0"
root@csbuild:~ # echo $?
0
root@csbuild:~ # ifconfig ue0
ue0: flags=8843 metric 0 mtu 1500
 options=80001
 ether b8:27:eb:fd:58:69
 inet 192.168.2.176 netmask 0xff00 broadcast 192.168.2.255
 media: Ethernet autoselect (100baseTX )
 status: active
 nd6 options=29
root@csbuild:~ #


As you can see, ifconfig sets the netmask to 255.255.255.0, ignoring the 
netmask we provided. If provided with a 10.* address, ifconfig sets the netmask 
to 255.0.0.0, no matter what actual netmask we entered. Also, it doesn't exit 
with a status indicating error, which made it a little harder to debug this 
issue. The following works as expected:


root@csbuild:~ # ifconfig ue0
ue0: flags=8843 metric 0 mtu 1500
 options=80001
 ether b8:27:eb:fd:58:69
 inet 192.168.2.176 netmask 0xff00 broadcast 192.168.2.255
 media: Ethernet autoselect (100baseTX )
 status: active
 nd6 options=29
root@csbuild:~ # ifconfig ue0 inet "192.168.2.176" netmask "255.0.0.0"
root@csbuild:~ # ifconfig ue0
ue0: flags=8843 metric 0 mtu 1500
 options=80001
 ether b8:27:eb:fd:58:69
 inet 192.168.2.176 netmask 0xff00 broadcast 192.255.255.255
 media: Ethernet autoselect (100baseTX )
 status: active
 nd6 options=29
root@csbuild:~ #

What exactly does ifconfig do? It seems to me that it reads the IP address from 
the quoted string but truncates the netmask. Is this a bug in ifconfig or 
intended behavior?

it's not so much as ifconfig, as the shell

you have ifconfig with 3 arguments, the last of which is

  "192.168.2.176 netmask 255.255.255.0"

which ifconfig inspects to see if it has an IP address in it (followed 
by a space which terminates the test successfully).


this is expected behaviour.   Though admittedly a less than clear 
example of it.







Best wishes
Jeremy
___
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"

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

[Julian Elischer]

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 on network card
underlaying my VLANs and it was enough to solve problem with port
redirection. Without turning tso4 off ipfw + in-kernel NAT works
fine but port redirection fails.



Thank you. It's my mistake - was confused by home gateway, where 
redirect_port worked perfectly (NIC without TSO support), and there 
is a notice in section BUGS of ipfw(8) about incompatible libalias 
and TSO.


so why are you using libalias?
I may have misread what you are doing but IP masquerading might work 
better.  (ipfw fwd rule with local destination)

___
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"

Re: ppp(8) PPPoE fails when ifname contains "."

[Julian Elischer]

On 7/01/2016 6:29 AM, Ben Woods wrote:

Hey everyone,

I was recently trying to set up PPPoE to my ISP, over my network interface
which is configured with 802.1q VLAN tagging using vlan(4).

I utilised the vlans_= feature described in rc.conf(5),
which creates a cloned interface named ..

In /etc/ppp.conf I used the syntax PPPoE:. and this exposed
an interesting issue - ppp(8) would not set up the PPPoE interface
correctly when the interface contains a period.

When I manually created the vlan clone interface with a name not containing
a period, ppp(8) worked fine.

Has anyone seen this before? A quick review of the ppp(8) code, and I am
struggling to see the exact point where this syntax problem is.


pppoe is implemented using netgraph.
 '.' has special meaning in netgraph.



Regards,
Ben

--
From: Benjamin Woods
woods...@gmail.com
___
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"

Re: Does FreeBSD have sendmmsg or recvmmsg system calls?

[Julian Elischer]

On 4/01/2016 5:32 AM, HuanHuan wrote:

Hi Rui,

There are no existing applications, but these two calls are for 
developing new application on 10G links.


Currently I use netgraph, especially ng_socket node. And a simple 
recvfrom() on a ng_socket costs ~5us or so (200K per second). And 
there are many netgraph sockets. So it's good to reduce the time by 
ultilizing send/recvmmsg() if there are these two syscalls. Even a 
simple-loop like implmentation like linux's will be good as Luigi 
has suggested.


As the writer of netgraph I would like to point out that it was never 
designed to be a high throughput service.
I'm happy thought that it CAN be used at these speeds but I designed 
it for prototyping and for serial line speeds.
The idea was that once something was prototyped out, one would take 
the code from all the modules used and create

a special purpose module that dd what you need.
The fact that people have not needed the last step is gratifying but 
surprising.




On Sun, 3 Jan 2016, Rui Paulo wrote:


On Sun, 2016-01-03 at 18:34 +0800, HuanHuan wrote:

NetBSD 7.0 has just introduced these two syscalls.
And Linux also has them.

Does FreeBSD have them? Or plan to support them in the future?


FreeBSD does not have them.  It doesn't seem especially hard to
implement, though.  Do you know any major application already using
them?

--
Rui Paulo



___
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"

Re: BPF Berkeley Packet Filter

[Julian Elischer]

On 30/12/2015 12:22 PM, Juan Herrera wrote:

Hello BSD folks,

I am developing a networking application in C and I have a question
regarding BPF (Berkeley Packet Filters),
I will give you an idea of the app first,  I need to send a packet from
machine A to machine B (any kind of packet) so for this I wrote a packet
generator application which will send a packet to machine B, but before
sending the packet I need to append some metadata values at the end of the
packet, already done, so in machine B I have a raw socket listener app
ready to receive incoming packets from machine A, however I want to
implement filtering with BPF on machine B, but as my metadata was appended
at the end of the packet (have to be at the end), I need to read the packet
length with(using) Berkeley Packet Filter to match a specific field to
filter one of the bytes at the end of my packet (metadata appended), in
other words I need to know the incoming packet length to filtered against
one of the metadatas fields and be able to drop the packet before reaching
user space applications(drop it in kernel space).

So my question is, Can I use BPF to read the packet length to do what I
want?

you mean can you use a bpf filter to act upon a trailer?
yes you can
look at the man page for BPF_LD and BPF_LEN




Thank you in advance!

Happy Holidays!
___
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"

Re: BPF Berkeley Packet Filter

[Julian Elischer]

On 30/12/2015 6:26 AM, Juan Herrera wrote:

Hello,

I have a question regarding Berkeley Packet filter, which is Can I read an
incoming packet length with BPF, I am working on a project that requires to
filter the receiving packets in the kernel before they get to userspace,
but I need to be able to read the packet length when applying BPF because I
(previously) encapsulated the packet with my own metadata before sending it
to the machine with BPF so I want to read packet length to decapsulate as I
know the value for the metadata at the end of the packet?

https://www.freebsd.org/cgi/man.cgi?bpf%284%29
should show you what you need.

there is a structure prepended to the packet that includes the 
original length.


or do you want to know the length BEFORE reading it?
or do you want your filter to know the length?

what do you mean by "applying BPF"?







Thank you in advance!
___
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"

Re: ipsec tunnel and vnet jails: routing, howto?

[Julian Elischer]

On 27/12/2015 4:24 AM, Michael Grimm wrote:

Hi,

I am currently stuck, somehow, and I do need your input. Thus, let me explain, 
what I do want to achieve:

I do have two servers connected via an ipsec/tunnel ...
[A] dead:beef:1234:abcd::1 <—> dead:feed:abcd:1234::1 [B]
… which is sending all traffic destined for dead:beef:1234:abcd::/64 and 
dead:feed:abcd:1234::/64 through the tunnel, and vice versa.

That did run perfectly well during the last years until I decided to give VNET 
jails a try. Previously, some of my old fashioned jails got an IPv6 address 
attached like dead:beef:1234:abcd:1:2::3, and I could reach that address from 
the remote server without any routing/re-directing or alike, necessary. Now, 
after having moved those jails to VNET jails (having those addresses bound to 
their epairXXb interfaces), I cannot reach those addresses within those jails 
any longer.

>From my point of view and understanding this must have to do with lack of 
proper routing, but I am not sure, if that is correct, thus my questions to the 
experts:

1) Is my assumption correct, that my tunnel is "ending" after having passed my 
firewalls at each server, *bevor* decrypting its ESP traffic into its final destination 
(yes, I do have pf rules to allow for esp traffic to pass my outer internet facing 
interface)?

2) If that is true, racoon has to decide where to deliver those packets, 
finally?

3) If that is true, I do have an issue with routing that *cannot* be solved by 
pf firewall rules, right?

4) If that is true, what do I have to look for? What am I missing? How can I 
route incoming and finally decrypted traffic to its final destination within a 
VNET jail?

5) Do I need to look for a completely different approach? Every hint is highly 
welcome.


basically you have to treat the jails as if they are totally separate 
machines that are reached through the vpn endpoints instead of being 
the endpoints themselves.
This will require a different setup.  for example your tunnel will 
need to be exactly that  a tunnel and not just an encapsulation. And 
you will need full routing information for the other end at each end.




Thanks in advance and with kind regards,
Michael

___
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"

Re: Have I got this VIMAGE setup correct?

[Julian Elischer]

On 23/12/2015 1:05 AM, Garrett Wollman wrote:

The consensus when I asked seemed to be that VIMAGE+jail was the right
combination to give every container its own private loopback
interface, so I tried to build that.  I noticed a few things:

1) The kernel prints out a warning message at boot time that VIMAGE is
"highly experimental".  Should I be concerned about running this in
production?

CYA only

If you are not doing much that is super unusual you should be fine.


2) Stopping jails with virtual network stacks generates warnings from
UMA about memory being leaked.


I haven't any information about that.


3) It wasn't clear (or documented anywhere that I could see) how to
get the host network set up properly.  Obviously I'm not going to have
a vlan for every single jail, so it seemed like what most people were
doing was "bridge" along with a bunch of "epair" interfaces.  I ended
up with the following:

there are exapmples in /usr/share/examples/netgraph for some things..
I've never used the build in configuration stuff,, always handcoded 
it.. It's probably improved a lot since then.

network_interfaces="lo0 bridge0 bce0"
autobridge_interfaces="bridge0"
autobridge_bridge0="bce0 epair0a epair1a"
cloned_interfaces="bridge0 epair0 epair1"
ifconfig_bridge0="inet [deleted] netmask 0xff00"
ifconfig_bridge0_ipv6="inet6 [deleted] prefixlen 64 accept_rtadv"
ifconfig_bce0="up"
ifconfig_epair0a="up"
ifconfig_epair1a="up"

The net.link.bridge.inherit_mac sysctl, which is documented in
bridge(4), doesn't appear to work; I haven't yet verified that I can
create a /etc/start_if.bridge0 to set the MAC address manually without
breaking something else.  The IPv6 stack regularly prints
"in6_if2idlen: unknown link type (209)" to the console, which is
annoying, and IPv6 on the host doesn't entirely work -- it accepts
router advertisements but then gives [ENETUNREACH] trying to actually
send packets to the default gateway.  (IPv6 to the jails *does* work!)

In each of the jails I have to manually configure a MAC address using
/etc/start_if.epairNb to ensure that it's globally unique, but then
everything seems to work.

Does this match up with what other people have been doing?  Anything
I've missed?  Any patches I should pull up to make this setup more
reliable before I roll it out in production?


I haven't used it for a couple of years..
I know others are, so I'll let them pipe up.


-GAWollman
___
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"

Re: Per-jail private loopback

[Julian Elischer]

On 18/12/2015 11:51 AM, Craig Rodrigues wrote:

On Thu, Dec 17, 2015 at 3:48 PM, Garrett Wollman 
wrote:


Or is VIMAGE cheap
enough that I won't notice the performance hit?
Vimage is a negligable overhead in a 1 jail (base jail) system and can 
actually end up with a negative overhead (gain) in some scenarios.


Most vimage systems use a bridge (either netgraph or if_bridge) to 
connect the jails together to the outside world which leads to some 
extra packet handling, but in a system with 24 CPUs it's often handled 
by an otherwise idle CPU so no performance hit is seen.  It can be a 
nett gain if you have several interfaces and assign each interface to 
a different jail/VNET.  In this case the different network stacks are 
not contending with each other for locks where in a single stack jail 
configuration they would be contending. Different vlan interfaces can 
be assigned to different VNETS for the same effect if you don't have 
multiple physical interfaces avaliable.
Even with the extra packet handling of bridged VNETs there can be 
advantages.. For example you can put your jails behind an extra layer 
of routing WITHIN the host so that changes of routes and connectivity 
from the machine to the outside world are not seen by the applications.



Olivier did some measurements with VIMAGE:
https://lists.freebsd.org/pipermail/freebsd-arch/2014-October/016054.html

I think you should give VIMAGE a shot, if you are doing any serious work
with jails.  I run with VIMAGE configured by default in all my systems
running 10-STABLE
and CURRENT.

--
Craig
___
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"

Re: IPFW blocked my IPv6 NTP traffic

[Julian Elischer]

On 2/12/2015 12:27 AM, el...@sentor.se wrote:

On Tue, 1 Dec 2015, Mark Felder wrote:




On Tue, Dec 1, 2015, at 02:02, wishmaster wrote:


Hi, Mark.


I'm hoping someone can explain what happened here and this isn't 
a bug,

but if it is a bug I'll gladly open a PR.

I noticed in my ipfw logs that I was getting a log of "DENY" 
entries for

an NTP server

Nov 30 13:35:16 gw kernel: ipfw: 4540 Deny UDP
[2604:a880:800:10::bc:c004]:123 [2001:470:1f11:1e8::2]:58285 in 
via gif0


Three long-shots:

1)
I see that you use a gif interface. That makes me wonder:
Do the 'keep-state' function in 'ipfw' work as bad as it does in 'pf'?
Not to solve the problem here, but to give some general education, the 
keep-state in ipfw keeps a pointer to the action section of the rule 
that generates it, and if another packet from the same session is 
detected, the same action section is executed again. so, for example 
if the action section is "skipto 2" it will skip to rule 2, regardless 
of where it is. (it's theoretically possible to crash/hang your system 
that way by having a rule skip to a rule before itself, which is not 
normally allowed).
No notice is taken of where ipfw was called from or what interface 
introduced the packet..
Only source and destination addresses (and ports) and the protocol are 
examined. (no ports if icmp).




In pf, 'keep state" doesn't keep state between software network 
interfaces and real network interfaces. So if I allow something in 
via tun0 (a software OpenVPN NIC), with keep state, the response is 
*not* automatically (via the state table) allowed back in on the 
ethernet NIC it was sent out. So for all my VPN-rules, I have to 
make two of them like this:


Pf example:
pass in  quick on tun0 inet proto tcp from  to 
 port 22 keep state label "VpnIN - SSH"
pass out quick on em1  inet proto tcp from  to 
 port 22 keep state label "DmzOUT - SSH"




2)
Is this hapening over and over, or was it just a one time thing?
If the latter, could it be that you flushed your firewall state 
table just after a cron job ran 'ntpdate 2604:a880:800:10::bc:c004', 
so the query got out but immediately after the state table was 
emptied and hence the response got blocked?




3)
If 2001:470:1f11:1e8::2 is not the ipfw node itself, but some node 
behind it, could the ntp query to 2604:a880:800:10::bc:c004 have 
taken a different path? I.e. the ipfw node doesn't see the query, 
but the response packet is routed to it, so it gets blocked.


/Elof
___
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"

Re: vimage and jail networking

[Julian Elischer]

On 1/12/2015 3:49 PM, Ben Woods wrote:
On 1 December 2015 at 06:48, Nathan Aherne > wrote


interestingly this is the first time I see this email.  I think 
something blocked he original for me.


Thank you for helping me to understand vimage better Julian! I
have read all three links you posted a number of times.



I think the example in /usr/share/examples/netgraph actually does all 
that you want for you..  just edit and run.



I use iocage for jail management and it uses epair. From your
comments it seems you recommend netgraph?


no
I recommend you use whatever works for you..  :-)
epair allows you to connect jails together with point to point links. 
it is then jsut a routing problem.
If you want a bridged solution I think you can combine epair with 
if_bridge,  but haven't tried that myself.


you can achieve the exact same with netgraph. netgraph will give you 
more flexibility but is more 'complex' to drive.
On the other hand its designed to be embedded in scripts. So you don't 
usually have to confront the complexity each time you use it.





This is the link to the iocage image instructions -

https://iocage.readthedocs.org/en/latest/networking.html#configuring-a-vnet-jail

.
It seems that iocage does a number of things automatically or at
least I am still confused on how to use iocage and vimage to
have multiple jails share a single public (external) IP. I will
continue to read the links you sent me in the hopes that the
ahah moment comes to me.

Regards,

Nathan


The public IP will be configured on whichever device you have 
connected to the internet. Normally that is a physically separate 
edge firewall/router. It has the public IP and performs NAT for any 
devices on the LAN that talk to the internet. This configuration has 
nothing to do with your jails - it is required for any computers on 
your LAN which talk to the internet.


The jails are then each configured with a LAN address (10.0.0.0/8 
 range if you like). When they need to talk to 
the internet, they will go via their default route, which is 
normally your edge firewall/router, and is often given a 10.0.0.1 
address (but could be anything you like). The router will perform 
the NAT, and if you want the jails to host service listening for 
internet traffic, you will also need to configure port forwarding on 
the router to send traffic on the relevant ports to your jails on 
their LAN IP address.


Note that if your router happens to be the host running the jails, 
this doesn't change any of the above.


yes usually I would have Nat on the outgoing interface of whichever 
jail isn my 'final router',
 and all the jails connected together by some bridge construction 
that has one leg on
a second interface in the router jail (maybe the base jail but not 
necessarily).






Regards,
Ben


___
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: Outgoing packets being sent via wrong interface

[Julian Elischer]

On 1/12/2015 4:03 PM, Daniel Bilik wrote:

On Mon, 30 Nov 2015 23:47:18 +0800
Julian Elischer <jul...@freebsd.org> wrote:


ok next time try
netstat -raAnW before and after

Attached ("Internet6" part removed to reduce noise).


maybe we can spot at difference.

According to diff(1), entries differ only by "Use" column between .pre
and .during. The .post output shows the state after "refreshing" default
route, so there are also different addresses for those entries.


so that doesn't tell us much..

I"m as stumped as you are here..

if you reload pf it has no effect?
pf is the part of the picture I have no experience with so I'm 
naturally suspicious of it.

have you tried a simple ipfw nat instead?  just as a sanity check?

something like
ipfw nat 1 config if re0
ipfw add 30 nat 1 ip from not me  to any out xmit re0
ipfw add 40 nat 1 ip from any to me in recv re0






--
Dan


___
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: Outgoing packets being sent via wrong interface

[Julian Elischer]

On 30/11/2015 5:18 PM, Daniel Bilik wrote:

On Sat, 28 Nov 2015 18:06:45 +0800
Julian Elischer <jul...@freebsd.org> wrote:


next time it happens try flushing the arp table.

Just tried...

arp -d -a

... didn't help. Followed by refreshing default route, which solved it


ok next time try

netstat -raAnW before and after

maybe we can spot at difference.



again.

--
Dan



___
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: Kernel NAT issues

[Julian Elischer]

On 27/11/2015 12:55 PM, Nathan Aherne wrote:

Hi Julian,

Thank you for replying. I was completely off grid for a while and only got back 
on it today.

I thought that Vimage was probably the way to achieve what I want. The main 
reason I was staying away from Vimage was the reported bugs with it, another 
reason was the extra overhead. I would like to be able to shutdown jails quite 
regularly so was worried the kernel panic bug or memory leak bug might be a 
problem here. Is there any version of Vimage/FreeBSD which is stable?
Generally vimage is stable. It has had problems with pf over the years 
becasue pf is imported from OpenBSD and has some pretty 
vimage-unfriendly assumptions in its design, but I hear that even some 
of thise have been ironed out.
I know of vimage being used to run production virtual systems in some 
of the largest banks in the world processing amounts of trnasactions 
that would make your head spin so have a small play with it.

Vimage overhead is negative in some situations. i.e. things work faster..
This is especially true when non vimage workloads contest a single 
lock heavily,

but vimage splits it over many locks.. one for each VM.

run up a virtualbox or amazon or whatever freebsd instance and play 
around with it.
once realize how insanely powerful it is,  you will wonder how you 
ever did jails without it.


you can use bridges, epairs or netgraph to do your networking... your 
choice.







Regards,

Nathan


On 23 Nov 2015, at 5:02 pm, Julian Elischer <jul...@freebsd.org> wrote:

On 21/11/2015 10:06 AM, Nathan Aherne wrote:

I had a bit of a think about how to describe what I am trying to achieve.

I am treating each jail likes its own little "virtual machine”. The jail 
provides certain services, using things like nginx or nodejs, php-fpm, mysql or 
postgresql. The jails can control connections to themselves by configuring the 
firewall ports that are opened on the IP their IP  (10.0.0.0/16 or a public IP). I 
know the jails have no firewall of their own, the firewall is configured from the 
host.

I want each jail or “virtual machine” to be able to communicate with one 
another and the wider internet. When a jail does a DNS query for another App 
jail, it may get a public IP on its own Host (or it may get another host) and 
it has no issues being able to communicate with another jail on the same host.

At the moment all of the above is working perfectly except for jail to jail 
communication on the same host (when the communication is not directly between 
10.0.0.0/16 IP addresses).

this is pretty much exactly when vimage/vnet jails could be used to great 
affect.
Is there a reason you are not doing that?  Each jail has it's own routing 
tables, addresses and (virtual) interfaces.

here's how I'd do it with vimage

   +--+
   +---+  | servers
   |   +--+
   |
   |   +--+
   |  ++  |
   |  |+--+
   |  |
 ++ +--+--++
 | iface  | | bridge   |
 |+-+  |
 ++ ++-+
 |
 |
 |
 |
 |
 |
++-+
|  |
|  |
|   NAT jail router|
|  |
|  |
+---+++---++
|||   |
 +--+--+  +--+--+  +--+--+ +--+--+
 | |  | |  | | | |
 | |  | |  | | | |
 | |  | |  | | | |jails
 | |  | |  | | | |
 +-+  +-+  +-+ +-+



however the hairpin idea might still be useful even in that scenario if they 
don't know about each other's 'local' addresses, but do NAT'd machines need to 
talk to each other by externeal addresses?

i Nathan

On 21 Nov 2015, at 9:12 am, Nathan Aherne <nat...@reddog.com.au> wrote:

I am not exactly sure how to draw the setup so it doesn’t confuse the 
situation. The setup is extremely simple (I am not running vimage), jails 
running on the 10.0.0.0/16 (cloned lo1 interface) network or with public IPs. 
The jails with private IPs are the HTTP app jails. The Host runs a HTTP Proxy 
(nginx) and forwards traffic to each HTTP App jail based on the URL it 
receives. The jails with public IPs are things like database jails which cannot 
be proxied by the Host.

I can happily communicate with any jail from my laptop (externally

Re: Outgoing packets being sent via wrong interface

[Julian Elischer]

On 27/11/2015 5:13 PM, Daniel Bilik wrote:

On Wed, 25 Nov 2015 12:20:33 +
Gary Palmer  wrote:


route -n get 

As suggested by Kevin and Ryan, I set the router to drop redirects...

net.inet.icmp.drop_redirect: 1

... but it happened again today, and again affected host was 192.168.2.33.
Routing and arp entries were correct. Output of "route -n get"...

route to: 192.168.2.33
destination: 192.168.2.0
mask: 255.255.255.0
 fib: 0
   interface: re1
   flags: 
  recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
0 0 0 0  1500 1 0

... has not changed during the problem.

Interesting was ping result...

PING 192.168.2.33 (192.168.2.33): 56 data bytes
ping: sendto: Operation not permitted
ping: sendto: Operation not permitted
...
64 bytes from 192.168.2.33: icmp_seq=11 ttl=128 time=0.593 ms
ping: sendto: Operation not permitted
...
64 bytes from 192.168.2.33: icmp_seq=20 ttl=128 time=0.275 ms
64 bytes from 192.168.2.33: icmp_seq=21 ttl=128 time=0.251 ms
ping: sendto: Operation not permitted
...
64 bytes from 192.168.2.33: icmp_seq=40 ttl=128 time=0.245 ms
ping: sendto: Operation not permitted
64 bytes from 192.168.2.33: icmp_seq=42 ttl=128 time=7.111 ms
ping: sendto: Operation not permitted
...
--- 192.168.2.33 ping statistics ---
46 packets transmitted, 5 packets received, 89.1% packet loss

It seems _some_ packets go the right interface (re1), but most
try to go wrong (re0) and are dropped by pf...

00:00:01.066886 rule 53..16777216/0(match): block out on re0: 82.x.y.50 > 
192.168.2.33: ICMP echo request, id 58628, seq 39, length 64
00:00:02.017874 rule 53..16777216/0(match): block out on re0: 82.x.y.50 > 
192.168.2.33: ICMP echo request, id 58628, seq 41, length 64
00:00:02.069634 rule 53..16777216/0(match): block out on re0: 82.x.y.50 > 
192.168.2.33: ICMP echo request, id 58628, seq 43, length 64

And again, refreshing default route (delete default / add default)
resolved it...

PING 192.168.2.33 (192.168.2.33): 56 data bytes
64 bytes from 192.168.2.33: icmp_seq=0 ttl=128 time=0.496 ms
64 bytes from 192.168.2.33: icmp_seq=1 ttl=128 time=0.226 ms
64 bytes from 192.168.2.33: icmp_seq=2 ttl=128 time=0.242 ms
64 bytes from 192.168.2.33: icmp_seq=3 ttl=128 time=0.226 ms


next time it happens try flushing the arp table.



--
Dan
___
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"

Re: Is it allowed to copy hyper-v drivers from FreeBSD 10 and packed it into FreeBSD 9.2

[Julian Elischer]

On 23/11/2015 11:30 PM, Adrian Chadd wrote:

On 22 November 2015 at 21:58, Hongjiang Zhang  wrote:

Hi,

Some people, who used FreeBSD 9.2 and back-port network driver for Hyper-v from FreeBSD 10, 
encountered a network issue. They installed 2 VM (FreeBSD 9.2 with the customized FreeBSD kernel) 
on Azure. Network went offline very soon when the big file (~320M byte) is copied from one VM to 
anther through "scp". If TSO is disabled through "sysctl -w 
net.inet.tcp.tso=0", this issue will be alleviated but cannot be eliminated. I did not figure 
out why.

I have checked the release notes of FreeBSD 9.2/9.3/10, but did not find 
anything which blocked the back-port. It is supposed 9.2 allows the back-ported 
Hyper-v drivers from 10. Is this assumption correct?

Hi!

It may be something to do with maximum mbufs per packet or some other
limit like that. Is there a lot of interest in backporting the latest
hyperv driver to 9.2?


I believe we  ($JOB) have them back ported to 8.0. (I didn't do the work)




-a


___
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"



___
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: tap(4) and host-only networking between host and guest

[Julian Elischer]

On 11/5/15 10:31 AM, Victor Sudakov wrote:

Neel Natu wrote:

Julian Elischer wrote:

I am experimenting with bhyve which uses tap(4) for network access.

I don't want to bridge tap0 with any of the hosts's real NICs. How can
I create a private network just between the host and the guest?

you are thinking too hard!

tap IS the interface..

ifconfig tap0 $address...
and in the VM, ifconfig vtnet0 ${some_other_address}

Thank you, Julian! It works. I felt I was missing something obvious.

For some reason, after a guest is shutdown or rebooted, the IP address
on the host's tap0 interface is deleted.


Try using 'vmnet0' instead of 'tap0'. It will retain the IP address
even after a guest reboot/shutdown.

Thanks, I see now vmnet is documented in tap(4).

I didn't know that...
Ok, so now you are an expert, can we count on you to answer all future 
questions on this topic?  ;-)







___
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: tap(4) and host-only networking between host and guest

[Julian Elischer]

On 11/4/15 3:54 PM, Victor Sudakov wrote:

Colleagues,

I am experimenting with bhyve which uses tap(4) for network access.

I don't want to bridge tap0 with any of the hosts's real NICs. How can
I create a private network just between the host and the guest?

you are thinking too hard!

tap IS the interface..

ifconfig tap0 $address...
and in the VM, ifconfig vtnet0 ${some_other_address}





I even tried to create a lo1 interface on the host and bridge it with
tap0 but lo1 would not add as a bridge member even if I adjust its MTU.


root@vas:/etc # ifconfig bridge0 create
root@vas:/etc # ifconfig lo1 mtu 1500 up
root@vas:/etc # ifconfig bridge0 addm tap0
root@vas:/etc # ifconfig bridge0 addm lo1
ifconfig: BRDGADD lo1: Invalid argument
root@vas:/etc #
root@vas:/etc # ifconfig bridge0
bridge0: flags=8802 metric 0 mtu 1500
 ether 02:8f:fd:16:50:00
 nd6 options=9
 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
 root id 00:00:00:00:00:00 priority 0 ifcost 0 port 0
 member: tap0 flags=143
 ifmaxaddr 0 port 5 priority 128 path cost 200
root@vas:/etc #

Any help is appreciated.



___
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: nice stuff from cloudflare (and, we need something like ethtool!)

[Julian Elischer]

On 10/10/15 10:59 PM, Luigi Rizzo wrote:

the nice folks at cloudflare implemented a nice feature
in netmap that puts some queues of the NIC in netmap mode
leaving others attached to the host stack

https://blog.cloudflare.com/single-rx-queue-kernel-bypass-with-netmap/

and use ethtool (and native NIC filters) to steer traffic around.
[FWIW, the chelsio native netmap driver is similar except that
the netmap queue has a different MAC address]

While their code was developed on linux, it should run
almost unmodified on FreeBSD (and we plan to import it soon),
except for the fact that we don't have ethtool hence no
device-independent mechanism to configure traffic steering.

We really need to address the latter.


I suspect the answer may be a device dependent sysctl



cheers
luigi




___
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: Value of congestion window (cwnd) when loss is detected

[Julian Elischer]

On 9/3/15 7:13 PM, Lawrence Stewart wrote:

On 09/03/15 10:54, hiren panchasara wrote:

I am failing to understand the reason behind this behavior.

What should the congestion window (snd_cwnd) be set to when we hit loss?
It seems that we set it to 1 segment right now.
https://svnweb.freebsd.org/base/head/sys/netinet/tcp_input.c?revision=286227=markup#l2531

I also see that in the simulations I did. Sender side pcap can be found
at: https://people.freebsd.org/~hiren/pcaps/single_packet_loss.pcap

Trying to send 50kb of data from freebsd 10.2 server to freebsd client.
Initial cwnd is 10 so we blast out 10 packets but 1 packet gets dropped:
seq 2897:4345. We get 3 dupacks and we retransmit it. But as soon as we
detect this loss, we reduce cwnd to 1 segment. In fact, we could've used
data in SACK to see how much we could send on the n/w, imo.

3rd dup ack (which triggered the retransmit) looks like this:
IP 192.168.11.10.41674 > 192.168.10.10.http: Flags [.], ack 2897, win
12579, options [nop,nop,TS val 4236220288 ecr 3905376863,nop,nop,sack 1
{4345:10137}], length 0

And the retransmit:
IP 192.168.10.10.http > 192.168.11.10.41674: Flags [.], seq 2897:4345,
ack 172, win 12579, options [nop,nop,TS val 3905376894 ecr 4236220288],
length 1448

At this point in time, sender knows that it has sent 23169 bytes (last
packet server sent was seq 21721:23169) and received ack for 10137
bytes minus a missing packet = 8689 bytes. i.e. 6 packets. So, there is
at least that much room on n/w at that point in time. We can go
conservative and halve that. i.e. 3 packets. That is still better than
going down to 1 packet.

Is there something basic I am missing here?
Any insights would be helpful.

You want to read up about window inflation during fast recovery in RFC
5681 followed by 3782, and then consult Stevens vol 2 to understand how
variables are used for different purposes depending on connection state
and which code path was taken (something I greatly dislike and would
love to change one day).

how about today?


Cheers,
Lawrence
___
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"

Re: FreeBSD 10.2 , ospf vs. aggregated static routes, performance issue

[Julian Elischer]

On 8/25/15 10:07 PM, Evgeny Khorokhorin wrote:

Hi,

I have 10.2-STABLE, 2 CPU Intel E5-2643v3, network Intel XL710 with 
1.4.0 driver from Intel
I know that going through routing table is very fast (rn_match). But 
I decided to optimize routing table.

I'm using 2 interfaces - ixl0 and ixl1.
Behind ixl0 I have 304 networks 172.16.. from /28 to /24 all via the 
same gw 1.1.1.1 (because ip on ixl0 with /30 mask). And behind ixl1 
I have default route via 2.2.2.2.
That 304 172.16 networks I receive via OSPF (quagga). Now all is OK 
- on every interface I have up to 500kpps/395kpps, 4.5Gbps/1.57Gbps 
(rx/tx on ixl1 and tx/rx on ixl0).
If I disable OSPF and in zebra add static route 172.16.0.0/12 via 
1.1.1.1, the system works good until traffic grow up to 
251kpps/181kpps , 2.27Gbps/637Mbps. After that the system is 
degrading: ixl's queue threads utilizes 100% CPU and I see many many 
traffic drops (netstat -i)
If I turn on ospfd and receive 304 more specific routes the problem 
disappears.


Where is the problem? Or I have misunderstanding about how FreeBSD 
uses routing table..
P.S. I use this machine as NAT. I checked this on ipfw and pf, all 
the same.


without knowing anything, it looks like a lock on the route is a 
bottleneck.

lots of routes spreads the pain..

try two manually added static routes  172.16.0.0/13 and 172.24.0.0/13 
(I hope I split that correctly) and see if it changes things..

then try 4..




-- Cheers,
Evgeny

___
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

Re: Mellanox 40Gb support

[Julian Elischer]

On 8/21/15 11:24 PM, aurfalien wrote:

Hi,

Well, this is all in a test env of course, but I’m planning to use head.

What are your thoughts?
My curiosity was as to whether you hook this into the current NFS or 
whether

it's so different that it's almost a new implementation..?



- aurf

Janitorial Services

On Aug 21, 2015, at 8:21 AM, Julian Elischer jul...@freebsd.org 
mailto:jul...@freebsd.org wrote:



On 8/21/15 10:29 PM, aurfalien wrote:

Hi,

Thanks very much for the response.

Well, I’m implementing NFSoRDMA and as a best practices, Mellanox 
suggested I use the very latest drivers.




really?
On FreeBSD?
Is this a fresh implementation of NFS or using the NFS in head?





___
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: Ethernet tunneling options under FreeBSD

[Julian Elischer]

On 8/15/15 10:40 AM, James Lott wrote:

you haven't really described the network well enough..
try an ascii-art diagram (don't forget to set fixed width font :-)
a VPN required two ends.. one is FreeBSD... what's the other?

The thing is, the other could be any number of operating systems. I'm
looking for a tunneling protocol with good cross-platform representation, but
the higher priority it enduring it tunnels ethernet frames.

For the sake of example we can say the other end is a FreeBSD host, since
FreeBSD is looking like the lowest common denominator on this topic.


if both ends are FreeBSD there are dozens of possibilities..
for example:
ng_eif-netgraph-ppp-ipsec-ppp-netgraph-ng_eif

ng_eif-ng_ksock(udp)-IPsec-ng_ksock-ng_eif


I'm not overly concerned with the host side interfaces. What I'm really
concerned with is the tunneling protocol since that's what will need support
on all of my platforms. Thus, a solution requiring netgraph on both ends is
not an option in my case.


tap-ppp-ppp-tap

I have not found any ppp implementations under FreeBSD which support BCP.
To my understanding, that's the only method by which ethernet frames can be
tunneled over ppp... if I'm wrong, please do correct me! I would love nothing
more than to be wrong about that :)


I have, in the past used UDP packets to encapsulate ethernet frames, 
and tunnelled them over a PPP link using mpd.
I don't have specifics any more. I think there may be support in 
Openvpn for what you want but I've never tried it.


On Friday, August 14, 2015 23:16:41 Julian Elischer wrote:

On 8/14/15 6:40 AM, James Lott wrote:

Hello list,

I am in the process of planning a build out of a L2 VPN, in which
I'd like to have my primary switch and DHCP server be a FreeBSD
system. I would like to join each new host to the VPN by
establishing an IP tunnel with the primary switch which transports
ethernet frames over the tunnel.

you haven't really described the network well enough..
try an ascii-art diagram (don't forget to set fixed width font :-)
a VPN required two ends.. one is FreeBSD... what's the other?


So far, the only protocol I have found supported by FreeBSD which
seems capable of this is EtherIP. As far as I can tell, it doesn't
look like there is any support for L2TPv3, and none of the PPP
implementations available appear to support BCP.

I'm not completely opposed to using EtherIP, but if there is
something more modern which will meet my needs, I would probably try
that first. So my question becomes:

* Does anyone know of a method supported under FreeBSD (other than
EtherIP) for tunneling ethernet over IP that they may be able to
suggest I check out?

if both ends are FreeBSD there are dozens of possibilities..
for example:
ng_eif-netgraph-ppp-ipsec-ppp-netgraph-ng_eif

ng_eif-ng_ksock(udp)-IPsec-ng_ksock-ng_eif

tap-ppp-ppp-tap


Thanks for any suggestions!
___
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


___
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: Ethernet tunneling options under FreeBSD

[Julian Elischer]

On 8/15/15 11:32 AM, James Lott wrote:

n2n honestly looks wonderful, but it also appears to be dead... I'm trying to
stay as close to the OS layer as possible with my options, so I would prefer
to limit the role of comprehensive software like OpenVPN or what
ZeroTierOne appears to be.

I actually found this interesting github project, which provides a simple
solution for what I'm trying to do...

https://github.com/vsergeev/tinytaptunnel


you can do this on freebsd with no added software
look at /usr/share/examples/netgraph. In particular the ether.bridge, 
virtual.lan and the udp.tunnel

examples.
You should be able to create a script that will tunnel two ethernet 
bridges together using elements from each script.


I suspect you could make it totally compatible with tinytaptunnel.




Unfortunately, it's written for Linux... and... in go... but the README at
least gave me a couple more ideas to look into.

Feel free to keep coming with the suggestions if anyone has anymore! This is
great stuff

On Saturday, August 15, 2015 13:05:17 Outback Dingo wrote:

On Sat, Aug 15, 2015 at 12:40 PM, James Lott ja...@lottspot.com

wrote:

you haven't really described the network well enough..
try an ascii-art diagram (don't forget to set fixed width font :-)
a VPN required two ends.. one is FreeBSD... what's the other?

The thing is, the other could be any number of operating systems. I'm
looking for a tunneling protocol with good cross-platform representation,
but
the higher priority it enduring it tunnels ethernet frames.

For the sake of example we can say the other end is a FreeBSD host, since
FreeBSD is looking like the lowest common denominator on this topic.


if both ends are FreeBSD there are dozens of possibilities..
for example:
ng_eif-netgraph-ppp-ipsec-ppp-netgraph-ng_eif

ng_eif-ng_ksock(udp)-IPsec-ng_ksock-ng_eif

I'm not overly concerned with the host side interfaces. What I'm really
concerned with is the tunneling protocol since that's what will need
support
on all of my platforms. Thus, a solution requiring netgraph on both ends
is
not an option in my case.


tap-ppp-ppp-tap

I have not found any ppp implementations under FreeBSD which support

BCP.

To my understanding, that's the only method by which ethernet frames can
be
tunneled over ppp... if I'm wrong, please do correct me! I would love
nothing
more than to be wrong about that :)

On Friday, August 14, 2015 23:16:41 Julian Elischer wrote:

On 8/14/15 6:40 AM, James Lott wrote:

Hello list,

I am in the process of planning a build out of a L2 VPN, in which
I'd like to have my primary switch and DHCP server be a FreeBSD
system. I would like to join each new host to the VPN by
establishing an IP tunnel with the primary switch which transports
ethernet frames over the tunnel.

you haven't really described the network well enough..
try an ascii-art diagram (don't forget to set fixed width font :-)
a VPN required two ends.. one is FreeBSD... what's the other?


So far, the only protocol I have found supported by FreeBSD which
seems capable of this is EtherIP. As far as I can tell, it doesn't
look like there is any support for L2TPv3, and none of the PPP
implementations available appear to support BCP.

I'm not completely opposed to using EtherIP, but if there is
something more modern which will meet my needs, I would probably

try

that first. So my question becomes:

* Does anyone know of a method supported under FreeBSD (other than
EtherIP) for tunneling ethernet over IP that they may be able to
suggest I check out?

if both ends are FreeBSD there are dozens of possibilities..
for example:
ng_eif-netgraph-ppp-ipsec-ppp-netgraph-ng_eif

ng_eif-ng_ksock(udp)-IPsec-ng_ksock-ng_eif

tap-ppp-ppp-tap


Thanks for any suggestions!

theres also N2N which is pretty nice, and well ZeroTierOne  which is
somewhat unique


___
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

--
James Lott
___
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