Re: altq vs pppoe
On Monday, Jun 9, 2003, at 02:14 US/Pacific, Primož Gabrijelčič wrote: Trevor Talbot wrote ... As I don't have a PPPoE setup to work with, I did my own testing with just tun0, and saw the spin effect. Below is a patch for if_tun.c, which fixed the problem I observed. I'd like to know if it fixes pppoe queueing for anyone brave enough to try patches from me. I've been known to make things explode. As far as I'm concerned, this patch works just great. I can finally queue on tun0 with my _upload_ bandwidth (minus the pppoe overhead). PPPoE hasn't blown up yet and computer still processes packets correctly. Download works much better over the saturated link now. Great! Hopefully this will hold for everyone else who's testing it. The only weird thing I have noticed is that the download started at 127 KB/s (full DL bandwidth of my ADSL link), but then slowly dropped to the 60 KB/s and stabilized there. During that slowdown, pppoe CPU% raised to the 26% and then stabilised. When download completed, pppoe CPU% normalized back to the < 1%. Do you know if it does the same thing without queueing enabled? I realize this would be hard to test with a saturated uplink. I'm wondering if the CPU usage is in direct response to the queueing, or just a result of the traffic patterns. This could, of course, be the result of the user-landness of OBSD ppp. CPU usage in general, no doubt; but I'm slightly concerned that pppoe's usage went higher as less traffic came through. It's likely that pppoe is contributing to the drop in throughput. Unless TCP just settled down, and the outbound traffic was more frequent -- pppoe would then have to wrap packets at a faster rate, which could account for it. Something I'm unsure of is the interaction between ppp and pppoe. In the tun0 case, ppp's spinning should not make pppoe's CPU usage rise. Choke it, yes; stress it, no. I wonder if ppp is doing something silly itself. I don't think I can go much farther than the if_tun.c stuff myself, as I don't understand the other components (ppp in particular). If there's still a problem with the queueing, I can keep looking, but otherwise this would probably be a discussion to start on one of the other lists.
Re: pf round-robin load balancing patent issue
On Tue, Jun 10, 2003 at 12:30:10AM +0200, Wouter Clarie wrote: > > On Tue, 10 Jun 2003, Henning Brauer wrote: > > > would help if we had access to the patent. > > http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=6,493,341.WKU.&OS=PN/6,493,341&RS=PN/6,493,341 well, this rules us out completely. nor affected. responding to the SYN request with a modified SYN packet that specifies the physical address of the selected router, the selected router not necessarily having the IP address specified in the unmodified original SYN request. it talks continously abbout mnodified SYNs. we don;t modify SYNs.
Re: pf round-robin load balancing patent issue
On Tue, 10 Jun 2003, Henning Brauer wrote: > would help if we had access to the patent. http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=6,493,341.WKU.&OS=PN/6,493,341&RS=PN/6,493,341
Re: pf round-robin load balancing patent issue
On Mon, Jun 09, 2003 at 05:06:17PM -0500, Charles Steaderman wrote: > Hi all. > I am involved with a project to provide load balanced, redundent links > to the internet. We have been approached by the holder's of Patent > 6,493,341 indicating that we are in violation of their patent. It > appears that the patent covers identifying a SYN packet and picking a > line over which to send the data. This sounds like NAT, then pick a > line, doesn't it? I know that pf provides simple, round-robin load > balancing and I was wondering if anyone has had a chance to see if the > patent holder is out of line. would help if we had access to the patent. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
pf round-robin load balancing patent issue
Hi all. I am involved with a project to provide load balanced, redundent links to the internet. We have been approached by the holder's of Patent 6,493,341 indicating that we are in violation of their patent. It appears that the patent covers identifying a SYN packet and picking a line over which to send the data. This sounds like NAT, then pick a line, doesn't it? I know that pf provides simple, round-robin load balancing and I was wondering if anyone has had a chance to see if the patent holder is out of line. - Charlie -- Charlie Steaderman [EMAIL PROTECTED] VP Engineering Poliac Research Corporation Phone: 952.707.6245 Cel: 612.242.6364
FW: OpenBSD Bridge setup with OSPF routed networks behind it - W0ES-
Forwarding to PF list as well.
--- Begin Message ---
Title: RE: OpenBSD Bridge setup with OSPF routed networks behind it - W0ES-
I disabled pf and then re-enabled it and now my config works fine - after
I ping the Bridge External Address from a host behind the /28
I did notice this in the dmesg probably 50 times on the OpenBSD Bridge.
arplookup: unable to enter address for XXX.XXX.56.211
arpresolve: can't allocate llinfo
## This was a result of my reply-to config though.
Everything will work great till a timeout expires. It seems i need to
ping XXX.XXX.43.114 before I can get it to be able to ssh. Any ideas why
arp is giving me a hard time or is this more a proxy-arp needed scenario?
hum - i think I may have just answered my own question.
beast.some.net:/home/coldiso% route get XXX.XXX.56.211
route to: XXX.XXX.56.211
destination: XXX.XXX.56.211
gateway: xxx.xxx.43.116
interface: fxp0
flags:
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu
0 0 0 0 0 0 0
expire
0
Is there a way for me to encourage traffic to the /28 to always use fxp1?
I realize this is a bridge but it is not learning the MAC because it is
separated by the 2514 router which would stop broadcasts of layer2.
Interesting if i disable pf i don't have to ping the host first before I
can ssh to it. Now I am really confused.
my pf.conf is available at http://www.comnetohio.com/~jasonh/
Thanks for any suggestions.
Jason
On Mon, 9 Jun 2003, Amir Seyavash Mesry wrote:
> I take it this is not a transparent Bridge, as well, I think it would help
> if you posted your pf.conf.
>
> Amir Seyavash Mesry
> [EMAIL PROTECTED]
> LSI Logic Corporation
> http://www.lsilogic.com/
> Raid Support Test Technician
> 6145-D Northbelt Parkway
> Norcross, GA 30071
> 678-728-1211
>
> NOTICE: This communication may contain privileged or other confidential
> information. If you are not the intended recipient, or believe that you have
> received this communication in error, please do not print, copy, retransmit,
> disseminate, or otherwise use the information. Also, please indicate to the
> sender that you have received this communication in error, and delete the
> copy you received. Thank you.
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
> Jason Houx
> Sent: Monday, June 09, 2003 1:12 PM
> To: [EMAIL PROTECTED]
> Subject: OpenBSD Bridge setup with OSPF routed networks behind it - W0ES -
>
>
>
>
> {2600}---
> | --- /29
> | |
> fxp0 { OpenBSD } fxp1 --|
> { Bridge } |
> eth0 { Cisco 2514 } eth1 --|
> |
> | /28
> More OpenBSD Units
>
>
>
> I am having a problem that I have been unable to fix. The scenario above is
> what my lab looks like. Essentially my workstation lives off the /29 behind
> the fxp1 interface. The OpenBSD Bridge is a 3.3 Generic with pf/altq
> protecting everything behind it. I can ssh to the OpenBSD bridge from my
> workstation because my IP address is on the same /29 as the External Int of
> the Bridge on fxp0, but none of my machines behind the Cisco 2514 on the
> eth1 network /28 can talk directly to the Bridge but can bridge out/in just
> fine. Mind you traffic from the /29 can talk to the
> bridge just fine. Just to clarify anything that comes in from the
> Internet and lands on fxp0 can talk to the Bridge as well.
>
> I see this in my tcpdumps
>
> ## XXX.XXX.56.211 = machine on /28 subnet
> ## xxx.xxx.43.114 = fxp0 IP on Bridge on /29
>
> Jun 09 11:09:48.142206 rule 20/0(match): pass in on fxp0:
> XXX.XXX.56.211.32214 > xxx.xxx.43.114.22: S Jun 09 11:09:48.146181 rule
> 6/0(match): block in on fxp0: xxx.xxx.43.114.22 > XXX.XXX.56.211.32214: S
>
> supporting icmp redirect dumps show this
> Jun 09 11:19:55.824378 : ROU.TER.IP.113 > xxx.xxx.43.114: icmp: redirect
> XXX.XXX.56.211 to net xxx.xxx.43.116
>
>
> This looks to me like a icmp redirect problem because I am seeing the
> External IP of my bridge send the packet right back at the interface with
> destination of the correct machine on the /29.
>
> I at first thought it was a problem with icmp route-redirects on the Bridge
> not being allowed to pass in to tell the Bridge external IP to redirect the
> traffic back out fxp1. After adding
>
> $gw_router = ip of bridge next hop --> Cisco 2600
>
> # ICMP router redirect for multiple networks
> pass in log quick on $br0_if inet proto icmp from $gw_router to any
> icmp-type 5 code 0 keep state queue man
Re: ftp-proxy without nat - fixed
Nevermind, I got it. Had to add some rules to pass traffic from the external interface to 127.0.0.1 On Mon, 2003-06-09 at 13:22, Nick Lomonte wrote: > I'm running PF as a routing firewall without NAT. > > Unless I'm mistaken, ftp-proxy should work in either direction without > having the reverse patch in this situation. Am I wrong in this > assumption? > > It works fine for local ftp clients, but I can't seem to get it to work > in the other direction. > >
OpenBSD Bridge setup with OSPF routed networks behind it - W0ES -
{2600}---
|--- /29
||
fxp0 { OpenBSD } fxp1 --|
{ Bridge }|
eth0 { Cisco 2514 } eth1 --|
|
| /28
More OpenBSD Units
I am having a problem that I have been unable to fix. The scenario above
is what my lab looks like. Essentially my workstation lives off the /29
behind the fxp1 interface. The OpenBSD Bridge is a 3.3 Generic with
pf/altq protecting everything behind it. I can ssh to the OpenBSD bridge
from my workstation because my IP address is on the same /29 as the
External Int of the Bridge on fxp0, but none of my machines behind the
Cisco 2514 on the eth1 network /28 can talk directly to the Bridge but can
bridge out/in just fine. Mind you traffic from the /29 can talk to the
bridge just fine. Just to clarify anything that comes in from the
Internet and lands on fxp0 can talk to the Bridge as well.
I see this in my tcpdumps
## XXX.XXX.56.211 = machine on /28 subnet
## xxx.xxx.43.114 = fxp0 IP on Bridge on /29
Jun 09 11:09:48.142206 rule 20/0(match): pass in on fxp0: XXX.XXX.56.211.32214 >
xxx.xxx.43.114.22: S
Jun 09 11:09:48.146181 rule 6/0(match): block in on fxp0: xxx.xxx.43.114.22 >
XXX.XXX.56.211.32214: S
supporting icmp redirect dumps show this
Jun 09 11:19:55.824378 : ROU.TER.IP.113 > xxx.xxx.43.114: icmp: redirect
XXX.XXX.56.211 to net xxx.xxx.43.116
This looks to me like a icmp redirect problem because I am seeing the
External IP of my bridge send the packet right back at the interface with
destination of the correct machine on the /29.
I at first thought it was a problem with icmp route-redirects on the
Bridge not being allowed to pass in to tell the Bridge external IP to
redirect the traffic back out fxp1. After adding
$gw_router = ip of bridge next hop --> Cisco 2600
# ICMP router redirect for multiple networks
pass in log quick on $br0_if inet proto icmp from $gw_router to any icmp-type 5 code 0
keep state queue man1 label "pass icmp redirects from gw_router"
pass in log quick on $br0_if inet proto icmp from $gw_router to any icmp-type 5 code 1
keep state queue man1 label "pass icmp redirects from gw_router"
pass in log quick on $br0_if inet proto icmp from $gw_router to any icmp-type 5 code 2
keep state queue man1 label "pass icmp redirects from gw_router"
pass in log quick on $br0_if inet proto icmp from $gw_router to any icmp-type 5 code 3
keep state queue man1 label "pass icmp redirects from gw_router"
This didn't work and I noticed that the block was on xxx.xxx.43.114
coming in the fxp0 interface so I put a statement for xxx.xxx.43.114 to
allow in on fxp0 although this should never happen except in this
situation. After doing this I see the following when trying to ssh to
xxx.xxx.43.114 from a IP on the /28 network.
Jun 09 12:09:24.680962 rule 20/0(match): pass in on fxp0: XXX.XX.56.211.32148 >
xxx.xxx.43.114.22: S
Jun 09 12:09:24.700588 rule 61/0(match): pass in on fxp0: xxx.xxx.43.114.22 >
XXX.XXX.56.211.32148: S
Jun 09 12:09:30.692264 rule 61/0(match): pass in on fxp0: xxx.xxx.43.114.22 >
XXX.XXX.56.211.32148: S
Jun 09 12:09:36.679255 rule 61/0(match): pass in on fxp0: xxx.xxx.43.114.22 >
XXX.XXX.56.211.32148: S
but It never establishes the connection and I don't see any blocks on
pflog0
Seeing how this didn't work I again looked at what was happening and tried
to add a route on the bridge using the interface as the direction to push
the /28 network - I assumed this would work like a Cisco { ie static
route a network out a interface }q
route add XXX.XXX.56.208/28 -interface fxp1
route: fxp1: bad value
route add XXX.XXX.56.208 -netmask XXX.XXX.XXX.240 -interface fxp1
route: fxp1: bad value
I am confused now - do I have syntax wrong on this can I not influence a
route out a interface
that is just "up"
fxp1: flags=8943 mtu 1500
address: 00:02:b3:bf:e8:b6
media: Ethernet 100baseTX full-duplex
status: active
inet6 fe80::202:b3ff:febf:e8b6%fxp1 prefixlen 64 scopeid 0x2
I even tried this line in my pf.conf
@13 pass in log quick on fxp0 reply-to fxp1 inet proto tcp from XXX.XXX.56.211 to
xxx.xxx.43.114 port = ssh keep state
and do see the action hiting that line
Jun 09 12:59:01.243481 rule 13/0(match): pass in on fxp0: XXX.XXX.56.211.9681 >
xxx.xxx.43.114.22: S
but I still get no connection.
The 2514 can talk directly to the bridge but it knows about both /29 and
/28
2514_dual_eth>telnet XXX.XXX.43.114 22
Trying XXX.XXX.43.114, 22 ... Open
SSH-1.99-OpenSSH_3.6.1
But a Unit on the other side of the 2514 can't
some.host.name:/etc% telnet XXX.XXX.43.114 22
Trying XXX.XXX.43.114...
Any Ideas or anyone have a similar situation and they found a resolution?
TIA
Jason Houx
ftp-proxy without nat
I'm running PF as a routing firewall without NAT. Unless I'm mistaken, ftp-proxy should work in either direction without having the reverse patch in this situation. Am I wrong in this assumption? It works fine for local ftp clients, but I can't seem to get it to work in the other direction.
Samba + OpenBSD VPN
I am cross-posting this to openbsd-pf because I am at a complete loss and don't know where the problem lies. I have a OpenBSD ipsec vpn setup between several node sites and one central site. For the most part it seems they are setup fine (isakmpd, pf etc). I can ping, I can do all sorts of nice things over the network. The problem appears when I try to use samba over the vpn. Sometimes, I can login to a server (using smbclient) and there is no problem. Other times, I get this: # smbclient //linux1/publicadded interface ip=192.168.2.1 bcast=192.168.2.255 nmask=255.255.255.0Got a positive name query response from 192.168.1.6 ( 192.168.1.6 )Password:Domain=[ABC] OS=[Unix] Server=[Samba 2.2.8a]smb: \> lsSUCCESS - 0 listing \*Error in dskattr: SUCCESS - 0smb: \> Memory fault (core dumped) I know it looks like I am connecting from the firewall itself, which should be a no-no, but the result is the same from a host behind it. What makes this so strange, is that there is no apparent cause of failure or success. I was almost sure that it was a pf issue that was dropping some UDP packets, but I have watched the pflog and that doesn't seem to be the case, especially because it works sometimes. Does anyone have any insight into this? Thanks
RE: altq vs pppoe
> Trevor Talbot wrote ... > > I did some playing around and discovered something. It seems that > someone forgot to fully ALTQify tun0. Specifically, select() > always returns read-ready if there's any data in the internal queue, > whether ALTQ's discipline is ready to release it or not. > > The theory is that when the queues start filling, ppp's non-blocking > I/O loop starts spinning on tun0, trying to pull packets off when > they aren't ready. Once it starts spinning, pppoe will be adversely > affected and lose throughput. > > As I don't have a PPPoE setup to work with, I did my own testing with > just tun0, and saw the spin effect. Below is a patch for if_tun.c, > which fixed the problem I observed. I'd like to know if it fixes > pppoe queueing for anyone brave enough to try patches from me. I've > been known to make things explode. As far as I'm concerned, this patch works just great. I can finally queue on tun0 with my _upload_ bandwidth (minus the pppoe overhead). PPPoE hasn't blown up yet and computer still processes packets correctly. Download works much better over the saturated link now. The only weird thing I have noticed is that the download started at 127 KB/s (full DL bandwidth of my ADSL link), but then slowly dropped to the 60 KB/s and stabilized there. During that slowdown, pppoe CPU% raised to the 26% and then stabilised. When download completed, pppoe CPU% normalized back to the < 1%. This could, of course, be the result of the user-landness of OBSD ppp. Now I'll recompile the kernel on the second firewall with faster ADSL (4Mb/768Kb) and test (and report, of course). Best regards and thanks, Primoz
