Hi, I'abouto install Fedora to be able to use NetEm for WAN simuation. Which versioof Fedora would you recommend (or is therany you *don't* recommend) using iterms of bug fixes/known issues? Thanks, Marit -------------- nexpar-------------- AHTML attachmenwas scrubbed... URL: http://lists.linux-foundation.org/pipermail/netem/attachments/20090202/df99e0cf/attachment.ht Frodavid alinuxfoundation.org Tue Feb 3 09:04:26 2009 From: david alinuxfoundation.org (David Ames) Date: Tue, 3 Feb 2009 09:04:26 -0800 Subject: New beta CMS for linuxfoundation.org Message-ID: <20090203170425.GB16583@xxxxxxxxxxxxxxxxxxxx> Warabout to launch our public beta content management system. We wanted to address our work groups first to give you the opportunity to have first access and update content in the new CMS. Log into https://beta.linuxfoundation.org/collaborate/workgroups with your LF account. Thsamaccount you used for wiki. Click oyour respectivgroup and then click Join or Request Membership from the right hand menu options. I will respond to these requests ASAP. Please send me an email if you should be the manager of the group. The manager can decide how the group is configured and handles membership requests. Groups cabin one of the following configurations: Ope- membership requests araccepted immediately. Moderated - membership requests musbapproved. Invitonly - membership musbe created by an administrator. Closed - membership is exclusively managed by aadministrator. Thprimary contentype to utilize for work group content is "Group wiki" this content type will be associated with your group and can be edited by all group members. You can create this content type by clicking on "Create Content in the upper right or Create Group wiki page in the right hand menu. If your group has noyebeen created, please let me know and I will get it setup. I havattached our public beta releasnotification for further details. -- David Ames ThLinux Foundation david alinuxfoundation.org Hello Linux FoundatioCommunity, IFebruary 2009, thLinux Foundation (LF) will release to the public a new beta content management system that will support improved publishing, membership acquisition, workgroup management, and content management using the open source Drupal 6 as our Content Management System (CMS) of choice. The goal of the implementation is to develop a long-term comprehensive CMS solution that will support the growth and sustainability of the foundation's goals, strategies, and growth. The new system will integrate with other LF workgroup and publishing sites. Thintention of this communication is thano stakeholder in the new CMS implementation process be surprised by the content of the beta system, or by the identification of the alternative legacy data that resides in the Wiki. This will be achieved through a multi-step release strategy in which the release process is conducted in a manner that stakeholders have input, and ample time to migrate their respective information into the new system. Thadvantagof this approach is that all stakeholders will have an opportunity to make their data up-to-date and only migrate what is relavant and known during the process. The LF web team will assist and provide technical know-how, training , and support as necessary for the stakeholder to input their workgroup information prior to the public release of the new site, and thereafter. A disadvantage of this approach, however, lies in the possibility that stakeholders may or may not have their entire documentation migrated to the new site prior to launch. The LF web team is aware of this issue, and therefore will keep the old MediaWiki site and data up and accessable by web browsing and search as long as possible to support workgroup migration to the new CMS. Unfortunately, some URLs will change as a result of migration to the new system. New CMS Benefits! * Implemenrobuscontent management system * Focus obranding, usability, and SEO of content * Replacone-off homgrown templates and disparate websites wherever possible * Workgroups havbetter control of content, and access to content * Makieasier for the Linux community to use/reuse the Linux Foundation content Whanow? * Thweb teais readying Phase 1 roll out of the beta site for February 4, 2009 * ContacDan Lopez (dlopez alinuxfoundation.org) or Craig Ross (ccr at linuxfoundation.org) to acknowledge and coordinate migration action items for respective content * Review currenstaging area and contenfor your workgroup * Attend training for thnew systeon [Date TBD] ActioItems: 1. Pleasmigratyour existing content from the existing LF site to http://beta.linuxfoundation.org by February 6, 2009. It's importanthacontent that the public should easily be able to navigate be moved. If you have content that is not up to date, you can simply leave on MediaWiki site and the LF will continue to maintain it at http://wiki.linuxfoundation.org. Please do not create new content on the old site. 2. If you ara workgroup lead, pleascreate a group, invite people, and start building your community on the new site. To coordinate group creation please contact David Ames (david at linuxfoundation.org) no later than February 4, 2009. If you do not do this in a timely fashion your workgroup may not make it to the launch of the site and will have to go up after the site has launched. 3. Any new contenyou'd likto create for your workgroup should be created in the new beta site after February 4, 2009. If you need assistance in getting content created prior to receiving training, please contact Dan (dlopez at linuxfoundation.org) or Craig (ccr at linuxfoundation.org). Your existing LF accounts will work ithnew system. You will also be able to login to your MediaWiki account with the same account to retrieve other information that you mave have stored there. 4. A training sessiofor all interested parties on thnew site will be held on [Date TBD] at 1pm-3pm PST. For questions or feedback on the site, please email webteam at linuxfoundation.org. Taining is not mandatory but is highly recommended. PhasI - Process Steps to RollouSummary * ImplemenDrupal CMS * Contenmigration - firspass * Delegatcontenauthors and owners to LF workgroups * Workgroups to schedultraining with web team * Workgroup contenmigration - second pass * Go-Live Delegatioof Ownership * Workgroup ownership of content * Web teaownership of CMS systeadministration and support * Web teaownership of branding, look and feel, and implementation * Workgroups to coordinatwith web teaabout proper permissions and roles per workgroup Go Live! * Deadlinfor completion of contenmigration Phase 1 is February 6 2009 * Old sitwill remain up throughouthis process, and old data will be available * Flip thswitch on February 2-6 2009 with public PR campaigns announcing thnew site following week * All new contenshould bcreated in the new public beta release of the Drupal CMS system at http://www.linuxfoundation.org February 9, 2009 onward. By March 1 the LF media wiki site will no longer be write accessible, so it's imperative that you create a workgroup account on the new site if you wish to create content on LF web properties. For questions, comments, or suggestions pleascontact: Amanda McPherso- amanda alinuxfoundation.org DaLopez - dlopez alinuxfoundation.org -------------- nexpar-------------- A non-texattachmenwas scrubbed... Name: noavailable Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.linux-foundation.org/pipermail/netem/attachments/20090203/5f329a9f/attachment.pgp FroBob.Oneil aL-3Com.com Wed Feb 11 10:54:02 2009 From: Bob.Oneil aL-3Com.co(Bob.Oneil at L-3Com.com) Date: Wed, 11 Feb 2009 13:54:02 -0500 Subject: Linux Advicon Controlled Bridgbased on MAC Address with Delay and Dropout Message-ID: <8A69033E02ED29419B0F43AD421CEC3A1AB9EC@xxxxxxxxxxxxxxxxxxxxxxxx> I was considering using NetEto perfortwo functions associated with ondirection on a Linux Bridge: 1. Delaying each framby a fixed amount. 2. Unifordropping of a frame. This is for a Red HaEnterprisLinux 4, kernel 2.6. Artherany issues of using NetEm with the Netbridge effort and IPTables? Any recommendations would bappreciated. ISHORT How to I leveragwhais available on the Linux Communcations Stack, either as parof thkernel itself (i.e. ebtables, netbridge, tcc, iptables, etc.) and/or aaddon modul, that allows mto implemena Linux Bridge, with the additional requirement of dropping ouEtherneframes (not bytes) based on a soft setting, and delaying frames (fro4 ms to 10 ms in 1 ms increments) iONE direction only of thbridge? This is for a i386 machine with 2 NICS thawill need to bin promiscuous mode. MORE DETAILS I atrying to determinthe best course of action for an application/scripthaI need to composfor execution under Red HaLinux AS 4.0, Linux Kernel v2.6.x. I hava 386 based Linux machinwith two NICs that acts a bit like a bridge, dispatching frames athData Link Layer (not IP, Layer 3). On the ingress of NIC 1 (eth0), therwill bcertain frames which havmatching MACs thawill be consumed (i.e. passed up thstack). Other frames, with a rangof matching MAC addresses, broadcasand multicast need to bbridged to thother NIC (call iNIC 2, or eth1). Broadcasand Multicast also need to bconsumed, so may hav two destinations, bridged betweeNICs and consumed frothe internal stack. I will need to assign aIP address to thapplication so that it may act as an SNMP agent. Thconversdirection follows a similar pattern based on the MAC address, certaiframes matching a rangof MAC address will bbridged to NIC 1 from NIC 2, ones which match thMAC address of NIC 2 will bconsumed, broadcasand multicast need to be both consumed and forwarded to thegress of NIC 1. Thassignments of thIPs, subnets, and subnet masks is flexible. Now heris thcomplication that deviates from standard Linux kernel behavior. ONLY for frames forwarded/bridged fro NIC 1 to NIC2, therartwo soft settings that dictate the forwarding behavior: 1. Delay - this may rangfrosay 4 ms to 15 ms. Based on this setting, ingress frames oNIC 1 thawill bforwarded on to NIC 2 need to be delayed in the process. Thdelay timing needs to bfairly precise, to thmillisecond if possible, and possibly as low as 4 ms. 2. Drop OuPercentag- ranges from 0 to 100%. Based on this setting, ingress frames oNIC 1 will bdropped based on thpercentage set. The dropout could be a simplunifordropout, so that if thpercentagis set to 25%, 1 in 4 frames will be dropped. Etherneframes forwarded in thopposite direction (eth1 to eth0) do nohavto be delayed or dropped. I atrying to comup with a design that is optimum, and that takes maximuadvantagof what is availablin thLinux kernel (via NetFilter/IPTables/EBTables/TCC/bctrl, etc.) via commands. To slow dowoutgoing traffic, thTunnel Bucket Filter (TBF) seems like a possiblcommand lin solutiofor thdelay requirement. However, of particular concern is thfacthat it is byte based rather thaframbased, and it appears it may not guarantee a uniform pacing of frames to the user specified delay valuwith fidelity. In addition, frothe documenentitled "Linux Advanced Routing & Traffic Control HOWTO", is thquote: "However, duto thdefault 10ms timer resolution of Unix, with 10.000 bits averagpackets, w arlimited to 1mbit/s of peakrate!" This statemenseems to suggesthat the maximum precision for a delay would coma10 ms increments, and iis noclear if a low value, say 4 ms would be possible. For thdropourequirement, perhaps some form of Random Early Drops, although thdropping needs to bpercisaccording to a fixed percentage. The dropping needs to bbased probably on frames rather than bytes. I aconsidering solutions composed of scripting of thLinux kernel to do all thwork entirely, or hybrid approach as required to supplementhLinux kernel with user code as required. I considered using thIPTABLES -j QUEUE method to queucontents matching a MAC address rangto user land queues, wherthey would programatically bdropped or delayed. Perhaps a better fiwould be EPTables thadeals with Etherneframes, However, it would seem these mighbproblematic for frames which havtwo destinations, such as broadcasand multicast, which need to bboth lefon the internal stack and forwarded/bridged to thother NIC. Whereas a purbridgforwards on all content, I also need to maintain aSMNP agent, which will requirthat frames matching thIP assigned to thbridge are allowed to pass up the stack for internal consumption. Forwarding will also blimited to a rangof MAC addresses. Both NICs will need to operatin promiscuous mode. Iis noentirely clear whether or not I can do bridging (brctl) in combinatiowith ebtables/netfilter/iptables/tcc. I may to implemensomform of the Spanning Tree Protocol (STP), and perhaps DHCP to establish thIP for thpseudo-bridge. Thloweslevel alternative that I have considered, the one with the higheslevel of control bupossible thmoscustom coding, is using the PCAPS (libpcap) frame sniffer technology based othlow level NDIS driver, which allows mto gea callback into user land for each frame received by thNIC in promiscuous mode. Using this approach, I would queuor drop frames in a userland application, and thebridge/forward theon to thother NIC based on a custom scheduler thread. This would requirmto queue the frames iuser land, buprovides the highest level of control, and perhaps thfastest forwarding as I would read froonNIC and bridge to the other. I would also leavthframe othstack so it could have two destinations. This technique would allow mto delay frames with a fairly fingrain of precision, budoes not take maximum advantage of the services already provided by thLinux kernel. Interested iwhadesign approach you think will fulfil my goals. Any directioyou can poin min would bmost appreciated. Bob O'Neil -------------- nexpar-------------- AHTML attachmenwas scrubbed... URL: http://lists.linux-foundation.org/pipermail/netem/attachments/20090211/2010e9ed/attachment-0001.ht FroBob.Oneil aL-3Com.com Wed Feb 11 11:14:03 2009 From: Bob.Oneil aL-3Com.co(Bob.Oneil at L-3Com.com) Date: Wed, 11 Feb 2009 14:14:03 -0500 Subject: FW: Linux Advicon Controlled Bridgbased on MAC Address with Delay and Dropout Message-ID: <8A69033E02ED29419B0F43AD421CEC3A1AB9ED@xxxxxxxxxxxxxxxxxxxxxxxx> Assuming I was to do thfollowing, whereth1 is the forwarding queue, would this accomplish thtask of unifordelay and dropout (100 ms and 25% ithexample) in one direction of a network bridge from eth0 to eth1? Is this only applicablto thegress device (eth1), or would this be morappropriatfor the ingress device (eth0)? $ sudo tc qdisc add dev eth1 roonetedelay 100ms loss 25% ________________________________ From: O'Neil, Bob @ CSW-NOVA Sent: Wednesday, February 11, 2009 1:54 PM To: 'netealists.linux-foundation.org' Subject: Linux Advicon Controlled Bridgbased on MAC Address with Delay and Dropout I was considering using NetEto perfortwo functions associated with ondirection on a Linux Bridge: 1. Delaying each framby a fixed amount. 2. Unifordropping of a frame. This is for a Red HaEnterprisLinux 4, kernel 2.6. Artherany issues of using NetEm with the Netbridge effort and IPTables? Any recommendations would bappreciated. ISHORT How to I leveragwhais available on the Linux Communcations Stack, either as parof thkernel itself (i.e. ebtables, netbridge, tcc, iptables, etc.) and/or aaddon modul, that allows mto implemena Linux Bridge, with the additional requirement of dropping ouEtherneframes (not bytes) based on a soft setting, and delaying frames (fro4 ms to 10 ms in 1 ms increments) iONE direction only of thbridge? This is for a i386 machine with 2 NICS thawill need to bin promiscuous mode. MORE DETAILS I atrying to determinthe best course of action for an application/scripthaI need to composfor execution under Red HaLinux AS 4.0, Linux Kernel v2.6.x. I hava 386 based Linux machinwith two NICs that acts a bit like a bridge, dispatching frames athData Link Layer (not IP, Layer 3). On the ingress of NIC 1 (eth0), therwill bcertain frames which havmatching MACs thawill be consumed (i.e. passed up thstack). Other frames, with a rangof matching MAC addresses, broadcasand multicast need to bbridged to thother NIC (call iNIC 2, or eth1). Broadcasand Multicast also need to bconsumed, so may hav two destinations, bridged betweeNICs and consumed frothe internal stack. I will need to assign aIP address to thapplication so that it may act as an SNMP agent. Thconversdirection follows a similar pattern based on the MAC address, certaiframes matching a rangof MAC address will bbridged to NIC 1 from NIC 2, ones which match thMAC address of NIC 2 will bconsumed, broadcasand multicast need to be both consumed and forwarded to thegress of NIC 1. Thassignments of thIPs, subnets, and subnet masks is flexible. Now heris thcomplication that deviates from standard Linux kernel behavior. ONLY for frames forwarded/bridged fro NIC 1 to NIC2, therartwo soft settings that dictate the forwarding behavior: 1. Delay - this may rangfrosay 4 ms to 15 ms. Based on this setting, ingress frames oNIC 1 thawill bforwarded on to NIC 2 need to be delayed in the process. Thdelay timing needs to bfairly precise, to thmillisecond if possible, and possibly as low as 4 ms. 2. Drop OuPercentag- ranges from 0 to 100%. Based on this setting, ingress frames oNIC 1 will bdropped based on thpercentage set. The dropout could be a simplunifordropout, so that if thpercentagis set to 25%, 1 in 4 frames will be dropped. Etherneframes forwarded in thopposite direction (eth1 to eth0) do nohavto be delayed or dropped. I atrying to comup with a design that is optimum, and that takes maximuadvantagof what is availablin thLinux kernel (via NetFilter/IPTables/EBTables/TCC/bctrl, etc.) via commands. To slow dowoutgoing traffic, thTunnel Bucket Filter (TBF) seems like a possiblcommand lin solutiofor thdelay requirement. However, of particular concern is thfacthat it is byte based rather thaframbased, and it appears it may not guarantee a uniform pacing of frames to the user specified delay valuwith fidelity. In addition, frothe documenentitled "Linux Advanced Routing & Traffic Control HOWTO", is thquote: "However, duto thdefault 10ms timer resolution of Unix, with 10.000 bits averagpackets, w arlimited to 1mbit/s of peakrate!" This statemenseems to suggesthat the maximum precision for a delay would coma10 ms increments, and iis noclear if a low value, say 4 ms would be possible. For thdropourequirement, perhaps some form of Random Early Drops, although thdropping needs to bpercisaccording to a fixed percentage. The dropping needs to bbased probably on frames rather than bytes. I aconsidering solutions composed of scripting of thLinux kernel to do all thwork entirely, or hybrid approach as required to supplementhLinux kernel with user code as required. I considered using thIPTABLES -j QUEUE method to queucontents matching a MAC address rangto user land queues, wherthey would programatically bdropped or delayed. Perhaps a better fiwould be EPTables thadeals with Etherneframes, However, it would seem these mighbproblematic for frames which havtwo destinations, such as broadcasand multicast, which need to bboth lefon the internal stack and forwarded/bridged to thother NIC. Whereas a purbridgforwards on all content, I also need to maintain aSMNP agent, which will requirthat frames matching thIP assigned to thbridge are allowed to pass up the stack for internal consumption. Forwarding will also blimited to a rangof MAC addresses. Both NICs will need to operatin promiscuous mode. Iis noentirely clear whether or not I can do bridging (brctl) in combinatiowith ebtables/netfilter/iptables/tcc. I may to implemensomform of the Spanning Tree Protocol (STP), and perhaps DHCP to establish thIP for thpseudo-bridge. Thloweslevel alternative that I have considered, the one with the higheslevel of control bupossible thmoscustom coding, is using the PCAPS (libpcap) frame sniffer technology based othlow level NDIS driver, which allows mto gea callback into user land for each frame received by thNIC in promiscuous mode. Using this approach, I would queuor drop frames in a userland application, and thebridge/forward theon to thother NIC based on a custom scheduler thread. This would requirmto queue the frames iuser land, buprovides the highest level of control, and perhaps thfastest forwarding as I would read froonNIC and bridge to the other. I would also leavthframe othstack so it could have two destinations. This technique would allow mto delay frames with a fairly fingrain of precision, budoes not take maximum advantage of the services already provided by thLinux kernel. Interested iwhadesign approach you think will fulfil my goals. Any directioyou can poin min would bmost appreciated. Bob O'Neil -------------- nexpar-------------- AHTML attachmenwas scrubbed... URL: http://lists.linux-foundation.org/pipermail/netem/attachments/20090211/c540a234/attachment-0001.ht FroBob.Oneil aL-3Com.com Wed Feb 11 12:27:53 2009 From: Bob.Oneil aL-3Com.co(Bob.Oneil at L-3Com.com) Date: Wed, 11 Feb 2009 15:27:53 -0500 Subject: Linux Advicon Controlled Bridgbased on MAC Address with Delay and Dropout Message-ID: <8A69033E02ED29419B0F43AD421CEC3A1AB9EE@xxxxxxxxxxxxxxxxxxxxxxxx> I issued thfollowing commands on eth0, buping does not reveal the 100 ms delay expected, or any significandifferences with thping results prior to issuing thcommand. Any thoughts owhy a local ping tesdoes not reflect the additional 100 ms delay? "sudo tc qdisc add dev eth0 roonetedelay 100 ms" [BobO aMSE ~]$ ifconfig eth0 Link encap:EthernHWaddr 00:23:AE:69:96:81 ineaddr:128.170.150.109 Bcast:128.170.150.255 Mask:255.255.255.0 inet6 addr: fe80::223:aeff:fe69:9681/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:15 errors:0 dropped:0 overruns:0 frame:0 TX packets:19 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:1520 (1.4 KiB) TX bytes:4269 (4.1 KiB) Memory:febe0000-fec00000 eth1 Link encap:EthernHWaddr 00:10:5A:E1:1A:50 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:16 Basaddress:0x8f80 lo Link encap:Local Loopback ineaddr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:12 errors:0 dropped:0 overruns:0 frame:0 TX packets:12 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:800 (800.0 b) TX bytes:800 (800.0 b) [BobO aMSE ~]$ ping 128.170.150.109 PING 128.170.150.109 (128.170.150.109) 56(84) bytes of data. 64 bytes fro128.170.150.109: icmp_seq=1 ttl=64 time=0.053 ms 64 bytes fro128.170.150.109: icmp_seq=2 ttl=64 time=0.042 ms 64 bytes fro128.170.150.109: icmp_seq=3 ttl=64 time=0.026 ms 64 bytes fro128.170.150.109: icmp_seq=4 ttl=64 time=0.018 ms 64 bytes fro128.170.150.109: icmp_seq=5 ttl=64 time=0.022 ms 64 bytes fro128.170.150.109: icmp_seq=6 ttl=64 time=0.017 ms 64 bytes fro128.170.150.109: icmp_seq=7 ttl=64 time=0.018 ms ^C --- 128.170.150.109 ping statistics --- 7 packets transmitted, 7 received, 0% packeloss, tim6689ms rtmin/avg/max/mdev = 0.017/0.028/0.053/0.013 ms [BobO aMSE ~]$ sudo tc qdisc add dev eth0 root ________________________________ From: O'Neil, Bob @ CSW-NOVA Sent: Wednesday, February 11, 2009 2:14 PM To: 'netealists.linux-foundation.org' Subject: FW: Linux Advicon Controlled Bridgbased on MAC Address with Delay and Dropout Assuming I was to do thfollowing, whereth1 is the forwarding queue, would this accomplish thtask of unifordelay and dropout (100 ms and 25% ithexample) in one direction of a network bridge from eth0 to eth1? Is this only applicablto thegress device (eth1), or would this be morappropriatfor the ingress device (eth0)? $ sudo tc qdisc add dev eth1 roonetedelay 100ms loss 25% ________________________________ From: O'Neil, Bob @ CSW-NOVA Sent: Wednesday, February 11, 2009 1:54 PM To: 'netealists.linux-foundation.org' Subject: Linux Advicon Controlled Bridgbased on MAC Address with Delay and Dropout I was considering using NetEto perfortwo functions associated with ondirection on a Linux Bridge: 1. Delaying each framby a fixed amount. 2. Unifordropping of a frame. This is for a Red HaEnterprisLinux 4, kernel 2.6. Artherany issues of using NetEm with the Netbridge effort and IPTables? Any recommendations would bappreciated. ISHORT How to I leveragwhais available on the Linux Communcations Stack, either as parof thkernel itself (i.e. ebtables, netbridge, tcc, iptables, etc.) and/or aaddon modul, that allows mto implemena Linux Bridge, with the additional requirement of dropping ouEtherneframes (not bytes) based on a soft setting, and delaying frames (fro4 ms to 10 ms in 1 ms increments) iONE direction only of thbridge? This is for a i386 machine with 2 NICS thawill need to bin promiscuous mode. MORE DETAILS I atrying to determinthe best course of action for an application/scripthaI need to composfor execution under Red HaLinux AS 4.0, Linux Kernel v2.6.x. I hava 386 based Linux machinwith two NICs that acts a bit like a bridge, dispatching frames athData Link Layer (not IP, Layer 3). On the ingress of NIC 1 (eth0), therwill bcertain frames which havmatching MACs thawill be consumed (i.e. passed up thstack). Other frames, with a rangof matching MAC addresses, broadcasand multicast need to bbridged to thother NIC (call iNIC 2, or eth1). Broadcasand Multicast also need to bconsumed, so may hav two destinations, bridged betweeNICs and consumed frothe internal stack. I will need to assign aIP address to thapplication so that it may act as an SNMP agent. Thconversdirection follows a similar pattern based on the MAC address, certaiframes matching a rangof MAC address will bbridged to NIC 1 from NIC 2, ones which match thMAC address of NIC 2 will bconsumed, broadcasand multicast need to be both consumed and forwarded to thegress of NIC 1. Thassignments of thIPs, subnets, and subnet masks is flexible. Now heris thcomplication that deviates from standard Linux kernel behavior. ONLY for frames forwarded/bridged fro NIC 1 to NIC2, therartwo soft settings that dictate the forwarding behavior: 1. Delay - this may rangfrosay 4 ms to 15 ms. Based on this setting, ingress frames oNIC 1 thawill bforwarded on to NIC 2 need to be delayed in the process. Thdelay timing needs to bfairly precise, to thmillisecond if possible, and possibly as low as 4 ms. 2. Drop OuPercentag- ranges from 0 to 100%. Based on this setting, ingress frames oNIC 1 will bdropped based on thpercentage set. The dropout could be a simplunifordropout, so that if thpercentagis set to 25%, 1 in 4 frames will be dropped. Etherneframes forwarded in thopposite direction (eth1 to eth0) do nohavto be delayed or dropped. I atrying to comup with a design that is optimum, and that takes maximuadvantagof what is availablin thLinux kernel (via NetFilter/IPTables/EBTables/TCC/bctrl, etc.) via commands. To slow dowoutgoing traffic, thTunnel Bucket Filter (TBF) seems like a possiblcommand lin solutiofor thdelay requirement. However, of particular concern is thfacthat it is byte based rather thaframbased, and it appears it may not guarantee a uniform pacing of frames to the user specified delay valuwith fidelity. In addition, frothe documenentitled "Linux Advanced Routing & Traffic Control HOWTO", is thquote: "However, duto thdefault 10ms timer resolution of Unix, with 10.000 bits averagpackets, w arlimited to 1mbit/s of peakrate!" This statemenseems to suggesthat the maximum precision for a delay would coma10 ms increments, and iis noclear if a low value, say 4 ms would be possible. For thdropourequirement, perhaps some form of Random Early Drops, although thdropping needs to bpercisaccording to a fixed percentage. The dropping needs to bbased probably on frames rather than bytes. I aconsidering solutions composed of scripting of thLinux kernel to do all thwork entirely, or hybrid approach as required to supplementhLinux kernel with user code as required. I considered using thIPTABLES -j QUEUE method to queucontents matching a MAC address rangto user land queues, wherthey would programatically bdropped or delayed. Perhaps a better fiwould be EPTables thadeals with Etherneframes, However, it would seem these mighbproblematic for frames which havtwo destinations, such as broadcasand multicast, which need to bboth lefon the internal stack and forwarded/bridged to thother NIC. Whereas a purbridgforwards on all content, I also need to maintain aSMNP agent, which will requirthat frames matching thIP assigned to thbridge are allowed to pass up the stack for internal consumption. Forwarding will also blimited to a rangof MAC addresses. Both NICs will need to operatin promiscuous mode. Iis noentirely clear whether or not I can do bridging (brctl) in combinatiowith ebtables/netfilter/iptables/tcc. I may to implemensomform of the Spanning Tree Protocol (STP), and perhaps DHCP to establish thIP for thpseudo-bridge. Thloweslevel alternative that I have considered, the one with the higheslevel of control bupossible thmoscustom coding, is using the PCAPS (libpcap) frame sniffer technology based othlow level NDIS driver, which allows mto gea callback into user land for each frame received by thNIC in promiscuous mode. Using this approach, I would queuor drop frames in a userland application, and thebridge/forward theon to thother NIC based on a custom scheduler thread. This would requirmto queue the frames iuser land, buprovides the highest level of control, and perhaps thfastest forwarding as I would read froonNIC and bridge to the other. I would also leavthframe othstack so it could have two destinations. This technique would allow mto delay frames with a fairly fingrain of precision, budoes not take maximum advantage of the services already provided by thLinux kernel. Interested iwhadesign approach you think will fulfil my goals. Any directioyou can poin min would bmost appreciated. Bob O'Neil -------------- nexpar-------------- AHTML attachmenwas scrubbed... URL: http://lists.linux-foundation.org/pipermail/netem/attachments/20090211/792b0b53/attachment-0001.ht Frocubic1271 agmail.com Thu Feb 12 08:44:53 2009 From: cubic1271 agmail.co(Steve) Date: Thu, 12 Feb 2009 11:44:53 -0500 Subject: Linux Advicon Controlled Bridgbased on MAC Address with Delay and Dropout In-Reply-To: <8A69033E02ED29419B0F43AD421CEC3A1AB9EE@xxxxxxxxxxxxxxxxxxxxxxxx> References: <8A69033E02ED29419B0F43AD421CEC3A1AB9EE@xxxxxxxxxxxxxxxxxxxxxxxx> Message-ID: <367782b60902120844n26ddc7d6l4f4b16fa54d4a0e3@xxxxxxxxxxxxxx> Hi Bob: I'vnever had any troublusing tc with iptables, personally; then again, I'vnever really donanything as complex as what you're looking to do, either. For whayou'rdoing, you might try taking a look at ebtables. Onthing I'd try is pinging your interfacfrom a different machine; I caseissues trying to get a delay from a local interface. Another thing you cado is seup a route out of the delayed interfacand ping another machine. Either way, thashould probably gethdelay applied how you'd like. Disclaimer(s): YMMV, UAYOR, AMNGOSFAPP, etc. --Steve OWed, Feb 11, 2009 a3:27 PM, <Bob.Oneil at l-3com.com> wrote: > I issued thfollowing commands on eth0, buping does not reveal the 100 ms > delay expected, or any significandifferences with thping results prior > to issuing thcommand. > > > > Any thoughts owhy a local ping tesdoes not reflect the additional 100 ms > delay? > > > > "sudo tc qdisc add dev eth0 roonetedelay 100 ms" > > > > > > [BobO aMSE ~]$ ifconfig > > eth0 Link encap:EthernHWaddr 00:23:AE:69:96:81 > > ineaddr:128.170.150.109 Bcast:128.170.150.255 > Mask:255.255.255.0 > > inet6 addr: fe80::223:aeff:fe69:9681/64 Scope:Link > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > RX packets:15 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:19 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:100 > > RX bytes:1520 (1.4 KiB) TX bytes:4269 (4.1 KiB) > > Memory:febe0000-fec00000 > > > > eth1 Link encap:EthernHWaddr 00:10:5A:E1:1A:50 > > UP BROADCAST MULTICAST MTU:1500 Metric:1 > > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:1000 > > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > > Interrupt:16 Basaddress:0x8f80 > > > > lo Link encap:Local Loopback > > ineaddr:127.0.0.1 Mask:255.0.0.0 > > inet6 addr: ::1/128 Scope:Host > > UP LOOPBACK RUNNING MTU:16436 Metric:1 > > RX packets:12 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:12 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:0 > > RX bytes:800 (800.0 b) TX bytes:800 (800.0 b) > > > > [BobO aMSE ~]$ ping 128.170.150.109 > > PING 128.170.150.109 (128.170.150.109) 56(84) bytes of data. > > 64 bytes fro128.170.150.109: icmp_seq=1 ttl=64 time=0.053 ms > > 64 bytes fro128.170.150.109: icmp_seq=2 ttl=64 time=0.042 ms > > 64 bytes fro128.170.150.109: icmp_seq=3 ttl=64 time=0.026 ms > > 64 bytes fro128.170.150.109: icmp_seq=4 ttl=64 time=0.018 ms > > 64 bytes fro128.170.150.109: icmp_seq=5 ttl=64 time=0.022 ms > > 64 bytes fro128.170.150.109: icmp_seq=6 ttl=64 time=0.017 ms > > 64 bytes fro128.170.150.109: icmp_seq=7 ttl=64 time=0.018 ms > > ^C > > --- 128.170.150.109 ping statistics --- > > 7 packets transmitted, 7 received, 0% packeloss, tim6689ms > > rtmin/avg/max/mdev = 0.017/0.028/0.053/0.013 ms > > [BobO aMSE ~]$ sudo tc qdisc add dev eth0 root > > > > > > > > ________________________________ > > From: O'Neil, Bob @ CSW-NOVA > Sent: Wednesday, February 11, 2009 2:14 PM > To: 'netealists.linux-foundation.org' > Subject: FW: Linux Advicon Controlled Bridgbased on MAC Address with > Delay and Dropout > > > > Assuming I was to do thfollowing, whereth1 is the forwarding queue, > would this accomplish thtask of unifordelay and dropout (100 ms and 25% > ithexample) in one direction of a network bridge from eth0 to eth1? > > > > Is this only applicablto thegress device (eth1), or would this be more > appropriatfor thingress device (eth0)? > > > > > > $ sudo tc qdisc add dev eth1 roonetedelay 100ms loss 25% > > > > > > > > ________________________________ > > From: O'Neil, Bob @ CSW-NOVA > Sent: Wednesday, February 11, 2009 1:54 PM > To: 'netealists.linux-foundation.org' > Subject: Linux Advicon Controlled Bridgbased on MAC Address with Delay > and Dropout > > > > I was considering using NetEto perfortwo functions associated with one > directioon a Linux Bridge: > > > > Delaying each framby a fixed amount. > Unifordropping of a frame. > > > > This is for a Red HaEnterprisLinux 4, kernel 2.6. > > > > Artherany issues of using NetEm with the Netbridge effort and IPTables? > > > > Any recommendations would bappreciated. > > > > > > > > ISHORT > > > > How to I leveragwhais available on the Linux Communcations Stack, either > as parof thkernel itself (i.e. ebtables, netbridge, tcc, iptables, > etc.) and/or aaddon modul, that > > allows mto implemena Linux Bridge, with the additional requirement of > dropping ouEtherneframes (not bytes) based on a soft setting, and > delaying frames (fro4 ms to 10 ms in 1 ms increments) > > iONE direction only of thbridge? This is for a i386 machine with 2 > NICS thawill need to bin promiscuous mode. > > > > MORE DETAILS > > > > I atrying to determinthe best course of action for an application/script > thaI need to > > composfor execution under Red HaLinux AS 4.0, Linux Kernel v2.6.x. > > I hava 386 based Linux machinwith two NICs that acts a bit like a > bridge, dispatching frames > > athData Link Layer (not IP, Layer 3). On the ingress of NIC 1 (eth0), > therwill bcertain > > frames which havmatching MACs thawill be consumed (i.e. passed up the > stack). Other frames, > > with a rangof matching MAC addresses, broadcasand multicast need to be > bridged to thother > > NIC (call iNIC 2, or eth1). Broadcasand Multicast also need to be > consumed, so may have > > two destinations, bridged betweeNICs and consumed frothe internal > stack. I will need to assign > > aIP address to thapplication so that it may act as an SNMP agent. > > Thconversdirection follows a similar pattern based on the MAC address, > certaiframes > > matching a rangof MAC address will bbridged to NIC 1 from NIC 2, ones > which match thMAC > > address of NIC 2 will bconsumed, broadcasand multicast need to be both > consumed and forwarded > > to thegress of NIC 1. > > > > Thassignments of thIPs, subnets, and subnet masks is flexible. > > Now heris thcomplication that deviates from standard Linux kernel > behavior. ONLY for frames forwarded/bridged from > > NIC 1 to NIC2, therartwo soft settings that dictate the forwarding > behavior: > > 1. Delay - this may rangfrosay 4 ms to 15 ms. Based on this setting, > ingress frames oNIC 1 > > thawill bforwarded on to NIC 2 need to be delayed in the process. The > delay timing needs to > > bfairly precise, to thmillisecond if possible, and possibly as low as 4 > ms. > > 2. Drop OuPercentag- ranges from 0 to 100%. Based on this setting, > ingress frames oNIC 1 > > will bdropped based on thpercentage set. The dropout could be a simple > unifordropout, so thaif > > thpercentagis set to 25%, 1 in 4 frames will be dropped. > > > > Etherneframes forwarded in thopposite direction (eth1 to eth0) do not > havto bdelayed or dropped. > > I atrying to comup with a design that is optimum, and that takes maximum > advantagof whais > > availablin thLinux kernel (via NetFilter/IPTables/EBTables/TCC/bctrl, > etc.) via commands. > > To slow dowoutgoing traffic, thTunnel Bucket Filter (TBF) seems like a > possiblcommand line > > solutiofor thdelay requirement. However, of particular concern is the > facthait is byte based > > rather thaframbased, and it appears it may not guarantee a uniform > pacing of frames to the > > user specified delay valuwith fidelity. In addition, frothe > documenentitled "Linux Advanced Routing & Traffic Control HOWTO", > > is thquote: > > "However, duto thdefault 10ms timer resolution of Unix, with 10.000 bits > averagpackets, we > > arlimited to 1mbit/s of peakrate!" > > This statemenseems to suggesthat the maximum precision for a delay would > coma10 ms > > increments, and iis noclear if a low value, say 4 ms would be possible. > > For thdropourequirement, perhaps some form of Random Early Drops, > although thdropping needs > > to bpercisaccording to a fixed percentage. The dropping needs to be > based probably oframes rather than bytes. > > > > I aconsidering solutions composed of scripting of thLinux kernel to do > all thwork entirely, or hybrid approach > > as required to supplementhLinux kernel with user code as required. > > I considered using thIPTABLES -j QUEUE method to queucontents matching a > MAC address rangto > > user land queues, wherthey would programatically bdropped or delayed. > Perhaps a better fiwould be > > EPTables thadeals with Etherneframes, However, it would seem these > mighbproblematic for frames > > which havtwo destinations, such as broadcasand multicast, which need to > bboth lefon the internal stack and > forwarded/bridged to thother NIC. > > > > Whereas a purbridgforwards on all content, I also need to maintain an > SMNP agent, which will requirthaframes > > matching thIP assigned to thbridge are allowed to pass up the stack for > internal consumption. Forwarding will > > also blimited to a rangof MAC addresses. Both NICs will need to > operatin promiscuous mode. > > > > Iis noentirely clear whether or not I can do bridging (brctl) in > combinatiowith ebtables/netfilter/iptables/tcc. > > > > I may to implemensomform of the Spanning Tree Protocol (STP), and > perhaps DHCP to establish thIP for > > thpseudo-bridge. > > Thloweslevel alternative that I have considered, the one with the > higheslevel of control bupossible > > thmoscustom coding, is using the PCAPS (libpcap) frame sniffer > technology based othlow level NDIS driver, > > which allows mto gea callback into user land for each frame received by > thNIC in promiscuous mode. Using > > this approach, I would queuor drop frames in a userland application, and > thebridge/forward > > theon to thother NIC based on a custom scheduler thread. This would > requirmto queue the > > frames iuser land, buprovides the highest level of control, and perhaps > thfastest > forwarding as I would read froonNIC and bridge to the other. I would > also leavthframe > > othstack so it could have two destinations. This technique would allow > mto delay frames with a fairly > > fingrain of precision, budoes not take maximum advantage of the services > already provided by thLinux > > kernel. > > Interested iwhadesign approach you think will fulfil my goals. Any > directioyou can point > > min would bmost appreciated. > > Bob O'Neil > > _______________________________________________ > Netemailing list > Netealists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/netem > Frohello.martin acomhem.se Mon Feb 23 11:23:12 2009 From: hello.martiacomhem.se (Martin Andersson) Date: Mon, 23 Feb 2009 20:23:12 +0100 Subject: Maximudelay Message-ID: <49A2F7A0.5050903@xxxxxxxxx> What's thmaximudelay that can be achieved with netem. I assumthat's depending on thtx-buffer (so actually dependent on the bandwith used), is thaan kernel issuor is't something with the network driver. CaI found thawith some command? /Martin Froshemminger avyatta.com Mon Feb 23 12:00:18 2009 From: shemminger avyatta.co(Stephen Hemminger) Date: Mon, 23 Feb 2009 12:00:18 -0800 Subject: Maximudelay In-Reply-To: <49A2F7A0.5050903@xxxxxxxxx> References: <49A2F7A0.5050903@xxxxxxxxx> Message-ID: <20090223120018.436b1449@extreme> OMon, 23 Feb 2009 20:23:12 +0100 MartiAndersson <hello.martin acomhem.se> wrote: > What's thmaximudelay that can be achieved with netem. > I assumthat's depending on thtx-buffer (so actually dependent on the > bandwith used), is thaan kernel issuor is't something with the > network driver. CaI found thawith some command? > Max delay = 2^32-1 us => 71 minutes
