Re: Redundant NIC/Connections
On Wed, 1 Jan 2003, David J Duchscher wrote: > >> >I was wondering how people are handling redundant connections? We > >> >would like to have dual NICs in the FreeBSD box with each NIC > >> connected > >> >to a different switch. Both switches are in the same broadcast > >> domain. > >> >In pointers, hints on this may done would be greatly appreciated. > > > > I think one of my colleagues responded directly to the poster. We do > > it by a daemon he wrote that monitors interface link status, and also > > pingability of default gateways, and reconfigures interfaces in event > > of a failure, based on the normal configuration file settings > > (/etc/rc.conf) > > > > Instantly in event of link loss; after a few seconds of retrying in > > event of router loss (we use HSRP addresses for routers.) > > Yes, I got a few responses including the one mentioned above. Lack of > time and changing priorities has prevented me from following up on > them. Anshuman Kanwar did mentioned he might release his solution as > open source if there was interest. I am at least interested in > reviewing it. I just need to find the time. I would also be very interested in this. We could write our own, but I'd much rather burn that time working on other projects ;-). Did Anshuman happen to mention what it's written in? Perl? C? other? -j To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
IPsec / ipfw interaction in 4.7-STABLE: a proposed change
A fairly recent change in 4.7-STABLE modified the way IPsec ESP tunneled packets are handled by the ipfw code. There was a brief thread on this at the freebsd-stable mailing list in the end of November, see for example http://docs.freebsd.org/cgi/getmsg.cgi?fetch=270433+0+archive/2002/freebsd-stable/20021201.freebsd-stable Earlier on packets received from an ESP tunnel were passed directly up; now they are processed again by ipfw. An example of worked fine before: # ipfw show 00100 allow esp from XX.XX.XX.XXto MY.IP.ADD.RRS in recv xl0 00110 allow esp from MY.IP.ADD.RRS to XX.XX.XX.XX out xmit xl0 00200 deny ip from 192.168.0.0/24 to 192.168.0.0/24 via xl0 # setkey -DP 192.168.0.192/29 192.168.0.0/24 any in ipsec esp/tunnel/XX.XX.XX.XX-MY.IP.ADD.RRS/require 192.168.0.0/24 192.168.0.192/29 any out ipsec esp/tunnel/MY.IP.ADD.RRS-XX.XX.XX.XX/require Under the old behaviour the ipfw rule 200 explicitly forbid unprotected traffic using the tunneled addresses from getting out or in via the external interface, xl0. This rule can't be used any more, since now it blocks incoming traffic, and it must be replaced by something that allows incoming traffic from the tunnel. Thus, the change has the undesired side effect that it is now impossible to use ipfw to protect the tunnel end-point from traffic that looks like coming from the tunnel but does not come after all. From the security point of view this does not matter so much, since the IPsec code is taking care of the protection and dropping those packets. However, in the case where the IPsec policies get screwed up (e.g. due to racoon failure...) security may be somewhat weaker than before. At the stable -list someone suggested for a fix where the packets coming from the ESP tunnel would be changed so that they look like coming grom another interface. A proper fix would probably require a real "esp" pseudo-interface, but that should be carefully considered and tested to see that routing etc. would work fine. Now, as a small step to that direction I made the following small hack to netinet6/esp_input.c It changes the ESP tunneled packets to look like they were coming from the loopback interface. And it works like charm. However, this is not a proper fix, and a better one might be to increment NLOOP and use loif[1] instead of loif[0]. Opinions? --Pekka Nikander --- esp_input.c.origMon Aug 26 03:09:03 2002 +++ esp_input.c Thu Jan 2 15:40:25 2003 @@ -404,6 +404,9 @@ splx(s); goto bad; } + /* XXX: Interface hack by pnr */ + m->m_pkthdr.rcvif = loif; + /* XXX: End of interface hack by pnr */ IF_ENQUEUE(&ipintrq, m); m = NULL; schednetisr(NETISR_IP); /* can be skipped but to make sure */ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Routing and Zebra
Hi, First of all, forgive me if my question is off-topic. I could have tried -questions but was afraid that is was kind of very specific. To the point: Two machines running 4.7, A and B, connected to the same switch. Both running zebra. When A is turned off, B receives A's traffic (which is normal as the switch needs to flood packets after a while): TCPdump on B: Source MAC: a router's MAC (on the same LAN) Dest. MAC: A's MAC Source IP: someplace in the net Dest. IP: A's IP To my surprise B tries to forwards the packet to A, which AFAIK shouldn't because it doesn't have the right destination MAC. Of course there is no VRRP or anything else. Is this a known behavior? Would it be Zebra? Thanks in advance for any help! Fernando. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Routing and Zebra
On Thu, 2 Jan 2003 11:49:11 -0300
Fernando Schapachnik <[EMAIL PROTECTED]> wrote:
> Hi,
> First of all, forgive me if my question is off-topic. I could have
> tried -questions but was afraid that is was kind of very specific.
>
> To the point: Two machines running 4.7, A and B, connected to the
> same
> switch. Both running zebra. When A is turned off, B receives A's traffic
> (which is normal as the switch needs to flood packets after a while):
>
> TCPdump on B:
>
> Source MAC: a router's MAC (on the same LAN)
> Dest. MAC: A's MAC
> Source IP: someplace in the net
> Dest. IP: A's IP
>
> To my surprise B tries to forwards the packet to A, which AFAIK
> shouldn't because it doesn't have the right destination MAC. Of course
> there is no VRRP or anything else.
>
> Is this a known behavior? Would it be Zebra?
>
> Thanks in advance for any help!
Hi,
I posted a few hours ago in freebsd-questions a problem that seems very
similar to yours ("promiscuous mode / strange ethernet packets duplication
problem"). I too have Zebra running on my machines.
Have you checked that the ethernet interface of your B machine is not
in promiscuous mode for an unknown reason ?
We have several FreeBSD 4.7 boxes that automatically put all their
interfaces into promiscuous mode during the boot process. Does anybody
knows how to prevent that from happening ?
Regards
Yann
--
Yann GROSSEL Email: [EMAIL PROTECTED]
HEXANET NOC URL: http://www.hexanet.fr/
Tel: +33 (0)3 26 79 30 05 Fax: +33 (0)3 26 79 30 06
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Routing and Zebra
÷ Thu, 02.01.2003, × 17:49, Fernando Schapachnik ÎÁÐÉÓÁÌ: > Hi, > First of all, forgive me if my question is off-topic. I could have > tried -questions but was afraid that is was kind of very specific. > > To the point: Two machines running 4.7, A and B, connected to the same > switch. Both running zebra. When A is turned off, B receives A's traffic > (which is normal as the switch needs to flood packets after a while): > > TCPdump on B: > > Source MAC: a router's MAC (on the same LAN) > Dest. MAC: A's MAC > Source IP: someplace in the net > Dest. IP: A's IP > > To my surprise B tries to forwards the packet to A, which AFAIK > shouldn't because it doesn't have the right destination MAC. Of course there is > no VRRP or anything else. > > Is this a known behavior? Would it be Zebra? > > Thanks in advance for any help! There was bug in zebra, it allows promosq. mode on interface so host begin catch all traffic as its own. (You can check this by ifconfig) This was fixed 2002/10/07. > Fernando. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message -- Vladimir B. Grebenschikov <[EMAIL PROTECTED]> TSB "Russian Express" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
ipfw man page
Hello, In the ipfw man page, we can read: "To ease configuration, rules can be put into a file which is processed using ipfw as shown in the first synopsis line." Shouldn't be the 'last synopsis line' ? Thanks. oc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RE: Redundant NIC/Connections
> From: Jonathan Disher [mailto:[EMAIL PROTECTED]] > On Wed, 1 Jan 2003, David J Duchscher wrote: > > > >> >I was wondering how people are handling redundant > connections? We > > >> >would like to have dual NICs in the FreeBSD box with each NIC > > >> connected > > >> >to a different switch. Both switches are in the same broadcast > > >> domain. > > >> >In pointers, hints on this may done would be greatly > appreciated. > > > > > > I think one of my colleagues responded directly to the > poster. We do > > > it by a daemon he wrote that monitors interface link > status, and also > > > pingability of default gateways, and reconfigures > interfaces in event > > > of a failure, based on the normal configuration file settings > > > (/etc/rc.conf) > > > > > > Instantly in event of link loss; after a few seconds of > retrying in > > > event of router loss (we use HSRP addresses for routers.) > > > > Yes, I got a few responses including the one mentioned > above. Lack of > > time and changing priorities has prevented me from following up on > > them. Anshuman Kanwar did mentioned he might release his > solution as > > open source if there was interest. I am at least interested in > > reviewing it. I just need to find the time. > > I would also be very interested in this. We could write our > own, but I'd > much rather burn that time working on other projects ;-). > > Did Anshuman happen to mention what it's written in? Perl? C? other? I wonder if the VRRP (http://www.bsdshell.net/hut_fvrrpd.html) can help here. its available as a port. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: mpd only let outbound packets flowing
> "Emss" == Eric Masson <[EMAIL PROTECTED]> writes: Emss> Followup to myself, sorry Once more, Braino on my side, ipnat configuration file hasn't been updated to the new interface, sorry for the noise. Eric Masson PS: mpd works damn fine here, thanks to Archie & Julian -- Lu sur linux.wine.users : > I have a bottle of Haut Medoc from 1971 and wondered if anyone on this BB > could advise as to possible value and drinkability. -+- PB in Guide du linuxien pervers - "Important ça, la drinkability !" -+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Routing and Zebra
En un mensaje anterior, Vladimir B. Grebenschikov escribió: > There was bug in zebra, it allows promosq. mode on interface > so host begin catch all traffic as its own. > (You can check this by ifconfig) > > > This was fixed 2002/10/07. Thanks! I've just posted saying it was not in promiscuous mode, but I misread the ifconfig flags! That's it. Thank you. Regards. Fernando. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Routing and Zebra
En un mensaje anterior, éé Yann GROSSEL ééé escribió: > Have you checked that the ethernet interface of your B machine is not > in promiscuous mode for an unknown reason ? No, B doesn't go into promiscuous mode, at least from what ifconfig and messages tell. > > > We have several FreeBSD 4.7 boxes that automatically put all their > interfaces into promiscuous mode during the boot process. Does anybody > knows how to prevent that from happening ? Mmmm... Seems like a trojan that acts on boot. Is that possible? Thanks & regards. Fernando. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IPsec / ipfw interaction in 4.7-STABLE: a proposed change
> "Pekka" == Pekka Nikander <[EMAIL PROTECTED]> writes: Pekka> Now, as a small step to that direction I made the following Pekka> small hack to netinet6/esp_input.c It changes the ESP tunneled Pekka> packets to look like they were coming from the loopback Pekka> interface. And it works like charm. However, this is not a Pekka> proper fix, and a better one might be to increment NLOOP and use Pekka> loif[1] instead of loif[0]. Opinions? Seems pretty close to what OpenBSD has implemented, except they don't use the stock loopback interface. Their enc(4) driver is a software loopback interface : http://www.openbsd.org/cgi-bin/man.cgi?query=enc&sektion=4&arch=i386&apropos=0&manpath=OpenBSD+Current It's used in src/sys/netinet/ipsec_input.c to impersonate the incoming interface just as you did in your patch. I'd like to know whether there would be any interest in associating a different interface to each incoming SPD entry or just use only one interface for all incoming SPD entries ? Regards Eric Masson -- «Comme annoncé dans fr.usenet.forums.annonces récemment, le vote pour la destruction/remplacement du groupe fr.comp.os.linux a reussi et est donc detruit.» -+- Control in Guide du linuxien pervers - "BSD a encore frappé" -+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IPsec / ipfw interaction in 4.7-STABLE: a proposed change
[Sorry to reply to the wrong message, but I missed this earlier.] On Thu, Jan 02, 2003 at 09:22:26PM +0100, Eric Masson wrote: > > "Pekka" == Pekka Nikander <[EMAIL PROTECTED]> writes: > > Pekka> Now, as a small step to that direction I made the following > Pekka> small hack to netinet6/esp_input.c It changes the ESP tunneled > Pekka> packets to look like they were coming from the loopback > Pekka> interface. And it works like charm. However, this is not a > Pekka> proper fix, and a better one might be to increment NLOOP and use > Pekka> loif[1] instead of loif[0]. Opinions? loif[] is evil and its use should not be extended. In any case, NLOOP no longer exists in current since loopback interfaces are clonable. If you didn't want to adopt OpenBSD's enc interface, an alternate solution might be to set up an ioctl to allow you to register the interface you want to have these packets come from. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg07995/pgp0.pgp Description: PGP signature
Re: when are mbuf clusters released?
Thanks for the info. Could you explain how mbuf clusters and mbufs are related? i'd like to better understand how we can run out of one and not the other. also, is there an upper value for mbuf clusters that we should be wary of? again, the tuning page is quite vague on this. 64000 seems to not do the trick so i was thinking of 2X this. we have plenty of memory (1GB and the machine only runs apache). for those interested, we think we've found why we're getting lots of connections in FIN_WAIT_1 state...it appears to be some sort of odd/bad interaction between IE and flash (we think). these machines serve popup adds (sorry!), and we're guessing that when a user with a slower connection gets one of these pop-ups and kills the window before the flash file is done downloading, IE leaves the socket open...sorta, and here's where it gets interesting. it leaves it open, but closes the window (sets it to 0)...or is the plugin doing this? apache is done sending data and considers the conenction closed, so its client timeout feature never comes into play. but there is still data in the sendq, including the FIN, we believe. BSD obeys the spec (unfortunately) and keeps probing to see if the window has opened so it can transmit the last of the data. this goes on indefinitely! so we get gobs connections stuck in fin_wait_1. interestingly, we have a solaris machine serving the same purpose and it does not have the problem. it seems to not folluw the rfc and silently closes the conenction after a number of tries when a socket is in fin_wait_1. these seems more reasonable to me. this seems (as i've read from other posts as well) quite an opportunity for a DoS attackjust keep advertising a window of 0. a single client could easily tie everything up in fin_wait_1... anyone think of a workaround (besides not serving pop-ups :) jeff Mike Silbersack wrote: On Mon, 30 Dec 2002, Jeff Behl wrote: 5066/52544/256000 mbufs in use (current/peak/max): 5031/50612/64000 mbuf clusters in use (current/peak/max) is there some strange interaction going on between apace2 and bsd? killing apache caused the mbuf clusters to start draining, but only slowly. will clusters still be allocated in FIN_WAIT_? states? TIME_WAIT? Before I answer your question, let me explain how clusters are allocated. The first number above shows how many are in use at the moment. The second number shows how many have been used, and are currently allocated. The third is the limit you have set. What this means is that once an mbuf (or cluster) has been allocated, it is never truly freed, only returned to the free list. As a result, after your spike in mbuf usage, you never really get the memory back. However, this may be OK if you have plenty of ram. This maching was serving a couple hundred connections a second...which doesn't seem like it should have taxed it much (p3 1.2 gHz). CPU util was low. Any help appreciated. Jeff Now, on to why the value spiked. Yes, connections in FIN_WAIT* states still hang on to mbuf clusters relating to the data they have been asked to send. There was a DoS script going around which intentionally stuck many sockets on a server in the FIN_WAIT_2 state until enough had been stuck to cause mbuf cluster exhaustion. To determine if this is the case, just run netstat -n and look at the sendq value; if you see high sendq values on a lot of sockets, this may be your answer. The other possibility is that you're being hit with lots of IP fragments... currently, the IP reassembly code allows too many unassembled packets to sit around. There's no way to inspect the IP reassembly queue actively, but you could use netstat -s to see "fragments received" - if the number is high, then it's likely something is up. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Quad ethernet question
Anyone using one of these? http://www.corpsys.com/store/prodinfo.asp?number=ANA6944&variation=&aitem=60&mitem=62 If so, is the performance good? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
SMP status of networking subsystem?
Just a quick question.. Where do we stand on bringing the networking subsystem out from under Giant? The mbuf system is soon to be safe, thanks to Alan Cox, so this allows INTR_MPSAFE drivers. However, swi:net is still under Giant, as are many of the important socket functions (sendto(), recvfrom(), etc). Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: SMP status of networking subsystem?
On Thu, 2 Jan 2003, Andrew Gallatin wrote: > > Just a quick question.. Where do we stand on bringing the networking > subsystem out from under Giant? > > The mbuf system is soon to be safe, thanks to Alan Cox, so this allows > INTR_MPSAFE drivers. However, swi:net is still under Giant, as are > many of the important socket functions (sendto(), recvfrom(), etc). netgraph has been partly done for a while but I need to do some more to complete it.. I need to add an 'MP-safe' timer/callback fascility (that can be used instead of nodes rolling hteir own and I need a fascility to assit hardware-triggered events queue data to the netgraph part of themselves, (i.e. move under the netgraph umbrella). > > Thanks, > > Drew > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: when are mbuf clusters released?
Mbufs are data structures in the kernel. They contain information relating to data to be sent/received. Mbufs on my stable system are 256 bytes and mbuf clusters are 2048 bytes. I believe that there are 4 different types of mbufs and they are usually chained together, depending on the amount of data. The different mbufs 1.) internal data, packet header 2.) internal data, no packet header 3.) external data (mbuf cluster), packet header 4.) external data (mbuf cluster), no packet header All mbufs have an mbuf header (20 bytes) that occupies the first portion of the mbuf. This mbuf header describes the type of mbuf, has pointers to link mbufs together and to link mbuf chains together, etc. All mbuf chains have a packet header (24 bytes) in the first mbuf of the chain. Mbuf 1 would have an mbuf header, a packet header and then room for the data in transit (20 + 24 + 212 = 256 bytes). Mbuf 2 would have an mbuf header and then room for data in transit (20 + 236 = 256 bytes). Mbuf 3 would have an mbuf header, a packet header, an extended structure and unused space (20 + 24 + 16 + 196 = 256 bytes). Mbuf 4 would have an mbuf header, some wasted space, an extended structure and more wasted space (20 + 24 + 16 + 196 = 256 bytes). The gap (some wasted space) is because of the unions in the mbuf structure. When the data in transit is small (less than MINCLSIZE = 213), a single mbuf is used. When the data in transit is larger (>= MINCLSIZE = 213) mbufs of type 3 and 4 are used. The extended structure in the mbufs identifies the mbuf cluster holding the data in transit. So if you are send a lot of large messages, your system will use lots of mbuf clusters. I do not know why your mbuf clusters are not being returned to the free list. In the case of fragmentation, the IP code should be returning the mbufs and mbuf clusters to the free lists. When the datagram cannot be fully reconstructed, its fragment list should be dropped. I know I haven't answered all of your questions, but maybe I have given you more insight. Ray Not necessarily a single mbuf. For example, as the the mbuf gets passed down the the stack, a new mbuf is added in front of this one to in order to prepend the headers from the other layers (i.e. ethernet header, ip header, udp header, etc.) On Thu, 02 Jan 2003 12:33:47 -0800 Jeff Behl wrote: > Thanks for the info. Could you explain how mbuf clusters and mbufs are > related? i'd like to better understand how we can run out of one and > not the other. also, is there an upper value for mbuf clusters that we > should be wary of? again, the tuning page is quite vague on this. > 64000 seems to not do the trick so i was thinking of 2X this. we have > plenty of memory (1GB and the machine only runs apache). > > for those interested, we think we've found why we're getting lots of > connections in FIN_WAIT_1 state...it appears to be some sort of odd/bad > interaction between IE and flash (we think). these machines serve popup > adds (sorry!), and we're guessing that when a user with a slower > connection gets one of these pop-ups and kills the window before the > flash file is done downloading, IE leaves the socket open...sorta, and > here's where it gets interesting. it leaves it open, but closes the > window (sets it to 0)...or is the plugin doing this? apache is done > sending data and considers the conenction closed, so its client timeout > feature never comes into play. but there is still data in the sendq, > including the FIN, we believe. BSD obeys the spec (unfortunately) and > keeps probing to see if the window has opened so it can transmit the > last of the data. this goes on indefinitely! so we get gobs > connections stuck in fin_wait_1. interestingly, we have a solaris > machine serving the same purpose and it does not have the problem. it > seems to not folluw the rfc and silently closes the conenction after a > number of tries when a socket is in fin_wait_1. these seems more > reasonable to me. this seems (as i've read from other posts as well) > quite an opportunity for a DoS attackjust keep advertising a window > of 0. a single client could easily tie everything up in fin_wait_1... > > anyone think of a workaround (besides not serving pop-ups :) > > jeff > > > Mike Silbersack wrote: > > On Mon, 30 Dec 2002, Jeff Behl wrote: > > > > > >>5066/52544/256000 mbufs in use (current/peak/max): > >>5031/50612/64000 mbuf clusters in use (current/peak/max) > >> > >>is there some strange interaction going on between apace2 and bsd? > >>killing apache caused the mbuf clusters to start draining, but only > >>slowly. will clusters still be allocated in FIN_WAIT_? states? > TIME_WAIT? > > > > > > Before I answer your question, let me explain how clusters are > allocated. > > The first number above shows how many are in use at the moment. The > > second number shows how many have been used, and are currently > allocated. > >
