Re: ipfw -- selecting locally generated packets
On Tue, May 01, 2018 at 09:04:36PM +0800, Julian Elischer wrote: > 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. Why recv * not used for this task? ___ 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: Filtering outbound traffic for private address jails?
On Sat, Jun 25, 2016 at 10:01:37PM +, org.freebsd.secur...@io7m.com wrote: > Hello. > > I have been searching for the best part of a day for a solution to this > problem and quite frankly cannot believe that I've spent this long on > something that appears to be so simple and that used to be fairly easy > to achieve. Many years ago, I solved this problem on FreeBSD 6, but the > way I did it there seems to no longer work on modern releases. > > The problem is this: I have a single public IP address. I want to run > multiple jails. > > Back in the days of FreeBSD 6.*, the accepted way to do this seemed to > be to create a new loopback device: > > # ifconfig lo1 create > > ... and then add a lot of private 127.0.0.* addresses, one per jail. > > Then, the real network adapter and the new loopback device were both > added to a bridge (if_bridge). Unfortunately, I can't remember the exact > details, but I believe that NAT was then enabled on the real interface. > In order to filter traffic to, from, and between jails, pf rules were > written that filtered the bridge device. > > This meant that jails could correctly send outbound traffic and > receive responses (via pf states), could correctly receive specific > inbound traffic (via rdr rules), and traffic in both directions could be > filtered based on packets entering and leaving the bridge. > > However (see my other mailing list post), it seems that now with > FreeBSD 10, you just can't add loopback devices to bridges. I can find > no evidence of anyone online doing this, or even using the old bridge > method that I just described! I can find one post in russian that seems > to have the same error that I encounter, but nobody has any idea why > it's happening. > > I can find dozens of blog posts describing how to set up jails on > private IP addresses. They all follow the same pattern: > > 1. Create a loopback device. > 2. Create a 127.0.0.* address on the loopback device. > 3. Create a jail using the address you just added. > 4. Set up pf and enable NAT between the real network adapter and > the new loopback device. > > Unfortunately, at this point, you completely lose the ability to filter > outbound jail traffic; All packets sent from a jail will obviously have > their source address changed to that of the host and therefore it's not > possible to distinguish between outbound host traffic and outbound jail > traffic in filter rules. > > As far as I can tell, people are just not filtering outbound traffic, > which seems insane! > > Is it really impossible to do this with FreeBSD 10? I am not shure about 127.0.0.* adresses, there is some restritions in kernel. It is easy to do what you want when using another private adresses and ipfw. Just ifconfig private adresses on em0 and use rules simirar to: 1 skip to 3 ip from any to any out 12000 allow deny ... 2 nat 1 ... 21000 allow deny ... 29000 deny ip fom any to any 31000 allow ip from your_private_IP to any src-port ... dst-port ... so on 4 nat 1 ... 41000 allow deny ... And config ipfw nat 1 as suit to 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"
Re: IPFW: table support for MAC addresses?
On Sun, Jun 05, 2016 at 01:41:12PM +0300, Alexander V. Chernikov wrote: > 05.06.2016, 11:45, "??zkan KIRIK" <ozkan.ki...@gmail.com>: > > I also need this feature > > Are you fine with exact-match mac addresses? Yes, exact-match is fine for me. > (E.g. new array/hash tabletype with the ability to do exact lookup on the > source/destination mac address, w/o any masks support). > > On Fri, Jun 3, 2016 at 4:11 PM, Aleksandr A Babaylov <"."@babolo.ru> wrote: > >> On Thu, Jun 02, 2016 at 02:18:56PM +0200, Julian K. wrote: > >> > is there anyone who wants to use MAC based rules with IPFW? > >> > I want to build a captive portal that also supports IPv6. MAC addresses > >> > in IPFW tables would help a lot. > >> I use MAC in IPFW and want MAC in IPFW tables to simplify rules. ___ 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: table support for MAC addresses?
On Thu, Jun 02, 2016 at 02:18:56PM +0200, Julian K. wrote: > is there anyone who wants to use MAC based rules with IPFW? > I want to build a captive portal that also supports IPv6. MAC addresses > in IPFW tables would help a lot. I use MAC in IPFW and want MAC in IPFW tables to simplify rules. ___ 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: arp response fails
On Tue, Dec 15, 2015 at 11:47:39PM +0100, bcs wrote: > I have 3 FreeBSD 10.2-RELEASE machines and all of them suffers of the > following problem. They are not responding to ARP requests which causes > network problem for me, other hosts can't access my FBSD machines on the > LAN nor my FBSD hosts can see each other unless I add permanent arp entry. > > [root@fbsd10 /]# arping my.host.hu > ARPING x.x.x.x > Timeout > Timeout > Timeout > > Pinging a linux host is ok from my bsd host: > [root@cool /]# arping linux.host.hu > ARPING y.y.y.y > 60 bytes from 00:15:17:ae:0c:44 (y.y.y.y): index=0 time=189.143 usec > 60 bytes from 00:15:17:ae:0c:44 (y.y.y.y): index=1 time=335.541 usec > 60 bytes from 00:15:17:ae:0c:44 (y.y.y.y): index=2 time=200.227 usec > ^C > > I use ipfw but "ipfw -q -f flush" didn't solve the issue. Here are my > sysctl.conf: > security.bsd.see_other_uids=0 > net.inet.tcp.recvspace=512000 > net.route.netisr_maxqlen=2048 > kern.ipc.nmbclusters=1310720 > net.inet.tcp.sendbuf_max=16777216 > net.inet.tcp.recvbuf_max=16777216 > kern.ipc.soacceptqueue=32768 > vm.v_free_min=19170 > > /boot/loader.conf: > ipfw_load="YES" > net.inet.ip.fw.default_to_accept=1 > kern.maxusers=4096 > accf_data_load="YES" > hw.em.rxd=4096 > > any idea how to enable arp response? I have similar behavior on ale interace with vlans on it. Change for re interface on that server works for me. ___ 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 Interfaces and ARPs
On Thu, Dec 03, 2015 at 08:54:10AM -0500, Jason Van Patten wrote: > Hey gang - > > I posted this to the FreeBSD user forums but figured I'd send a message > off to the list to see if anyone has any input, guidance, or ideas. > Emailing diagrams around isn't good form (IMHO) but having a diagram > handy will help with the discussion. So please glance at: > > http://pics.lateapex.net/vz.png > > Background: I have a business class Verizon FIOS connection for Internet > at home. Along with that connection, I have 13 (not 14!) static IPs > from VZ. They almost fall within a proper CIDR block, but not quite: > 1.2.3.210 - 1.2.3.222. I don't own .209, so I can't claim 1.2.3.208/28 > as my IP block (dammit!) The subnet for the static IPs is a /24, and > the default route is *Verizon's* router: 1.2.3.1. > > There are a number of different choices for this network layout: DMZ, > bridging, or binat. I chose bridging so that I don't have the > complexity of binatting, and yet have some protection for the servers > via my router. So, per the drawing, the FreeBSD router's em0 is > connected to the Verizon equipment, while re0 and re1 are both connected > to a managed Cisco switch, on different VLANs. > > VLAN 10 for re0: Public IPs (public services, etc) > VLAN 20 for re1: Private IPs (NAS, wireless AP, etc) > > Via the router, VLAN 10 and Verizon's network are bridged together. The > bridge interface on the router has IP: 1.2.3.222/24 with a default route > set to 1.2.3.1. All servers on VLAN 10 have IPs within the allocated > range (.210 - .220) and the same default route. > > Now: the problem. I used the LAGG'd server as an example in the > diagram, but the same thing is happening with other servers: the router > is learning ARP entries for the IPs I own *from* Verizon's router. As > soon as the router caches that bad entry, it no longer routes traffic to > those public IPs *from* VLAN 20 (private side). So, in other words, a > laptop on the wireless network won't be able to get to 1.2.3.215. > > My work-around for now has been a series of static ARP entries on the > router for each of my public servers. That seems to work fine, but I > wonder if there's something I might be doing wrong? > > If I didn't include enough info, fire away. Thanks! May be it is proxy arp from Verison. Just delete bridge0 ifconfig em0 inet 1.2.3.222/24 ifconfig re0 inet 127.127.127.127/24 or any other fake net route add 1.2.3.210/31 -iface re0 route add 1.2.3.212/30 -iface re0 route add 1.2.3.216/30 -iface re0 route add 1.2.3.220/31 -iface re0 sysctl net.link.ether.inet.proxyall=1 Default router for your public servers 1.2.3.222 in /28 or wider net. ___ 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: Can DUMMYNET handle weighting of traffic according to firewall rules?
On Fri, Dec 12, 2014 at 09:06:46PM +1100, Luigi Rizzo wrote: you can set the limit for the pipe, create two queues with different weights attached to the pipe, and then schedule. ipfw pipe 12 config bw 3456 Kbit/s ipfw queue 34 config weight 2 pipe 12 ipfw queue 56 config weight 1 pipe 12 ipfw add queue 34 in recv halfduplexlink0 ipfw add queue 56 out xmit halfduplexlink0 that should do the job ipfw add pipe 12 in recv halfduplexlink0 ipfw add pipe 12 out recv halfduplexlink0 ipfw add pipe 12 out xmit halfduplexlink0 or may be double ipfw add pipe 12 in recv halfduplexlink0 (not tested) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Fri, Apr 19, 2013 at 11:45:57AM +0200, David Demelier wrote: 2013/4/14 Gary Palmer gpal...@freebsd.org: Do we honestly need three packet filters? No, for me only one should be present. I completely understand that some users still use IPFilter and IPFW but why providing three packet filters? The answer should be: use one and document only one. If at the beginning we started documenting only one all users should have used the only one present. Now we really need to remove the ancestral ipfilter and tell people switching to pf(4). IPFW. It is more logical and easy to use in complex context. Everything in life change, if we need to maintain all code from the past we will have a lot of compat code that pollute the full source tree and we will never improve the code just because of old bits ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: dummynet delay
On Tue, Jun 19, 2012 at 01:48:45AM +0900, Randy Bush wrote: add pipe 1 tcp from 147.28.2.129 to 147.28.2.133 add pipe 2 tcp from 147.28.2.133 to 147.28.2.129 pipe 1 config queue 50 delay 200ms pipe 2 config queue 50 delay 200ms is a tcp packet from 147.28.2.129 to 147.28.2.133 delayed by 200ms or 400ms, 200 for each interface? if both addresses are external, 400ms. 200 on input and 200 on output. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Point-to-point connection between jails?
On Mon, May 28, 2012 at 09:37:27PM +1000, Darren Reed wrote: I've looked through the list of network interfaces that are supported with FreeBSD and none seem to meet my needs. What I want is a network interface that I can configure up in jail A with address 10.1.1.1 and for which I can configure a mate in jail B with the address 10.2.2.2 and use the network interface as the means by which two jails can directly communicate with each other without the need to send any packets out of the machine. Or another way to do this would be to have a virtual network (something like the internal network that VirtualBox has or the host only network supported by VMWware Workstation) defined somewhere and for there to be a specific driver that could be configured and attached to a jail and that virtual network so that you could have N:M communication between jails. Is what I'm looking for already present and google is failing me or is the above functionality the basis for future work, be it planned or otherwise? ifconfig lo1 create ifconfig lo1 inet 127.1.2.3/24 ifconfig lo1 inet 127.1.2.4/32 alias launch jail A with IP 127.1.2.3 and jail B with IP 127.1.2.4 No any packet leaves host. 127.1.2.0/24 will be something like the internal network ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: use of non-contiguous masks in address lookups ?
On Thu, May 24, 2012 at 02:07:11PM +0200, Luigi Rizzo wrote: On Thu, May 24, 2012 at 11:19:54AM +, Bjoern A. Zeeb wrote: On 24. May 2012, at 07:43 , sth...@nethelp.no wrote: every now and then the issue comes up on whether we still need to support non-contiguous masks in address lookups. I seem to remember someone (perhaps on this list) making a case for their presence, but forgot the details. So, does anyone know of a practical use of non contiguous masks ? I vote for removing non-contiguous masks. They are incompatible with CIDR, which was introduced in 1993 (!). Non-contiguous masks have been unsupported in many routers produced the last 10 years or so. Contrary I still know people using them and relying on it. Not sure on which version they are. I am not quite sure what micro-optimizations on legacy IP will help us after a decade or longer. Let it rest and die gracefully the next years. Of course, fixing bugs still considered good:) the point of my question was to get [f]actual usage information on non contiguous masks, because i don't know of any (at least on ipv4, maybe in ipv6 there is one). The answer does not have to affect FreeBSD, if that is what worries you. Load balansing: #netstat -rnfinet | sed -Ee 's|([ .])[1-9][0-9][.]|\1XX.|' -e 's|([ .])[1-9][0-9][0-9][.]|\1XXX.|' | head -8 Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire 0.0.0.00x101 XX.XXX.222.58 UGS 0 1241 vlan9 0.0.0.10x101 XXX.XX.246.254 UGS 0 1387 vlan1 0.0.1.00x101 XXX.XX.246.254 UGS 0 1568 vlan1 0.0.1.10x101 XX.XXX.222.58 UGS 0 1491 vlan9 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Any deployment with very many small (/28 .. /32) subnets ?
On Thu, May 24, 2012 at 09:16:05AM +0200, Luigi Rizzo wrote: Also related to my previous question on lookups, I believe some ISPs may have a huge number of very small subnets (say /28 or even smaller) attached to some kind of virtual interfaces (vlans, gif, tun,...). Can anyone comment on what the numbers are (i.e. 100-1k-10k subnets ?) and whether the subnets are taken from a single larger pool which only includes such subnets, or they are randomly scattered across a large number of /24 subnets ? When I ruled provider with /18 public pool and some private pools, there was about 100+ routes per router from 1..5 blocks /25 .. /22 per router, I try to minimize number of blocks per router (till 2008). Now wery little provider looks (last digit of vlan100..vlan202 not displayed): netstat -rnfinet | sed -Ee 's|^| |' -e 's| [1-9][0-9][.]| XX.|g' -e 's| [1-9][0-9][0-9][.]| XXX.|g' -e 's|X[.][1-9][0-9][0-9][.]|X.XXX.|g' -e 's|X[.][1-9][0-9][.]|X.XX.|g' Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire defaultXXX.XXX.212.33 UGS284116 2747511260 vlan0 0.0.0.1link#11UH 00 disc0 XX.XXX.0.0/24 link#22U 7 160800724 vlan10 XX.XXX.0.254 link#22UHS 00lo0 XX.XXX.2.0/28 link#25U 0 169319158 vlan10 XX.XXX.2.14link#25UHS 00lo0 XX.XXX.2.16/29 link#46U 00 vlan12 XX.XXX.2.22link#46UHS 00lo0 XX.XXX.2.24/29 link#47U 0 122053043 vlan12 XX.XXX.2.30link#47UHS 00lo0 XX.XXX.2.32/29 link#45U 14 65791304 vlan12 XX.XXX.2.38link#45UHS 03lo0 XX.XXX.2.40/29 link#44U 00 vlan12 XX.XXX.2.46link#44UHS 00lo0 XX.XXX.2.48/29 link#43U 00 vlan12 XX.XXX.2.54link#43UHS 00lo0 XX.XXX.2.56/29 link#42U 00 vlan12 XX.XXX.2.62link#42UHS 00lo0 XX.XXX.2.64/29 link#40U 34 39851507 vlan11 XX.XXX.2.70link#40UHS 00lo0 XX.XXX.2.76/30 link#48U 00 vlan20 XX.XXX.2.78link#48UHS 00lo0 XX.XXX.2.80/29 link#39U 00 vlan11 XX.XXX.2.86link#39UHS 00lo0 XX.XXX.2.88/29 link#38U 0 267457525 vlan11 XX.XXX.2.94link#38UHS 00lo0 XX.XXX.2.96/29 link#36U 00 vlan11 XX.XXX.2.102 link#36UHS 00lo0 XX.XXX.2.104/29link#23U 0 48128977 vlan10 XX.XXX.2.110 link#23UHS 00lo0 XX.XXX.2.112/29link#34U 3 110435637 vlan11 XX.XXX.2.118 link#34UHS 00lo0 XX.XXX.2.120/29link#33U 00 vlan11 XX.XXX.2.126 link#33UHS 05lo0 XX.XXX.2.176/29link#32U 00 vlan11 XX.XXX.2.182 link#32UHS 00lo0 XX.XXX.2.184/29link#31U 00 vlan11 XX.XXX.2.190 link#31UHS 00lo0 XX.XXX.2.192/29link#30U 00 vlan10 XX.XXX.2.198 link#30UHS 00lo0 XX.XXX.2.200/29link#29U 00 vlan10 XX.XXX.2.206 link#29UHS 00lo0 XX.XXX.2.216/29link#28U 00 vlan10 XX.XXX.2.222 link#28UHS 00lo0 XX.XXX.2.224/29link#27U 1 51358289 vlan10 XX.XXX.2.230 link#27UHS 00lo0 XX.XXX.2.232/29link#26U 0 128803235 vlan10 XX.XXX.2.238 link#26UHS 00lo0 XX.XXX.2.248/29link#24U 066067 vlan10 XX.XXX.2.254 link#24UHS 06lo0 XX.XXX.3.128/26link#37U 00 vlan11 XX.XXX.3.190 link#37UHS 00lo0 XX.XXX.3.192/26link#35U 0 79757547 vlan11 XX.XXX.3.254 link#35UHS 00lo0 XX.XXX.255.188/30 link#20U 00 vlan8 XX.XXX.255.190 link#20UHS 00lo0 XX.XXX.255.192/27 link#18U
Re: Dynamin/Static Resolver Table [netstat like]
On Fri, Jun 17, 2011 at 12:40:29PM +0900, Hiroki Sato wrote: jhell jh...@dataix.net wrote in 20110617022950.ga58...@dataix.net: jh Gosh, Wouldnt it be something if we could store our dynamic resolver jh information with the interface in the same sort of fashion that we store jh our routing tables ? and then modify our routines in the library to look jh them up via the resolving tables and think of resolv.conf as static jh routing information only ? jh jh If we can already do this via resolvconf(8) in order to modify jh resolv.conf how hard would it be to adjust to move in this direction ? jhell jh...@dataix.net wrote in 20110617023358.gb58...@dataix.net: jh I appologize for the insta-reply, but thinking more along the lines of jh this it may come as even more of a benefit to tie this more into the jh routing table so so each route can have a dynamic nameserver attached to jh it so when setfib(8) is used a whole nother batch of nameserver could jh also be used or fall back to the standard resolv.conf. I am not sure of the benefit to adopt same sort of fashion as the routing table for RDNSS entries. What is your problem, and how does your idea solve it? I think jhell's idea is overkill, but I like mount root read only. Symlinks are not beautiful. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Configuring for 1 static and 1 DHCP interface ?
On Tue, Nov 23, 2010 at 04:35:42AM -0800, Ronald F. Guilmette wrote: I should say however that even this is going to produce a slightly sub-optimal result, because (I guess) the DHCP client is _still_ going to wipe out my eisting /etc/resolve.con file and then write its own. Now that will at least have the proper IP address in it _however_ there does not seem to be any way to entice the DHCP client to place certain options into the /etc/resolv.conf file. That's a pity, because I wanted one in there. (Oh well, I guss I can append it from my /etc/rc.local file.) Does chflags schg /etc/resolve.conf helps? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Implementing a trivial TFTP client?
On Tue, Nov 23, 2010 at 04:12:49AM -0800, Ronald F. Guilmette wrote: I have been attempting to implment a trivial sort of TFTP client from scratch, and its been somewhat of a humbling experience so far, and its taught me that I don't know quite as much about BSD socket programming as I though I did. So anyway, maybe some kind soul here would be willing to help me out and offer me some guidance. I'm not going to go over thet TFTP protocol here. That's well documented elsewhere. My question is really pretty simple: What would be the proper sequence of socket-related kernel calls necessary to implement a TFTP client that just simply connected to a TFTP server, and then sent (wrote) one file consisting of less than 512 bytes of data (i.e. just one packet's worth)? I've been trying the following sequence, and my code is kinda-sorta working, but apparently not quite (because the file never actually gets there): socket() bind() /* grab a fixed local port# */ /* NOTE: sin_addr=INADDR_ANY and sin_port=0 */ sendto()/* send the initial WRQ packet */ recvfrom() /* get the initial ACK packet */ connect() /* now that we know what port# the sever wants to talk to us on, we can connect our existing socket to that specific port# on the server's side */ send() /* Send the data packet */ recv() /* receive the data ACK packet */ Obviously, I am leaving out all of the grubby little details. I just want to focus on the proper sequence of socket primitive calls to make a trivial TFTP client. So, ah, does the above sequence look reasonable for that job? If not, where have I gone wrong? It does appear that the initial few calls are doing what they should, and the connection does start up, lickety split. But then after that, ACK responses to the data packets seem to arrive VERY VERY slowly, and although the remote TFTP daemon _does_ create the new output file up on the server (see the tftp -w option) the file never seems to get any bigger than 0 bytes in length. :-( My guess is that I'm doing multiple things in a substantially Wrong way. Any guidance would be appreciated. Try ktrace -i tftp and look at kdump to see how it works ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: igb dual-port adapter 1200Mbps limit - what to tune?
On Thu, Nov 11, 2010 at 08:05:40PM +0200, Eugene Perevyazko wrote: On Thu, Nov 11, 2010 at 12:49:52PM +0200, Eugene Perevyazko wrote: On Thu, Nov 11, 2010 at 01:47:02AM +0100, Ivan Voras wrote: On 11/10/10 12:04, Eugene Perevyazko wrote: Tried 2 queues and 1 queue per iface, neither hitting cpu limit. Are you sure you are not hitting the CPU limit on individual cores? Have you tried running top -H -S? Sure, even with 1queue per iface load is 40-60% on busy core, with 2 queues it was much lower. Now I've got the module for mb with 2 more ports, going to see if it helps. The IO module has em interfaces on it and somehow I've already got 2 panics after moving one of vlans to it. In the mean time, can someone explain me what is processed by threads marked like irq256: igb0 and igb0 que. May be understanding this will let me pin those threads to cores more optimally. There are (hw.igb.num_queues+1) irq threads and (hw.igb.num_queues) que threads. Now I just pin them sequentially to even cores (odd ones are HT). As far as I understand, you are not right about HT cores. Try switch HT off and do not use HT in routers in usual cases. Now I use hw.igb.num_queues=2, and with traffic limited to 1200Mbits the busiest core is still 60% idle... -- Eugene Perevyazko ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: FreeBSD route tables limited 16?
On Tue, Sep 14, 2010 at 04:31:39PM +1000, Dave Seddon wrote: It sounds like dedicating some space for this in the mbuf would be the best way forward, but the question is how much. I'm worried that most freebsd users won't go for lots of route tables, which is why you went for 4 bits originally. Within the network service provider space there is frequently a requirement for lots of virtual-routing with MPLS. I imagine there are others in my situation, including vendors and people working on equipment like Cisco/Juniper/Lucatel. Regarding the size to dedicate, the best number might be 12 bits or 4096. This would allow a route table per VLAN on a 802.1q interface. (Actually I'm lying a little because the first and last vlan IDs aren't usable :) ). Perhaps a separate option for non-common users who want many route tables would be best. e.g. GIANT_ROUTETABLES=12 Why not 16? There can be several independent iface with VLAN on each. arg1 in ipfw has 16 bits for fib number. Yes, it is very special case when huge number of fib needed. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Inter-vlan routing problem
On Fri, Aug 20, 2010 at 05:52:50PM +0200, Xavier HUMBERT wrote: I've got some trouble routing vlans through FreeBSD 8.1-RELEASE. I had similar prolem in 8.0-STABLE. Try sysctl net.inet.flowtable.enable=0 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Poor performance with natd/ipfw and TSO enabled on bce(4) card and 8.1-PRERELEASE
On Thu, Jul 01, 2010 at 04:54:47PM -0700, Pyun YongHyeon wrote: On Wed, Jun 30, 2010 at 07:00:53PM -0700, Garrett Cooper wrote: Hi, Just an observation I made while transferring a file: # time scp floppy.img somehost: Password: floppy.img100% 1440KB 13.7KB/s 01:45 real1m59.400s user0m0.031s sys 0m0.028s # sysctl net.inet.tcp.tso=0 net.inet.tcp.tso: 1 - 0 # time scp floppy.img somehost: floppy.img100% 1440KB 1.4MB/s 00:00 real0m0.712s user0m0.018s sys 0m0.018s Going ISDN speeds transferring a 1.44MB file is sad when you have a gigabit uplink :(... natd seems to be doing a LOT of spinning when TSO is enabled (it's going up to 73% CPU on a dual-proc quad-core machine). I would use pf(4) if I have to handle lots of NAT rules. Or ipfw nat. man ipfw | grep nat ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
