Re: howto determine network device unit number? device.hints?
you may not change unit numbers as they are strictly controlled by kernel. However, on freebsd 5.3+, you may use 'ifconfig name ' to achieve the same affect Yony Yossef wrote: Hi, I would like to determine the unit number of my network cards, e.g. make the device on pci0:16 be assigned every time with unit number 0 and pci0:19 with unit number 1. Is it done by /boot/device.hints? if so, how? My cards are: mtn...@pci0:19:0:0: class=0x02 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 mtn...@pci0:16:0:0: class=0x02 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 So I've tried: hint.mtnic.0.at="pci0:16" hint.mtnic.1.at="pci0:19" but it doesn't work. They keep switching arbitrarily. I'm using FreeBSD 7.0. Thanks Yony ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" -- Best regards. Hooman Fazaeli Sepehr S. T. Co. Ltd. Web: http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: howto determine network device unit number? device.hints?
for example, say you have 2 interface em0 and em1 which you like to swap their minor numbers: ifconfig em0 name tmp ifconfig em1 name em0 ifconfig em0 name em1 or to assign cisco-like names to you interfaces: ifconfig xl0 name fastEthernet0 ifconfig em0 name gigaEthernet0 ifconfig fastEthernet0 192.168.1.0/24 Yony Yossef wrote: -Original Message- From: H.fazaeli [[1]mailto:faza...@sepehrs.com] Sent: Wednesday, January 14, 2009 6:24 PM To: Yony Yossef Cc: [2]freebsd-...@freebsd.org; [3]freebsd-questi...@freebsd.org; Eitan Shefi; Oleg Kats; Liran Liss Subject: Re: howto determine network device unit number? device.hints? you may not change unit numbers as they are strictly controlled by kernel. However, on freebsd 5.3+, you may use 'ifconfig name ' to achieve the same affect Sorry, I don't understand the usage of ifconfig you suggested and the effect it will cause. Can you please explain it? Yony Yony Yossef wrote: Hi, I would like to determine the unit number of my network cards, e.g. make the device on pci0:16 be assigned every time with unit number 0 and pci0:19 with unit number 1. Is it done by /boot/device.hints? if so, how? My cards are: mtn...@pci0:19:0:0: class=0x02 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 mtn...@pci0:16:0:0: class=0x02 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 So I've tried: hint.mtnic.0.at="pci0:16" hint.mtnic.1.at="pci0:19" but it doesn't work. They keep switching arbitrarily. I'm using FreeBSD 7.0. Thanks Yony ___ [4]freebsd-questi...@freebsd.org mailing list [5]http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [6]"freebsd-questions-unsubscr...@freebsd.org" -- Best regards. Hooman Fazaeli [7] Sepehr S. T. Co. Ltd. Web: [8]http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 ___ [9]freebsd-...@freebsd.org mailing list [10]http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [11]"freebsd-net-unsubscr...@freebsd.org" -- Best regards. Hooman Fazaeli [12] Sepehr S. T. Co. Ltd. Web: [13]http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 References 1. mailto:faza...@sepehrs.com 2. mailto:freebsd-net@freebsd.org 3. mailto:freebsd-questi...@freebsd.org 4. mailto:freebsd-questi...@freebsd.org 5. http://lists.freebsd.org/mailman/listinfo/freebsd-questions 6. mailto:freebsd-questions-unsubscr...@freebsd.org 7. mailto:h...@sepehrs.com 8. http://www.sepehrs.com/ 9. mailto:freebsd-net@freebsd.org 10. http://lists.freebsd.org/mailman/listinfo/freebsd-net 11. mailto:freebsd-net-unsubscr...@freebsd.org 12. mailto:h...@sepehrs.com 13. http://www.sepehrs.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: howto determine network device unit number? device.hints?
Yony Yossef wrote: Thanks for the explanation. So there's no way to determine this in advance.. What do you mean by 'in advance'? Assuming a fixed hardware configuration, when the kernel is loaded, you know all the interface names and can rename them, i.e., in rc.local. I must build a script that contains my own mapping between MAC addresses and the wanted interface names and run it after each driver load, rename the interfaces if necessary. I do not quite understand your requirement. Can you please explain? Do you need a script that works on multiple machines with different hardwares? It seems quite wrong, don't you agree? And how come the unit number is given an arbitrary value? Is there a good reason for that? Yony _ From: H.fazaeli [mailto:faza...@sepehrs.com] Sent: Thursday, January 15, 2009 10:26 AM To: Yony Yossef Cc: freebsd-net@freebsd.org; freebsd-questi...@freebsd.org Subject: Re: howto determine network device unit number? device.hints? for example, say you have 2 interface em0 and em1 which you like to swap their minor numbers: ifconfig em0 name tmp ifconfig em1 name em0 ifconfig em0 name em1 or to assign cisco-like names to you interfaces: ifconfig xl0 name fastEthernet0 ifconfig em0 name gigaEthernet0 ifconfig fastEthernet0 192.168.1.0/24 Yony Yossef wrote: -Original Message----- From: H.fazaeli [mailto:faza...@sepehrs.com] Sent: Wednesday, January 14, 2009 6:24 PM To: Yony Yossef Cc: freebsd-net@freebsd.org; freebsd-questi...@freebsd.org; Eitan Shefi; Oleg Kats; Liran Liss Subject: Re: howto determine network device unit number? device.hints? you may not change unit numbers as they are strictly controlled by kernel. However, on freebsd 5.3+, you may use 'ifconfig name ' to achieve the same affect Sorry, I don't understand the usage of ifconfig you suggested and the effect it will cause. Can you please explain it? Yony Yony Yossef wrote: Hi, I would like to determine the unit number of my network cards, e.g. make the device on pci0:16 be assigned every time with unit number 0 and pci0:19 with unit number 1. Is it done by /boot/device.hints? if so, how? My cards are: mtn...@pci0:19:0:0: class=0x02 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 mtn...@pci0:16:0:0: class=0x02 card=0x001715b3 chip=0x636815b3 rev=0xa0 hdr=0x00 So I've tried: hint.mtnic.0.at="pci0:16" hint.mtnic.1.at="pci0:19" but it doesn't work. They keep switching arbitrarily. I'm using FreeBSD 7.0. Thanks Yony ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" <mailto:freebsd-questions-unsubscr...@freebsd.org> -- Best regards. Hooman Fazaeli Sepehr S. T. Co. Ltd. Web: http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Advice on a multithreaded netisr patch?
Dear Jack Can you please comment on below statements ?! Is the assertion true for all OSes (windows, linux, ...) or it is just freebsd? I am actually concerned in how much production ready is igb drivers in your opinion. As a matter of fact, We have been (and are) using em drivers for years on production systems in biggest ICPs/ISPs/organizations without problem and we have very good faith in it (I have not tested igb). Barney Cordoba wrote: --- On Tue, 4/7/09, Ivan Voras [1] wrote: From: Ivan Voras [2] Subject: Re: Advice on a multithreaded netisr patch? To: [3]freebsd-...@freebsd.org Date: Tuesday, April 7, 2009, 5:59 PM Barney Cordoba wrote: 1) Multiple TX queues are not supported. There's some hokey code to test, but it doesn't properly separate flows to the queues. 2) 2 Rx queues don't work, so only 1 and 4 work 3) With 4 queues, it just sucks up CPU under heavy load on 4 cpus. It will blow 4 cpus at a lower load than em will with 1 4) You'll need to fix DMA setup, as it sets the alignment requirement to PAGE_SIZE. I haven't been able to convince Jack that its wrong, not that I've tried very hard since its easy to just fix myself. Reading this thread it looks like the development of both Intel drivers is a bit stalled, doesn't it? AFAIK the em driver is also semi-officially abandoned, and both from my experience and others it looks like new development and patches are being rejected. Time to shop other hardware? To be fair, the OS doesn't really support multiqueue yet, or has for only a few hours, so lets not go crazy. It makes a lot more sense to have someone on the "team" work with Jack on improving the performance and working out the kinks. When I asked Jack about the poor performance of if_igb, he indicated that Intel's position is that the drivers are "just samples", which really doesn't give anyone much confidence that they want to run their business on them. You already have Jack doing all of the hard work; that is supporting the new-chip-per-week that intel puts out, so it seems to me the best strategy would be to try to convince Intel that its in their best interest to have drivers that work well so people don't think that their hardware stinks. As an example, the Chelsio 10gb bypass card is $3495. and an Intel card is ~$1000, so its a big win for the community as a whole to have good intel drivers going forward. My work is commercially proprietary so I can't share my code, but I can certainly share ideas on things that I've tested and discovered. Barney ___ [4]freebsd-...@freebsd.org mailing list [5]http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [6]"freebsd-net-unsubscr...@freebsd.org" -- Best regards. Hooman Fazaeli [7] Sepehr S. T. Co. Ltd. Web: [8]http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 References 1. mailto:ivo...@freebsd.org 2. mailto:ivo...@freebsd.org 3. mailto:freebsd-net@freebsd.org 4. mailto:freebsd-net@freebsd.org 5. http://lists.freebsd.org/mailman/listinfo/freebsd-net 6. mailto:freebsd-net-unsubscr...@freebsd.org 7. mailto:h...@sepehrs.com 8. http://www.sepehrs.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
broadcom 57710 support
Is there any near plan to develop drivers for network cards based on broadcom NetXtereme II 57710 10 GbE controller? -- Best regards. Hooman Fazaeli Sepehr S. T. Co. Ltd. Web: http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
broadcom 57710 support
Is there any near plan to develop drivers for network cards based on broadcom NetXtereme II 57710 10 GbE controller? -- Best regards. Hooman Fazaeli Sepehr S. T. Co. Ltd. Web: http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: broadcom 57710 support
Wojciech A. Koszek wrote: On Sun, Jul 19, 2009 at 12:52:53PM +0430, H.Fazaeli wrote: Is there any near plan to develop drivers for network cards based on broadcom NetXtereme II 57710 10 GbE controller? Do you plan to help somehow with driver development? No. I just plan to use them on IBM blade servers. In order to develop this driver someone would probably have an easy access to those cards. Are they packaged in PCIe format as well, or they only have the blade version? Thanks, Both blade and usual PC form factors are available. See http://www.redbooks.ibm.com/technotes/tips0688.pdf and http://www.broadcom.com/products/Enterprise-Networking/10-Gigabit-Ethernet-Controllers/BCM57710 -- Best regards. Hooman Fazaeli ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: broadcom 57710 support
Nothing actually special. They are one of few 10GbE expansion cards supported on IBM blade servers. See http://www.redbooks.ibm.com/technotes/tips0688.pdf Barney Cordoba wrote: --- On Sun, 7/19/09, Hooman Fazaeli wrote: From: Hooman Fazaeli Subject: broadcom 57710 support To: freebsd-net@freebsd.org Date: Sunday, July 19, 2009, 5:08 AM Any one knows if there is any near plan to develop drivers for network cards based on broadcom NetXtereme II 57710 10 GbE controller? --- best regards Hooman Fazaeli Ok, I'll bite. What is so special about this particular part that you simply must use it in your 10GbE server? Barney ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" -- Best regards. Hooman Fazaeli ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: em driver input errors
Have you tries fixed speed/duplex?
alexpalias-bsd...@yahoo.com wrote:
Good day
I'm running a FreeBSD 7.2 router and I am seeing a lot of input errors on one
of the em interfaces (em0), coupled with (at approximately the same times) much
fewer errors on em1 and em2. Monitoring is done with SNMP from another
machine, and the CPU load as reported via SNMP is mostly below 30%, with a
couple of spikes up to 35%.
Software description:
- FreeBSD 7.2-RELEASE-p2, amd64
- bsnmpd with modules: hostres and (from ports) snmp_ucd
- quagga 0.99.12 (running only zebra and bgpd)
- netgraph (ng_ether and ng_netflow)
Hardware description:
- Dell machine, dual Xeon 3.20 GHz, 4 GB RAM
- 2 x built-in gigabit interfaces (em0, em1)
- 1 x dual-port gigabit interface, PCI-X (em2, em3) [see pciconf near the end]
The machine receives the global routing table ("netstat -nr | wc -l" gives
289115 currently).
All of the em interfaces are just configured "up", with various vlan interfaces on them. Note that
I use "kpps" to mean "thousands of packets per second", sorry if that's the wrong
shorthand.
- em0 sees a traffic of 10...22 kpps in, and 15...35 kpps out. In bits, it's
30...120Mbits/s in, and 100...210Mbits/s out. Vlans configured are vlan100 and
vlan200, and most of the traffic is on vlan100 (vlan200 sees 4kpps in / 0.5kpps
out maximum, with the average at about one third of this). em0 is the external
interface, and its traffic corresponds to the sum of traffic through em1 and em2
- em1 has 5 vlans, and sees about 22kpps in / 11kpps out (maximum)
- em2 has a single VLAN, and sees about 4...13kpps both in and out (almost
equal in/out during most of the day)
- em3 is a backup interface, with 2 VLANS, and is the only one which has seen
no errors.
Only the vlans on em0 are analyzed by ng_netflow, and the errors I'm seeing
have started appearing days before netgraph was even loaded in the kernel.
Tuning done:
/boot/loader.conf:
hw.em.rxd=4096
hw.em.txd=4096
Witout the above we were seeing way more errors, now they are reduced, but
still come in bursts of over 1000 errors on em0.
/etc/sysctl.conf:
net.inet.ip.fastforwarding=1
dev.em.0.rx_processing_limit=300
dev.em.1.rx_processing_limit=300
dev.em.2.rx_processing_limit=300
dev.em.3.rx_processing_limit=300
Still seeing errros, after some searching the mailing lists we also added:
# the four lines below are repeated for em1, em2, em3
dev.em.0.rx_int_delay=0
dev.em.0.rx_abs_int_delay=0
dev.em.0.tx_int_delay=0
dev.em.0.tx_abs_int_delay=0
Still getting errors, so I also added:
net.inet.ip.intr_queue_maxlen=4096
net.route.netisr_maxqlen=1024
and
kern.ipc.nmbclusters=655360
Also tried with rx_processing_limit set to -1 on all em interfaces, still
getting errors.
Looking at the shape of the error and packet graphs, there seems to be a correlation
between the number of packets per second on em0 and the height of the error
"spikes" on the error graph. These spikes are spread throughout the day, with
spaces (zones with no errors) of various lengths (10 minutes ... 2 hours spaces within
the last 24 hours), but sometimes there are errors even in the lowest kpps times of the
day.
em0 and em1 error times are correlated, with all errors on the graph for em0
having a smaller corresponding error spike on em1 at the same time, and
sometimes an error spike on em2.
The old router was seeing about the same traffic, and had em0, em1, re0 and re1
network cards, and was only seeing errors on the em cards. It was running
7.2-PRERELEASE/i386
Any suggestions would be greatly appreciated. Please note that this is a live
router, and I can't reboot it (unless absolutely necessary). Tuning that can
be applied without rebooting will be tried first.
Here are some more details:
Trimmed output of netstat -ni (sorry if there are line breaks):
NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll
em01500 00:14:22:xx:xx:xx 19744458839 15494721 24284439443
0 0
em11500 00:14:22:xx:xx:xx 12832245469 123181 10105031790
0 0
em21500 00:04:23:xx:xx:xx 12082552403 10964 10339416865 0
0
em31500 00:04:23:xx:xx:xx 79912337 0 48178737 0 0
Relevant part of pciconf -vl:
e...@pci0:6:7:0: class=0x02 card=0x016d1028 chip=0x10768086 rev=0x05
hdr=0x00
vendor = 'Intel Corporation'
device = '82541EI Gigabit Ethernet Controller'
class = network
subclass = ethernet
e...@pci0:7:8:0: class=0x02 card=0x016d1028 chip=0x10768086 rev=0x05
hdr=0x00
vendor = 'Intel Corporation'
device = '82541EI Gigabit Ethernet Controller'
class = network
subclass = ethernet
e...@pci0:9:4:0: class=0x02 card=0x10128086 chip=0x10108086 rev=0x01
hdr=0x00
vendor = 'Intel Corporation'
device = '82546EB Dual Port Gigabit Ethernet Controller (Copper)'
class = network
subclass = ethernet
e...@pci0:9:
Re: bikeshed for all!
What about "routing zone" or "forwarding zone" which may be abbreviated as "rtzone" or "fwdzone". Julian Elischer wrote: So, I'm playing with some multiple routing table support.. the first version is a minimal impact version with very limited functionality. It's done that way so I can put it in RELENG_6/7 without breaking ABIs (I hope). Later there will be a more flexible version for-current. Here's the question.. I need a word to use to describe the network view one is currently on.. e.g. if you are usinghe second routing table, you could say I've set xxx to 1 (0 based).. current;y in my code I'm using 'universe' but I don't like that.. one could think of it as a routing plane.. each routing plane has he same interfaces on it but they are logically treated differently becasue each plane has a different routing table. so here's an axample of it in use now... the names should change... setuniverse 1 netstat -rn [shows table 1] setuniverse 2 route add 10.0.0.0/24 192.168.2.1 setuinverse 1 route add 10.0.0.0/24 192.168.3.1 setuniverse 2 route -n get 10.0.0.3 [shows 192.168.2.1] setuniverse 1 route -n get 10.0.0.3 [shows 192.168.3.1] setuniverse 2 start_apache [appache starts, always using 192.168.2.1 to reach the 10.0.0 net. also the syscall is setuniverse() so, you see I really need a better name setrtab? rtab? rtbl? and the command should be called "" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- With best regards. Hooman Fazaeli <[EMAIL PROTECTED]> Technical Manager Sepehr S. T. Co. Ltd. Web: http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Routing SMP benefit
Hi all Where are 'those numbers' you are referring to? have I missed some message in the thread? Tiffany Snyder wrote: Hi Andre, are those numbers for small (64 bytes) packets? Good job on pushing the base numbers higher on the same HW. What piqued my attention was the note that our forwarding performance doesn't scale with multiple CPUs. Which means there's a lot of work to be done :-) Have we taken a look at OpenSolaris' Surya (http://www.opensolaris.org/os/community/networking/surya-design.pdf) project? They allow multiple readers/single writer on the radix_node_head (and not a mutex as we do) and we may be able to do the same to gain some parallelism. There are other things in Surya that exploit multiple CPUs. It's definitely worth a read. DragonFlyBSD seems to achieve parallelism by classifying packet as flows and then redirecting the flows to different CPUs. OpenSolaris also does something similar. We can definitely think along those lines. NOTE: 1) I said multiple instead of dual CPUs on purpose. 2) I mentioned OpenSolaris and DragonFlyBSD as examples and to acknowledge the work they are doing and to show that FreeBSD is far behind and is losing it's lustre on continuing to be the networking platform of choice. Thanks, Tiffany. On 12/29/05, Andre Oppermann <[EMAIL PROTECTED] > wrote: Markus Oestreicher wrote: Currently running a few routers on 5-STABLE I have read the recent changes in the network stack with interest. You should run 6.0R. It contains many improvements over 5-STABLE. A few questions come to my mind: - Can a machine that mainly routes packets between two em(4) interfaces benefit from a second CPU and SMP kernel? Can both CPUs process packets from the same interface in parallel? My testing has shown that a machine can benefit from it but not much in the forwarding performance. The main benefit is the prevention of lifelock if you have very high packet loads. The second CPU on SMP keeps on doing all userland tasks and running routing protocols. Otherwise your BGP sessions or OSPF hellos would stop and remove you from the routing cloud. - From reading the lists it appears that net.isr.direct and net.ip.fastforwarding are doing similar things. Should they be used together or rather not? net.inet.ip.fastforwarding has precedence over net.isr.direct and enabling both at the same doesn't gain you anything. Fastforwarding is about 30% faster than all other methods available, including polling. On my test machine with two em(4) and an AMD Opteron 852 (2.6GHz) I can route 580'000 pps with zero packet loss on -CURRENT. An upcoming optimization that will go into -CURRENT in the next few days pushes that to 714'000 pps. Futher optimizations are underway to make a stock kernel do close to or above 1'000'000 pps on the same hardware. -- Andre ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to " [EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- With best regards. Hooman Fazaeli <[EMAIL PROTECTED]> Sepehr S. T. Co. Ltd. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: if_bridge with two subnets
The bridge works as it should: It receives packets from XX.XX.XXX.YYY on the interface connected to the switch, and forwards them on the interface connected to the gateway. The problem is that forwarding between subnets is the responsibility of your switch. The switch does its job, but since the two clients are not on the same IP subnet, they can not reach each other w/o the help of an intermediate router. Jay L. T. Cornwall wrote: Hi, I have an if_bridge, thus: bridge0: flags=8843 metric 0 mtu 1500 inet XX.XX.XXX.20 netmask 0xfff8 broadcast XX.XX.XXX.23 inet 192.168.1.30 netmask 0xff00 broadcast 192.168.1.255 On one side of the bridge is a layer 2 switch with clients of a mix of addresses from these two subnets. On the other side is a gateway XX.XX.XXX.22. All clients can communicate through the gateway correctly, with the 192.168.1.x subnet being NAT'd. However, clients from one subnet cannot communicate with clients from the other subnet. Pinging a 192.168.1.X machine from the other subnet shows the packet incorrectly routed out through the gateway, not back through the interface it came. The routing table shows that both subnets should be routed through the bridge: XX.XX.XXX.XX/29link#5 UC 00 bridge 192.168.1.0/24 link#5 UC 00 bridge The bridge host itself can ping machines on both subnets. So why is the if_bridge routing packets destined for the private subnet out through the default route instead? (The specific hosts being pinged are present in the routing table from ARP lookups. They are all destined for the bridge interface.) -- With best regards. Hooman Fazaeli <[EMAIL PROTECTED]> Technical Manager Sepehr S. T. Co. Ltd. Web: http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: if_bridge with two subnets
Jay L. T. Cornwall wrote: H.fazaeli wrote: The bridge works as it should: It receives packets from XX.XX.XXX.YYY on the interface connected to the switch, and forwards them on the interface connected to the gateway. The problem is that forwarding between subnets is the responsibility of your switch. The switch does its job, but since the two clients are not on the same IP subnet, they can not reach each other w/o the help of an intermediate router. Perhaps I am mixing up two separate networking concepts. On a machine configured to act as a gateway, I would expect a single interface with more than one subnet to route packets correctly across those subnets. That may not be how it works in practice. If it does not work, I would question why not. If it does work then I would expect the same behaviour on each of a bridge's constituent interfaces? It does work. However, if I understand your setup correctly, the freebsd box has been setup to act as a bridge, not as a router (routing is enabled with sysctl net.inet.ip.forwarding=1). Bridging works when the forwarding is between the same subnets. For freebsd box to route between subnets: - enable routing: sysctl net.inet.ip.forwarding=1 - clients must use the freebsd box as gateway. - IP addresses must be removed from the bridge and assigned to the member interfaces. (the bridge is no longer needed). You may have bridging & routing on the same box at the same time but note that a single packet coming into the system either goes through bridging _or_ routing code, but not both. The former case happens if packet's destination MAC address is not that of box. The latter case happens when destination MAC address is that of receiving interface. If you provide a network diagram along with your requirements, we can better discuss the matter. -- With best regards. Hooman Fazaeli <[EMAIL PROTECTED]> Technical Manager Sepehr S. T. Co. Ltd. Web: http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
em(4) status
Hi all and Jack Are the changes discussed in: http://lists.freebsd.org/pipermail/freebsd-net/2008-January/016584.html http://lists.freebsd.org/pipermail/freebsd-net/2007-August/014959.html incorporated into em(4)? If not, is there any near plans to do so? -- Best regards. Hooman Fazaeli <[EMAIL PROTECTED]> Sepehr S. T. Co. Ltd. Web: http://www.sepehrs.com Tel: (9821)88975701-2 Fax: (9821)88983352 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
