Re: Looking for users of IPX over IP tunneling
On Mon, 26 Feb 2007, Robert Watson wrote: Over the next couple of weeks, I will be reviewing the set of non-MPSAFE network stack components in preparation for a status update to the arch@ mailing list. One of the remaining components that requires Giant is the IPX over IP tunneling facility (ipx_ip). I'd like to solicit users of this facility, if any, to work with me in testing locking patches I'm currently developing against FreeBSD 7.x. I'm actually not entirely convinced this feature works, so would also like to hear from users of IPX over IP tunneling for this reason. I've found a couple of bugs that would result in improper error messages being returned, etc. There's also a comment in the NOTES file that this feature is not available. Still looking for IPX over IP users. Please let me know if you use IPX over IP tunneling support, and/or if you would be able to test MPSAFEty patches on 6.x or 7.x. The other easy route here is to remove IPX over IP tunnel support from 7.0 and then reintroduce it if testers are found in the future, but such scenarios generally don't lead to feature re-introduction, so if this is a feature you care about, then please get in touch with me. :-) Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/110720: [net] [patch] support for interface descriptions
The following reply was made to PR kern/110720; it has been noted by GNATS. From: Dmitri Alenitchev [EMAIL PROTECTED] To: Roman Bogorodskiy [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: kern/110720: [net] [patch] support for interface descriptions Date: Tue, 27 Mar 2007 12:01:45 +0400 Roman Bogorodskiy wrote: [...] Doh, I copy-pasted wrong link. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/83622 brooks@ left some comments recently, though I have not had enough time to take a look at it... Yes, really. This PR is duplicated with 83622. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vrrp/CARP/ucarp Problems
HI all, Ross Draper wrote: Hi All I was wondering if I could get some advice from those of you who have successfully implemented ip address failover systems such as carp and freevrrpd. I am trying to set up a high availability web loadbalancer using a pair of freebsd 6.2 boxes. I have tried a number of ways to perform failover but always seem to be hitting a problem. UCARP Pro's:This would be my ideal solution as the startup/shutdown scripts enable me to stop and start my applications and add aliases to adaptors easily. Cons: When the backup box is rebooted it always comes up advertising itself as the master then after a few seconds reverts to backup, although I was under the impression it was supposed to wait and listen for advertisements(it doesnt seem to). The backup boxes initial gratuitous arp as a master is sufficient to poison any traffic from the local router to the shared ip address. Only solution was to use arp-sk to send gratuitous arps every few secs, however, arp-sk was a bit flakey and it was a bodge. CARP Pro's: stable and built into the kernel. Could enable acive/active arp load sharing at a later point. Cons: There is a Freebsd bug (I've seen it discussed on the lists) where the creation and destroyal of a carp interface causes a kernel panic. Also, there is no support for start/stop scripts. I do not have experience with ucarp and freevrrpd, so I can talk only about CARP :) The bug you are talking is fixed in -CURRENT, and you can trigger it only if you have more then 1 carp interface per host. I fetch changes from -current and made patch for -stable, that seems to work without problems. There are other bugs, and I'm not sure what is their status, but you always can search for PR. I do not think start/stop scripts are problem as average sysadmin can solve this for itself :) Freevrrpd Pros: Mac address changing removes some of the arp timeout issues/gratuitous arp problems and it supports start/stop scripts Cons: I'm finding that upon rebooting the backup unit it correctly starts as a backup, then three seconds later syslogs that it is the master and changes its mac address accordingly. although a sniff of the network traffic indicates it is sending the right advertisements(lower priority), it never goes into backup mode again. So, what am I doing wrong? Are these common problems, or something that appears specific to my hosts/switches? are there more suitable options? The loadbalancers are all single homed and I have tried a mixture of xl, bge and fxp cards. Any help/suggestions much appreciated, also, any links to a perl based gratuitous arp util would be great! Many thanks Ross PS - Apologies if you see multiple copies of this message, I seem to be having trouble getting mails onto the list. All correspondence, attachments and agreements remain strictly subject to fully executed contract. (c) GCap Media plc 2006. All rights remain reserved. This e-mail (and any attachments) contains information which may be confidential, subject to intellectual property protection and may be legally privileged and protected from disclosure and unauthorised use. It is intended solely for the use of the individual(s) or entity to whom it is addressed and others specifically authorised to receive it. If you are not the intended recipient of this e-mail or any parts of it please telephone 020 7054 8000 immediately upon receipt. No other person is authorised to copy, adapt, forward, disclose, distribute or retain this e-mail in any form without prior specific permission in writing from an authorised representative of GCap Media plc. We will not accept liability for any claims arising as a result of the use of the internet to transmit information by or to GCap Media plc. GCap Media plc. Registered address: 30 Leicester Square, London WC2H 7LA. Registered in England Wales with No. 923454 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] P.S. the attached patch is little old so I'm not sure it still apply cleanly to the latest -stable :) I tested base functionality with patched carp, but still do not have server in production with it, so be careful! -- Best Wishes, Stefan Lambrev ICQ# 24134177 --- src/sys/netinet/ip_carp.c.orig Thu Feb 1 18:53:55 2007 +++ src/sys/netinet/ip_carp.c Tue Feb 6 18:41:24 2007 @@ -191,7 +191,7 @@ static voidcarp_input_c(struct mbuf *, struct carp_header *, sa_family_t); static int carp_clone_create(struct if_clone *, int); static voidcarp_clone_destroy(struct ifnet *); -static voidcarpdetach(struct carp_softc *); +static voidcarpdetach(struct carp_softc *, int); static int carp_prepare_ad(struct mbuf *, struct carp_softc *, struct carp_header *); static voidcarp_send_ad_all(void); @@ -406,9 +406,7 @@ if
Re: Vrrp/CARP/ucarp Problems
On OpenBSD web server load balancing is achieved using PF + hoststated. Using CARP is not appropriate as is noted in the (FreeBSD) man page. I think VRRP is also not appropriate. Ross Draper wrote: Hi All I was wondering if I could get some advice from those of you who have successfully implemented ip address failover systems such as carp and freevrrpd. I am trying to set up a high availability web loadbalancer using a pair of freebsd 6.2 boxes. I have tried a number of ways to perform failover but always seem to be hitting a problem. UCARP Pro's:This would be my ideal solution as the startup/shutdown scripts enable me to stop and start my applications and add aliases to adaptors easily. Cons: When the backup box is rebooted it always comes up advertising itself as the master then after a few seconds reverts to backup, although I was under the impression it was supposed to wait and listen for advertisements(it doesnt seem to). The backup boxes initial gratuitous arp as a master is sufficient to poison any traffic from the local router to the shared ip address. Only solution was to use arp-sk to send gratuitous arps every few secs, however, arp-sk was a bit flakey and it was a bodge. CARP Pro's: stable and built into the kernel. Could enable acive/active arp load sharing at a later point. Cons: There is a Freebsd bug (I've seen it discussed on the lists) where the creation and destroyal of a carp interface causes a kernel panic. Also, there is no support for start/stop scripts. Freevrrpd Pros: Mac address changing removes some of the arp timeout issues/gratuitous arp problems and it supports start/stop scripts Cons: I'm finding that upon rebooting the backup unit it correctly starts as a backup, then three seconds later syslogs that it is the master and changes its mac address accordingly. although a sniff of the network traffic indicates it is sending the right advertisements(lower priority), it never goes into backup mode again. So, what am I doing wrong? Are these common problems, or something that appears specific to my hosts/switches? are there more suitable options? The loadbalancers are all single homed and I have tried a mixture of xl, bge and fxp cards. Any help/suggestions much appreciated, also, any links to a perl based gratuitous arp util would be great! Many thanks Ross PS - Apologies if you see multiple copies of this message, I seem to be having trouble getting mails onto the list. All correspondence, attachments and agreements remain strictly subject to fully executed contract. (c) GCap Media plc 2006. All rights remain reserved. This e-mail (and any attachments) contains information which may be confidential, subject to intellectual property protection and may be legally privileged and protected from disclosure and unauthorised use. It is intended solely for the use of the individual(s) or entity to whom it is addressed and others specifically authorised to receive it. If you are not the intended recipient of this e-mail or any parts of it please telephone 020 7054 8000 immediately upon receipt. No other person is authorised to copy, adapt, forward, disclose, distribute or retain this e-mail in any form without prior specific permission in writing from an authorised representative of GCap Media plc. We will not accept liability for any claims arising as a result of the use of the internet to transmit information by or to GCap Media plc. GCap Media plc. Registered address: 30 Leicester Square, London WC2H 7LA. Registered in England Wales with No. 923454 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GRE with key
Hi, Thank you for your quick reply. Bruce M. Simpson wrote: Cristian KLEIN wrote: Hello everybody, I am new to FreeBSD kernel hacking, so please excuse my perhaps stupid questions. I would like to add key support to gre(4). I have already been able to use gre(4) with a hardcoded key. The single thing remaining to do is to transfer the key from ifconfig(8). The key is an uint32_t and I haven't found a way to transfer it without modifying ifconfig(8). Excellent. Thanks for volunteering to do this! I just wanted to be able to use the OS I like. ;) My question is, which is the BSD-style to achieve the above? Solutions I came up with are as follows: 1) Use SIOCSDRVSPEC / SIOCGDRVSPEC 2) Add SIOCSGREKEY / SIOCGGREKEY 3) [Probably to ugly to be mentioned, but requires fairy few modifications.] Add a sysctl MIB which is read when calling ifconfig ... create. If I were doing this, I would add the code to ifconfig.c where the other tunnel stuff lives, and go for option number 2. Feel free to modify ifconfig to accomodate the the new options. I have added GREGKEY / GRESKEY in if_gre.h and included this file in ifconfig.c. Another thing I wanted to ask is, which function of ifconfig(8) should I modify to display the GRE key? Look at how af_status_tunnel() works and consider adding it there. I have included key displaying in status() because it is af independent. Please review the patch, so I can PR it. The patch is against RELENG_6_2. Could someone check whether it works on HEAD? http://users.utcluj.ro/~cristiklein/patches/grekey.patch One note: gre(4) still ignores incomming keys (i.e. accepts any incomming key) and I think that is quite okey, because they are deprecated in RFC2784. However, should someone find it useful, I am willing to implement it, for the sake of correctness. I have tested the current implementation against both a Cisco router and a Linux box, so it should work for everybody. Thank you for your help! ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge
Good day. Sun, Mar 18, 2007 at 08:17:09AM +0300, Eygene Ryabinkin wrote: You're right, thanks for spotting the error. The corrected patch is attached. After some iterations with rik@ we came to a next version of an if_bridge.4 patch. Comments are welcome. -- Eygene --- if_bridge.4.origSun Mar 4 15:37:22 2007 +++ if_bridge.4 Tue Mar 27 18:25:52 2007 @@ -82,6 +82,13 @@ .Nm interface randomly chooses a link (MAC) address in the range reserved for locally administered addresses when it is created. +This address is guaranteed to be unique +.Em only +across all +.Nm if_bridge +interfaces on the local machine. +Thus you can theoretically have two +bridges on the different machines with the same link addresses. The address can be changed by assigning the desired link address using .Xr ifconfig 8 . .Pp @@ -219,9 +226,89 @@ so all packets are passed to the filter for processing. .Pp -Note that packets to and from the bridging host will be seen by the -filter on the interface with the appropriate address configured as well -as on the interface on which the packet arrives or departs. +The packets originating from the bridging host will be seen by +the filter on the interface that is looked up in the routing +table. +.Pp +The packets destined to the bridging host will be seen by the filter +on the interface with the MAC address equal to the packet's destination +MAC. There are situations when some of the bridge members are sharing +the same MAC address (for example the +.Xr if_vlan 4 +interfaces: they are currenly sharing the +MAC address of the parent physical interface). +It is not possible to distinguish between these interfaces using +their MAC address, excluding the case when the packet's destination +MAC address is equal to the MAC address of the interface on which +the packet was entered to the system. +In this case the filter will see the incoming packet on this +interface. +In all other cases the interface seen by the packet filter is chosen +from the list of bridge members with the same MAC address and the +result strongly depends on the member addition sequence and the +actual implementation of +.Nm if_bridge . +It is not recommended to rely on the order chosen by the current +.Nm if_bridge +implementation: it can be changed in the future. +.Pp +The previous paragraph is best illustrated with the following +pictures. Let +.Bl -bullet +.It +the MAC address of the incoming packet's destination is +.Nm nn:nn:nn:nn:nn:nn , +.It +the interface on which packet entered the system is +.Nm ifX , +.It +.Nm ifX +MAC address is +.Nm xx:xx:xx:xx:xx:xx , +.It +there are possibly other bridge members with the same MAC address +.Nm xx:xx:xx:xx:xx:xx , +.It +the bridge has more than one interface that are sharing the +same MAC address +.Nm yy:yy:yy:yy:yy:yy ; +we will call them +.Nm vlanY1 , +.Nm vlanY2 , +etc. +.El +.Pp +Then if the MAC address +.Nm nn:nn:nn:nn:nn:nn +is equal to the +.Nm xx:xx:xx:xx:xx:xx +then the filter will see the packet on the interface +.Nm ifX +no matter if there are any other bridge members carrying the same +MAC address. +But if the MAC address +.Nm nn:nn:nn:nn:nn:nn +is equal to the +.Nm yy:yy:yy:yy:yy:yy +then the interface that will be seen by the filter is one of the +.Nm vlanYn . +It is not possible to predict the name of the actual interface +without the knowledge of the system state and the +.Nm if_bridge +implementation details. +.Pp +This problem arises for any bridge members that are sharing the same +MAC address, not only to the +.Xr if_vlan 4 +ones: they we taken just as the example of such situation. +So if one wants the filter the locally destined packets based on +their interface name, one should be aware of this implication. +The described situation will appear at least on the filtering bridges +that are doing IP-forwarding; in some of such cases it is better +to assign the IP address only to the +.Nm if_bridge +interface and not to the bridge members. +But your mileage may vary. .Sh EXAMPLES The following when placed in the file .Pa /etc/rc.conf ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Vrrp/CARP/ucarp Problems
Hi Firstly, many thanks to Stefan (who provided me a diff of the CURRENT update) and Bruce for advising me that the multiple CARP interface destroy bug is fixed in CURRENT. Jordan, thanks for your reply, but I cant find a reference to CARP being unsuitable for this purpose in the CARP man page, have I perhaps misunderstood you? I also did a quick search of the freebsd.org site and cant find any mention of it being an issue - If you could provide me with a link I'd be grateful. Further to this, I have been in the office today performing local testing as opposed to remote testing and have noticed that when both machines in the cluster are using xl network cards, failover etc seems fine. However, when having one node using xl and the other using em/bge I can see the em or bge card physically go down after it reverts to backup mode, then come back up and goto master. (this wasnt displaying in the messages log, but was obvious on the console). I believe that this down period is sufficient for it to miss the remaining advertisements and believe it is the master again. For some reason it doesnt seem to ever remove the mac address or recover after this point, but I'm not particularly suprised. Not sure how to take this further, but I'll continue fiddling. Many thanks Ross All correspondence, attachments and agreements remain strictly subject to fully executed contract. (c) GCap Media plc 2006. All rights remain reserved. This e-mail (and any attachments) contains information which may be confidential, subject to intellectual property protection and may be legally privileged and protected from disclosure and unauthorised use. It is intended solely for the use of the individual(s) or entity to whom it is addressed and others specifically authorised to receive it. If you are not the intended recipient of this e-mail or any parts of it please telephone 020 7054 8000 immediately upon receipt. No other person is authorised to copy, adapt, forward, disclose, distribute or retain this e-mail in any form without prior specific permission in writing from an authorised representative of GCap Media plc. We will not accept liability for any claims arising as a result of the use of the internet to transmit information by or to GCap Media plc. GCap Media plc. Registered address: 30 Leicester Square, London WC2H 7LA. Registered in England Wales with No. 923454 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD router
Hi, i'm busy creating a a http-proxy server/router with FreeBSD 6.2, but somewhere along the line i'm doing things wrong i think. situation: network 172.45.x.x/12 -FREEBSD ROUTER - 192.168.3.x/16 -- firewall. The defaultroute will be the ip-adress of the firewall, being 192.168.3.1. i won't be needing a firewall or NAT on the machine, since the only traffic to the internet will be HTTP and that will be handled by the proxy server. But all the howto's handle firewalls and HTTP. Anyone knows a good page with information on doing this without a firewall and NAT. Kind Regards Maarten Verbeek ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vrrp/CARP/ucarp Problems
The only load balancing that CARP supports, to my knowledge, is ARP level load balancing. From carp(4): The ARP load balancing has some limitations. First, ARP balancing only works on the local network segment. It cannot balance traffic that crosses a router, because the router itself will always be balanced to the same virtual host. Ross Draper wrote: Hi Firstly, many thanks to Stefan (who provided me a diff of the CURRENT update) and Bruce for advising me that the multiple CARP interface destroy bug is fixed in CURRENT. Jordan, thanks for your reply, but I cant find a reference to CARP being unsuitable for this purpose in the CARP man page, have I perhaps misunderstood you? I also did a quick search of the freebsd.org site and cant find any mention of it being an issue - If you could provide me with a link I'd be grateful. Further to this, I have been in the office today performing local testing as opposed to remote testing and have noticed that when both machines in the cluster are using xl network cards, failover etc seems fine. However, when having one node using xl and the other using em/bge I can see the em or bge card physically go down after it reverts to backup mode, then come back up and goto master. (this wasnt displaying in the messages log, but was obvious on the console). I believe that this down period is sufficient for it to miss the remaining advertisements and believe it is the master again. For some reason it doesnt seem to ever remove the mac address or recover after this point, but I'm not particularly suprised. Not sure how to take this further, but I'll continue fiddling. Many thanks Ross All correspondence, attachments and agreements remain strictly subject to fully executed contract. (c) GCap Media plc 2006. All rights remain reserved. This e-mail (and any attachments) contains information which may be confidential, subject to intellectual property protection and may be legally privileged and protected from disclosure and unauthorised use. It is intended solely for the use of the individual(s) or entity to whom it is addressed and others specifically authorised to receive it. If you are not the intended recipient of this e-mail or any parts of it please telephone 020 7054 8000 immediately upon receipt. No other person is authorised to copy, adapt, forward, disclose, distribute or retain this e-mail in any form without prior specific permission in writing from an authorised representative of GCap Media plc. We will not accept liability for any claims arising as a result of the use of the internet to transmit information by or to GCap Media plc. *GCap Media plc. Registered address: 30 Leicester Square, London WC2H 7LA. Registered in England Wales with No. 923454* ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Vrrp/CARP/ucarp Problems
Ah... I see your point, thankyou for clarifying. Sorry, this is down to me only explaining half the story. The actual loadbalancing will be performed by HAProxy, I require carp or freevrrp to enable a clustered pair of loadbalancers. I did toy with the idea arp balancing to enable greater throughput in an active/active scenario, but as you say mention this is not suitable for certain deployments. Kind Regards Ross From: Jordan Gordeev [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 27, 2007 3:47 PM To: Ross Draper Cc: freebsd-net@freebsd.org Subject: Re: Vrrp/CARP/ucarp Problems The only load balancing that CARP supports, to my knowledge, is ARP level load balancing. From carp(4): The ARP load balancing has some limitations. First, ARP balancing only works on the local network segment. It cannot balance traffic that crosses a router, because the router itself will always be balanced to the same virtual host. Ross Draper wrote: Hi Firstly, many thanks to Stefan (who provided me a diff of the CURRENT update) and Bruce for advising me that the multiple CARP interface destroy bug is fixed in CURRENT. Jordan, thanks for your reply, but I cant find a reference to CARP being unsuitable for this purpose in the CARP man page, have I perhaps misunderstood you? I also did a quick search of the freebsd.org site and cant find any mention of it being an issue - If you could provide me with a link I'd be grateful. Further to this, I have been in the office today performing local testing as opposed to remote testing and have noticed that when both machines in the cluster are using xl network cards, failover etc seems fine. However, when having one node using xl and the other using em/bge I can see the em or bge card physically go down after it reverts to backup mode, then come back up and goto master. (this wasnt displaying in the messages log, but was obvious on the console). I believe that this down period is sufficient for it to miss the remaining advertisements and believe it is the master again. For some reason it doesnt seem to ever remove the mac address or recover after this point, but I'm not particularly suprised. Not sure how to take this further, but I'll continue fiddling. Many thanks Ross All correspondence, attachments and agreements remain strictly subject to fully executed contract. (c) GCap Media plc 2006. All rights remain reserved. This e-mail (and any attachments) contains information which may be confidential, subject to intellectual property protection and may be legally privileged and protected from disclosure and unauthorised use. It is intended solely for the use of the individual(s) or entity to whom it is addressed and others specifically authorised to receive it. If you are not the intended recipient of this e-mail or any parts of it please telephone 020 7054 8000 immediately upon receipt. No other person is authorised to copy, adapt, forward, disclose, distribute or retain this e-mail in any form without prior specific permission in writing from an authorised representative of GCap Media plc. We will not accept liability for any claims arising as a result of the use of the internet to transmit information by or to GCap Media plc. GCap Media plc. Registered address: 30 Leicester Square, London WC2H 7LA. Registered in England Wales with No. 923454 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD router
Verbeek, Maarten [EMAIL PROTECTED] wrote: i'm busy creating a a http-proxy server/router with FreeBSD 6.2, but somewhere along the line i'm doing things wrong i think. What exactly did you do so far and how is it failing? situation: network 172.45.x.x/12 -FREEBSD ROUTER - 192.168.3.x/16 -- firewall. The defaultroute will be the ip-adress of the firewall, being 192.168.3.1. The defaultroute on which system? i won't be needing a firewall or NAT on the machine, since the only traffic to the internet will be HTTP and that will be handled by the proxy server. But all the howto's handle firewalls and HTTP. Anyone knows a good page with information on doing this without a firewall and NAT. It's not clear to me what exactly you're trying to do. Which systems are supposed to use the proxy? Are these systems configured to use the proxy or should the proxy intercept their requests? Which proxy do you use? Building a router and a http proxy are two different problems and maybe you should solve them one at the time. Fabian signature.asc Description: PGP signature
bin/110933: [traceroute] minimal wait time should be 1 sec, not 2
Hi, Are there any ideas why traceroute requires waittime =2 seconds? The only place it used is select(2) timeout. -- Maxim Konovalov -- Forwarded message -- Date: Tue, 27 Mar 2007 19:44:54 +0400 (MSD) From: Dmitry Marakasov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: bin/110933: [traceroute][patch] minimal wait time should be 1 sec, not 2 Resent-Date: Tue, 27 Mar 2007 15:50:09 GMT Resent-From: [EMAIL PROTECTED] (GNATS Filer) Resent-To: [EMAIL PROTECTED] [...] In traceroute utility, minimal time to wait for reply is 2 seconds. That's annoying, because system administrators often need traceroute to skip hosts that do not respond faster, but when specifying obvious wait time as 1 sec, they get an error. I see no reason for minimal wait time to be 2 sec, the patch attached lowers limit to well expected 1 second. How-To-Repeat: 1) traceroute -w1 somehost traceroute: wait time must be 1 2) ?! Fix: --- traceroute.patch begins here --- --- src/contrib/traceroute/traceroute.c.origTue Mar 27 19:34:53 2007 +++ src/contrib/traceroute/traceroute.c Tue Mar 27 19:35:00 2007 @@ -608,7 +608,7 @@ case 'w': waittime = str2val(optarg, wait time, - 2, 24 * 60 * 60); + 1, 24 * 60 * 60); break; case 'z': --- traceroute.patch ends here --- Release-Note: Audit-Trail: Unformatted: ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge
Eygene Ryabinkin wrote: Good day. Sun, Mar 18, 2007 at 08:17:09AM +0300, Eygene Ryabinkin wrote: You're right, thanks for spotting the error. The corrected patch is attached. After some iterations with rik@ we came to a next version of an if_bridge.4 patch. Comments are welcome. If there is no objections, I'll wait till the weekend and commit this patch to finally close the PR. Eygene what about the next patch for physically input filtration? I guess we need a separate PR and a thread here for it. rik ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
carp/vrrp/ucarp advice
Hi guys I was wondering if I could get some advice from those of you who have successfully implemented ip address failover systems such as carp and freevrrpd. I am trying to set up a high availability web loadbalancer using a pair of freebsd 6.2 boxes. I have tried a number of ways to perform failover but always seem to be hitting a problem. UCARP Pro's:This would be my ideal solution as the startup/shutdown scripts enable me to stop and start my applications and add aliases to adaptors easily. Cons: When the backup box is rebooted it always seems to come up advertising itself as the master, then after a few seconds reverts to backup, although I was under the impression it was supposed to wait and listen for advertisements(it doesnt seem to)to see if a master exists. Its initial gratuitous arp as a master is sufficient to poison any traffic from the local router to the shared ip address. Only solution was to use arp-sk to send gratuitous arps every few secs, however, arp-sk was a bit flakey and it was a bodge. CARP Pro's: stable and built into the kernel. Could enable acive/active arp load sharing at a later point. Cons: There is a Freebsd bug (I've seen it discussed on the lists) where the creation and destroyal of a carp interface causes a kernel panic. Also, there is no support for start/stop scripts. Freevrrpd Pros: Mac address changing removes some of the arp timeout issues/gratuitus arp problems and it supports start/stop scripts Cons: I'm finding that upon rebooting the backup unit it correctly starts as a backup, then three seconds later syslogs that it is the master and changes its mac address accordingly. although a sniff of the network traffic indicates it is sending the right advertisements, it never goes into backup mode again and keeps the virtual mac address. So, what am I doing wrong? are there more suitable options? the loadbalancers are all single homed and I have tried a mixture of xl, bge and fxp cards. Also, any links to a perl based gratuitous arp utils would be great Any help/suggestions much appreciated. Ross PS - I mailed this to freebsd-cluster earlier but it didnt seem to make it onto the list - apologies if this ends up as a cross post. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vrrp/CARP/ucarp Problems
Jordan Gordeev wrote: The only load balancing that CARP supports, to my knowledge, is ARP level load balancing. From carp(4): The ARP load balancing has some limitations. First, ARP balancing only works on the local network segment. It cannot balance traffic that crosses a router, because the router itself will always be balanced to the same virtual host. Forgive me for stepping in, but I had read the above statement over and over trying to figure what it meant; perhaps it's not so clear... If I understood it correctly it's not saying you should not use CARP on routers. Instead it's meaning that load-balancing won't cross a third router which is on cascade of the two CARP routers. An image might help to clarify: +--+ +--+ +--+ +--+ |host I| |host J| |host K| |host Z| +--+ +--+ +--+ +--+ ||| | \++-+-\ | +--+ +--+ +--+ +--+ ++ |host A| |host B| |host C| |host H| |Router 3| +--+ +--+ +--+ +--+ ++ ||| | | \+-+--+---+-+-/ | | ++ ++ |Router 1| |Router 2| ++ ++ Suppose you are arp-balancing with CARP on Router 1 2, hosts A-H will get balanced, but hosts I-Z will all go to the same router (wether Router 1 or Router 2). This is because all their incoming packets will bear Router 3's MAC address. Is this interpretation correct? bye Thanks av. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vrrp/CARP/ucarp Problems
Andrea Venturoli wrote: Jordan Gordeev wrote: The only load balancing that CARP supports, to my knowledge, is ARP level load balancing. From carp(4): The ARP load balancing has some limitations. First, ARP balancing only works on the local network segment. It cannot balance traffic that crosses a router, because the router itself will always be balanced to the same virtual host. Forgive me for stepping in, but I had read the above statement over and over trying to figure what it meant; perhaps it's not so clear... If I understood it correctly it's not saying you should not use CARP on routers. Instead it's meaning that load-balancing won't cross a third router which is on cascade of the two CARP routers. ... Andrea, you are correct. Jordan is pointing out the main limitation of CARP, which is that it operates only within a broadcast domain. I should point out such a feature is out of scope for VRRP, CARP, IPMP or other Layer 2 IP sharing protocol. However this behaviour is just fine for load balancing a router, in which case one relies on next-hop reachability anyway. The thing to remember with CARP is that it relies on the ability of the interface to go into promiscuous mode to pick up traffic for its virtual MAC addresses. More modern cards may support more than one station address in hardware, which avoids the need for promiscuous mode processing, however we don't currently support this hardware feature. If one wishes to load balance across Layer 3 hops (rather than within the same broadcast domain), what one is asking for is a feature like BGP4 Anycast, IPv6 Anycast, or OSPF-based Anycast which relies on cooperating routers to inject a route into the Layer 3 routing domain for a given 'virtual' IP address. There is a daemon out there which uses the OSPF API in Quagga to flood OSPF domains with virtual host routes for anycasting services using Opaque LSAs but I forget its name. XORP has the potential to do the same but requires some development effort to do so. If one wishes to load balance specific requests for an application layer service, one enters the wonderful world of 'middleware' and competing commercial solutions to the problem. And this is where money comes into play... Regards, BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
The broadcast of python in FreeBSD
Hi, Everybody. In FreeBSD, I write a program in python(2.4.4 2.5), which include a broadcast routine. But, I send the broadcast in FreeBSD, it's different from others OS, like Windows, Linux... When I send the broadcast in FreeBSD with address 255.255.255.255, the packet can not be received by other OS. But I send the broadcast in non-BSD System with address 255.255.255.255, all OS got it. When I send the broadcast in FreeBSD with address like 192.168.1.255, all OS got it. I have seen the Python socket implement, there is no added option for FreeBSD, but why? Why it is different? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge
Tue, Mar 27, 2007 at 10:20:40PM +0400, Roman Kurakin wrote: Eygene what about the next patch for physically input filtration? I guess we need a separate PR and a thread here for it. Yes, I will port it to the new if_bridge.c. The end of this week is a good estimate for the patching and testing timeline from my side. Will open a PR once the new patch will work for me. -- Eygene ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The broadcast of python in FreeBSD
Hi, Zhu Yan wrote: Hi, Everybody. In FreeBSD, I write a program in python(2.4.4 2.5), which include a broadcast routine. But, I send the broadcast in FreeBSD, it's different from others OS, like Windows, Linux... When I send the broadcast in FreeBSD with address 255.255.255.255, the packet can not be received by other OS. But I send the broadcast in non-BSD System with address 255.255.255.255, all OS got it. When I send the broadcast in FreeBSD with address like 192.168.1.255, all OS got it. I have seen the Python socket implement, there is no added option for FreeBSD, but why? Why it is different? Can you change sysctl net.inet.icmp.bmcastecho=1 and test again? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/110959: Filtering incoming packets with enc0 does not work with GIF-based IPSec setups
Synopsis: Filtering incoming packets with enc0 does not work with GIF-based IPSec setups Responsible-Changed-From-To: freebsd-bugs-freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Wed Mar 28 06:57:07 UTC 2007 Responsible-Changed-Why: Networking issue http://www.freebsd.org/cgi/query-pr.cgi?pr=110959 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
