From owner-freebsd-ipfw@FreeBSD.ORG Sun Oct 31 20:35:33 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A8BA16A4CE for ; Sun, 31 Oct 2004 20:35:33 +0000 (GMT) Received: from shellma.zin.lublin.pl (shellma.zin.lublin.pl [212.182.126.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 890F543D45 for ; Sun, 31 Oct 2004 20:35:31 +0000 (GMT) (envelope-from pawmal-posting@freebsd.lublin.pl) Received: by shellma.zin.lublin.pl (Postfix, from userid 1018) id E94C73474C1; Sun, 31 Oct 2004 21:35:58 +0100 (CET) Date: Sun, 31 Oct 2004 21:35:58 +0100 From: Pawel Malachowski To: freebsd-ipfw@freebsd.org Message-ID: <20041031203558.GA49557@shellma.zin.lublin.pl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2i Subject: [PATCH] burstable dummynet pipe X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2004 20:35:33 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello, Attached (poor) patch (against 5.3-RC1) implements pipes that can be overloaded (exceed their bw) for a (short) period of time. It adds yet another parameter for pipe: `burst x', x in (K)Bytes. Should also work with dynamic (clonable via mask) pipes. Configuring `x bytes burst' means we are allowing to transmit x bytes with increased (by default: ~2x) speed. After that, traffic passes through pipe as usual (bw-limited), however, burst credit is slowly (by default: ~10x lower than bw) accumulated when pipe is idle (low traffic, empty ticks). When x bytes of burst credit is accumulated, one can consume it once again. Etc. No man page provided. Sorry for poor coding. Still, seems to work. ;) Example: % ipfw add ... // pass my test traffic to pipe 1 % ipfw pipe 1 config bw 256kbit queue 5KB burst 110KB % ipfw pipe show 00001: 256.000 Kbit/s 0 ms 110 KB 5120 B 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 % sleep 15 % wget --progress=dot some-file [...] HTTP request sent, awaiting response... 200 OK Length: 10,485,760 [text/plain] 0K .......... .......... .......... .......... .......... 0% 61.80 KB/s 50K .......... .......... .......... .......... .......... 0% 58.14 KB/s 100K .......... .......... .......... .......... .......... 1% 32.05 KB/s 150K .......... .......... .......... .......... .......... 1% 30.49 KB/s 200K .......... .......... .......... .......... .......... 2% 29.59 KB/s 250K .......... .......... .......... .......... .......... 2% 30.30 KB/s 300K .......... .......... .......... .......... .......... 3% 29.59 KB/s 350K .......... .......... .......... .......... .......... 3% 29.41 KB/s 400K .......... .......... ......^C % sleep 10 % wget --progress=dot some-file [...] HTTP request sent, awaiting response... 200 OK Length: 10,485,760 [text/plain] 0K .......... .......... .......... .......... .......... 0% 26.32 KB/s 50K .......... .......... .......... .......... .......... 0% 33.36 KB/s 100K .......... .......... .......... .......... .......... 1% 28.74 KB/s 150K .......... .......... .......... .......... .......... 1% 31.23 KB/s 200K .......^C % sleep 15 % wget --progress=dot some-file [...] HTTP request sent, awaiting response... 200 OK Length: 10,485,760 [text/plain] 0K .......... .......... .......... .......... .......... 0% 61.73 KB/s 50K .......... .......... .......... .......... .......... 0% 58.14 KB/s 100K .......... .......... .......... .......... .......... 1% 32.05 KB/s 150K .......... ...^C -- Paweł Małachowski --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: attachment; filename="burst--ip_dummynet.c.diff" --- /sys/netinet/ip_dummynet.c-orig Fri Oct 29 21:34:46 2004 +++ /sys/netinet/ip_dummynet.c Sun Oct 31 20:23:33 2004 @@ -580,14 +580,34 @@ * setting len_scaled = 0 does the job. */ q->numbytes += ( curr_time - q->sched_time ) * p->bandwidth; +#if 0 + if ( q->burstmode==DN_BURST_FLUSH && (q->currburst < q->numbytes/8/hz) ) { + printf("Full burst power. ;)\n"); + } + else if ( q->burstmode==DN_BURST_FLUSH ) { /* currbust >= numbytes/8/hz */ + printf("Burst getting empty, slow down a bit\n"); + } +#endif while ( (pkt = q->head) != NULL ) { int len = pkt->m_pkthdr.len; int len_scaled = p->bandwidth ? len*8*hz : 0 ; + if (q->burstmode==DN_BURST_FLUSH) + len_scaled /= 2; /* increase burst speed 2x. this will be <2x because we left SET_TICKS untouched but hey, it still works good enough... */ if (len_scaled > q->numbytes ) break ; q->numbytes -= len_scaled ; + if ( q->burstmode==DN_BURST_FLUSH ) + q->currburst -= len ; /* can go <0, we will fix this later */ move_pkt(pkt, q, p, len); } + + /* If burst credit is empty, announce that we are accumulatig it now. */ + if (q->burstmode==DN_BURST_FLUSH && q->currburst<=0) { + q->currburst = 0 ; + q->burstmode = DN_BURST_ACCUMULATE ; /* will get leftovers if found */ + //printf("Stop flushing burst (empty), start accumulating!\n"); + } + /* * If we have more packets queued, schedule next ready event * (can only occur when bandwidth != 0, otherwise we would have @@ -603,6 +623,21 @@ * queue on error hoping next time we are luckier. */ } else { /* RED needs to know when the queue becomes empty */ +#if 0 + if ( q->burstmode==DN_BURST_ACCUMULATE ) { + /* There are some leftovers, saturation<=bw (can be <). + * After some tests I decided not to accumulate them because + * burst credit grows even when saturation~=bw and burst + * explode from time to time during heavy-downloading + * sessions (it looks weird). */ + q->currburst += ( q->numbytes/(8*hz) ); + if (q->currburst >= p->burst) { + q->currburst = p->burst ; + q->burstmode = DN_BURST_FLUSH ; + //printf("Accumulate leftovers, we can start flushing burst now.\n"); + } + } +#endif q->q_time = curr_time; q->numbytes = 0; } @@ -880,11 +915,14 @@ return NULL ; } q->fs = fs ; + q->currburst = 0 ; /* we will accumulate burst while waiting */ + q->burstmode = DN_BURST_ACCUMULATE ; q->hash_slot = i ; q->next = fs->rq[i] ; q->S = q->F + 1; /* hack - mark timestamp as invalid */ fs->rq[i] = q ; fs->rq_elements++ ; + return q ; } @@ -1224,9 +1262,35 @@ * Fixed-rate queue: just insert into the ready_heap. */ dn_key t = 0 ; + dn_key pst = 0 ; /* preserved schedule time */ + dn_key ct = 0 ; /* computed time, with bw, gives burst credit for idle ticks */ if (pipe->bandwidth) t = SET_TICKS(m, q, pipe); + pst = q->sched_time ; q->sched_time = curr_time ; + + if (pipe->burst && q->burstmode==DN_BURST_ACCUMULATE) { + /* We should use `previous' t, but hey, when passing constant + current traffic, t is usually the same or very close. + So it is acceptable to use current t value for simplicity. */ + ct = curr_time - pst - t; + /* Make sure, we avoid negative. This happens all the time + when bw is full of passing traffic. */ + if (DN_KEY_LT(curr_time-pst,t)) ct=0; + + /* Pipe was idle for some time, increase burst credit + to reflect this. + Burst credit can grow slower or faster (but it is always + connected with pipe bw), just increase or descrease `a' + in this expression: (8*hz*a), a=10 is the default. */ + q->currburst += ct*pipe->bandwidth/(8*hz*10); + if ( q->currburst >= pipe->burst ) { + q->currburst = pipe->burst ; + q->burstmode = DN_BURST_FLUSH ; + } + //printf("dummynet_io(): (t=%lld,curr-sched=%lld) added %lld, now currburst=%d(burst=%d)\n", t,ct,(ct) * pipe->bandwidth /(8*hz*10),q->currburst,pipe->burst ); + } + if (t == 0) /* must process it now */ ready_event( q ); else @@ -1614,6 +1678,7 @@ bcopy(p->if_name, x->if_name, sizeof(p->if_name) ); x->ifp = NULL ; /* reset interface ptr */ x->delay = p->delay ; + x->burst = p->bandwidth ? p->burst : 0 ; /* burst is for fixed-bw pipes */ set_fs_parms(&(x->fs), pfs); --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: attachment; filename="burst--ip_dummynet.h.diff" --- /sys/netinet/ip_dummynet.h-orig Fri Oct 29 21:34:56 2004 +++ /sys/netinet/ip_dummynet.h Sun Oct 31 19:31:36 2004 @@ -208,6 +208,11 @@ u_int len_bytes ; u_long numbytes ; /* credit for transmission (dynamic queues) */ + int currburst ; /* current burst buffer credit, in bytes */ + u_short burstmode ; +#define DN_BURST_ACCUMULATE 0 /* accumulating burst credit */ +#define DN_BURST_FLUSH 1 /* we can use accumulated burst credit */ + u_int64_t tot_pkts ; /* statistics counters */ u_int64_t tot_bytes ; u_int32_t drops ; @@ -315,6 +320,7 @@ int pipe_nr ; /* number */ int bandwidth; /* really, bytes/tick. */ int delay ; /* really, ticks */ + int burst ; /* burst buffer credit, in bytes */ struct mbuf *head, *tail ; /* packets in delay line */ --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: attachment; filename="burst--ipfw.c.diff" --- /usr/src/sbin/ipfw/ipfw2.c-orig Fri Oct 29 21:16:23 2004 +++ /usr/src/sbin/ipfw/ipfw2.c Sun Oct 31 20:14:17 2004 @@ -253,6 +253,7 @@ TOK_DROPTAIL, TOK_PROTO, TOK_WEIGHT, + TOK_BURST, }; struct _s_x dummynet_params[] = { @@ -275,6 +276,7 @@ { "delay", TOK_DELAY }, { "pipe", TOK_PIPE }, { "queue", TOK_QUEUE }, + { "burst", TOK_BURST }, { "dummynet-params", TOK_NULL }, { NULL, 0 } /* terminator */ }; @@ -1518,6 +1520,7 @@ for (; nbytes >= sizeof *p; p = (struct dn_pipe *)next) { double b = p->bandwidth; char buf[30]; + char buf2[30]; char prefix[80]; if (p->next != (struct dn_pipe *)DN_IS_PIPE) @@ -1547,8 +1550,14 @@ else sprintf(buf, "%7.3f bit/s ", b); - sprintf(prefix, "%05d: %s %4d ms ", - p->pipe_nr, buf, p->delay); + if (p->burst >= 8192) + sprintf(buf2, "%d KB", p->burst / 1024); + else + sprintf(buf2, "%d B", p->burst); + + sprintf(prefix, "%05d: %s %4d ms %s", + p->pipe_nr, buf, p->delay, buf2); + print_flowset_parms(&(p->fs), prefix); if (verbose) printf(" V %20qd\n", p->V >> MY_M); @@ -2280,6 +2289,18 @@ p.fs.qsize *= 1024; } else if (*end == 'B' || !strncmp(end, "by", 2)) { p.fs.flags_fs |= DN_QSIZE_IS_BYTES; + } + ac--; av++; + break; + + case TOK_BURST: + if (do_pipe != 1) + errx(EX_DATAERR, "burst only valid for pipes"); + NEED1("burst needs credit size\n"); + end = NULL; + p.burst = strtoul(av[0], &end, 0); + if (*end == 'K' || *end == 'k') { + p.burst *= 1024; } ac--; av++; break; --OXfL5xGRrasGEqWY-- From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 1 10:16:44 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D80BC16A4D0 for ; Mon, 1 Nov 2004 10:16:44 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B3E143D69 for ; Mon, 1 Nov 2004 10:16:43 +0000 (GMT) (envelope-from vincepoy@gmail.com) Received: by rproxy.gmail.com with SMTP id 79so122443rnk for ; Mon, 01 Nov 2004 02:16:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=OIMXm/F7s+zHqKPDd5T9Ye1gtRbEALIg20gM+JjnGK7hrKcwvx7OULiUFup8IWbN2qZMQSI7cqhv1kBWxFr93LFe2TuVPZSylo6VxcTuqsuqEYyEVcwou8bNbfIRcrym5GQFJiJYU/OtbAu3qt79MnjefmPQGPNOY4RLCjB+Q3U= Received: by 10.38.150.78 with SMTP id x78mr646511rnd; Mon, 01 Nov 2004 02:16:42 -0800 (PST) Received: by 10.38.14.49 with HTTP; Mon, 1 Nov 2004 02:16:42 -0800 (PST) Message-ID: <429af92e041101021638e8598e@mail.gmail.com> Date: Mon, 1 Nov 2004 02:16:42 -0800 From: Vincent Poy To: Ari Suutari In-Reply-To: <016901c4bfe5$77c19d90$2508473e@sad.syncrontech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200410300927.51286.ari@suutari.iki.fi> <429af92e04103118435b35f235@mail.gmail.com> <016901c4bfe5$77c19d90$2508473e@sad.syncrontech.com> cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw and ipsec processing order for outgoing packets wrong X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Vincent Poy List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2004 10:16:45 -0000 Hi, I don't know how to explain my problem but it goes something like this... root@bigbang [2:05am][/home/vince] >> ipfw show 00049 1557131 244839199 skipto 100 ip from 208.201.244.224/29 to any 00050 12072800468 917651580916 divert 8668 ip from any to any via xl0 00100 69518 8548222 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 63000 0 0 allow ip from any to 10.0.0.0/8 out 63001 0 0 allow ip from any to 172.16.0.0/12 out 63002 312 16048 allow ip from any to 192.168.0.0/16 out 63003 24237 2952214 allow ip from any to 208.201.244.224/29 out 63004 667879 129410867 queue 1 tcp from any to any tcpflags ack out 63005 1 40 queue 2 tcp from any to any dst-port 22,23 out 63006 38782 3364689 queue 2 udp from any to any not dst-port 80,443 out 63007 43021 2194871 queue 3 ip from any to any dst-port 80,443 out 63008 5467 405319 queue 4 ip from any to any out 65000 1795325 424479044 allow ip from any to any 65535 0 0 deny ip from any to any The counters for queue 1 keeps increasing when I do a ftp out even for non-ACK packets but the other counters for queue 2-4 doesn't move at all so it seems like everything is going out one queue instead of what the rules actually say. I have one pipe configured as 480Kbit/sec which is what rules 63005-63008 does. ipfw pipe show and ipfw queue show would seem normal except the Source IP and Destination IP is stuck with the first processed queues information while only the counters for queue 1 updates. root@bigbang [2:12am][/home/vince] >> ipfw pipe show 00001: 480.000 Kbit/s 0 ms 50 sl. 0 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 q00001: weight 100 pipe 1 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 208.201.244.226/3748 205.188.179.233/5190 673549 137223155 0 0 2303 q00002: weight 66 pipe 1 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 208.201.244.225/1026 208.201.224.11/53 40022 3470523 0 0 0 q00003: weight 33 pipe 1 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 208.201.244.226/3750 199.181.132.105/80 43058 2196795 0 0 0 q00004: weight 1 pipe 1 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 208.201.244.226/3748 205.188.179.233/5190 5492 407173 0 0 0 root@bigbang [2:12am][/home/vince] >> ipfw queue show q00001: weight 100 pipe 1 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 208.201.244.226/3748 205.188.179.233/5190 673550 137223195 0 0 2303 q00002: weight 66 pipe 1 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 208.201.244.225/1026 208.201.224.11/53 40025 3470881 0 0 0 q00003: weight 33 pipe 1 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 208.201.244.226/3750 199.181.132.105/80 43058 2196795 0 0 0 q00004: weight 1 pipe 1 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 208.201.244.226/3748 205.188.179.233/5190 5493 407225 0 0 0 I don't know how else I would test this. Cheers, Vince On Mon, 1 Nov 2004 09:35:58 +0200, Ari Suutari wrote: > >I am experiencing the same problem as well when I updated from a March > > 6, 2004 -CURRENT to the October 19, 2004 -CURRENT. The problem still > > exists with the October 27, 2004 -CURRENT. I'm using ipfw/dummynet > > for outgoing queues with the ACK packets having the highest priority > > in it's own queue. However, it seems like while the queues are there, > > the information on ipfw queue show doesn't update at all as the Source > > and Destination IP is still the same as the first packet after bootup > > while the counters change but the ACK packets are not sent on it's own > > queue but rather with all other packets. I know it is related with > > pfil_hook when ipfw was converted. > > This is not related to pfil_hook conversion. The problem is also present > in > FreeBSD 4.x-STABLE (just tested it). I think that history of ipfw and > ipsec > interaction goes like this: > > - in the very beginning, a packet that was processed by ipsec didn't > hit ipfw at all in unencrypted form, ie. one was able to able to > filter esp > and ah protocols only. > > - someone fixed this, apparently for incoming packets only, but this > some folks were upset by the fact that they would have to add a rule > for unencrypted protocols into ipfw. At that time (in ipfw1), there > was > possibility to check that unencrypted packet actually came from ipsec > (ie. ipfw ipsec flag wasn't implemented) > > - IPSEC_FILTERGIF option was added. If set, incoming packets go > through ipfw twice (encrypted and unencrypted). If not set, packets > go > to ipfw only once (encrypted). > > Currently outgoing packets are always processed like IPSEC_FILTERGIF was > not set (I like to have it set, because I need quite fine-grained > firewalling > even inside my ipsec tunnels, which are between different companies). > What > I was suggesting (ie. moving pfil_hook processing in ip_output before > ipsec stuff) wasn't really correct: This change should be conditional > based on > IPSEC_FILTERGIF setting: The change I described should be done only > when IPSEC_FILTERGIF is set. > > Now, ip_output is quite central part in ip stack. I would be happy if > someone > who knows that part better than me could implement this (I can sure test > it easily). > > Ari S. > > > > > > > Cheers, > > Vince > > > > On Sat, 30 Oct 2004 09:27:50 +0300, Ari Suutari > > wrote: > >> Hi, > >> > >> I noticed that processing order of ipsec and ipfw (pfil_hook) is not > >> correct for outgoing packets. Currently, ipsec processing is done first, > >> which makes packets to go through without firewall inspection. > >> This might be a security problem for someone, but at least it > >> breaks stateful rule handling. > >> > >> My test setup is (all freebsd 5.3-rc1 machines): > >> > >> freebsd laptop <-> ipsec tunnel <->freebsd server > >> > >> When server sends packet to laptop, it now goes like this: > >> > >> ip_output -> ipsec -> ip_output -> ipfw -> network > >> > >> It should go like this: > >> > >> ip_output -> ipfw -> ipsec -> ip_output -> ipfw -> network > >> > >> I think that this could be fixed by just moving pfil_hook > >> processing in ip_output before ipsec processing. > >> > >> Ari S. > >> > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to > >> "freebsd-current-unsubscribe@freebsd.org" > >> > >> > > > > From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 1 11:02:33 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9182516A4CF for ; Mon, 1 Nov 2004 11:02:33 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8845343D46 for ; Mon, 1 Nov 2004 11:02:33 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id iA1B2WVu094651 for ; Mon, 1 Nov 2004 11:02:32 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id iA1B2WD1094645 for ipfw@freebsd.org; Mon, 1 Nov 2004 11:02:32 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 1 Nov 2004 11:02:32 GMT Message-Id: <200411011102.iA1B2WD1094645@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: ipfw@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2004 11:02:33 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/04/22] kern/51274 ipfw ipfw2 create dynamic rules with parent nu f [2003/04/24] kern/51341 ipfw ipfw rule 'deny icmp from any to any icmp o [2003/12/11] kern/60154 ipfw ipfw core (crash) o [2004/03/03] kern/63724 ipfw IPFW2 Queues dont t work f [2004/03/25] kern/64694 ipfw [ipfw] UID/GID matching in ipfw non-funct 5 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [2001/04/13] kern/26534 ipfw Add an option to ipfw to log gid/uid of w o [2002/12/10] kern/46159 ipfw ipfw dynamic rules lifetime feature o [2003/02/11] kern/48172 ipfw ipfw does not log size and flags o [2003/03/10] kern/49086 ipfw [patch] Make ipfw2 log to different syslo o [2003/04/09] bin/50749 ipfw ipfw2 incorrectly parses ports and port r o [2003/08/26] kern/55984 ipfw [patch] time based firewalling support fo o [2003/12/30] kern/60719 ipfw ipfw: Headerless fragments generate cryp o [2004/08/03] kern/69963 ipfw ipfw: install_state warning about already o [2004/09/04] kern/71366 ipfw "ipfw fwd" sometimes rewrites destination 9 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 1 12:20:14 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCD9E16A4CE; Mon, 1 Nov 2004 12:20:14 +0000 (GMT) Received: from poison2.syncrontech.com (adsl-nat.syncrontech.com [213.28.98.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F09943D1F; Mon, 1 Nov 2004 12:20:13 +0000 (GMT) (envelope-from ari@suutari.iki.fi) Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.57])iA1CK8L6030602; Mon, 1 Nov 2004 14:20:09 +0200 (EET) (envelope-from ari@suutari.iki.fi) Received: from coffee (coffee.syncrontech.com [62.71.8.37]) iA1CK7b2043496; Mon, 1 Nov 2004 14:20:07 +0200 (EET) (envelope-from ari@suutari.iki.fi) Message-ID: <02d801c4c00d$24fc2a30$2508473e@sad.syncrontech.com> From: "Ari Suutari" To: "Vincent Poy" References: <200410300927.51286.ari@suutari.iki.fi> <429af92e04103118435b35f235@mail.gmail.com> <016901c4bfe5$77c19d90$2508473e@sad.syncrontech.com> <429af92e041101021638e8598e@mail.gmail.com> Date: Mon, 1 Nov 2004 14:20:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw and ipsec processing order for outgoing packets wrong X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2004 12:20:15 -0000 Hi, > The counters for queue 1 keeps increasing when I do a ftp out even for > non-ACK packets but the other counters for queue 2-4 doesn't move at > all so it seems like everything is going out one queue instead of what > the rules actually say. I have one pipe configured as 480Kbit/sec > which is what rules 63005-63008 does. Are you using IPsec ? Ari S. From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 1 13:13:22 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2039716A4CF for ; Mon, 1 Nov 2004 13:13:22 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id A584543D48 for ; Mon, 1 Nov 2004 13:13:21 +0000 (GMT) (envelope-from vincepoy@gmail.com) Received: by rproxy.gmail.com with SMTP id 79so130317rnk for ; Mon, 01 Nov 2004 05:13:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=iXAalXBYT44OWlIM6Pen5lfuSUZcOCt3D8gklVEEiKZ6yfW3hnB3a++BEbNvdIyVVErUzOmhjMOq3bIfp5p3VbpIB5NwaH4UpP2kr4Xjn+H1v2XAwHJwsGybCz3cDvTX1pMae9T6Llb9AWRQdCnUmnDRj4kGQMU62INgc0UWfzM= Received: by 10.38.66.50 with SMTP id o50mr718621rna; Mon, 01 Nov 2004 05:13:21 -0800 (PST) Received: by 10.38.14.49 with HTTP; Mon, 1 Nov 2004 05:13:21 -0800 (PST) Message-ID: <429af92e041101051357fc2384@mail.gmail.com> Date: Mon, 1 Nov 2004 05:13:21 -0800 From: Vincent Poy To: Ari Suutari In-Reply-To: <02d801c4c00d$24fc2a30$2508473e@sad.syncrontech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200410300927.51286.ari@suutari.iki.fi> <429af92e04103118435b35f235@mail.gmail.com> <016901c4bfe5$77c19d90$2508473e@sad.syncrontech.com> <429af92e041101021638e8598e@mail.gmail.com> <02d801c4c00d$24fc2a30$2508473e@sad.syncrontech.com> cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw and ipsec processing order for outgoing packets wrong X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Vincent Poy List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2004 13:13:22 -0000 On Mon, 1 Nov 2004 14:20:10 +0200, Ari Suutari wrote: > > The counters for queue 1 keeps increasing when I do a ftp out even for > > non-ACK packets but the other counters for queue 2-4 doesn't move at > > all so it seems like everything is going out one queue instead of what > > the rules actually say. I have one pipe configured as 480Kbit/sec > > which is what rules 63005-63008 does. > > Are you using IPsec ? > > Ari S. Nope... As you can see, I'm just using ipfw2 with dummynet for pipe/queue just for traffic shaping. Cheers, Vince From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 1 13:24:07 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 872D116A4CE for ; Mon, 1 Nov 2004 13:24:07 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29E0B43D5A for ; Mon, 1 Nov 2004 13:24:07 +0000 (GMT) (envelope-from vincepoy@gmail.com) Received: by rproxy.gmail.com with SMTP id 79so92400rnl for ; Mon, 01 Nov 2004 05:24:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=M+3ZWmf5M/wVRoYvlnMrJ8G7TheJ1PwV722pcfiZfZEZOs31ZpA1XKHF6WZXCWgApqfHAc87mhZ12RGxg+f7BQcQ2r3sJwH8sspBX/W3YYJVAZKKyD/xXi04NK9O83U0W2KR0Yl5U9OFutnFWxBcq/D10bqwVhcDn4jo5e4z75Y= Received: by 10.38.150.54 with SMTP id x54mr716337rnd; Mon, 01 Nov 2004 05:24:06 -0800 (PST) Received: by 10.38.14.49 with HTTP; Mon, 1 Nov 2004 05:24:06 -0800 (PST) Message-ID: <429af92e041101052447a808e6@mail.gmail.com> Date: Mon, 1 Nov 2004 05:24:06 -0800 From: Vincent Poy To: Ari Suutari In-Reply-To: <429af92e041101051357fc2384@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200410300927.51286.ari@suutari.iki.fi> <429af92e04103118435b35f235@mail.gmail.com> <016901c4bfe5$77c19d90$2508473e@sad.syncrontech.com> <429af92e041101021638e8598e@mail.gmail.com> <02d801c4c00d$24fc2a30$2508473e@sad.syncrontech.com> <429af92e041101051357fc2384@mail.gmail.com> cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw and ipsec processing order for outgoing packets wrong X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Vincent Poy List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2004 13:24:07 -0000 On Mon, 1 Nov 2004 05:13:21 -0800, Vincent Poy wrote: > On Mon, 1 Nov 2004 14:20:10 +0200, Ari Suutari wrote: > > > > > The counters for queue 1 keeps increasing when I do a ftp out even for > > > non-ACK packets but the other counters for queue 2-4 doesn't move at > > > all so it seems like everything is going out one queue instead of what > > > the rules actually say. I have one pipe configured as 480Kbit/sec > > > which is what rules 63005-63008 does. > > > > Are you using IPsec ? > > > > Ari S. > > Nope... As you can see, I'm just using ipfw2 with dummynet for > pipe/queue just for traffic shaping. Maybe this will explain it better as this was what my rules are based on: http://www.topfx.com/prioritizingackfreebsd.shtml From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 1 13:54:35 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD7A616A4CE for ; Mon, 1 Nov 2004 13:54:35 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A1DE43D2F for ; Mon, 1 Nov 2004 13:54:35 +0000 (GMT) (envelope-from vincepoy@gmail.com) Received: by rproxy.gmail.com with SMTP id 79so132936rnk for ; Mon, 01 Nov 2004 05:54:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ImGbuBSVAzRj+Nvs8MM3E4nwmo74w2VgE2+jT0PmlWciKLaLMe6f8xZOEFi20sqbLu7GZ/3HgDamYzNBRMmmLyvNmIGGo9Wp2DFTfmvsqE5zuDG6NA9xF7AFdzFtvR/RJCL0YGCCLncI8hMzqYGHFA02lmIFZ/ycUTcmFDkL2sI= Received: by 10.38.66.50 with SMTP id o50mr739172rna; Mon, 01 Nov 2004 05:54:34 -0800 (PST) Received: by 10.38.14.49 with HTTP; Mon, 1 Nov 2004 05:54:33 -0800 (PST) Message-ID: <429af92e0411010554456059d9@mail.gmail.com> Date: Mon, 1 Nov 2004 05:54:33 -0800 From: Vincent Poy To: Ari Suutari In-Reply-To: <429af92e041101052447a808e6@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200410300927.51286.ari@suutari.iki.fi> <429af92e04103118435b35f235@mail.gmail.com> <016901c4bfe5$77c19d90$2508473e@sad.syncrontech.com> <429af92e041101021638e8598e@mail.gmail.com> <02d801c4c00d$24fc2a30$2508473e@sad.syncrontech.com> <429af92e041101051357fc2384@mail.gmail.com> <429af92e041101052447a808e6@mail.gmail.com> cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw and ipsec processing order for outgoing packets wrong X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Vincent Poy List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2004 13:54:35 -0000 On Mon, 1 Nov 2004 05:24:06 -0800, Vincent Poy wrote: > On Mon, 1 Nov 2004 05:13:21 -0800, Vincent Poy wrote: > > > > On Mon, 1 Nov 2004 14:20:10 +0200, Ari Suutari wrote: > > > > > > > > The counters for queue 1 keeps increasing when I do a ftp out even for > > > > non-ACK packets but the other counters for queue 2-4 doesn't move at > > > > all so it seems like everything is going out one queue instead of what > > > > the rules actually say. I have one pipe configured as 480Kbit/sec > > > > which is what rules 63005-63008 does. > > > > > > Are you using IPsec ? > > > > > > Ari S. > > > > Nope... As you can see, I'm just using ipfw2 with dummynet for > > pipe/queue just for traffic shaping. > > Maybe this will explain it better as this was what my rules are based on: > > > http://www.topfx.com/prioritizingackfreebsd.shtml Looks like the problem fixed itself for whatever reason. Now I'm getting the 400KB/s down/52KB/s up when I do file transfers at the same time instead of 200KB/s down/52KB/s up like when I updated -CURRENT after 7 months. I guess it must be some coincidence that SBC's ATM network had problems. Cheers, Vince From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 1 17:58:51 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7916416A4CE for ; Mon, 1 Nov 2004 17:58:51 +0000 (GMT) Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19F5243D2F for ; Mon, 1 Nov 2004 17:58:51 +0000 (GMT) (envelope-from ababurko@adelphia.net) Received: from ample.adelphia.net ([24.52.224.96]) by mta9.adelphia.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20041101175848.ETHV2497.mta9.adelphia.net@ample.adelphia.net> for ; Mon, 1 Nov 2004 12:58:48 -0500 Message-Id: <6.0.3.0.0.20041101123154.02265a08@mail.dc2.adelphia.net> X-Sender: ababurko@mail.dc2.adelphia.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 01 Nov 2004 12:58:47 -0500 To: freebsd-ipfw@freebsd.org From: Bob Ababurko Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: assistance dummynet config(need efficiency) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2004 17:58:51 -0000 Hello all- WHat I am trying to accomplish with this dummynet config is give priority to udp traffic, namely dns and tcp ack's so that I can send mail to our clients announcement list, as fast and efficient as possible without congestion. So basically, I need this machine to ba able to make dns lookups with out a problem and I need the acks to get back to my machine so that the SMTP conversation can take place with out latency. I am not sure if I have taken all that I need into consideration, but for now I could use some constructive criticism in terms of making it better. Using FreeBSD 5.2.1, I have: /etc/sysctl.conf : net.inet.ip.fw.one_pass=0 /etc/rc.conf : firewall_enable="YES" firewall_script="/etc/rc.dummynet" firewall_type="open" firewall_logging="YES" /etc/rc.dummynet : ipfw -f flush ipfw pipe 1 config bw 300kbits/s ipfw queue 1 config pipe 1 weight 100 ipfw queue 2 config pipe 1 weight 1 mask all ipfw add 100 queue 1 udp from any to any out via fxp0 ipfw add 101 skipto 1000 udp from any to any out via fxp0 ipfw add 110 queue 1 tcp from any to any out via fxp0 tcpflags ack ipfw add 111 skipto 1000 tcp from any to any out via fxp0 tcpflags ack ipfw add queue 2 ip from any to any out via fxp0 ipfw add 1000 allow all from any to any Can I make this better or am I even on the right road?? Thanks in advance for your help. Regards, Bob From owner-freebsd-ipfw@FreeBSD.ORG Tue Nov 2 10:49:33 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A97D16A4CE for ; Tue, 2 Nov 2004 10:49:33 +0000 (GMT) Received: from sloti.sofia.itdnet.net (sloti.sofia.ITDNet.net [212.116.151.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 0C72C43D4C for ; Tue, 2 Nov 2004 10:49:29 +0000 (GMT) (envelope-from evgeny@sofia.itdnet.net) Received: (qmail 26528 invoked by uid 0); 2 Nov 2004 10:49:25 -0000 Received: from unknown (HELO ?127.0.0.1?) (212.116.151.30) by sloti.sofia.itdnet.net with SMTP; 2 Nov 2004 10:49:25 -0000 Message-ID: <418766FE.50702@sofia.itdnet.net> Date: Tue, 02 Nov 2004 12:52:46 +0200 From: Evgeny Ivanov User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: bandwidth limitations X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2004 10:49:33 -0000 HI all, I have a problem/question. This is something that I cannot explain to myself why it is happening. I have a machine wich acts like a router and traffic shaper for 3 networks. The upstream connection is about 100Mbps and I have 3 networks that must share this connectivity. The schema is something like that: / | net1-nic2| --- | SWITCH | -- | LAN | / / | nic 1| --- cable --- | net1-nic1| / Upstream ISP ---------- |ISP-NIC router / shaper |-- | nic 2| --- wireless link --- | net2-nic1| ---- | net2-nic2| ---- | SWITCH | --- | LAN | \ \ | nic 3| --- cable --- | net3-nic1| --- | net3-nic2 | ---- | SWITCH | --- | LAN | The machine was originaly installed on 4.9 Stable and was upgrated to 4.10. The IPFW is version 2 - because i needed to use the lookup tables and the autonic step change. I use the lookup tables to split the trafffic ( received from IPS for the 3 nets ) into 2 flows - a local one and international. I am doing that by describing the networks into table and then using skipto for sending it to different pipes. I dont use queue becaus it is not working quite well with ipfw2. The rules are like that: 00005 180161 262752066 skipto 1100 ip from table(1) to net2 out via fxp2 01000 8121 5276242 pipe 1000 ip from any to net2 out via fxp2 01100 180161 262752066 pipe 1100 ip from any to net2 out via fxp2 65535 88428442 64567418299 allow ip from any to any Same is for each other 2 nets. The router/shaper ISP-NIC has no any limitations. All NICs are fxp's. The problem is that I have is that when I load the ipfw rules I cannot use more than 30Mbps received from ISP-NIC. When I flush the rules the speed goes up to 80Mbps. Can anyone give an advice why is that? What should I do to use at least 80Mbps after applying the rules? Thanks in advance -- Evgeny Ivanov Sales Consultant Sofia 1111 28-30 Nikola Kopernik str. tel: +359 02/ 971 26 22 mobile: +359 886 000 321 e-mail: evgeny@sofia.itdnet.net www.itdnet.net From owner-freebsd-ipfw@FreeBSD.ORG Wed Nov 3 06:38:38 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CEB816A4CE for ; Wed, 3 Nov 2004 06:38:38 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57B0943D46 for ; Wed, 3 Nov 2004 06:38:38 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id iA36caPI042650; Tue, 2 Nov 2004 22:38:36 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id iA36cZqI042649; Tue, 2 Nov 2004 22:38:35 -0800 (PST) (envelope-from rizzo) Date: Tue, 2 Nov 2004 22:38:35 -0800 From: Luigi Rizzo To: Pawel Malachowski Message-ID: <20041102223835.B42486@xorpc.icir.org> References: <20041031203558.GA49557@shellma.zin.lublin.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20041031203558.GA49557@shellma.zin.lublin.pl>; 09:35:58PM +0100 cc: freebsd-ipfw@freebsd.org Subject: Re: [PATCH] burstable dummynet pipe X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2004 06:38:38 -0000 On Sun, Oct 31, 2004 at 09:35:58PM +0100, Pawel Malachowski wrote: > Hello, > > Attached (poor) patch (against 5.3-RC1) implements pipes that can be > overloaded (exceed their bw) for a (short) period of time. > It adds yet another parameter for pipe: `burst x', x in (K)Bytes. > Should also work with dynamic (clonable via mask) pipes. > > Configuring `x bytes burst' means we are allowing to transmit x bytes > with increased (by default: ~2x) speed. After that, traffic passes > through pipe as usual (bw-limited), however, burst credit is slowly > (by default: ~10x lower than bw) accumulated when pipe is idle (low to tell the truth, the 2x and 10x thing seems to me a rather kludgy and arbitrary way to implement 'bursts'. The most straightforward way to implement this feature is to let the pipe be "burst" bytes ahead of the programmed rate, which results in a rather trivial change to the current code. If you really want to burst out data and recover credt at a different rate, these extra rates should be configurable. so if someone thinks of committing this patch in the current form, please at least note in the commit log that i am opposed to that. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Wed Nov 3 09:57:09 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7066216A4CE for ; Wed, 3 Nov 2004 09:57:09 +0000 (GMT) Received: from shellma.zin.lublin.pl (shellma.zin.lublin.pl [212.182.126.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE3F643D46 for ; Wed, 3 Nov 2004 09:57:08 +0000 (GMT) (envelope-from pawmal-posting@freebsd.lublin.pl) Received: by shellma.zin.lublin.pl (Postfix, from userid 1018) id D240F3474C1; Wed, 3 Nov 2004 10:57:49 +0100 (CET) Date: Wed, 3 Nov 2004 10:57:49 +0100 From: Pawel Malachowski To: freebsd-ipfw@freebsd.org Message-ID: <20041103095749.GA56028@shellma.zin.lublin.pl> References: <20041031203558.GA49557@shellma.zin.lublin.pl> <20041102223835.B42486@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20041102223835.B42486@xorpc.icir.org> User-Agent: Mutt/1.4.2i Subject: Re: [PATCH] burstable dummynet pipe X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-ipfw@freebsd.org List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2004 09:57:09 -0000 On Tue, Nov 02, 2004 at 10:38:35PM -0800, Luigi Rizzo wrote: Helo, > > Configuring `x bytes burst' means we are allowing to transmit x bytes > > with increased (by default: ~2x) speed. After that, traffic passes > > through pipe as usual (bw-limited), however, burst credit is slowly > > (by default: ~10x lower than bw) accumulated when pipe is idle (low > > to tell the truth, the 2x and 10x thing seems to me a rather > kludgy and arbitrary way to implement 'bursts'. > The most straightforward way to implement this feature is > to let the pipe be "burst" bytes ahead of the programmed rate, > which results in a rather trivial change to the current code. > If you really want to burst out data and recover credt at a > different rate, these extra rates should be configurable. Fully agree, these values are hardcoded because this is a concept preview, and as I wrote, this is a poor patch. It also won't work for pipes connected with WFQ queues (but I'm not too sure if it is worth implementing). > so if someone thinks of committing this patch in the current form, > please at least note in the commit log that i am opposed to that. Commiting it like this is a bad idea. I've posted this here only to see if someone is interested and maybe can pick it up. Since I do not even know C language, I'm not a proper person to implement this. I've made this patchset having two things in mind: . small burst may be a good thing for web users, they just: click, , click, , ... so we can allow them to exceed their bw for few seconds, just to load typical webpage. . bigger burst may be a good thing when limiting per-user upstream usage on assymetric lines, e.g. on 128kbit/512kbit ADSL limit user so one is able to send 64kbit/s up, however, after sending more than x MBytes (e-mail with attachment) his speed will go down to 32kbit/s. regards, -- Paweł Małachowski From owner-freebsd-ipfw@FreeBSD.ORG Wed Nov 3 16:53:43 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71E0A16A4CE for ; Wed, 3 Nov 2004 16:53:43 +0000 (GMT) Received: from iscan1.intra.oki.co.jp (okigate.oki.co.jp [202.226.91.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60CC943D48 for ; Wed, 3 Nov 2004 16:53:42 +0000 (GMT) (envelope-from yamamoto436@oki.com) Received: from aoi.bmc.oki.co.jp (localhost.localdomain [127.0.0.1]) by iscan1.intra.oki.co.jp (8.9.3/8.9.3) with SMTP id BAA31258 for ; Thu, 4 Nov 2004 01:53:41 +0900 Received: (qmail 29282 invoked from network); 4 Nov 2004 01:53:41 +0900 Received: from tulip.bmc.oki.co.jp (172.19.234.100) by aoi.bmc.oki.co.jp with SMTP; 4 Nov 2004 01:53:41 +0900 Received: from localhost (tulip [172.19.234.100]) by tulip.bmc.oki.co.jp (8.13.1/8.12.11) with ESMTP id iA3GrfxL089349; Thu, 4 Nov 2004 01:53:41 +0900 (JST) (envelope-from yamamoto436@oki.com) Date: Thu, 04 Nov 2004 01:53:41 +0900 (JST) Message-Id: <20041104.015341.71171019.yamamoto436@oki.com> To: freebsd-stable@FreeBSD.ORG, freebsd-ipfw@FreeBSD.ORG From: Hideki Yamamoto X-Mailer: Mew version 3.3 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: IPv6 bridge + gif tunnel X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2004 16:53:43 -0000 Hi, I am considering a network application test environments with FreeBSD boxes as following. In the following, we show three step architectures. This is an example for IPv6 VPN using IPv4 network. I would like to use the IPv6 address assigned by IPv6 router on the remote the IPv6 terminal. And the packets from/to IPv6 MC router, which supports MLDv1 or v2 specification, are also transfered to/from the IPv6 terminal. At the first step, I think it seems to be possible by using ipf bridge function. I wonder if it is possible to implement the second step or later. Are there any information about this issue? Any information are welcomed. Thanks in advance. <> Simple IPv6 bridge +------box#1-------------+ [IPv6 MC router ]-+---------+-(fxp0) IPv6 bridge | | | | | +--+-(bge0) IPv6 bridge | | +------------------------+ | | term#1 +-----[IPv6 terminal(NDP client)] <> IPv6 bridge cascaded by gif tunnel +------box#2------------------+ [IPv6 MC router ]-+---------+-(fxp0) IPv6 bridge | | | | | +--+-(bge0) IPv6 bridge and IPv4 | | | (gif0) IPv6 over IPv4 | | +-----------------------------+ | | | +-------box#3-----------------+ +--+-(bge1) IPv6 bridge and IPv4 | | (gif1) IPv6 over IPv4 | | | | | | | +--+-(fxp0) IPv6 bridge | | +-----------------------------+ | | term#2 +-----[IPv6 terminal(NDP client)] <> IPv6 bridge cascaded by gif tunnel with tun device +------box#4------------------+ [IPv6 MC router ]-+---------+-(fxp0) IPv6 bridge | | | | | +--+-(tun0) IPv6 bridge and IPv4 | | | (gif0) IPv6 over IPv4 | | +-----------------------------+ | [PPPoE server] [IPv4 router ] | | +-------box#5-----------------+ +--+-(bge1) IPv6 bridge and IPv4 | | (gif1) IPv6 over IPv4 | | | | | | | +--+-(fxp0) IPv6 bridge | | +-----------------------------+ | | term#3 +-----[IPv6 terminal(NDP client)] P.S. To save network cards and to show the network in detail, I thik that the ideal architecture is as follows: +--------box#6----------------+ [IPv6 router(RA)]-+---------+-(fxp0) IPv6 bridge | [PPPoE server]-+ | (tun0) IPv6 bridge and IPv4 | | | (gif0) IPv6 over IPv4 | | | | | +-----------------------------+ | [IPv4 router ] | | | +--------box#7----------------+ [IPv6 router(RA)]-+---------+-(bge1) IPv6 bridge | [PPPoE server]-+ | (tun1) IPv6 bridge and IPv4 | | (gif1) IPv6 over IPv4 | | | | | +--+-(fxp0) IPv6 bridge | | +-----------------------------+ | | term#4 +-----[IPv6 terminal(NDP client)] ----------------------------------------------------------------- Hideki YAMAMOTO | Broadband Media Solutions Department | E-mail: yamamoto436@oki.com Broadband Media Company | Tel: +81-48-420-7012 Oki Electric Industry Co., Ltd. | FAX: +81-48-420-7016 From owner-freebsd-ipfw@FreeBSD.ORG Wed Nov 3 21:10:16 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B96616A4CE for ; Wed, 3 Nov 2004 21:10:16 +0000 (GMT) Received: from dreadlock.phreakout.net (dreadlock.phreakout.net [12.45.16.51]) by mx1.FreeBSD.org (Postfix) with SMTP id 3689843D45 for ; Wed, 3 Nov 2004 21:10:15 +0000 (GMT) (envelope-from bob@phreakout.net) Received: (qmail 11362 invoked from network); 3 Nov 2004 21:10:36 -0000 Received: from 24-52-224-96.kntnny.adelphia.net (HELO ample.phreakout.net) (24.52.224.96) by dreadlock.phreakout.net with SMTP; 3 Nov 2004 21:10:36 -0000 Message-Id: <6.0.3.0.0.20041103152300.02238ec0@dreadlock.phreakout.net> X-Sender: bob@phreakout.net@dreadlock.phreakout.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 03 Nov 2004 16:10:08 -0500 To: freebsd-ipfw@freebsd.org From: Bob Ababurko In-Reply-To: <6.0.3.0.0.20041101123154.02265a08@mail.dc2.adelphia.net> References: <6.0.3.0.0.20041101123154.02265a08@mail.dc2.adelphia.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: assistance dummynet config X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2004 21:10:16 -0000 At 12:58 PM 11/1/2004, you wrote: >Hello all- > >WHat I am trying to accomplish with this dummynet config is give priority >to udp traffic, namely dns and tcp ack's so that I can send mail to our >clients announcement list, as fast and efficient as possible without >congestion. So basically, I need this machine to ba able to make dns >lookups with out a problem and I need the acks to get back to my machine >so that the SMTP conversation can take place with out latency. I am not >sure if I have taken all that I need into consideration, but for now I >could use some constructive criticism in terms of making it better. > >Using FreeBSD 5.2.1, I have: > >/etc/sysctl.conf : >net.inet.ip.fw.one_pass=0 > >/etc/rc.conf : >firewall_enable="YES" >firewall_script="/etc/rc.dummynet" >firewall_type="open" >firewall_logging="YES" > > >/etc/rc.dummynet : >ipfw -f flush >ipfw pipe 1 config bw 300kbits/s >ipfw queue 1 config pipe 1 weight 100 >ipfw queue 2 config pipe 1 weight 1 mask all >ipfw add 100 queue 1 udp from any to any out via fxp0 >ipfw add 101 skipto 1000 udp from any to any out via fxp0 >ipfw add 110 queue 1 tcp from any to any out via fxp0 tcpflags ack >ipfw add 111 skipto 1000 tcp from any to any out via fxp0 tcpflags ack >ipfw add queue 2 ip from any to any out via fxp0 >ipfw add 1000 allow all from any to any > > >Can I make this better or am I even on the right road?? Thanks in advance >for your help. > >Regards, >Bob > >_______________________________________________ >freebsd-ipfw@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" I find myself responding to my own post....I noted in my initial post that I am using the dummynet on a machine that is sending mail, I am not sure that I need to let it be known, but I am not a spammer and the announcement list is a newsletter for an opt-in list. We do hosting , but we just took on a client that has a newsletter and when it is deploying, the machine that it is on, is totally worthless to the rest of us at the shop. I am wondering why I am not getting any responses from the list and hope that this is the reason and it is not because people do not care, or do not bother to get the list. I am also wondering if there is a way to do any limiting based on alias addresses. I am thinking about putting the DNS, which is the service that we at the office are not able to access while the mail is being sent out on the machine. Is there a way to designate a virtual interface in the dummynet config. I came from a Solaris background and the virtual interface were addressed as hme0:1. I know that FreeBSD does not use this notation, but is there a way to make rules for additional virtual interface or aliases? Thanks for the help in advance? I hope. peace, Bob From owner-freebsd-ipfw@FreeBSD.ORG Wed Nov 3 22:18:29 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9ADA316A4CF; Wed, 3 Nov 2004 22:18:29 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7637243D53; Wed, 3 Nov 2004 22:18:29 +0000 (GMT) (envelope-from csjp@freebsd.org) Received: from freefall.freebsd.org (csjp@localhost [127.0.0.1]) iA3MIT3O060466; Wed, 3 Nov 2004 22:18:29 GMT (envelope-from csjp@freebsd.org) Received: (from csjp@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id iA3MIT0Q060465; Wed, 3 Nov 2004 22:18:29 GMT (envelope-from csjp@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: csjp set sender to csjp@freebsd.org using -f Date: Wed, 3 Nov 2004 22:18:29 +0000 From: "Christian S.J. Peron" To: ipfw@freebsd.org Message-ID: <20041103221829.GA60132@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i cc: current@freebsd.org cc: net@freebsd.org Subject: [PATCH] testers wanted X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2004 22:18:29 -0000 I have generated a patch which appears to solve the lock ordering issues associated with ucred based filtering which results in hard locks (while mpsafenet=1). This patch basically implements a shared locking mechanism. http://people.freebsd.org/~csjp/ip_fw2.c.1099500281.diff It would be appriciated if interested parties could download it, load a large number of rules and try to manipulate (delete/add) rules under high loads. Thanks! -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer From owner-freebsd-ipfw@FreeBSD.ORG Sat Nov 6 15:50:02 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58CC016A4CE for ; Sat, 6 Nov 2004 15:50:02 +0000 (GMT) Received: from smtpauth08.mail.atl.earthlink.net (smtpauth08.mail.atl.earthlink.net [209.86.89.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FB1643D31 for ; Sat, 6 Nov 2004 15:50:02 +0000 (GMT) (envelope-from martes.wigglesworth@earthlink.net) Received: from [213.209.169.198] (helo=[192.168.1.50]) by smtpauth08.mail.atl.earthlink.net with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1CQSpD-0003pB-BM for freebsd-ipfw@freebsd.org; Sat, 06 Nov 2004 10:50:01 -0500 From: Martes Wigglesworth To: ipfw-mailings Content-Type: text/plain Organization: Wiggtekmicro Corporation Message-Id: <1099756198.703.4.camel@Mobile1.276NET> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 06 Nov 2004 18:49:58 +0300 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 532caf459ba90ce6996df0496707a79d9bea09fe345ed53d9ef193a6bfc3dd486784e266ebcab6c1b557441a8a6228378093ec8fa1ef8ec6350badd9bab72f9c X-Originating-IP: 213.209.169.198 Subject: More specific diverting rules... X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: martes.wigglesworth@earthlink.net List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2004 15:50:02 -0000 Greetings list. I am trying to explore the abilities of ipfw to divert more specific traffic patterns. Has anyone been able to successfully divert only specific entities to the outside word, and only specific replies, as follows: divert natd ip from ${int_net} to any out xmit ${ext_dev} divert natd ip from any to ${int_net} in recv ${ext_dev} I have not read a good explanation of what the significance of the divert address/device, is. Does the interface in the last example have to be the external device, or do I need to designate the internal address that the int_net is running on, within the natd machine? Any help would be splended. Thanks. -- Respectfully, M.G.W. System: Asus M6N Intel Dothan 1.7 512MB RAM 40GB HD 10/100/1000 NIC Wireless b/g (not working yet) BSD-5.2.1 GCC-3.3.5/3.3.3(until I replace indigenous gcc) IFORT-for linux(Intell Fortran) gfortran python-2.3 Perl-5.6.1/5.8.5 Java-sdk-1.4.2_5 KDE-3.1.4 From owner-freebsd-ipfw@FreeBSD.ORG Sat Nov 6 21:15:51 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96EF216A4CF for ; Sat, 6 Nov 2004 21:15:51 +0000 (GMT) Received: from iscan1.intra.oki.co.jp (okigate.oki.co.jp [202.226.91.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id E496343D4C for ; Sat, 6 Nov 2004 21:15:49 +0000 (GMT) (envelope-from yamamoto436@oki.com) Received: from aoi.bmc.oki.co.jp (localhost.localdomain [127.0.0.1]) by iscan1.intra.oki.co.jp (8.9.3/8.9.3) with SMTP id GAA27525 for ; Sun, 7 Nov 2004 06:15:48 +0900 Received: (qmail 7810 invoked from network); 7 Nov 2004 06:15:48 +0900 Received: from tulip.bmc.oki.co.jp (172.19.234.100) by aoi.bmc.oki.co.jp with SMTP; 7 Nov 2004 06:15:48 +0900 Received: from localhost (tulip [172.19.234.100]) by tulip.bmc.oki.co.jp (8.13.1/8.12.11) with ESMTP id iA6LFmZv098608; Sun, 7 Nov 2004 06:15:48 +0900 (JST) (envelope-from yamamoto436@oki.com) Date: Sun, 07 Nov 2004 06:15:47 +0900 (JST) Message-Id: <20041107.061547.71182690.yamamoto436@oki.com> To: freebsd-stable@freebsd.org, freebsd-ipfw@freebsd.org From: Hideki Yamamoto In-Reply-To: <20041104.015341.71171019.yamamoto436@oki.com> References: <20041104.015341.71171019.yamamoto436@oki.com> X-Mailer: Mew version 3.3 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: IPv6 bridge + gif tunnel X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2004 21:15:51 -0000 Hi, I would like to make my problems clear. I have two questions about bridge function in the following figure. (1) Can we use bridge function over psuedo devices such as gif and tun? box3# ifconfig bge0 inet 133.149.0.2 netmask 255.255.255.0 box2# ifconfig create gif0 box2# gifconfig gif0 inet 133.149.0.2 133.149.1.2 box2# sysctl net.link.ether.bridge: 1 box2# sysctl net.link.ether.bridge_cfg: fxp0,gif0 box3# ifconfig bge1 inet 133.149.1.2 netmask 255.255.255.0 box3# ifconfig create gif1 box3# gifconfig gif1 inet 133.149.1.2 133.149.0.2 box3# sysctl net.link.ether.bridge: 1 box3# sysctl net.link.ether.bridge_cfg: gif1,fxp0 (2) Can any protocols go through between IPv6 MC router and IPv6 terminal in this step2 figure? Are there any limitations? Is IPv6 packet available? > <> IPv6 bridge cascaded by gif tunnel > > +------box#2------------------+ > [IPv6 MC router ]-+---------+-(fxp0) IPv6 bridge | > | | > | | > (IPv4)133.149.0.2 +--+-(bge0) IPv6 bridge and IPv4 | > | | (gif0) IPv6 over IPv4 | > | +-----------------------------+ > | > > | > | +-------box#3-----------------+ > (IPv4)133.149.1.2 +--+-(bge1) IPv6 bridge and IPv4 | > | (gif1) IPv6 over IPv4 | > | | > | | > | | > +--+-(fxp0) IPv6 bridge | > | +-----------------------------+ > | > | term#2 > +-----[IPv6 terminal(NDP client)] > Thanks in advance Hidei Yamamoto From: Hideki Yamamoto Subject: IPv6 bridge + gif tunnel Date: Thu, 04 Nov 2004 01:53:41 +0900 (JST) Message-ID: <20041104.015341.71171019.yamamoto436@oki.com> > > Hi, > > I am considering a network application test environments with FreeBSD > boxes as following. In the following, we show three step > architectures. This is an example for IPv6 VPN using IPv4 network. I would > like to use the IPv6 address assigned by IPv6 router on the remote the > IPv6 terminal. And the packets from/to IPv6 MC router, which supports > MLDv1 or v2 specification, are also transfered to/from the IPv6 > terminal. > > At the first step, I think it seems to be possible by using ipf bridge > function. I wonder if it is possible to implement the second step or > later. Are there any information about this issue? Any information > are welcomed. Thanks in advance. > > <> Simple IPv6 bridge > +------box#1-------------+ > [IPv6 MC router ]-+---------+-(fxp0) IPv6 bridge | > | | > | | > +--+-(bge0) IPv6 bridge | > | +------------------------+ > | > | term#1 > +-----[IPv6 terminal(NDP client)] > > > <> IPv6 bridge cascaded by gif tunnel > > +------box#2------------------+ > [IPv6 MC router ]-+---------+-(fxp0) IPv6 bridge | > | | > | | > +--+-(bge0) IPv6 bridge and IPv4 | > | | (gif0) IPv6 over IPv4 | > | +-----------------------------+ > | > > | > | +-------box#3-----------------+ > +--+-(bge1) IPv6 bridge and IPv4 | > | (gif1) IPv6 over IPv4 | > | | > | | > | | > +--+-(fxp0) IPv6 bridge | > | +-----------------------------+ > | > | term#2 > +-----[IPv6 terminal(NDP client)] > > > <> IPv6 bridge cascaded by gif tunnel with tun device > > +------box#4------------------+ > [IPv6 MC router ]-+---------+-(fxp0) IPv6 bridge | > | | > | | > +--+-(tun0) IPv6 bridge and IPv4 | > | | (gif0) IPv6 over IPv4 | > | +-----------------------------+ > | > [PPPoE server] > [IPv4 router ] > | > | +-------box#5-----------------+ > +--+-(bge1) IPv6 bridge and IPv4 | > | (gif1) IPv6 over IPv4 | > | | > | | > | | > +--+-(fxp0) IPv6 bridge | > | +-----------------------------+ > | > | term#3 > +-----[IPv6 terminal(NDP client)] > > P.S. To save network cards and to show the network in detail, > I thik that the ideal architecture is as follows: > > +--------box#6----------------+ > [IPv6 router(RA)]-+---------+-(fxp0) IPv6 bridge | > [PPPoE server]-+ | (tun0) IPv6 bridge and IPv4 | > | | (gif0) IPv6 over IPv4 | > | | | > | +-----------------------------+ > | > [IPv4 router ] > | > | > | +--------box#7----------------+ > [IPv6 router(RA)]-+---------+-(bge1) IPv6 bridge | > [PPPoE server]-+ | (tun1) IPv6 bridge and IPv4 | > | (gif1) IPv6 over IPv4 | > | | > | | > +--+-(fxp0) IPv6 bridge | > | +-----------------------------+ > | > | term#4 > +-----[IPv6 terminal(NDP client)] > ----------------------------------------------------------------- > Hideki YAMAMOTO | > Broadband Media Solutions Department | E-mail: yamamoto436@oki.com > Broadband Media Company | Tel: +81-48-420-7012 > Oki Electric Industry Co., Ltd. | FAX: +81-48-420-7016 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" ----------------------------------------------------------------- Hideki YAMAMOTO | Broadband Media Solutions Department | E-mail: yamamoto436@oki.com Broadband Media Company | Tel: +81-48-420-7012 Oki Electric Industry Co., Ltd. | FAX: +81-48-420-7016