Re: Bridging + VLANS + RSTP / MSTP
On 2/19/2011 7:32 PM, Tom Judge wrote: In this setup it does not matter where the root bridge is, each of the firewalls will always have on port in disguarding state as both ports lead back to the same peer bridge. With states such as: fw 1 - 1: forwarding fw 2 - 1: forwarding fw 1 - 2: disguarding - backup fw 2 - 2: disguarding - backup If I got the topology correctly, it is supposed to be like this: (Broadcast domain 1) | | | | | | (fw1) (fw2) | | | | | | (Broadcast domain 2) If fw1 is the root bridge, then it'll look like this: (Broadcast domain 1) | | | | D R (fw1) (fw2) D B | | | | (Broadcast domain 2) fw2 will have one root port and one backup, and the fw1 will have two designated ports. Since the switch will not take part in the STP, there is no single bridge. If I get the topology correctly... There is a also the caveat: The switch will probably _not_ forward the STP BPDU's from one port to another. This is because if the switch is a properly compliant bridge it will not forwards the frames as they are marked as link local ethernet multicast frame which is not allowed to forwarded by a bridge per the ethernet spec. If this is indeed the case you will make an instant forwarding loop in your network when you try to make it work. Yes this is true, but when a port is not running STP it is not considered to be part of a compliant bridge so there should be mechanism to allow forwarding BPDUs to the other bridges that run STP. Like when one combines simple unmanaged switches(with no STP functionality) with managed ones. The unmanaged ones simply forward everything they receive and the STP ones can detect and break the loops. Nikos ___ 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"
problem analysys (Re: [Panic] Dummynet/IPFW related recurring crash.)
On Sun, Feb 20, 2011 at 04:54:34AM +0100, Pawel Tyll wrote: > > I've never seen a trace like this, and no absolutely nothing about > > dummynet, sorry. > > If it is in some way em's fault, then making sure you have the latest code > > would be > > a good idea. I have a test driver that is under selective test, it does > > effect the code > > path that you seem to be in, so it might be worth a try. If you want to try > > it early > > just pipe up and I'll send it. > I'm less and less sure that it has anything to do with em. I'd like to > hear Luigi's take on all this. That being said, I'll gladly try the > new driver -- if I'm right, I'll drop under 7 day reboot threshold > later into the year anyway, so I really need a permanent solution of > some kind. Apparently next crash always comes sooner that previous > one, which coincides with growing traffic. > i fully welcome pawel's (or everyone else's) bug reports, and consider them as his contribution to improve the system and not as a way to get free consulting, so no need for him to apolgize. In fact, i even welcome direct emails if people feel i missed some reports which i should read. At the same time, everyone should understand that some bugs are hard and time-consuming to track down, and so when the presentation suggests that the problem falls in this category, even developers with deep knowledge of the subsystems involved may step back because of lack of time (and this would not be fixable even if monetary incentives were involved). Conversely, there are cases where somehow one can quickly identify a problem and a fix, and you see it coming out either as a commit to the source tree, or as a patch by email. I have done this myself many times, and have seen the same for many other developers. The way a problem is presented has a big impact on how it gets handled: in this specific case the poster is pointing out a possible culprit (which may be helpful or misleading), and gives no hint on other things that may be relevant: number of interfaces, vlans, tunnels, taps, bpf etc ? any significant other activity on the machine such as interfaces going up or down, routing deamons etc ? amount of traffic ? Without furter details, I can only trust the statements in the report, and this determines how i classify the bug and decide whether i have time or ideas to pursue it. The bug in this case seems to fall in the 'hard, irreproducible' category: panics *always* need many many days to happen on machines under heavy load, no panics on similar machines under lighter load. With a description like this, i am afraid, i can't even start looking at the problem becaue i have no chance to reproduce it. Now let's forget what is in the bug report and dig into the backtrace at http://www.freebsd.org/cgi/query-pr.cgi?pr=152360 assuming that the information there is reliable (which we cannot tell for sure, as the stack could be corrupt). Note that this is some analysis that I would expect the poster to make, because it does not require a huge amount of time and is part of the "fair" sharing of responsibilities to get a bug fixed in a cooperative enviroment. The panic seems to occur in at /usr/src/sys/amd64/amd64/exception.S:223 #7 0x80698abf in in_localaddr (in=Variable "in" is not available. ) at /usr/src/sys/netinet/in.c:115 which is a piece of code that scans the list of interfaces. The argument to in_localaddr() is an ipv4 addr passed by value, so it is certainly not guilty even if we had a bogus argument. This seems to suggest that the problem is elsewhere -- perhaps some piece of code is manipulating the IN_IFADDR list without locking, causing it to become corrupt ? cheers luigi -+--- Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/. Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -+--- ___ 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 analysys (Re: [Panic] Dummynet/IPFW related recurring crash.)
> The way a problem is presented has a big impact on how it gets handled: > in this specific case the poster is pointing out a possible culprit > (which may be helpful or misleading), and gives no hint on other > things that may be relevant: number of interfaces, vlans, tunnels, taps, > bpf etc ? any significant other activity on the machine such as interfaces > going up or down, routing deamons etc ? amount of traffic ? > Without furter details, I can only trust the statements in the report, > and this determines how i classify the bug and decide whether i have time > or ideas to pursue it. > The bug in this case seems to fall in the 'hard, irreproducible' category: > panics *always* need many many days to happen on machines under heavy load, > no panics on similar machines under lighter load. > With a description like this, i am afraid, i can't even start looking > at the problem becaue i have no chance to reproduce it. This machine is only doing dummynet traffic shaping from significant things (otherwise it runs a dhcpd, ntpd and named). It's pretty straight-forward routing, packets come in, packets come out via static routes - there are currently no routing daemons involved. As to the interfaces, there are two physical ifaces, em0 and em1, only em1 is currently used. There are 49 vlan interfaces connected to em1, and they are pretty much static, no IP address changes, no interfaces going up or down, sometimes new one is being added, but there is no automation here, and panics do not coincide with anything significant in logs, or being done manually. Traffic oscillates between 20k pps at night and close to 35-40k pps daytime, slightly more on weekends. There are currently 2556 pipes defined and traffic shaping is done with two rules: 3 pipe tablearg ip from table(100) to any in 30001 pipe tablearg ip from any to table(101) out Currently running FreeBSD 8.2-PRERELEASE #1: Fri Jan 7 17:19:28 CET 2011, but problem persists since 8.0-RELEASE net.inet.flowtable.enable=0 net.inet.ip.fw.one_pass=0 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.ip.random_id=1 net.inet.ip.forwarding=1 kern.ipc.maxsockbuf=8388608 net.inet.tcp.sendspace=4194304 net.inet.tcp.recvspace=4194304 net.inet.udp.recvspace=1048576 net.inet.udp.maxdgram=65536 net.inet.ip.fw.dyn_buckets=16384 net.inet.ip.fw.dyn_max=65536 hw.machine: amd64 hw.model: Intel(R) Xeon(R) CPU X3440 @ 2.53GHz hw.ncpu: 8 hw.byteorder: 1234 hw.physmem: 4240433152 hw.usermem: 2734768128 Base Board Information Manufacturer: Intel Corporation Product Name: S3420GP em1: port 0x1000-0x101f mem 0xb190-0xb191,0xb192-0xb1923fff irq 16 at device 0.0 on pci2 em1: Using MSIX interrupts with 3 vectors If I missed anything here, then just tell me what more I can do, my intentions were never to make this harder to debug or hide anything relevant. ___ 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 analysys (Re: [Panic] Dummynet/IPFW related recurring crash.)
On Sun, Feb 20, 2011 at 11:50:28PM +0100, Pawel Tyll wrote: ... > This machine is only doing dummynet traffic shaping from significant > things (otherwise it runs a dhcpd, ntpd and named). It's pretty > straight-forward routing, packets come in, packets come out via static > routes - there are currently no routing daemons involved. As to the > interfaces, there are two physical ifaces, em0 and em1, only em1 is > currently used. There are 49 vlan interfaces connected to em1, and > they are pretty much static, no IP address changes, no interfaces > going up or down, sometimes new one is being added, but there is no > automation here, and panics do not coincide with anything significant > in logs, or being done manually. Traffic oscillates between 20k pps at > night and close to 35-40k pps daytime, slightly more on weekends. > There are currently 2556 pipes defined and traffic shaping is done > with two rules: > > 3 pipe tablearg ip from table(100) to any in > 30001 pipe tablearg ip from any to table(101) out > ... > If I missed anything here, then just tell me what more I can do, my > intentions were never to make this harder to debug or hide anything > relevant. understood. I am just saying that for instance the vlan presence and changes is quite significant in this context. You say vlans are "pretty much static" but can you tell us who adds/remove them, assign addresses ? Also the ruleset must have something more than those two rules. >From the stack trace, the panic seems to occur in a call to the "antispoof" option which presumably is somewhere in your ruleset. If not, then the stack is corrupt. cheers luigi ___ 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 analysys (Re: [Panic] Dummynet/IPFW related recurring crash.)
> understood. I am just saying that for instance the vlan presence and > changes is quite significant in this context. > You say vlans are "pretty much static" but can you tell us who adds/remove > them, assign addresses ? It's not that much work and changes are simple and far between. I do that personally. IP addresses don't change, however I sometimes (rarely) destroy and recreate vlans. Panics don't happen immediately after this operation, or while it happens, and there were times from panic to panic that I didn't touch a thing. > Also the ruleset must have something more than those two rules. > From the stack trace, the panic seems to occur in a call to the > "antispoof" option which presumably is somewhere in your ruleset. > If not, then the stack is corrupt. Full ruleset with IP addresses removed: 00010 1691128516 deny ip from any to any not antispoof in 00020 874400106826835332 fwd [removed] ip from table(60) to table(61) 00050 3246156244 allow tcp from any to [removed] dst-port 53 // DNS Rules 50-59 000512463493 260607132 allow udp from any to [removed] // DNS Rules 50-59 00059 23891 1091822 deny ip from any to [removed] // DNS Rules 50-59 00100 32 2176 allow ip from any to any via lo0 00100 929493 48342523 deny ip from any to table(10) dst-port 131-139,445 00102 56574 2779124 fwd [removed] tcp from table(1) to not table(5) dst-port 80 00103 0 0 fwd [removed] tcp from table(2) to not table(5) dst-port 80 00104427 17244 fwd [removed] tcp from table(3) to not table(5) 00105 6 808 deny ip from table(3) to not table(5) 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 00400 0 0 deny ip from any to ::1 00500 0 0 deny ip from ::1 to any 00600 0 0 allow ipv6-icmp from :: to ff02::/16 00700 0 0 allow ipv6-icmp from fe80::/10 to fe80::/10 00800 0 0 allow ipv6-icmp from fe80::/10 to ff02::/16 00900 0 0 allow ipv6-icmp from any to any ip6 icmp6types 1 01000 0 0 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136 3 462392089 204487140826 pipe tablearg ip from table(100) to any in 30001 535282183 461888428313 pipe tablearg ip from any to table(101) out 34900 116507831216622001 skipto 35001 ip from table(10) to table(10) 35000 597825867 244960831012 fwd [removed] ip from 192.168.0.0/16 to not 192.168.0.0/16 65534 1595697378 1254723485778 allow ip from any to any 65535 0 0 allow ip from any to any 12:07AM up 1 day, 21 mins, 1 user, load averages: 0.08, 0.06, 0.01 Should IP addresses be required, I'll gladly send "uncensored" ruleset to you privately. ___ 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"
Radiotap, BPF, and related system calls
Hello, I'm somewhat of a novice C programmer endeavoring in a project to write my own protocol which will sit on top of the 1480 byte 802.3 frames (which are on top of 802.11 frames) to accomplish remote file transmission. The communication will be one way, but one roadblock I'm running into is discovering the exact system calls I have to make to send raw frames. I want to work on the higher level API as opposed to the kernel level (for one I'd like the 802.11 layer to auto fragment the 802.3 frames for me). The exact protocol will require two cards in monitor mode so that raw injection and blind reception can occur. Control signals will be transmitted over a TCP socket via the internet. I've found documentation that points to the system independent radiotap specification, and from there I've seen documentation which talks about initializing the ioctl through a BPF clone to be utilized by userland applications. I'm sure that wireshark and other wireless utilities use this, but there is a boat load of code I've been looking through to find the precise call which opens up the device ioctl, initiates the the tap, and gives me simple functions to construct and transmit my simple frames. I've found in the headers many references to the structs themselves, but I'm not sure where to start to initiate communication through the device. Any 802.11 experts on this list that could perhaps give me some specific instruction or point me to a man page / example code which does this? Thanks in advance for whatever you can offer me. ___ 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 analysys (Re: [Panic] Dummynet/IPFW related recurring crash.)
On Mon, Feb 21, 2011 at 12:13:12AM +0100, Pawel Tyll wrote: > > understood. I am just saying that for instance the vlan presence and > > changes is quite significant in this context. > > You say vlans are "pretty much static" but can you tell us who adds/remove > > them, assign addresses ? > It's not that much work and changes are simple and far between. I do > that personally. IP addresses don't change, however I sometimes > (rarely) destroy and recreate vlans. Panics don't happen immediately > after this operation, or while it happens, and there were times from > panic to panic that I didn't touch a thing. > > > Also the ruleset must have something more than those two rules. > > From the stack trace, the panic seems to occur in a call to the > > "antispoof" option which presumably is somewhere in your ruleset. > > If not, then the stack is corrupt. > Full ruleset with IP addresses removed: > 00010 1691128516 deny ip from any to any not antispoof in > 00020 874400106826835332 fwd [removed] ip from table(60) to table(61) > 00050 3246156244 allow tcp from any to [removed] dst-port 53 // > DNS Rules 50-59 > 000512463493 260607132 allow udp from any to [removed] // DNS Rules > 50-59 > 00059 23891 1091822 deny ip from any to [removed] // DNS Rules > 50-59 > 00100 32 2176 allow ip from any to any via lo0 > 00100 929493 48342523 deny ip from any to table(10) dst-port > 131-139,445 > 00102 56574 2779124 fwd [removed] tcp from table(1) to not > table(5) dst-port 80 > 00103 0 0 fwd [removed] tcp from table(2) to not > table(5) dst-port 80 > 00104427 17244 fwd [removed] tcp from table(3) to not table(5) > 00105 6 808 deny ip from table(3) to not table(5) > 00200 0 0 deny ip from any to 127.0.0.0/8 > 00300 0 0 deny ip from 127.0.0.0/8 to any > 00400 0 0 deny ip from any to ::1 > 00500 0 0 deny ip from ::1 to any > 00600 0 0 allow ipv6-icmp from :: to ff02::/16 > 00700 0 0 allow ipv6-icmp from fe80::/10 to fe80::/10 > 00800 0 0 allow ipv6-icmp from fe80::/10 to ff02::/16 > 00900 0 0 allow ipv6-icmp from any to any ip6 icmp6types > 1 > 01000 0 0 allow ipv6-icmp from any to any ip6 icmp6types > 2,135,136 > 3 462392089 204487140826 pipe tablearg ip from table(100) to any in > 30001 535282183 461888428313 pipe tablearg ip from any to table(101) out > 34900 116507831216622001 skipto 35001 ip from table(10) to table(10) > 35000 597825867 244960831012 fwd [removed] ip from 192.168.0.0/16 to not > 192.168.0.0/16 > 65534 1595697378 1254723485778 allow ip from any to any > 65535 0 0 allow ip from any to any > > 12:07AM up 1 day, 21 mins, 1 user, load averages: 0.08, 0.06, 0.01 > > Should IP addresses be required, I'll gladly send "uncensored" ruleset > to you privately. addresses not needed, thanks. From what i saw in the backtrace, the panic occurred on an incoming packet on the 'antispoof' option. The ruleset confirms the backtrace, but since 'antispoof' happens to be run on every packet given it is on the first rule, it apparently has nothing to do with dummynet because even if you reinjected the packets, they go to rule 34900. So, i'd still focus the attention on a corrupt interface list. Sure, that memory can be corrupt by anything including dummynet, but there is no reason to believe that dummynet is more likely than other subsystems to cause the breakage. Unfortunately i don't think I can be of more help. cheers luigi ___ 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 analysys (Re: [Panic] Dummynet/IPFW related recurring crash.)
> addresses not needed, thanks. From what i saw in the backtrace, the panic > occurred on an incoming packet on the 'antispoof' option. > The ruleset confirms the backtrace, but since > 'antispoof' happens > to be run on every packet given it is on the first rule, > it apparently has nothing to do with dummynet because even if > you reinjected the packets, they go to rule 34900. > So, i'd still focus the attention on a corrupt interface list. > Sure, that memory can be corrupt by anything including dummynet, > but there is no reason to believe that dummynet is more likely > than other subsystems to cause the breakage. > Unfortunately i don't think I can be of more help. Actually that's a lot of help: new thing to try. I've removed the antispoof rule and automatic reboot. Lets see what comes out of it. ___ 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: Radiotap, BPF, and related system calls
On Sunday 20 February 2011 23:56:31 Adam Stylinski wrote: > Hello, > > I'm somewhat of a novice C programmer endeavoring in a project to > write my own protocol which will sit on top of the 1480 byte 802.3 > frames (which are on top of 802.11 frames) to accomplish remote file > transmission. The communication will be one way, but one roadblock > I'm running into is discovering the exact system calls I have to > make to send raw frames. I want to work on the higher level API as > opposed to the kernel level (for one I'd like the 802.11 layer to > auto fragment the 802.3 frames for me). The exact protocol will > require two cards in monitor mode so that raw injection and blind > reception can occur. Control signals will be transmitted over a TCP > socket via the internet. I've found documentation that points to > the system independent radiotap specification, and from there I've > seen documentation which talks about initializing the ioctl through > a BPF clone to be utilized by userland applications. I'm sure that > wireshark and other wireless utilities use this, but there is a boat > load of code I've been looking through to find the precise call > which opens up the device ioctl, initiates the the tap, and gives me > simple functions to construct and transmit my simple frames. I've > found in the headers many references to the structs themselves, but > I'm not sure where to start to initiate communication through the > device. Any 802.11 experts on this list that could perhaps give me > some specific instruction or point me to a man page / example code > which does this? > > Thanks in advance for whatever you can offer me. You might want to have a look at tools/tools/net80211/wlaninject, the code there is supposed to inject raw frames into any 802.11 VAP. On a side note, you want to use ahdemo mode for packet injection, not monitor mode. -- Bernhard ___ 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"
IPv6 carp trouble
Hi everyone, I've been setting up IPv6 on the various networks I look after over the last weeks. Today the turn came to a system that's running two FreeBSD boxes with carp etc. I added an inet6 address to the ethernet interface and then the 'carp address' to carp0. The carp address is used by our upstream provider. Things appear to work except I can't ping the carp address -- even from localhost! carp0: flags=49 metric 0 mtu 1500 inet 207.171.2.194 netmask 0xfff8 inet6 2607:f238:0:11::2 prefixlen 125 carp: MASTER vhid 110 advbase 1 advskew 100 If I from the box itself ping this ::2 address, 'tcpdump -nn -i lo0' says: 06:57:47.606443 IP6 2607:f238:0:11::2 > 2607:f238:0:11::2: ICMP6, time exceeded in-transit for 2607:f238:0:11::2, length 64 06:57:47.606472 IP6 2607:f238:0:11::2 > 2607:f238:0:11::2: ICMP6, time exceeded in-transit for 2607:f238:0:11::2, length 64 06:57:47.606502 IP6 2607:f238:0:11::2 > 2607:f238:0:11::2: ICMP6, time exceeded in-transit for 2607:f238:0:11::2, length 64 06:57:47.606531 IP6 2607:f238:0:11::2 > 2607:f238:0:11::2: ICMP6, time exceeded in-transit for 2607:f238:0:11::2, length 64 06:57:47.606560 IP6 2607:f238:0:11::2 > 2607:f238:0:11::2: ICMP6, time exceeded in-transit for 2607:f238:0:11::2, length 64 If I ping the ::2 address from another box, the relevant interface shows the same response. Any ideas? - ask___ 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: [Panic] Dummynet/IPFW related recurring crash.
On 2011-Feb-20 01:39:00 +0100, Pawel Tyll wrote: >Since nobody came up with any interest in having this properly >investigated, then I suppose I'm the only one that uses dummynet for >some larger-scale traffic shaping - maybe that's my mistake? I'm using dummpnet+pf (not ipfw) on (roughly) FreeBSD 7.2 quite extensively for traffic shaping. I have about 20 pipes varying from 600kbps to 100Mbps all with ~9msec delay. There's a background load of at least 10Mbps with peaks to several times that (and several 2Mbps pipes are virtually permanently saturated). The system has nearly 80 VLANs and uses CARP and lagg/LACP (1 bge and 1 em NIC) for redundancy. The system has an uptime of several months. I haven't responded before because I can't offer any solutions. All I can say is that I've been successfully using dummynet with ipfw or pf for about a decade without any stability issues. -- Peter Jeremy pgpPOChNt5SGB.pgp Description: PGP signature
