About Hierarchical MobileIPv6
Hi all!! What do you know about merging HMIPv6 in FreeBSD? I´ve found in http://www.freebsd.org/news/sou1999.html that INRIA agreed to merge his code in freeBSD. I want to install it in my computer, have you ever done it? I have the code files but I need some hints. Ana To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
How to send mail on behave of other domains.
Hi I setup mail server for our office users send mail to Internet with domain name YYY.net. But there are some users register their own domain name XXX.net. They want to send mail out from our mail server. Most of their mail is OK but there are some mail servers out there reject some mails from them. Because domain name at Sender field([EMAIL PROTECTED]) and Host(mail.YYY.net) is mismatch. How do I config my sendmail.cf for them can use for send mail out? Thks Chutima S. -- Chutima Subsirin [EMAIL PROTECTED] - email (202) 777-2641 ext. 6020 - voicemail/fax ___ To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax, all in one place - sign up today at http://www.zdnetonebox.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
annoying bug on routing tables...
< said: > Symptoms are -- if you change the address to an interface, > packets to destinations to which you have talked to in the past > will still go out with the previous address unless > you delete and reinstall a route for that destination. Yes. The address deletion code is supposed to make sure that everything gets cleaned up, but it doesn't actually work in practice. (My fault in part.) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: bandwith limitation
[Clemens Hermann] > Hi together, > > for quite a while I have been looking around for a way to limit the bandwith > for each IP that accesses my server. I want to slow down any connektion > to 128 KBit/s. > The only thing I found was Dummynet in combination with ipfw. I am using > ipf as firewall an for IP-accounting. It does a very good job and I > really do not want to miss it. Is there any way besides dummynet to get > bandwith limitation to run on my FreeBSD 4.2 box? You might want to take a look at ALTQ[0] from the KAME people, or just use ipfw with a default pass all rule (or IPFIREWALL_DEFAULT_ACCEPT), so that it's only used for bw limiting. (The packets will then first go through ipfw, and then through ipf, IIRC). [0] http://www.csl.sony.co.jp/person/kjc/software.html#ALTQ -- Martin Eggen <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: annoying bug on routing tables...
On Tue, Jan 16, 2001 at 11:30:56AM -0500, Garrett Wollman wrote: > < said: > > > Symptoms are -- if you change the address to an interface, > > packets to destinations to which you have talked to in the past > > will still go out with the previous address unless > > you delete and reinstall a route for that destination. > > Yes. The address deletion code is supposed to make sure that > everything gets cleaned up, but it doesn't actually work in practice. > (My fault in part.) > kern/20785. I hope to find some spare time to handle it... Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Problem with gif tunnel: nd6_lookup: failed to add route for a neighbor
>> > Jan 16 02:34:05 ipv6-gw /kernel: nd6_lookup: failed to add route for a = >neighbor(3ffe:2900:000b:000d::0001), errno=3D17 >> >=20 >> > each time i use such tunnel >> >=20 >> > I've looked at some search engines and know it's a common problem but no >> > known solution (i'm tempted to recompile commenting out the log call) >>=20 >> Your address prefix length is incorrect..can't remember what the >> correct value should be off the top of my head, but it's come up >> before so it should be in the archives upon closer examination. >It looks like 128 is the "right" prefixlen. Problem is that my upstream >provider (Sprint) wants to use 64 as prefixlen (IMHO FBSD is ok, but it >seems to be the common practice to assign /64 to tunnels) you need to configure like either: # ifconfig gif0 3ffe:2900:000b:000d::1 3ffe:2900:000b:000d::2 \ prefixlen 128 alias # ifconfig gif0 3ffe:2900:000b:000d::1 prefixlen 64 alias if you specify both your and peer's address, you need to set prefixlen to 128. if you specify prefixlen to 64, the peer's address is not necessary (it will get discovered automatically). actually, the prefix length on p2p interface does not, and should not really matter. (the separate problem is that there are multiple interpretation of p2p in the world - major ones are gated interpretation and cisco interpretation) we (as KAME) will try to improve the behavior, like non-working ones get rejected on ifconfig time or such. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Problem with gif tunnel: nd6_lookup: failed to add route for a neighbor
On Tue, Jan 16, 2001 at 02:58:03AM -0300, [EMAIL PROTECTED] wrote: > ¡Hola! > > > > I'm experimenting with ipv6 and i need some help. I've a gif > > > tunnel between a FBSD 4.0 and a FBSD 4.2. > > > > > > In the 4.2 side i get lots of messages like: > > > > > > Jan 16 02:34:05 ipv6-gw /kernel: nd6_lookup: failed to add route for a >neighbor(3ffe:2900:b00d:ff00::0002), errno=17 > > > Jan 16 02:34:05 ipv6-gw /kernel: nd6_lookup: failed to add route for a >neighbor(3ffe:2900:000b:000d::0001), errno=17 > > > > > > each time i use such tunnel > > > > > > I've looked at some search engines and know it's a common problem but no > > > known solution (i'm tempted to recompile commenting out the log call) > > > > Your address prefix length is incorrect..can't remember what the > > correct value should be off the top of my head, but it's come up > > before so it should be in the archives upon closer examination. > > It looks like 128 is the "right" prefixlen. Problem is that my upstream > provider (Sprint) wants to use 64 as prefixlen (IMHO FBSD is ok, but it > seems to be the common practice to assign /64 to tunnels) Hmm, not sure what can be done about that. > > It's a common mistake - a FAQ question/answer would probably be in > > order (could you write a doc PR once you've fixed it?). > > What's a PR? Problem Report - it's the submission mechanism for changes and patches, as well as bugs. You can submit one from the command-line using send-pr with the doc patches if/when you write them (if you're not familiar with docbook then ascii text is also fine), or using the web interface at www.freebsd.org/send-pr.html Kris PGP signature
arp bp's
We have a FreeBSD 3.1R machine as our main router uplinking to a Cisco 3620 (back to back, no switch). All works well, and had for months. After a reboot of cisco and freebsd, all still works well, but we cannot ping cisco inside to fbsd outside (the back to back interfaces with x-over cable), plus when we traceroute up to internet, all we get is * * * when traversing that link, followed by normal traceoute behavior. This link carries several a gigabyte of traffic a day in both directions without pb's, but we have this problem with that link. dmesg shows tons of: arpresolve: can't allocate llinfo for 255.255.255.252rt arplookup 255.255.255.252 failed: host is not on local network arpresolve: can't allocate llinfo for 255.255.255.252rt arplookup 255.255.255.252 failed: host is not on local network arpresolve: can't allocate llinfo for 255.255.255.252rt and /var/log/messages shows: Jan 16 18:03:49 gw1 /kernel: arplookup 255.255.255.252 failed: host is not on local network Jan 16 18:03:49 gw1 /kernel: arpresolve: can't allocate llinfo for 255.255.255.252rt Jan 16 18:03:51 gw1 /kernel: arplookup 255.255.255.252 failed: host is not on local network Jan 16 18:03:51 gw1 /kernel: arpresolve: can't allocate llinfo for 255.255.255.252rt Jan 16 18:03:52 gw1 /kernel: arplookup 255.255.255.252 failed: host is not on local network Jan 16 18:03:52 gw1 /kernel: arpresolve: can't allocate llinfo for 255.255.255.252rt 255.255.255.252 is of course not an ip address but a netmask on the two of the 3 xl0 cards in that machine. ifconfig -a shows nothing strange stumped Len To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: annoying bug on routing tables...
Ruslan Ermilov writes: > > > Symptoms are -- if you change the address to an interface, > > > packets to destinations to which you have talked to in the past > > > will still go out with the previous address unless > > > you delete and reinstall a route for that destination. > > > > Yes. The address deletion code is supposed to make sure that > > everything gets cleaned up, but it doesn't actually work in practice. > > (My fault in part.) > > > kern/20785. I hope to find some spare time to handle it... See also kern/10778, which may be related. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: bandwith limitation
Am 16.01.2001 um 17:38:46 schrieb Martin Eggen: Hi Martin, thanks a lot for your hints. > You might want to take a look at ALTQ[0] from the KAME people, or just use > ipfw with a default pass all rule (or IPFIREWALL_DEFAULT_ACCEPT), so that > it's only used for bw limiting. (The packets will then first go through > ipfw, and then through ipf, IIRC). so it is definitely impossible that a packet that passes ipfw (as every packet does) enters the system even if ipf says "no", right? I have some additional questions concerning the ipfw approach: - is it in general a bad thing to have ipf/ipfw together running on one machine or ist it just o.k. to have ipf as firewall and IP-accounting and ipfw for bandwith limitations? - is there a performance loss worth mentioning in using both tools compared to only have ipfw running for all purposes? - does the bandwith-limitation that ipfw/dummynet offer tear down the effective bandwith of my server? - does the bandwith-limitation (ipfw) cost a lot of cpu/memory performance? thanks a lot for your help /ch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: bandwith limitation
> so it is definitely impossible that a packet that passes ipfw (as every
> packet does) enters the system even if ipf says "no", right?
you have to look at the order of invokation of ipfw and ipfw
in the kernel (/sys/netinet/ip_{input,output}.c) to make
sure what happens.
> I have some additional questions concerning the ipfw approach:
>
> - is it in general a bad thing to have ipf/ipfw together running on one
> machine or ist it just o.k. to have ipf as firewall and IP-accounting
> and ipfw for bandwith limitations?
it is not bad, though you end up using two different packages
and maybe do the classification twice. As far as i can tell
the only real advantage of ipf is that you can do NAT in the kernel,
for all the rest (including stateful filtering) ipfw is pretty
much on par. The classification performance should be essentially
the same -- both filters use the same technique for matching.
> - is there a performance loss worth mentioning in using both tools
> compared to only have ipfw running for all purposes?
probably not. see above.
> - does the bandwith-limitation that ipfw/dummynet offer tear down the
> effective bandwith of my server?
that is exactly what you want to do, right ? seriously, the shaper per
se has very little cpu overhead (though you have to classify packets,
but that is a price you have to pay anyways). Memorywise you need
the buffers to store the packets that are delayed -- not a big deal
unless you want to do something real unusual.
> - does the bandwith-limitation (ipfw) cost a lot of cpu/memory
> performance?
see above
cheers
luigi
--+-
Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa)
http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704
Phone: (510) 666 2927
--+-
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: arp pb's : correction
>We have a FreeBSD 3.1R machine as our main router uplinking to a >Cisco 3620 (back to back, no switch). > >All works well, and had for months. After a reboot of cisco and >freebsd, all still works well, but we cannot ping cisco inside to >fbsd outside (the back to back interfaces with x-over cable), plus >when we traceroute up to internet, all we get is * * * when >traversing that link, followed by normal traceoute behavior. > >This link carries several a gigabyte of traffic a day in both >directions without pb's, but we have this problem with that link. I found a garbage route had crept into my routing table with a gateway of 255.255.255.252. So that's fixed the arp complaints but the above pb persists. >dmesg shows tons of: > >arpresolve: can't allocate llinfo for 255.255.255.252rt >arplookup 255.255.255.252 failed: host is not on local network >arpresolve: can't allocate llinfo for 255.255.255.252rt >arplookup 255.255.255.252 failed: host is not on local network >arpresolve: can't allocate llinfo for 255.255.255.252rt > > >and /var/log/messages shows: > >Jan 16 18:03:49 gw1 /kernel: arplookup 255.255.255.252 failed: host >is not on local network >Jan 16 18:03:49 gw1 /kernel: arpresolve: can't allocate llinfo for >255.255.255.252rt >Jan 16 18:03:51 gw1 /kernel: arplookup 255.255.255.252 failed: host >is not on local network >Jan 16 18:03:51 gw1 /kernel: arpresolve: can't allocate llinfo for >255.255.255.252rt >Jan 16 18:03:52 gw1 /kernel: arplookup 255.255.255.252 failed: host >is not on local network >Jan 16 18:03:52 gw1 /kernel: arpresolve: can't allocate llinfo for >255.255.255.252rt > >255.255.255.252 is of course not an ip address but a netmask on the >two of the 3 xl0 cards in that machine. > >ifconfig -a shows nothing strange To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: HEADSUP! New netgraph code coming
Dag-Erling Smorgrav writes: > Julian Elischer <[EMAIL PROTECTED]> writes: > > > Something is terribly broken with ng_ether at the moment. It lacks a > > > MODULE_VERSION line. > > is this required for something to be a depency? > > Yes. > > > Where is it documented? > > It's not, AFAIK. UTSL (like the rest of us) I don't think Julian is at fault here. At some point in the past, MODULE_VERSION wasn't required. Whoever committed the checkin that made suddenly made MODULE_VERSION required should have added it to all affected files, or at least there should have been a HEADS UP, but I don't recall seeing one. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Bridging-Firewall/bandwith limit problem
We have a FreeBSD 4.2-STABLE machine running as a Bridging Firewall and we are having some difficulties, can anyone give me a pointer, or outright help... figuring out what is the problem? Details below. Problem repeatable using different network cards (fxp or xl) FreeBSD 4.2 stable ipfw/dummynet issues (Kernel Config Below): Sending selected TCP ports, or selected subnets through dummynet pipes for bandwidth control, the pipes sometimes get "clogged up", causing all packets going through the pipe to be dropped. Deleting and re-creating the pipe clears it up. We tried assigning selected subnets to pipes via dummynet queues, masking for host addresses, so that each host address would get a bucket. The system seemed to ignore the actual mask we gave it and assigned flows to buckets by 4th octet only. The system generated log messages "... /kernel: == not eligible, size " and after a while paniced, rebooted. This set of rules get you "clogged" pipes: ipfw pipe 1 config bw 512KBytes/s queue 200Kbytes ipfw pipe 2 config bw 256KBytes/s queue 100Kbytes ipfw add 15130 pipe 1 ip from any to XXX.YYY.208.0/20 recv xl1 ipfw add 15140 pipe 1 ip from any to XXX.YYY.172.0/22 recv xl1 ipfw add 15110 pipe 2 ip from XXX.YYY.208.0/20 to any recv xl0 ipfw add 15120 pipe 2 ip from XXX.YYY.172.0/22 to any recv xl0 This set of rules caused OS-Crash (reboot): ipfw pipe 1 config bw 256KBytes/s queue 150Kbytes ipfw queue 1 config pipe 1 weight 1 mask src-ip 0x0FFF buckets 256 queue 75K Bytes ipfw queue 2 config pipe 1 weight 1 mask src-ip 0x03FF buckets 128 queue 75K Bytes ipfw pipe 2 config bw 512KBytes/s queue 300Kbytes ipfw queue 3 config pipe 2 weight 1 mask dst-ip 0x0FFF buckets 256 queue 75K Bytes ipfw queue 4 config pipe 2 weight 1 mask dst-ip 0x03FF buckets 128 queue 75K Bytes ipfw add 16010 queue 1 ip from XXX.YYY.208.0/20 to any recv xl0 ipfw add 16020 queue 2 ip from XXX.YYY.172.0/22 to any recv xl0 ipfw add 16030 queue 3 ip from any to XXX.YYY.208.0/20 recv xl1 ipfw add 16040 queue 4 ip from any to XXX.YYY.172.0/22 recv xl1 In each case traffic flows worked as we had intended for a while before failure. Appropriate Settings from /etc/rc.conf: bridging_enable="YES" bridging_fw_enable="YES" portmap_enable="NO" firewall_enable="YES" firewall_script="/usr/local/etc/firewall/rc.firewall" drop_synfin_enable="YES" extra Sysctls set are: sysctl -w net.link.ether.bridge=1 sysctl -w net.link.ether.bridge_ipfw=1 KERNEL Config file: # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246.2.20 2000/10/31 23:16:07 n_hibma Exp $ machine i386 cpu I586_CPU cpu I686_CPU ident GENERIC maxusers128 options INET#InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV# install a CDEV entry in /dev options DUMMYNET options IPDIVERT options BRIDGE options NMBCLUSTERS=16384 options TCP_DROP_SYNFIN options IPSTEALTH #support for stealth forwarding options TCP_RESTRICT_RST#restrict emission of TCP RST options ICMP_BANDLIM#Rate limit bad replies options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_FORWARD options IPFIREWALL_DEFAULT_TO_ACCEPT device isa device eisa device pci # Floppy drives device fdc0at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 #device fd1 at fdc0 drive 1 # ATA and ATAPI devices device ata0at isa? port IO_WD1 irq 14 device ata1at isa? port IO_WD2 irq 15 device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives
Re: bandwith limitation
Am 16.01.2001 um 09:54:55 schrieb Luigi Rizzo:
Hi Luigi,
first thanks for your hints,
> > so it is definitely impossible that a packet that passes ipfw (as every
> > packet does) enters the system even if ipf says "no", right?
>
> you have to look at the order of invokation of ipfw and ipfw
> in the kernel (/sys/netinet/ip_{input,output}.c) to make
> sure what happens.
I am not really a C-crack :-(. The only thing I really would like to
know is, if any packet has to pass ipf, no matter what ipfw sayd before
(or after). If this is the case it would be blocked if necessary.
I am just not sure if there could be a situation where ipfw says "o.k."
and the packet passes through both tools (ipf & ipfw) no matter what ipf
says.
> > I have some additional questions concerning the ipfw approach:
> >
> > - is it in general a bad thing to have ipf/ipfw together running on one
> > machine or ist it just o.k. to have ipf as firewall and IP-accounting
> > and ipfw for bandwith limitations?
>
> it is not bad, though you end up using two different packages
> and maybe do the classification twice. As far as i can tell
> the only real advantage of ipf is that you can do NAT in the kernel,
> for all the rest (including stateful filtering) ipfw is pretty
> much on par.
I used ipfw to do the filtering before but I needed IP-accounting and
for this purpose ipf does a pretty cool job. In combination with ipacct
I get a perfect report (devices, in-out, etc.). To drop ipf I would need
something similar to do this with ipfw. Is there a way to do this?
> > - does the bandwith-limitation that ipfw/dummynet offer tear down the
> > effective bandwith of my server?
>
> that is exactly what you want to do, right ?
perhaps my question was misleading. If I have 100 MBit and use the shaper
could it be possible to end up with a performance of 50 MBit (or
whatever) just because the shaper "eats" bandwith while doing the job?
Thanks a lot for your help (and Martin's of course). I have been looking
around for really a while to solve my problem and I get great help from
you.
/ch
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: HEADSUP! New netgraph code coming
Archie Cobbs <[EMAIL PROTECTED]> writes: > At some point in the past, MODULE_VERSION wasn't required. Whoever > committed the checkin that made suddenly made MODULE_VERSION required > should have added it to all affected files, or at least there should > have been a HEADS UP, but I don't recall seeing one. If I recall correctly, it was Mike, and the commit message was fairly explicit. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: bandwith limitation
Am 16.01.2001 um 10:22:23 schrieb Luigi Rizzo: Hi Luigi, hopefully you are not nerved by my continuing question, but there is still one thing I did not dompletely understand. > if ipf says no it says no. you just want tobe sure that > the packet actually passes through both things. I just do not know how to make this sure. It probably might have something to do with my kernel-config, right? So I show you how I would do it, perhaps you could tell if with this configuration every package passes both packages: options IPFILTER options IPFILTER_LOG options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT So if I have set up the config file for ipf (Firewall) and I only have configuration for bandwith limits in the ipfw config, does this make sure every packet passes ipf and is blocked if ipf says this? Thanks again for your help and patience /ch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: bandwith limitation
[Clemens Hermann] > I used ipfw to do the filtering before but I needed IP-accounting and > for this purpose ipf does a pretty cool job. In combination with ipacct > I get a perfect report (devices, in-out, etc.). To drop ipf I would need > something similar to do this with ipfw. Is there a way to do this? Depending on how fine-grained you want it, a couple of count rules and MRTG should do it, not? -- Martin Eggen <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: HEADSUP! New netgraph code coming
Dag-Erling Smorgrav writes: > > At some point in the past, MODULE_VERSION wasn't required. Whoever > > committed the checkin that made suddenly made MODULE_VERSION required > > should have added it to all affected files, or at least there should > > have been a HEADS UP, but I don't recall seeing one. > > If I recall correctly, it was Mike, and the commit message was fairly > explicit. It seems like fairly explicit commit message wasn't sufficient then. Whatever.. developers should pay more attention and committers should be more explicit. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Bridging-Firewall/bandwith limit problem
At Tue, 16 Jan 2001, [EMAIL PROTECTED] wrote: > >We have a FreeBSD 4.2-STABLE machine running as a Bridging Firewall >and we are having some difficulties, can anyone give me a pointer, >or outright help... figuring out what is the problem? Details >below. Problem repeatable using different network cards (fxp or xl) > >FreeBSD 4.2 stable ipfw/dummynet issues (Kernel Config Below): > >Sending selected TCP ports, or selected subnets through dummynet pipes >for bandwidth control, the pipes sometimes get "clogged up", causing all >packets going through the pipe to be dropped. Deleting and re-creating >the pipe clears it up. We had exactly the same problem with 4.1-STABLE or 4.0-STABLE (don't remember) a while ago. A 'downgrade' to 3.4-RELEASE fixed it, 3.4-STABLE had the same problem. Not much of a solution, but it may be helpful for the developers. Mark Lastdrager -- Pine Internet BV :: tel. +31-70-3111010 :: fax. +31-70-3111011 PGP 92BB81D1 fingerprint 0059 7D7B C02B 38D2 A853 2785 8C87 3AF1 Today's excuse: had to use hammer to free stuck disk drive heads. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: HEADSUP! New netgraph code coming
* Archie Cobbs <[EMAIL PROTECTED]> [010116 13:39] wrote: > Dag-Erling Smorgrav writes: > > > At some point in the past, MODULE_VERSION wasn't required. Whoever > > > committed the checkin that made suddenly made MODULE_VERSION required > > > should have added it to all affected files, or at least there should > > > have been a HEADS UP, but I don't recall seeing one. > > > > If I recall correctly, it was Mike, and the commit message was fairly > > explicit. > > It seems like fairly explicit commit message wasn't sufficient then. > Whatever.. developers should pay more attention and committers should > be more explicit. ~ % man 9 module No entry for module in section 9 of the manual ~ % man 9 MODULE No entry for MODULE in section 9 of the manual ~ % man 9 MODULE_VERSION No entry for MODULE_VERSION in section 9 of the manual ? This ought to be documented. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
cisco-freebsd link can't ping
We have a Cisco 3620 and FreeBSD 3.1R connected by an Ethernet crossover cable. Has been working fine for 14 months. A couple of gigabytes traffic pass over the link each day with no errors, speed is correct. ifconfig looks cool netstat -ib shows no collisions on the link A couple of months ago, we rebooted each box and now pinging from one's interface to on the linke the other boxes interface to this link, no responce. But either interface can ping the other box's other interfaces and further away. Traceroute across this link shows just: * * * and then the rest of the traceroute is ok. Apparently some kind of ICMP problem, but we're stumped, since no config info has been changed. We're looking for ways to troubleshoot the link. Tbanks, Len To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: cisco-freebsd link can't ping
Check the obvious. Your IP addresses, netmasks, routing table. Can you provide more info? ifconfig -au, netstat -rn, on the FreeBSD system. and sho ip route on your Cisco. RM On 17 Jan 2001, at 5:11, Len Conrad wrote: > We have a Cisco 3620 and FreeBSD 3.1R connected by an Ethernet > crossover cable. Has been working fine for 14 months. A couple of > gigabytes traffic pass over the link each day with no errors, speed > is correct. > > ifconfig looks cool > > netstat -ib shows no collisions on the link > > A couple of months ago, we rebooted each box and now pinging from > one's interface to on the linke the other boxes interface to this > link, no responce. But either interface can ping the other box's > other interfaces and further away. Traceroute across this link shows just: > > * * * > > and then the rest of the traceroute is ok. Apparently some kind of > ICMP problem, but we're stumped, since no config info has been changed. > > We're looking for ways to troubleshoot the link. > > Tbanks, > Len > > > > 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: cisco-freebsd link can't ping
>Check the obvious. Your IP addresses, netmasks, routing table. >Can you provide more info? ifconfig -au, netstat -rn, on the FreeBSD >system. and sho ip route on your Cisco. It was simple in fact. We had added some ipfilter rules on disk but hadn't loaded them into memory until the reboot dit dit. If I remove these rules: block in log quick all with short block in log quick all with opt lsrr block in log quick all with opt ssrr The ping and traceroute across that link work fine. I was led to believe those rules blocked trash but obviously they block more than that. thanks Len http://BIND8NT.MEIway.com : Binary for ISC BIND 8.2.3 T9B for NT4 & W2K http://IMGate.MEIway.com : Build free, hi-perf, anti-spam mail gateways To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
LVS with FreeBSD
Hello, I am setting up a LVS/DR cluster with 2 nodes(FreeBSD), but It doesn't work. Here is my network configuration; Internet(203.231.63.70 is Virtual IP) | | Router (203.231.63.0/24 network) | | <- eth0 : 203.231.63.74 LVS(Linux) | <- eth1 : 203.231.63.70 (VIP) | -- | | SVR1SVR2 <-- Real Servers are FreeBSD 4.2-RELEASE fxp0 : 203.231.63.70 203.231.63.70 (VIP) fxp1 : 203.231.63.71 203.231.63.72 (Real IP) ] in Load Valancing Server(203.231.63.74); [root@ha1 log]# ifconfig -a eth0Link encap:Ethernet HWaddr 00:10:5A:80:D7:FF inet addr:203.231.63.74 Bcast:203.231.63.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 eth1Link encap:Ethernet HWaddr 00:10:5A:76:02:49 inet addr:203.231.63.70 Bcast:203.231.63.70 Mask:255.255.255.255 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 [root@LVS /]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 203.231.63.70 0.0.0.0255.255.255.255 UH 0 0 0eth1 203.231.63.74 0.0.0.0255.255.255.255 UH 0 0 0eth0 203.231.63.00.0.0.0 255.255.255.0U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0203.231.63.254 0.0.0.0 UG 0 0 0 eth0 [root@LVS /]# sysctl -p net.ipv4.ip_forward = 1 net.ipv4.conf.all.rp_filter = 1 net.ipv4.ip_always_defrag = 0 kernel.sysrq = 0 [root@LVS /]# vi /etc/ha.d/conf/ldirectord.cf timeout=3 checkinterval=5 autoreload=no fallback=127.0.0.1:80 virtual=203.231.63.70:80 real=203.231.63.71:80 gate 1 real=203.231.63.72:80 gate 1 service=http request="index.html" receive="Test Page" scheduler=rr protocol=tcp ] in Real Server(231.63.71,72); SVR1# ifconfig -a fxp0: flags=8843 mtu 1500 inet 203.231.63.70 netmask 0x broadcast 203.231.63.70 fxp1: flags=8843 mtu 1500 inet 203.231.63.72 netmask 0xff00 broadcast 203.231.63.255 SVR2 in the same way.. *** Problem: 1. LVS dosen't forward http request packet to the real server.. 2. I don't know how FreeBSD(real server) can avoid arp request.. About first problem: Client try to connect 203.231.63.70:80, but LVS doesn't reply to that SYN packet.. :-( There are 2 things that seems odd.. First, When I start up ldirectord, output is like this.. [root@LVS /]# /etc/rc.d/init.d/ldirectord start Starting ldirectord [ OK ] [root@LVS /]# vi /var/log/ldirectord.log .. [Tue Jan 16 13:47:48 2001..] Starting Linux Director Daemon [Tue Jan 16 13:47:48 2001..] Adding virtual server: 203.231.63.70:80 [Tue Jan 16 13:47:48 2001..] Starting fallback server for: 203.231.63.70:80 [Tue Jan 16 13:47:49 2001..] Adding real server: 203.231.63.71:80 (1*203.231.63.70:80) [Tue Jan 16 13:47:49 2001..] Turning off fallback server for: 203.231.63.70:80 [Tue Jan 16 13:47:49 2001..] system(/sbin/ipvsadm -a -t 203.231.63.70:80 -R 203.231.63.72:80 -g -w 1) failed [Tue Jan 16 13:47:49 2001..] Adding real server: 203.231.63.72:80 (2*203.231.63.70:80) .. system(/sbin/ipvsadm -a -t 203.231.63.70:80 -R 203.231.63.72:80 -g -w 1) failed **Why this error occured?? What should I do to eliminate this error message?? Second, Here's my ipvsadm output: [root@LVS /]# ipvsadm -L -n
LVS with FreeBSD
Hello, I am setting up a LVS/DR cluster with 2 nodes(FreeBSD), but It doesn't work. Here is my network configuration; Internet(203.231.63.70 is Virtual IP) | | Router (203.231.63.0/24 network) | | <- eth0 : 203.231.63.74 LVS(Linux) | <- eth1 : 203.231.63.70 (VIP) | -- || SVR1 SVR2 <-- Real Servers are FreeBSD 4.2-RELEASE fxp0 : 203.231.63.70 203.231.63.70 (VIP) fxp1 : 203.231.63.71 203.231.63.72 (Real IP) ] in Load Valancing Server(203.231.63.74); [root@ha1 log]# ifconfig -a eth0 Link encap:Ethernet HWaddr 00:10:5A:80:D7:FF inet addr:203.231.63.74 Bcast:203.231.63.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 eth1 Link encap:Ethernet HWaddr 00:10:5A:76:02:49 inet addr:203.231.63.70 Bcast:203.231.63.70 Mask:255.255.255.255 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 [root@LVS /]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 203.231.63.70 0.0.0.0 255.255.255.255 UH0 00 eth1 203.231.63.74 0.0.0.0 255.255.255.255 UH0 00 eth0 203.231.63.00.0.0.0 255.255.255.0 U 0 00 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 00 lo 0.0.0.0 203.231.63.254 0.0.0.0 UG0 00 eth0 [root@LVS /]# sysctl -p net.ipv4.ip_forward = 1 net.ipv4.conf.all.rp_filter = 1 net.ipv4.ip_always_defrag = 0 kernel.sysrq = 0 [root@LVS /]# vi /etc/ha.d/conf/ldirectord.cf timeout=3 checkinterval=5 autoreload=no fallback=127.0.0.1:80 virtual=203.231.63.70:80 real=203.231.63.71:80 gate 1 real=203.231.63.72:80 gate 1 service=http request="index.html" receive="Test Page" scheduler=rr protocol=tcp ] in Real Server(231.63.71,72); SVR1# ifconfig -a fxp0: flags=8843 mtu 1500 inet 203.231.63.70 netmask 0x broadcast 203.231.63.70 fxp1: flags=8843 mtu 1500 inet 203.231.63.72 netmask 0xff00 broadcast 203.231.63.255 SVR2 in the same way.. *** Problem: 1. LVS dosen't forward http request packet to the real server.. 2. I don't know how FreeBSD(real server) can avoid arp request.. About first problem: Client try to connect 203.231.63.70:80, but LVS doesn't reply to that SYN packet.. There are 2 things that seems odd.. First, When I start up ldirectord, output is like this.. [root@LVS /]# /etc/rc.d/init.d/ldirectord start Starting ldirectord [ OK ] [root@LVS /]# vi /var/log/ldirectord.log .. [Tue Jan 16 13:47:48 2001..] Starting Linux Director Daemon [Tue Jan 16 13:47:48 2001..] Adding virtual server: 203.231.63.70:80 [Tue Jan 16 13:47:48 2001..] Starting fallback server for: 203.231.63.70:80 [Tue Jan 16 13:47:49 2001..] Adding real server: 203.231.63.71:80 (1*203.231.63.70:80) [Tue Jan 16 13:47:49 2001..] Turning off fallback server for: 203.231.63.70:80 [Tue Jan 16 13:47:49 2001..] system(/sbin/ipvsadm -a -t 203.231.63.70:80 -R 203.231.63.72:80 -g -w 1) failed [Tue Jan 16 13:47:49 2001..] Adding real server: 203.231.63.72:80 (2*203.231.63.70:80) .. system(/sbin/ipvsadm -a -t 203.231.63.70:80 -R 203.231.63.72:80 -g -w 1) failed **Why this error occured?? What should I do to eliminate this error message?? Second, Here's my ipvsadm output: [root@LVS /]# ipvsadm -L -n IP Virtual Server version 0.9.7 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 203.231.63.70:www rr -> 255.255.255.255:52199 Masq4194304 0 0 Last output line seems wrong,, I think It should look like this.. right? TCP 203.231.63.70:www rr -> 203.231.63.71:80route 1 0 0 -> 203.231.63.72:80route 1 0 0 **How can I fix this thing?? Second problem: As you know.. in LVS cluster, real servers should not reply to arp request that asks VIP's MAC address.. Only LVS should reply to that arp request.. I have an idea about it.. Let the real server reply to client's arp request(for VIP) with LVS's hardware address.. then all client's packet that towards VIP go to the LVS.. That's a good idea.. so I commanded like this.. arp -s 203.231.63.70 00:10:5A:76:02:49 pub 203.231.63.70 is VIP and 00:10:5A:76:02:49 is LV
