netgraph and high availability(bonding) problem
Hi at all
I have some problem to configure two network card in high availabilty mode.
I have done many test with some configurations but I desn't work. I have
Freebsd 5.2.1 and I have also add a patch realized from Evgeny Dolgopiat
about ng_one2many.c and ng_one2many.h. Test n.1 (with 2 cards on single
switch(yes, i know that is not a best ha solution)
In this case I have had packets duplication but I have HA to get or put a
net cable. Test n2. (with 2 cards on differnet switch) In this case I have
not packets duplication but I haven't HA to get or put a net cable: if I get
a secondary cable It works but if I get the primary cable it doesn't work
all. This the configuration that I have testes:
#from README of ng_one2many patch
#!/bin/sh
#Build ng_one2many module
kldload /usr/src/sys/modules/netgraph/one2many/ng_one2many.ko
#Stat about module
kldstat
#Create one pseudo interface
ngctl mkpeer xl0: one2many upper many
#Assegno il nome xl0 al nodo o2m
ngctl name xl0: upper o2m
#Creo un link tra xl0 e o2m usando many0
ngctl connect xl0: o2m: lower many0
#Creo un link tra xl1 e o2m usando many1
ngctl connect xl1: o2m: lower many1
#Metto in promisc mode xl1
ngctl msg xl1: setpromisc 1
#Metto xl1 in autosrc=0
ngctl msg xl1: setautosrc 0
ifconfig xl0 inet 192.168.168.239 netmask 255.255.255.0
ngctl msg o2m: setconfig { xmitAlg=1 failAlg=2 } # set heartbit algo
ngctl msg o2m: sethbconfig { timeout=2 period=3 } # set time between
ngctl list
route add default 192.168.168.220
___
#IDS:port bonding and taps
#in etherchannel ok
#
#!/bin/sh
kldload /usr/src/sys/modules/netgraph/fec/ng_fec.ko
kldstat
ngctl list
ngctl mkpeer fec dummy fec
ngctl msg fec0: add_iface 'xl0'
ngctl msg fec0: add_iface 'xl1'
ngctl msg fec0: set_mode_inet
ngctl msg fec0: set_mode_mac
ngctl msg fec0: set_mode_inet6
ngctl list
ifconfig fec0 promisc
ifconfig fec0 up
ifconfig fec0 inet 192.168.168.239 netmask 255.255.255.0
route add default 192.168.168.220
__
#!/bin/sh
kldload /usr/src/sys/modules/netgraph/ether/ng_ether.ko
kldload /usr/src/sys/modules/netgraph/one2many/ng_one2many.ko
kldstat
ngctl list
ifconfig xl0 promisc -arp up
ifconfig xl1 promisc -arp up
ngctl mkpeer . eiface hook ether
ngctl mkpeer ngeth0: one2many lower one
ngctl connect xl0: ngeth0:lower lower many0
ngctl connect xl1: ngeth0:lower lower many1
ngctl list
ifconfig ngeth0 up
ifconfig ngeth0 inet 192.168.168.239 netmask 255.255.255.0 ifconfig -a route
add default 192.168.168.220 _
#Taosecurity
#!/bin/sh
kldload /usr/src/sys/modules/netgraph/ether/ng_ether.ko
kldstat
ifconfig xl0 promisc -arp up
ifconfig xl1 promisc -arp up
ngctl mkpeer . eiface hook ether
ngctl mkpeer ngeth0: one2many lower one
ngctl connect xl0: ngeth0: lower lower many0
ngctl connect xl1: ngeth0: lower lower many1
ngctl list
ifconfig ngeth0 -arp up
ifconfig ngeth0 inet 192.168.168.239 netmask 255.255.255.0 ifconfig -a route
add default 192.168.168.220
#Taosecurity modified 30/07/04
#!/bin/sh
kldload /usr/src/sys/modules/netgraph/ether/ng_ether.ko
kldstat
ifconfig xl0 promisc -arp up
ifconfig xl1 -arp up
ngctl mkpeer . eiface hook ether
ngctl mkpeer ngeth0: one2many lower one
ngctl connect xl0: ngeth0: lower lower many0
ngctl connect xl1: ngeth0: lower lower many1
ngctl list
ifconfig ngeth0 -arp up
ifconfig ngeth0 inet 192.168.168.239 netmask 255.255.255.0 route add default
192.168.168.220 ifconfig -a
Any suggetion.
Maurizio
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
Networking/Security Question...
Hello. My first post here, Hope you're all well and enjoying the summer. Okay, this is likely to be an extremely exhaustive post, so I'd really be grateful if you could spare the time to read and reply please... Let me first introduce you to the scenario. We are a not for profit organisation that I'm dealing with during free time. We have fortunately (as it's Internet based) had funds to get a Leased Line - after about a year of negotiating with various UK providers, we finally got the price completely down - although still scarily high as we're a not for profit. As mentioned, I do this in my spare time, and do not lie I have expertise in this field. However, I have researched, and compiled a very simple step by step guide of what I *think* I should be doing to a) install the Leased Line and get it working, and b) secure the network. Please have a look through and comment on whether you agree, or where I've completely gone wrong. The Leased Line is due to be installed in a few weeks time, so basically I want to have a completely clear set of instructions and knowing I'm doing everything right so I'm not stumped when the time comes! Okay... 1. Obviously complete the process to get the Leased Line. The will consist of 2 visits to the presmise, one to install an NTU and the other to install the circuit. 2. The router will come preconfigured - not quite sure what that exactly involves. The router itself will be a Cisco 1721. As I want to perhaps support up 4 or 5 PC's through the connection my new ISP's response regarding it was: The 1721 will allow as many PC's as you wish to connect. The machines would need to be networking together but the whole network can be given access by a single router. With regards to IP's we will allocate a block of 8 IP's with the leased line. These could be assigned to individual machines (one will be needed for the router). To achieve this, as I'd ideally like each machine to have a public internet address. To explain myself: PC1: 211.167.0.1 -- running a HTTPD. -- running FreeBSD. PC2: 211.167.0.2 -- running a mail daemon. -- running FreeBSD. PC3: 211.167.0.3 -- just internet access. -- running XP. PC4: 211.167.0.4 -- again internet access. -- running XP. PC5: 211.167.0.5 -- internet access through a Netgear HE102 Access Point and Netgear HA501 PC card. -- running XP. I have no idea what the IPs would be, but I'm sure you'll get the point I'm trying to make... Therefore to achieve that, I'll need to purcahse a Switch that would plug into the Router itself. I want to use an External Switch to link all the PC's to the connection. With advice from some people, it seems people prefer Swithces to Hubs because it only directs data when it's needed. Are you able to recommend a decent 8 port external switch that'd be suited? I searched sites like dabs.com and there's just so many, I don't which are suitable. 3. This switch would need to be connected to the Router with a Cat5 cable - could you advise what port it'd go into? I tried reading the guide at http://www.cisco.com/univercd/cc/td...hig/1721ovw.htm about the Ethernet, Auxilary, and Console port, and I *think* it's the Auxiliry one? Is the Ethernet port used to actually connect the router to the NTU? 4. Each PC wanting to access the connection, including 3 PC's and one laptop would need to do the following: 2 x FreeBSD servers would need a Cat5 cable from an Ethernet card in the Boxes to the Switch. 1 x Windows machine would need a Cat5 cable from an Ethernet card in the box to the switch. 1 x Laptop (Netgear HE102 Access Point) talking to a HA501 PC card on the Laptop. In the FreeBSD machines, I'd need to use the following in /etc/rc.conf: ifconfig_sis0=inet the.ip.here netmask 255.255.255.0 where sis0 is the Ethernet in that particular machine, the.ip.here the public IP assigned to me by the ISP (I'll be getting a block of them) and ensure /etc/hosts and /etc/resolv.conf are all set. I'd also need to repeat this on the 2 Windows machines, though their setup is very simple... Do you agree this is the right idea for the actual network setup? Now my questions begin regarding security for the services in particular. Would it be sufficient to just run IPFW rules on each of the FreeBSD servers, and software firewalls on the Windows machines? Or, could you recommend a Hardware Firewall that and how it'd integrate into the above setup please? For the FreeBSD machines I thought the following fules (again researching to find these - but I may very well be incorrect): # Define the firewall command (as in /etc/rc.firewall) for easy # reference. Helps to make it easier to read. fwcmd=/sbin/ipfw # Force a flushing of the current rules before we reload. $fwcmd -f flush # Allow all connections that have dynamic rules built for them, # but deny established connections that don't have a dynamic rule. # See ipfw(8) for details. $fwcmd add check-state $fwcmd add pass tcp from any to any
Re: uma_zcreate() call from kern_mbuf.c - bug?
Brian Somers [EMAIL PROTECTED] wrote: Of course m_get() et. al. seem to manage to get MSIZE aligned pointers back from uma_zalloc_arg(zone_mbuf...) anyway, but surely that's an implementation side effect and the align argument should be corrected. This change looks right to me, but I'm hardly an expert here. There should probably also be a KASSERT here to ensure that MSIZE is sane This might be better as a CTASSERT: Index: kern_mbuf.c === RCS file: /ref/cvsf/src/sys/kern/kern_mbuf.c,v retrieving revision 1.3 diff -u -r1.3 kern_mbuf.c --- kern_mbuf.c 2 Aug 2004 00:18:35 - 1.3 +++ kern_mbuf.c 10 Sep 2004 06:53:10 - @@ -123,6 +123,9 @@ static voidmb_reclaim(void *); static voidmbuf_init(void *); +/* Ensure that MSIZE doesn't break dtom(). */ +CTASSERTMSIZE - 1) ^ MSIZE) + 1) 1 == MSIZE); + /* * Initialize FreeBSD Network buffer allocation. */ @@ -135,7 +138,7 @@ * Configure UMA zones for Mbufs, Clusters, and Packets. */ zone_mbuf = uma_zcreate(Mbuf, MSIZE, mb_ctor_mbuf, mb_dtor_mbuf, - NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_MAXBUCKET); + NULL, NULL, MSIZE - 1, UMA_ZONE_MAXBUCKET); zone_clust = uma_zcreate(MbufClust, MCLBYTES, mb_ctor_clust, mb_dtor_clust, NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_REFCNT); if (nmbclusters 0) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: uma_zcreate() call from kern_mbuf.c - bug?
Brian Somers [EMAIL PROTECTED] wrote: Of course m_get() et. al. seem to manage to get MSIZE aligned pointers back from uma_zalloc_arg(zone_mbuf...) anyway, but surely that's an implementation side effect and the align argument should be corrected. This change looks right to me, but I'm hardly an expert here. There should probably also be a KASSERT here to ensure that MSIZE is sane This might be better as a CTASSERT: Index: kern_mbuf.c === RCS file: /ref/cvsf/src/sys/kern/kern_mbuf.c,v retrieving revision 1.3 diff -u -r1.3 kern_mbuf.c --- kern_mbuf.c 2 Aug 2004 00:18:35 - 1.3 +++ kern_mbuf.c 10 Sep 2004 06:53:10 - @@ -123,6 +123,9 @@ static void mb_reclaim(void *); static void mbuf_init(void *); +/* Ensure that MSIZE doesn't break dtom(). */ +CTASSERTMSIZE - 1) ^ MSIZE) + 1) 1 == MSIZE); + /* * Initialize FreeBSD Network buffer allocation. */ @@ -135,7 +138,7 @@ * Configure UMA zones for Mbufs, Clusters, and Packets. */ zone_mbuf = uma_zcreate(Mbuf, MSIZE, mb_ctor_mbuf, mb_dtor_mbuf, - NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_MAXBUCKET); + NULL, NULL, MSIZE - 1, UMA_ZONE_MAXBUCKET); zone_clust = uma_zcreate(MbufClust, MCLBYTES, mb_ctor_clust, mb_dtor_clust, NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_REFCNT); if (nmbclusters 0) Agreed. I didn't know about CTASSERT()! Cheers. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org [EMAIL PROTECTED] Don't _EVER_ lose your sense of humour ! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VoIP and IPFW
On 2004-09-08T16:29:50-0400, Forrest Aldrich wrote:
Hi there,
I'm considering testing the Vonage service, with my FreeBSD-4.10 system
(maybe 5 or 6).
I wonder if anyone here has a configuration they can share, or if there
are any pages out there that detail the proper (and secure) setup.
Sure! I am using IPFW2+NATD and the following (partial) configuration
works well for me...
--8---
vonage_ata=10.0.0.192
ipfw pipe 2 config bw 200Kbit/s
ipfw pipe 4 config bw 200Kbit/s
ipfw pipe 6 config bw 99800Kbit/s
ipfw pipe 8 config bw 384Kbit/s
ipfw queue 20 config weight 100 pipe 2
ipfw queue 40 config weight 100 pipe 4
ipfw queue 60 config weight 5 pipe 6
ipfw queue 80 config weight 5 pipe 8
${fwcmd} add pass udp from ${vonage_ata} to any in recv ${lan_if}
${fwcmd} add queue 40 udp from ${wan_ip} to any src-port 5060-5061 out xmit ${wan_if}
${fwcmd} add queue 40 udp from ${wan_ip} to any src-port 1-2 out xmit ${wan_if}
${fwcmd} add pass udp from any to ${vonage_ata} in recv ${wan_if}
${fwcmd} add queue 20 udp from any to ${vonage_ata} out xmit ${lan_if}
#
${fwcmd} add pass udp from ${vonage_ata} to any dst-port 53 in recv ${lan_if}
${fwcmd} add queue 80 udp from ${wan_ip} to any dst-port 53 out xmit ${wan_if}
${fwcmd} add pass udp from any to ${vonage_ata} src-port 53 in recv ${wan_if}
${fwcmd} add queue 60 udp from any to ${vonage_ata} src-port 53 out xmit ${lan_if}
#
${fwcmd} add pass udp from ${vonage_ata} to any dst-port 69 in recv ${lan_if}
${fwcmd} add queue 80 udp from ${wan_ip} to any dst-port 69 out xmit ${wan_if}
${fwcmd} add pass udp from any to ${vonage_ata} src-port 69 in recv ${wan_if}
${fwcmd} add queue 60 udp from any to ${vonage_ata} src-port 69 out xmit ${lan_if}
--8---
I am using this with RoadRunner, which gives me 2Mb/s down and 384kb/s
up, which is why the pipes are configured the way that they are.
Naturally, you would want to change those values to match your up/down
speed. In addition, you need to make sure that you are queueing your
other traffic as well, using queues 60 and 80 for non-VoIP traffic.
I hope that this helps.
--
Mike
perl -e 'print unpack(u,88V]N=%C=\!I;F9O(EN(AE861EG,*);'
pgpqa9P0kEnsJ.pgp
Description: PGP signature
original interface name? (5.*)
Hi, is there a stable way to determine original interface name (before any renaming) in 5.3? I.e. as driver + sequence number? -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: original interface name? (5.*)
On Friday 10 September 2004 21:18, Valentin Nechayev wrote: Hi, is there a stable way to determine original interface name (before any renaming) in 5.3? I.e. as driver + sequence number? From inside the kernel you can use ifnet.if_dname + ifnet.if_dunit, from the userland I don't know if it's possible to get a look at those fields. In any way, I suggest not to do that. ifnet.if_xname is supposed to be *the* name of the interface. There is no such thing as original name. -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpHOvSqJNgRy.pgp Description: signature
Re: original interface name? (5.*)
On Fri, Sep 10, 2004 at 10:18:31PM +0300, Valentin Nechayev wrote: Hi, is there a stable way to determine original interface name (before any renaming) in 5.3? I.e. as driver + sequence number? What do you want it for and where do you want it? I think there were plans to export if_dname and if_dunit via sysctls, but I don't think that ever happened and they aren't really ment to be user visiable. There's also no requirement that (%s%d, if_dname, if_dunit) ever have been the name of the interface (for instance in enhanced cloners such as stf(4) and vlan(4)). -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpZxTjvaFcw3.pgp Description: PGP signature
Re: original interface name? (5.*)
On Fri, Sep 10, 2004 at 09:30:11PM +0200, Max Laier wrote: On Friday 10 September 2004 21:18, Valentin Nechayev wrote: Hi, is there a stable way to determine original interface name (before any renaming) in 5.3? I.e. as driver + sequence number? From inside the kernel you can use ifnet.if_dname + ifnet.if_dunit, from the userland I don't know if it's possible to get a look at those fields. In any way, I suggest not to do that. ifnet.if_xname is supposed to be *the* name of the interface. There is no such thing as original name. Yes, for that matter, the name should not be considered to be a reliable handle to an interface unless you know it won't change. This means it's OK for rc.conf or ifconfig, but not OK for a long running, general purpose monitoring program. In 6-CURRENT, and hopefully 5.3, the correct unique identification of an interface will be its index and the value of ifi_epoch. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpPXWTJyiLfn.pgp Description: PGP signature
Re: original interface name? (5.*)
Fri, Sep 10, 2004 at 21:30:11, max wrote about Re: original interface name? (5.*): Hi, is there a stable way to determine original interface name (before any renaming) in 5.3? I.e. as driver + sequence number? From inside the kernel you can use ifnet.if_dname + ifnet.if_dunit, from the userland I don't know if it's possible to get a look at those fields. In any way, I suggest not to do that. ifnet.if_xname is supposed to be *the* name of the interface. There is no such thing as original name. Having driver name one can determine essential capabilities of the interface, including VLAN support, possibility and allowed style of media specification, etc. Device number among with driver name are enough to determine needed information based on driver information and boot logs. It is pointless to use interface without such information, and it is pointless to do manual logging as the only source. In any way, I suggest not to do that. What about good old principle Tools, not policy? -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
dyn buckets
I have a firewall running 4.10 that handles around 20mbits/sec of traffic and has around 500 ipfw rules. Lately I've noticed that net.inet.ip.fw.curr_dyn_buckets seems to be maxing out. I've increased net.inet.ip.fw.dyn_buckets a few times, but they seem to max out each time. Is there any problem with increasing net.inet.ip.fw.dyn_buckets far beyond the default? (I'm at 2048 now) -Glenn ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: dyn buckets
From: [EMAIL PROTECTED] I have a firewall running 4.10 that handles around 20mbits/sec of traffic and has around 500 ipfw rules. Lately I've noticed that net.inet.ip.fw.curr_dyn_buckets seems to be maxing out. I've increased net.inet.ip.fw.dyn_buckets a few times, but they seem to max out each time. Is there any problem with increasing net.inet.ip.fw.dyn_buckets far beyond the default? (I'm at 2048 now) I use net.inet.ip.fw.dyn_buckets=16384 net.inet.ip.fw.dyn_syn_lifetime=5 net.inet.ip.fw.dyn_max=32000 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: original interface name? (5.*)
On Fri, Sep 10, 2004 at 10:46:42PM +0300, Valentin Nechayev wrote: Fri, Sep 10, 2004 at 21:30:11, max wrote about Re: original interface name? (5.*): Hi, is there a stable way to determine original interface name (before any renaming) in 5.3? I.e. as driver + sequence number? From inside the kernel you can use ifnet.if_dname + ifnet.if_dunit, from the userland I don't know if it's possible to get a look at those fields. In any way, I suggest not to do that. ifnet.if_xname is supposed to be *the* name of the interface. There is no such thing as original name. Having driver name one can determine essential capabilities of the interface, including VLAN support, possibility and allowed style of media specification, etc. The output of ifconfig -m contains this information. Device number among with driver name are enough to determine needed information based on driver information and boot logs. It is pointless to use interface without such information, and it is pointless to do manual logging as the only source. This is a better reason, but if you want the logs to make sense, you will have to be aware of changes. Hmm, we may want to log(9) renames. I'm considering adding an ifconfig -v option that would imply -m and add more details like index, epoch, dname, dunit, etc. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgphHUrJH8noQ.pgp Description: PGP signature
Re: original interface name? (5.*)
Fri, Sep 10, 2004 at 12:58:26, brooks wrote about Re: original interface name? (5.*): Device number among with driver name are enough to determine needed information based on driver information and boot logs. It is pointless to use interface without such information, and it is pointless to do manual logging as the only source. This is a better reason, but if you want the logs to make sense, you will have to be aware of changes. Hmm, we may want to log(9) renames. I'm considering adding an ifconfig -v option that would imply -m and add more details like index, epoch, dname, dunit, etc. Well, both ideas (logging renames and a switch to print more info) are highly pleasant. Thanks in advance for implementation. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: original interface name? (5.*)
Brooks Davis wrote: I'm considering adding an ifconfig -v option that would imply -m and add more details like index, epoch, dname, dunit, etc. That would be great! -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: original interface name? (5.*)
On Fri, 10 Sep 2004 22:05:02 +0200, Andre Oppermann [EMAIL PROTECTED] said: Brooks Davis wrote: I'm considering adding an ifconfig -v option that would imply -m and add more details like index, epoch, dname, dunit, etc. That would be great! A particularly relevant feature would give `ifconfig' an option to emit the current configuration of the interface in a form which would be acceptable on the `ifconfig' command line. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [TEST/REVIEW] Netflow implementation
Gleb Smirnoff wrote: Dumping to SQL is a bad idea. I have tried it, too :) Certainly dumping to MySQL is typically wretched ... to a real database much less so. --ckg ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [TEST/REVIEW] Netflow implementation
On Fri, Sep 10, 2004 at 05:32:22PM -0400, Clark Gaylord wrote: Certainly dumping to MySQL is typically wretched ... to a real database much less so. works just fine if you aggregate the flows and build lookup tables instead of just dumping raw flows straight into a database. i think it's great that a freebsd netflow implementation exists, it's just a shame that you have to configure netkitchensink to use it.. -- - bill fumerola / [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
packet generator
Does anybody have a free, in-kernel tool to generate packets quicky and send them out a particular etherent interface on FreeBSD? Something similar to pktgen on linux? I'm trying to excersize just the send-side of programmable firmware based NIC. The recieve side of the NIC firmware is not yet written, but I want to get started tuning and shaking the bugs out of the send side while the firmware author does the recieve path. The packets just get dropped on the floor by the NIC, so its a good way to test the interface.. I can add an arp entry and ping -l HUGEVAL, but that only generates 205K pkts/sec (where *think* I see 1.1 million pkts/sec with pktgen on linux, but I'm not sure I trust it). Thanks, Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: packet generator
Andrew Gallatin wrote: Does anybody have a free, in-kernel tool to generate packets quicky and send them out a particular etherent interface on FreeBSD? Something similar to pktgen on linux? I'm trying to excersize just the send-side of programmable firmware based NIC. The recieve side of the NIC firmware is not yet written, but I want to get started tuning and shaking the bugs out of the send side while the firmware author does the recieve path. The packets just get dropped on the floor by the NIC, so its a good way to test the interface.. I can add an arp entry and ping -l HUGEVAL, but that only generates 205K pkts/sec (where *think* I see 1.1 million pkts/sec with pktgen on linux, but I'm not sure I trust it). netgraph/ng_source.c Doesn't have a man page though. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: packet generator
yes ther e is a netgraph source ng_source from memory.. Andrew Gallatin wrote: Does anybody have a free, in-kernel tool to generate packets quicky and send them out a particular etherent interface on FreeBSD? Something similar to pktgen on linux? I'm trying to excersize just the send-side of programmable firmware based NIC. The recieve side of the NIC firmware is not yet written, but I want to get started tuning and shaking the bugs out of the send side while the firmware author does the recieve path. The packets just get dropped on the floor by the NIC, so its a good way to test the interface.. I can add an arp entry and ping -l HUGEVAL, but that only generates 205K pkts/sec (where *think* I see 1.1 million pkts/sec with pktgen on linux, but I'm not sure I trust it). Thanks, Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: packet generator
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Andrew Gallatin Sent: September 10, 2004 19:08 PM To: [EMAIL PROTECTED] Subject: packet generator Does anybody have a free, in-kernel tool to generate packets quicky and send them out a particular etherent interface on FreeBSD? Something similar to pktgen on linux? I'm trying to excersize just the send-side of programmable firmware based NIC. The recieve side of the NIC firmware is not yet written, but I want to get started tuning and shaking the bugs out of the send side while the firmware author does the recieve path. The packets just get dropped on the floor by the NIC, so its a good way to test the interface.. ng_source was a netgraph module we wrote and contributed. It can transmit ~800Kpps on a PCI-X system. The code is in src/sys/netgraph/ng_source.c. I drive it with a tcl library that can create arbitrary packets with an object-oriented model, let me know if you'd like to try that. --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
