Re: problem with vlan interfaces tagging/untagging in a simulated switch box
On 2012-Mar-06 09:15:57 +0330, h bagade wrote: >On 3/6/12, Peter Jeremy wrote: >> The following example diagram shows 3 distinct packet flows: >> - packets tagged 5 in trunk1 and 6 in trunk0 >> - packets tagged 7 in trunk1 and 9 in trunk0 >> - packets tagged 8 in trunk0 and 10 in trunk2 >> >> +-- vlan5 --- bridge1 --- vlan6 --+ >> | | >> trunk1 --- eth1 -+- vlan7 --- bridge2 --- vlan9 --+-- eth0 --- trunk0 >>| >>bridge3 --- vlan8 --+ >> | >> trunk2 -- eth2 --- vlan10 >> >I've described the function of Cisco switches in vlan >tagging/untagging. Real switches typically have everything tagged internally, with the native VLAN tags added/removed at the ingress/egress ports. This simplifies the internal switch logic (at the expense of meaning that tags have to be consistent across all trunks). FreeBSD works differently. Packets are _untagged_ internally and you need a separate bridge(4) device for each broadcast domain (vlan). > In your topology, packets should be tagged when >recieved on real interfaces to be send out to vlan interfaces. Packets are never tagged by real interfaces and always have tags added/removed by vlan devices. > It >would be fine when two trunks are communicating because on both side >packets are tagged. But as I mentioned before, Cisco switches receive >packets on an interface untagged and then sending packets tagged out >of trunk port, based on which interface it receives, You can connect a physical interface (ethX) directly to a bridge device to access untagged packets. Note that I'm not sure whether it is safe to access the native VLAN in a trunk in this way. To continue the above example, ifconfig bridge1 addm eth3 would result in packets arriving on eth3 leaving tagged as vlan 5 in trunk1, vlan 6 in trunk0 and vice versa. -- Peter Jeremy pgphisjpKbXaP.pgp Description: PGP signature
Re: Difference between "struct addr" and "struct addrs"
On 6 March 2012 06:05, hiren panchasara wrote: > What is the difference between following 2 structs? > > /src/sys/net/if_var.h: struct ifaddr (from the comments seems like it > contains a particular address (of probably many) information for an > interface.) > > /src/include/ifaddrs.h: struct ifaddrs > struct ifaddr is the in-kernel representation of the interface address. In kernel each network interface consists of a linked list of interface addresses, described by ifaddr structures. See man ifnet(9): http://man.freebsd.org/ifnet struct ifaddrs is used in the userland BSD API getifaddrs(3). This interface is used to get interface addresses in userland programs. See how it is used in e.g. ifconfig(8) sources: /usr/src/sbin/ifconfig/ifconfig.c See man getifaddrs(3): http://man.freebsd.org/getifaddrs -- wbr, pluknet ___ 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: Difference between "struct addr" and "struct addrs"
On Mon, Mar 5, 2012 at 10:57 PM, Sergey Kandaurov wrote: > struct ifaddr is the in-kernel representation of the interface address. > In kernel each network interface consists of a linked list of interface > addresses, described by ifaddr structures. > See man ifnet(9): http://man.freebsd.org/ifnet > > struct ifaddrs is used in the userland BSD API getifaddrs(3). This > interface > is used to get interface addresses in userland programs. See how it is > used in e.g. ifconfig(8) sources: /usr/src/sbin/ifconfig/ifconfig.c > See man getifaddrs(3): http://man.freebsd.org/getifaddrs > Thanks Sergey, appreciate your help. Are they connected in any way? Can I get one if I have another? Hiren ___ 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: problem with vlan interfaces tagging/untagging in a simulated switch box
On 3/6/12, Peter Jeremy wrote: > Please don't top-post. > > > OK. Sorry, I misunderstood what you were trying to achieve. I am > using FreeBSD as a router rather than a switch. That said, I suspect > your problem is that you are misunderstanding how VLAN tagging is > applied. If a packet flows through a vlan(4) device, the appropriate > tag is removed from incoming (from the network) packets and added to > outgoing (to the network) packets. Packets flowing through normal > ethernet devies (your ethX) without also flowing through a vlan(4) are > not tagged (and so will appear in the default vlan as far as an > external switch is concerned). Internally (ie as seen by bridge(4) > instances), packets are not tagged. > > The following example diagram shows 3 distinct packet flows: > - packets tagged 5 in trunk1 and 6 in trunk0 > - packets tagged 7 in trunk1 and 9 in trunk0 > - packets tagged 8 in trunk0 and 10 in trunk2 > > +-- vlan5 --- bridge1 --- vlan6 --+ > | | > trunk1 --- eth1 -+- vlan7 --- bridge2 --- vlan9 --+-- eth0 --- trunk0 >| >bridge3 --- vlan8 --+ > | > trunk2 -- eth2 --- vlan10 > > This would be configured as: > ifconfig vlan5 vlan 5 vlandev eth1 > ifconfig vlan6 vlan 6 vlandev eth0 > ifconfig vlan7 vlan 7 vlandev eth1 > ifconfig vlan8 vlan 8 vlandev eth0 > ifconfig vlan9 vlan 9 vlandev eth0 > ifconfig vlan10 vlan 10 vlandev eth2 > ifconfig bridge1 addm vlan5 addm vlan6 > ifconfig bridge2 addm vlan7 addm vlan9 > ifconfig bridge3 addm vlan8 addm vlan10 > > -- > Peter Jeremy > I've described the function of Cisco switches in vlan tagging/untagging. In your topology, packets should be tagged when recieved on real interfaces to be send out to vlan interfaces. It would be fine when two trunks are communicating because on both side packets are tagged. But as I mentioned before, Cisco switches receive packets on an interface untagged and then sending packets tagged out of trunk port, based on which interface it receives, ___ 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"
Difference between "struct addr" and "struct addrs"
What is the difference between following 2 structs? /src/sys/net/if_var.h: struct ifaddr (from the comments seems like it contains a particular address (of probably many) information for an interface.) /src/include/ifaddrs.h: struct ifaddrs Thanks in advance, Hiren ___ 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: problem with vlan interfaces tagging/untagging in a simulated switch box
Please don't top-post. On 2012-Mar-05 13:30:36 +0330, h bagade wrote: >on layer 2 switch, ports doesn't have ip addresses and traffic comming >from a vlan port is tagged and pass through trunk port. this means >that in our freebsd box which plays the role of switch, no interfaces >should have ip addresses. OK. Sorry, I misunderstood what you were trying to achieve. I am using FreeBSD as a router rather than a switch. That said, I suspect your problem is that you are misunderstanding how VLAN tagging is applied. If a packet flows through a vlan(4) device, the appropriate tag is removed from incoming (from the network) packets and added to outgoing (to the network) packets. Packets flowing through normal ethernet devies (your ethX) without also flowing through a vlan(4) are not tagged (and so will appear in the default vlan as far as an external switch is concerned). Internally (ie as seen by bridge(4) instances), packets are not tagged. The following example diagram shows 3 distinct packet flows: - packets tagged 5 in trunk1 and 6 in trunk0 - packets tagged 7 in trunk1 and 9 in trunk0 - packets tagged 8 in trunk0 and 10 in trunk2 +-- vlan5 --- bridge1 --- vlan6 --+ | | trunk1 --- eth1 -+- vlan7 --- bridge2 --- vlan9 --+-- eth0 --- trunk0 | bridge3 --- vlan8 --+ | trunk2 -- eth2 --- vlan10 This would be configured as: ifconfig vlan5 vlan 5 vlandev eth1 ifconfig vlan6 vlan 6 vlandev eth0 ifconfig vlan7 vlan 7 vlandev eth1 ifconfig vlan8 vlan 8 vlandev eth0 ifconfig vlan9 vlan 9 vlandev eth0 ifconfig vlan10 vlan 10 vlandev eth2 ifconfig bridge1 addm vlan5 addm vlan6 ifconfig bridge2 addm vlan7 addm vlan9 ifconfig bridge3 addm vlan8 addm vlan10 -- Peter Jeremy pgp7griifAX2e.pgp Description: PGP signature
Re: igbX: could not setup receive structures
Increase the number of nmbclusters via sysctl, internally we set it to 262144. Jack 2012/3/5 Özkan KIRIK > Hi, > > I am using FreeBSD 8.2-STABLE-201105 amd64 snapshot. > System has about 200 ipfw rules. > There is 78 vlans assigned on igb3. > > igb3 interface asserts as "igb3: Could not setup receive structures" > once a day and then nic stops working. > Even ifconfig down && ifconfig up doesnt help. > > What the problem can be ? > Thanks > > > --- > igb3: flags=8943 > metric 0 mtu 1500 > > options=1bb >ether 00:1e:67:06:c5:45 >inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 >media: Ethernet autoselect (1000baseT ) >status: active > > > > pciconf -lv: > > igb0@pci0:3:0:0:class=0x02 card=0x34f28086 chip=0x10c98086 > rev=0x01 hdr=0x00 >vendor = 'Intel Corporation' >class = network >subclass = ethernet > igb1@pci0:3:0:1:class=0x02 card=0x34f28086 chip=0x10c98086 > rev=0x01 hdr=0x00 >vendor = 'Intel Corporation' >class = network >subclass = ethernet > igb2@pci0:6:0:0:class=0x02 card=0x34f28086 chip=0x10c98086 > rev=0x01 hdr=0x00 >vendor = 'Intel Corporation' >class = network >subclass = ethernet > igb3@pci0:6:0:1:class=0x02 card=0x34f28086 chip=0x10c98086 > rev=0x01 hdr=0x00 >vendor = 'Intel Corporation' >class = network >subclass = ethernet > > > -- > > #sysctl dev.igb.3. > dev.igb.3.%desc: Intel(R) PRO/1000 Network Connection version - 2.2.3 > dev.igb.3.%driver: igb > dev.igb.3.%location: slot=0 function=1 > handle=\_SB_.PCI0.MRP1.GRP1.G2P2.G2K4 > dev.igb.3.%pnpinfo: vendor=0x8086 device=0x10c9 subvendor=0x8086 > subdevice=0x34f2 class=0x02 > dev.igb.3.%parent: pci6 > dev.igb.3.nvm: -1 > dev.igb.3.enable_aim: 1 > dev.igb.3.flow_control: 3 > dev.igb.3.rx_processing_limit: 100 > dev.igb.3.link_irq: 26 > dev.igb.3.dropped: 0 > dev.igb.3.tx_dma_fail: 0 > dev.igb.3.rx_overruns: 0 > dev.igb.3.watchdog_timeouts: 0 > dev.igb.3.device_control: 1490027073 > dev.igb.3.rx_control: 67141658 > dev.igb.3.interrupt_mask: 4 > dev.igb.3.extended_int_mask: 2147484159 > dev.igb.3.tx_buf_alloc: 0 > dev.igb.3.rx_buf_alloc: 0 > dev.igb.3.fc_high_water: 58976 > dev.igb.3.fc_low_water: 58960 > dev.igb.3.queue0.interrupt_rate: 125000 > dev.igb.3.queue0.txd_head: 20 > dev.igb.3.queue0.txd_tail: 20 > dev.igb.3.queue0.no_desc_avail: 0 > dev.igb.3.queue0.tx_packets: 1136 > dev.igb.3.queue0.rxd_head: 0 > dev.igb.3.queue0.rxd_tail: 1023 > dev.igb.3.queue0.rx_packets: 0 > dev.igb.3.queue0.rx_bytes: 0 > dev.igb.3.queue0.lro_queued: 0 > dev.igb.3.queue0.lro_flushed: 0 > dev.igb.3.queue1.interrupt_rate: 8000 > dev.igb.3.queue1.txd_head: 0 > dev.igb.3.queue1.txd_tail: 0 > dev.igb.3.queue1.no_desc_avail: 0 > dev.igb.3.queue1.tx_packets: 0 > dev.igb.3.queue1.rxd_head: 0 > dev.igb.3.queue1.rxd_tail: 1023 > dev.igb.3.queue1.rx_packets: 0 > dev.igb.3.queue1.rx_bytes: 0 > dev.igb.3.queue1.lro_queued: 0 > dev.igb.3.queue1.lro_flushed: 0 > dev.igb.3.queue2.interrupt_rate: 8000 > dev.igb.3.queue2.txd_head: 0 > dev.igb.3.queue2.txd_tail: 0 > dev.igb.3.queue2.no_desc_avail: 0 > dev.igb.3.queue2.tx_packets: 0 > dev.igb.3.queue2.rxd_head: 0 > dev.igb.3.queue2.rxd_tail: 1023 > dev.igb.3.queue2.rx_packets: 0 > dev.igb.3.queue2.rx_bytes: 0 > dev.igb.3.queue2.lro_queued: 0 > dev.igb.3.queue2.lro_flushed: 0 > dev.igb.3.queue3.interrupt_rate: 8000 > dev.igb.3.queue3.txd_head: 0 > dev.igb.3.queue3.txd_tail: 0 > dev.igb.3.queue3.no_desc_avail: 0 > dev.igb.3.queue3.tx_packets: 0 > dev.igb.3.queue3.rxd_head: 0 > dev.igb.3.queue3.rxd_tail: 1023 > dev.igb.3.queue3.rx_packets: 0 > dev.igb.3.queue3.rx_bytes: 0 > dev.igb.3.queue3.lro_queued: 0 > dev.igb.3.queue3.lro_flushed: 0 > dev.igb.3.queue4.interrupt_rate: 8000 > dev.igb.3.queue4.txd_head: 0 > dev.igb.3.queue4.txd_tail: 0 > dev.igb.3.queue4.no_desc_avail: 0 > dev.igb.3.queue4.tx_packets: 0 > dev.igb.3.queue4.rxd_head: 0 > dev.igb.3.queue4.rxd_tail: 1023 > dev.igb.3.queue4.rx_packets: 0 > dev.igb.3.queue4.rx_bytes: 0 > dev.igb.3.queue4.lro_queued: 0 > dev.igb.3.queue4.lro_flushed: 0 > dev.igb.3.queue5.interrupt_rate: 8000 > dev.igb.3.queue5.txd_head: 0 > dev.igb.3.queue5.txd_tail: 0 > dev.igb.3.queue5.no_desc_avail: 0 > dev.igb.3.queue5.tx_packets: 0 > dev.igb.3.queue5.rxd_head: 0 > dev.igb.3.queue5.rxd_tail: 1023 > dev.igb.3.queue5.rx_packets: 0 > dev.igb.3.queue5.rx_bytes: 0 > dev.igb.3.queue5.lro_queued: 0 > dev.igb.3.queue5.lro_flushed: 0 > dev.igb.3.queue6.interrupt_rate: 8000 > dev.igb.3.queue6.txd_head: 0 > dev.igb.3.queue6.txd_tail: 0 > dev.igb.3.queue6.no_desc_avail: 0 > dev.igb.3.queue6.tx_packets: 0 > dev.igb.3.queue6.rxd_head: 0 > dev.igb.3.queue6.rxd_tail: 1023 > dev.igb.3.queue6.rx_packets: 0 > dev.igb.3.queue6.rx_bytes: 0 > dev.igb.3.queue6.lro_queued: 0 > dev.igb.3.queue6.lro_flushed: 0 > dev.igb.3.queue7.interrupt_rate: 8000 > dev
Re: igbX: could not setup receive structures
thank you On Mon, Mar 5, 2012 at 8:28 PM, Jack Vogel wrote: > Increase the number of nmbclusters via sysctl, internally we set it to > 262144. > > Jack > > > > 2012/3/5 Özkan KIRIK >> >> Hi, >> >> I am using FreeBSD 8.2-STABLE-201105 amd64 snapshot. >> System has about 200 ipfw rules. >> There is 78 vlans assigned on igb3. >> >> igb3 interface asserts as "igb3: Could not setup receive structures" >> once a day and then nic stops working. >> Even ifconfig down && ifconfig up doesnt help. >> >> What the problem can be ? >> Thanks >> >> >> --- >> igb3: flags=8943 >> metric 0 mtu 1500 >> >> options=1bb >> ether 00:1e:67:06:c5:45 >> inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 >> media: Ethernet autoselect (1000baseT ) >> status: active >> >> >> >> pciconf -lv: >> >> igb0@pci0:3:0:0: class=0x02 card=0x34f28086 chip=0x10c98086 >> rev=0x01 hdr=0x00 >> vendor = 'Intel Corporation' >> class = network >> subclass = ethernet >> igb1@pci0:3:0:1: class=0x02 card=0x34f28086 chip=0x10c98086 >> rev=0x01 hdr=0x00 >> vendor = 'Intel Corporation' >> class = network >> subclass = ethernet >> igb2@pci0:6:0:0: class=0x02 card=0x34f28086 chip=0x10c98086 >> rev=0x01 hdr=0x00 >> vendor = 'Intel Corporation' >> class = network >> subclass = ethernet >> igb3@pci0:6:0:1: class=0x02 card=0x34f28086 chip=0x10c98086 >> rev=0x01 hdr=0x00 >> vendor = 'Intel Corporation' >> class = network >> subclass = ethernet >> >> >> -- >> >> #sysctl dev.igb.3. >> dev.igb.3.%desc: Intel(R) PRO/1000 Network Connection version - 2.2.3 >> dev.igb.3.%driver: igb >> dev.igb.3.%location: slot=0 function=1 >> handle=\_SB_.PCI0.MRP1.GRP1.G2P2.G2K4 >> dev.igb.3.%pnpinfo: vendor=0x8086 device=0x10c9 subvendor=0x8086 >> subdevice=0x34f2 class=0x02 >> dev.igb.3.%parent: pci6 >> dev.igb.3.nvm: -1 >> dev.igb.3.enable_aim: 1 >> dev.igb.3.flow_control: 3 >> dev.igb.3.rx_processing_limit: 100 >> dev.igb.3.link_irq: 26 >> dev.igb.3.dropped: 0 >> dev.igb.3.tx_dma_fail: 0 >> dev.igb.3.rx_overruns: 0 >> dev.igb.3.watchdog_timeouts: 0 >> dev.igb.3.device_control: 1490027073 >> dev.igb.3.rx_control: 67141658 >> dev.igb.3.interrupt_mask: 4 >> dev.igb.3.extended_int_mask: 2147484159 >> dev.igb.3.tx_buf_alloc: 0 >> dev.igb.3.rx_buf_alloc: 0 >> dev.igb.3.fc_high_water: 58976 >> dev.igb.3.fc_low_water: 58960 >> dev.igb.3.queue0.interrupt_rate: 125000 >> dev.igb.3.queue0.txd_head: 20 >> dev.igb.3.queue0.txd_tail: 20 >> dev.igb.3.queue0.no_desc_avail: 0 >> dev.igb.3.queue0.tx_packets: 1136 >> dev.igb.3.queue0.rxd_head: 0 >> dev.igb.3.queue0.rxd_tail: 1023 >> dev.igb.3.queue0.rx_packets: 0 >> dev.igb.3.queue0.rx_bytes: 0 >> dev.igb.3.queue0.lro_queued: 0 >> dev.igb.3.queue0.lro_flushed: 0 >> dev.igb.3.queue1.interrupt_rate: 8000 >> dev.igb.3.queue1.txd_head: 0 >> dev.igb.3.queue1.txd_tail: 0 >> dev.igb.3.queue1.no_desc_avail: 0 >> dev.igb.3.queue1.tx_packets: 0 >> dev.igb.3.queue1.rxd_head: 0 >> dev.igb.3.queue1.rxd_tail: 1023 >> dev.igb.3.queue1.rx_packets: 0 >> dev.igb.3.queue1.rx_bytes: 0 >> dev.igb.3.queue1.lro_queued: 0 >> dev.igb.3.queue1.lro_flushed: 0 >> dev.igb.3.queue2.interrupt_rate: 8000 >> dev.igb.3.queue2.txd_head: 0 >> dev.igb.3.queue2.txd_tail: 0 >> dev.igb.3.queue2.no_desc_avail: 0 >> dev.igb.3.queue2.tx_packets: 0 >> dev.igb.3.queue2.rxd_head: 0 >> dev.igb.3.queue2.rxd_tail: 1023 >> dev.igb.3.queue2.rx_packets: 0 >> dev.igb.3.queue2.rx_bytes: 0 >> dev.igb.3.queue2.lro_queued: 0 >> dev.igb.3.queue2.lro_flushed: 0 >> dev.igb.3.queue3.interrupt_rate: 8000 >> dev.igb.3.queue3.txd_head: 0 >> dev.igb.3.queue3.txd_tail: 0 >> dev.igb.3.queue3.no_desc_avail: 0 >> dev.igb.3.queue3.tx_packets: 0 >> dev.igb.3.queue3.rxd_head: 0 >> dev.igb.3.queue3.rxd_tail: 1023 >> dev.igb.3.queue3.rx_packets: 0 >> dev.igb.3.queue3.rx_bytes: 0 >> dev.igb.3.queue3.lro_queued: 0 >> dev.igb.3.queue3.lro_flushed: 0 >> dev.igb.3.queue4.interrupt_rate: 8000 >> dev.igb.3.queue4.txd_head: 0 >> dev.igb.3.queue4.txd_tail: 0 >> dev.igb.3.queue4.no_desc_avail: 0 >> dev.igb.3.queue4.tx_packets: 0 >> dev.igb.3.queue4.rxd_head: 0 >> dev.igb.3.queue4.rxd_tail: 1023 >> dev.igb.3.queue4.rx_packets: 0 >> dev.igb.3.queue4.rx_bytes: 0 >> dev.igb.3.queue4.lro_queued: 0 >> dev.igb.3.queue4.lro_flushed: 0 >> dev.igb.3.queue5.interrupt_rate: 8000 >> dev.igb.3.queue5.txd_head: 0 >> dev.igb.3.queue5.txd_tail: 0 >> dev.igb.3.queue5.no_desc_avail: 0 >> dev.igb.3.queue5.tx_packets: 0 >> dev.igb.3.queue5.rxd_head: 0 >> dev.igb.3.queue5.rxd_tail: 1023 >> dev.igb.3.queue5.rx_packets: 0 >> dev.igb.3.queue5.rx_bytes: 0 >> dev.igb.3.queue5.lro_queued: 0 >> dev.igb.3.queue5.lro_flushed: 0 >> dev.igb.3.queue6.interrupt_rate: 8000 >> dev.igb.3.queue6.txd_head: 0 >> dev.igb.3.queue6.txd_tail: 0 >> dev.igb.3.queue6.no_desc_avail: 0 >> dev.igb.3.queue6.tx_packets: 0 >> dev.igb.3.que
igbX: could not setup receive structures
Hi, I am using FreeBSD 8.2-STABLE-201105 amd64 snapshot. System has about 200 ipfw rules. There is 78 vlans assigned on igb3. igb3 interface asserts as "igb3: Could not setup receive structures" once a day and then nic stops working. Even ifconfig down && ifconfig up doesnt help. What the problem can be ? Thanks --- igb3: flags=8943 metric 0 mtu 1500 options=1bb ether 00:1e:67:06:c5:45 inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT ) status: active pciconf -lv: igb0@pci0:3:0:0:class=0x02 card=0x34f28086 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet igb1@pci0:3:0:1:class=0x02 card=0x34f28086 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet igb2@pci0:6:0:0:class=0x02 card=0x34f28086 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet igb3@pci0:6:0:1:class=0x02 card=0x34f28086 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet -- #sysctl dev.igb.3. dev.igb.3.%desc: Intel(R) PRO/1000 Network Connection version - 2.2.3 dev.igb.3.%driver: igb dev.igb.3.%location: slot=0 function=1 handle=\_SB_.PCI0.MRP1.GRP1.G2P2.G2K4 dev.igb.3.%pnpinfo: vendor=0x8086 device=0x10c9 subvendor=0x8086 subdevice=0x34f2 class=0x02 dev.igb.3.%parent: pci6 dev.igb.3.nvm: -1 dev.igb.3.enable_aim: 1 dev.igb.3.flow_control: 3 dev.igb.3.rx_processing_limit: 100 dev.igb.3.link_irq: 26 dev.igb.3.dropped: 0 dev.igb.3.tx_dma_fail: 0 dev.igb.3.rx_overruns: 0 dev.igb.3.watchdog_timeouts: 0 dev.igb.3.device_control: 1490027073 dev.igb.3.rx_control: 67141658 dev.igb.3.interrupt_mask: 4 dev.igb.3.extended_int_mask: 2147484159 dev.igb.3.tx_buf_alloc: 0 dev.igb.3.rx_buf_alloc: 0 dev.igb.3.fc_high_water: 58976 dev.igb.3.fc_low_water: 58960 dev.igb.3.queue0.interrupt_rate: 125000 dev.igb.3.queue0.txd_head: 20 dev.igb.3.queue0.txd_tail: 20 dev.igb.3.queue0.no_desc_avail: 0 dev.igb.3.queue0.tx_packets: 1136 dev.igb.3.queue0.rxd_head: 0 dev.igb.3.queue0.rxd_tail: 1023 dev.igb.3.queue0.rx_packets: 0 dev.igb.3.queue0.rx_bytes: 0 dev.igb.3.queue0.lro_queued: 0 dev.igb.3.queue0.lro_flushed: 0 dev.igb.3.queue1.interrupt_rate: 8000 dev.igb.3.queue1.txd_head: 0 dev.igb.3.queue1.txd_tail: 0 dev.igb.3.queue1.no_desc_avail: 0 dev.igb.3.queue1.tx_packets: 0 dev.igb.3.queue1.rxd_head: 0 dev.igb.3.queue1.rxd_tail: 1023 dev.igb.3.queue1.rx_packets: 0 dev.igb.3.queue1.rx_bytes: 0 dev.igb.3.queue1.lro_queued: 0 dev.igb.3.queue1.lro_flushed: 0 dev.igb.3.queue2.interrupt_rate: 8000 dev.igb.3.queue2.txd_head: 0 dev.igb.3.queue2.txd_tail: 0 dev.igb.3.queue2.no_desc_avail: 0 dev.igb.3.queue2.tx_packets: 0 dev.igb.3.queue2.rxd_head: 0 dev.igb.3.queue2.rxd_tail: 1023 dev.igb.3.queue2.rx_packets: 0 dev.igb.3.queue2.rx_bytes: 0 dev.igb.3.queue2.lro_queued: 0 dev.igb.3.queue2.lro_flushed: 0 dev.igb.3.queue3.interrupt_rate: 8000 dev.igb.3.queue3.txd_head: 0 dev.igb.3.queue3.txd_tail: 0 dev.igb.3.queue3.no_desc_avail: 0 dev.igb.3.queue3.tx_packets: 0 dev.igb.3.queue3.rxd_head: 0 dev.igb.3.queue3.rxd_tail: 1023 dev.igb.3.queue3.rx_packets: 0 dev.igb.3.queue3.rx_bytes: 0 dev.igb.3.queue3.lro_queued: 0 dev.igb.3.queue3.lro_flushed: 0 dev.igb.3.queue4.interrupt_rate: 8000 dev.igb.3.queue4.txd_head: 0 dev.igb.3.queue4.txd_tail: 0 dev.igb.3.queue4.no_desc_avail: 0 dev.igb.3.queue4.tx_packets: 0 dev.igb.3.queue4.rxd_head: 0 dev.igb.3.queue4.rxd_tail: 1023 dev.igb.3.queue4.rx_packets: 0 dev.igb.3.queue4.rx_bytes: 0 dev.igb.3.queue4.lro_queued: 0 dev.igb.3.queue4.lro_flushed: 0 dev.igb.3.queue5.interrupt_rate: 8000 dev.igb.3.queue5.txd_head: 0 dev.igb.3.queue5.txd_tail: 0 dev.igb.3.queue5.no_desc_avail: 0 dev.igb.3.queue5.tx_packets: 0 dev.igb.3.queue5.rxd_head: 0 dev.igb.3.queue5.rxd_tail: 1023 dev.igb.3.queue5.rx_packets: 0 dev.igb.3.queue5.rx_bytes: 0 dev.igb.3.queue5.lro_queued: 0 dev.igb.3.queue5.lro_flushed: 0 dev.igb.3.queue6.interrupt_rate: 8000 dev.igb.3.queue6.txd_head: 0 dev.igb.3.queue6.txd_tail: 0 dev.igb.3.queue6.no_desc_avail: 0 dev.igb.3.queue6.tx_packets: 0 dev.igb.3.queue6.rxd_head: 0 dev.igb.3.queue6.rxd_tail: 1023 dev.igb.3.queue6.rx_packets: 0 dev.igb.3.queue6.rx_bytes: 0 dev.igb.3.queue6.lro_queued: 0 dev.igb.3.queue6.lro_flushed: 0 dev.igb.3.queue7.interrupt_rate: 8000 dev.igb.3.queue7.txd_head: 0 dev.igb.3.queue7.txd_tail: 0 dev.igb.3.queue7.no_desc_avail: 0 dev.igb.3.queue7.tx_packets: 0 dev.igb.3.queue7.rxd_head: 0 dev.igb.3.queue7.rxd_tail: 1023 dev.igb.3.queue7.rx_packets: 0 dev.igb.3.queue7.rx_bytes: 0 dev.igb.3.queue7.lro_queued: 0 dev.igb.3.queue7.lro_flushed: 0 dev.igb.3.mac_stats.excess_coll: 0 dev.igb.3.mac_stats.single_coll: 0 dev.igb.3.mac
Re: bridge interface type
On Sun, Mar 4, 2012 at 11:14 PM, Andrew Thompson wrote:
> Here is a patch that changes it but I do not know what may break.
>
Thanks a lot Andrew. So, someone might be relying on interface type of
bridge being IFT_ETHER?
Who can confirm if this is a good patch?
>
> Index: if_bridge.c
> ===
> --- if_bridge.c (revision 232321)
> +++ if_bridge.c (working copy)
> @@ -568,6 +568,7 @@ bridge_clone_create(struct if_clone *ifc, int unit
> {
>struct bridge_softc *sc, *sc2;
>struct ifnet *bifp, *ifp;
> + struct sockaddr_dl *sdl;
>int fb, retry;
>unsigned long hostid;
>
> @@ -642,6 +643,8 @@ bridge_clone_create(struct if_clone *ifc, int unit
>/* Now undo some of the damage... */
>ifp->if_baudrate = 0;
>ifp->if_type = IFT_BRIDGE;
> + sdl = (struct sockaddr_dl *)ifp->if_addr->ifa_addr;
> + sdl->sdl_type = IFT_BRIDGE;
>
>mtx_lock(&bridge_list_mtx);
>LIST_INSERT_HEAD(&bridge_list, sc, sc_list);
>
Appreciate your help,
Hiren
___
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: problem with vlan interfaces tagging/untagging in a simulated switch box
On 2012-Mar-04 10:01:07 +0330, h bagade wrote: >I have problems with vlan interfaces on freebsd. I want to make my >system like a switch with vlan ports and also a trunk port in >conjuction with other switches. I thought that vlan interfaces would >help me tagging traffic when traffic is going out the trunk port(or >when it receives on vlan ports). >The problem, I've encountered is that vlan interafaces on freebsd do >tagging/untagging when the traffic is sourced/destined from/to them >which in this case they should be assigned IP addresses. In other >words they won't tag the traffic passing through their parent >interface which I need to. I am doing this with no problems so I suspect you are doing something wrong. As an example, the following creates a IEEE802.1Q trunk on em0 with 192.168.1.0/24 untagged and the remaining subnett tagged: ifconfig em0 inet 192.168.1.123/24 ifconfig vlan10 inet 192.168.10.123/24 vlandev em0 vlan 10 ifconfig vlan11 inet 192.168.11.123/24 vlandev em0 vlan 11 ifconfig vlan12 inet 192.168.12.123/24 vlandev em0 vlan 12 ifconfig vlan13 inet 192.168.13.123/24 vlandev em0 vlan 13 Can you post the rc.conf etc entries that you are using and a description of what you are trying to achieve. -- Peter Jeremy pgppcO8hHBl6F.pgp Description: PGP signature
Current problem reports assigned to freebsd-net@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/165643 net[net] [patch] Missing vnet restores in net/if_ethersub o kern/165526 net[bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net[ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o bin/165413 net[netgraph]: ngctl(8) does not work as advertised o kern/165305 net[ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net[vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net[igb] igb freezes after about 2 weeks of uptime o kern/165174 net[patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net[ip6] Does not work through the issue of ipv6 addresse o kern/164569 net[msk] [hang] msk network driver cause freeze in FreeBS o kern/164495 net[igb] connect double head igb to switch cause system t o kern/164490 net[pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net[gre] gre misses RUNNING flag after a reboot o kern/164400 net[ipsec] immediate crash after the start of ipsec proce o kern/164265 net[netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net[igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 netfreebsd do not add itself to ping route packet o kern/162927 net[tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net[ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net[dummynet] [panic] seldom dummynet panics o kern/162509 net[re] [panic] Kernel panic may be related to if_re.c (r o kern/162153 net[em] intel em driver 7.2.4 don't compile o kern/162110 net[igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net[ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161381 net[re] RTL8169SC - re0: PHY write failed o kern/161277 net[em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net[igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 netIntel PRO/1000 connection breaks under load until rebo o kern/160693 net[gif] [em] Multicast packet are not passed from GIF0 t o kern/160420 net[msk] phy write timeout on HP 5310m o kern/160293 net[ieee80211] ppanic] kernel panic during network setup o kern/160206 net[gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net[udp] write UDPv4: No buffer space available (code=55) o kern/159795 net[tcp] excessive duplicate ACKs and TCP session freezes o kern/159629 net[ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net[tcp] [panic] panic: soabort: so_count o kern/159603 net[netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net[netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net[em] em watchdog timeouts o kern/159203 net[wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net[bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net[ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net[ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net[ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net[em] TSO breaks BPF packet captures with em driver f kern/157802 net[dummynet] [panic] kernel panic in dummynet o kern/157785 netamd64 + jail + ipfw + natd = very slow outbound traffi o kern/157429 net[re] Realtek RTL8169 doesn't work with re(4) o kern/157418 net[em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net[ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net[re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net[ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net[network.subr] [patch] stf(4) can not communicate betw o kern/157182 net[lagg] lagg interface not working together with epair o kern/156877 net[dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net[em] em0 fails to init on CURRENT after March 17 o kern/156408 net[vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net[icmp]: host can ping other subnet but no have IP from o kern/156317 net[ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net[ip6] [patch
Re: problem with vlan interfaces tagging/untagging in a simulated switch box
on layer 2 switch, ports doesn't have ip addresses and traffic comming from a vlan port is tagged and pass through trunk port. this means that in our freebsd box which plays the role of switch, no interfaces should have ip addresses. In your topology the em0 which plays the role of trunk port has ip address and also vlan interfaces under its support. if we assume that em0 is the trunk port of our switch, and em1 the port assigned to vlan 2, which doesn't have any ip address too; then all traffic comes from em1 should be labled vlan 2 tag and send out the em0. I want to achieve this. besides if anoth On 3/5/12, Peter Jeremy wrote: > On 2012-Mar-04 10:01:07 +0330, h bagade wrote: >>I have problems with vlan interfaces on freebsd. I want to make my >>system like a switch with vlan ports and also a trunk port in >>conjuction with other switches. I thought that vlan interfaces would >>help me tagging traffic when traffic is going out the trunk port(or >>when it receives on vlan ports). >>The problem, I've encountered is that vlan interafaces on freebsd do >>tagging/untagging when the traffic is sourced/destined from/to them >>which in this case they should be assigned IP addresses. In other >>words they won't tag the traffic passing through their parent >>interface which I need to. > > I am doing this with no problems so I suspect you are doing something > wrong. As an example, the following creates a IEEE802.1Q trunk on > em0 with 192.168.1.0/24 untagged and the remaining subnett tagged: > > ifconfig em0 inet 192.168.1.123/24 > ifconfig vlan10 inet 192.168.10.123/24 vlandev em0 vlan 10 > ifconfig vlan11 inet 192.168.11.123/24 vlandev em0 vlan 11 > ifconfig vlan12 inet 192.168.12.123/24 vlandev em0 vlan 12 > ifconfig vlan13 inet 192.168.13.123/24 vlandev em0 vlan 13 > > Can you post the rc.conf etc entries that you are using and a > description of what you are trying to achieve. > > -- > Peter Jeremy > ___ 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"
