Re: [CALL FOR TESTERS] ng_bridge(4) multithreaded
On Sat, Nov 19, 2005 at 05:32:35PM +, Wojciech A. Koszek wrote: > Hello, > > With Gleb's help I've written patch for ng_bridge(4) which makes it ready > for running multithreaded. I think it would be better to let more people > test it. Patch is here: > > http://freebsd.czest.pl/dunstan/FreeBSD/ng_bridge_locking.2 > > Comments and eventual reports from anyone who uses ng_bridge(4) on MP > machine are welcome. > The comment preceding the ng_bridge_put() function should be updated accordingly, to account for KASSERT() removal and a function being "void" now. Otherwise, looks good. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpUQ0cCpvawL.pgp Description: PGP signature
Current problem reports assigned to you
Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description --- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit o [2005/11/03] kern/88450 net SYN+ACK reports strange size of window 2 problems total. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gratuitous ARP from CARP backup host
On Sun, Nov 20, 2005 at 01:04:40AM +0900, Kazuaki Oda wrote: K> I reported a problem a few days ago that CARP backup host replies ARP K> request. This problem has been fixed, thanks. But I found one more K> problem. K> K> 1) master host and backup host are connected to the same layer 3 K>switch. K> K> 2) at master host, I run the following command: K># ifconfig carp2 create K># ifconfig carp2 vhid 22 advskew 10 pass 192.168.1.7/24 K> K> 3) master host sends gratuitous ARP. K> K> 4) at backup host, I run the following command: K># ifconfig carp2 create K># ifconfig carp2 vhid 22 advskew 100 pass 192.168.1.7/24 K> K> 5) backup host sends gratuitous ARP. K>And so, layer 3 switch sends packets addressed for 192.168.1.7 to K>the port connected to backup host, sigh... Does it sends packets until next advertisement from master or forever? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: arp-proxy
> > On Thu, Nov 17, 2005 at 04:52:03PM +0100, Jon Otterholm wrote: > > > Scenario#1: > > > -I have a range of ip's, for example 215.10.10.0 - 215.10.10.255. > > > -I want to distrubute theese ip's to my customers via DHCP. > > > -They are all atached to me via a VLAN-trunk on a unique VID > > > -I have 200+ customers. Let me see if I can summarise your requirements: vlan1 cust1 , \ service network vlan2\ trunkedsingle subnet x.y.z.0/24 cust2 ---===*--++--- / || vlan3 /DHCP srv router ---> Internet cust3 ' The constraints are: - cust1, cust2, cust3 are all on the same subnet x.y.z.0/24 and get an IP address allocated by DHCP - However, the MAC address for cust1 must never appear as a source MAC address on vlan2 or vlan3, as this would confuse the provider's trunked switching infrastructure So you can't just bridge all the VLANs together. Rather: 1. a broadcast from custX must appear on the service network, but not on any of the other customer VLANs. More strongly, no packet from custX may appear on any other VLAN apart from the service network. [*] 2. a broadcast from the service subnet should appear on all customer VLANs (e.g. ARP from DHCP server or router) 3. an ARP request for custY from custX must be proxy-ARP responded to by a device on the service network, otherwise customers wouldn't be able to communicate with each other. 4. a unicast packet from the service network to a customer must be forwarded to the correct customer VLAN Is that a reasonable summary? Taking that as the base: Point (4) implies that a bridge forwarding table must still be built, because the device performing this function (labelled '*' in the above diagram) needs to associate a MAC address with a VLAN, and do so by learning rather than static configuration. Point (1) says that you can't just bridge all the VLANs together, because otherwise a packet to a broadcast address or to an unknown MAC address would be forwarded to all the other VLANs. We want this to happen for packets originating from the service network (point (2)), but not for packets which originate from the customer networks. So, some sort of L2 forwarding filter should do the trick: configure it so that packets may only be forwarded to customer VLANs if they originate from the service network. If this filter is applied, you guarantee that a customer's MAC address will never appear as a source on any other VLAN. Point (3), proxy ARP, is easy enough. You know all the possible customer IPs - they are exactly the range assigned to the DHCP server to allocate - and therefore you can proxy-ARP respond for any IP address within the DHCP range, as long as the request originated from a customer VLAN (which can also be determined by the ARP source IP). The router itself could perform this proxy ARP function, or else any server on the service network running something like choparp (which can give out the router's MAC address in the ARP responses). IP datagrams from custX to custY then go custX->router->custY. So actually, when thought about like this, the L2 masquerading requirement vanishes, and what you really need is bridging plus some L2 filtering based on ingress and egress interfaces. Unfortunately, I don't know if FreeBSD has this level of L2 filtering (I note that the bridge(4) documentation says that ipf/ipfw filtering only works for IP datagrams). However a frob on the bridging code should be possible; call the first interface 'master' and the rest 'slaves', and have a rule so that packets to a 'slave' interface are only forwarded if they originated from the 'master' interface. Aside: the network as designed above has an obvious flaw that any customer can DHCP for as many different machines as they wish, and therefore exhaust your DHCP pool. You could have a separate mini DHCP server listening on each VLAN and only handing out a single IP, but that doesn't stop customers stealing other customer's IPs through static configuration. So actually, I think you need anti-spoofing filters on each VLAN too. Doing that, you end up statically routing a separate IP down each VLAN, in which case what you *really* want is to be able to configure each VLAN subinterface as if it were a point-to-point interface. But I don't think FreeBSD supports that on broadcast media. Regards, Brian. [*] Or if it did appear on the other customer VLANs, it would have to be masqueraded to appear as if it came from a MAC address on the service network; however I believe this isn't actually necessary, as the only broadcasts we really care about here are ARP requests. All others can be dropped, and indeed probably should be dropped so that all your customers don't get drowned in each other's broadcast traffic. __
Re: gratuitous ARP from CARP backup host
Gleb Smirnoff wrote: On Sun, Nov 20, 2005 at 01:04:40AM +0900, Kazuaki Oda wrote: K> I reported a problem a few days ago that CARP backup host replies ARP K> request. This problem has been fixed, thanks. But I found one more K> problem. K> K> 1) master host and backup host are connected to the same layer 3 K>switch. K> K> 2) at master host, I run the following command: K># ifconfig carp2 create K># ifconfig carp2 vhid 22 advskew 10 pass 192.168.1.7/24 K> K> 3) master host sends gratuitous ARP. K> K> 4) at backup host, I run the following command: K># ifconfig carp2 create K># ifconfig carp2 vhid 22 advskew 100 pass 192.168.1.7/24 K> K> 5) backup host sends gratuitous ARP. K>And so, layer 3 switch sends packets addressed for 192.168.1.7 to K>the port connected to backup host, sigh... Does it sends packets until next advertisement from master or forever? Forever. Master host never receives the packets. Kazuaki Oda ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gratuitous ARP from CARP backup host
On Mon, Nov 21, 2005 at 08:41:31PM +0900, Kazuaki Oda wrote: K> >On Sun, Nov 20, 2005 at 01:04:40AM +0900, Kazuaki Oda wrote: K> >K> I reported a problem a few days ago that CARP backup host replies ARP K> >K> request. This problem has been fixed, thanks. But I found one more K> >K> problem. K> >K> K> >K> 1) master host and backup host are connected to the same layer 3 K> >K>switch. K> >K> K> >K> 2) at master host, I run the following command: K> >K># ifconfig carp2 create K> >K># ifconfig carp2 vhid 22 advskew 10 pass 192.168.1.7/24 K> >K> K> >K> 3) master host sends gratuitous ARP. K> >K> K> >K> 4) at backup host, I run the following command: K> >K># ifconfig carp2 create K> >K># ifconfig carp2 vhid 22 advskew 100 pass 192.168.1.7/24 K> >K> K> >K> 5) backup host sends gratuitous ARP. K> >K>And so, layer 3 switch sends packets addressed for 192.168.1.7 to K> >K>the port connected to backup host, sigh... K> > K> >Does it sends packets until next advertisement from master or forever? K> K> Forever. K> Master host never receives the packets. Well, I'm afraid I will just answer that your L3 switch is stupid, if it builds its FIB based only on ARP packets. The correct behavior IMHO would be to correct FIB on every packet with given IP address as src. Since master continously sends the CARP announcements, the FIB of the switch should be corrected in next second. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: arp-proxy
You got it all right. Antispoof sounds nice. The reason why I have to proxy-arp mac between VLANs is that one mac cannot end up mapped to more than one port in the switches FDB. If they do - we get something called "host-flapping" on IOS-language. /Jon On Mon, 2005-11-21 at 11:28 +, Brian Candler wrote: > > > On Thu, Nov 17, 2005 at 04:52:03PM +0100, Jon Otterholm wrote: > > > > Scenario#1: > > > > -I have a range of ip's, for example 215.10.10.0 - 215.10.10.255. > > > > -I want to distrubute theese ip's to my customers via DHCP. > > > > -They are all atached to me via a VLAN-trunk on a unique VID > > > > -I have 200+ customers. > > Let me see if I can summarise your requirements: > > vlan1 > cust1 , > \ service network > vlan2\ trunkedsingle subnet x.y.z.0/24 > cust2 ---===*--++--- > / || > vlan3 /DHCP srv router ---> Internet > cust3 ' > > The constraints are: > > - cust1, cust2, cust3 are all on the same subnet x.y.z.0/24 and get an IP > address allocated by DHCP > > - However, the MAC address for cust1 must never appear as a source MAC > address on vlan2 or vlan3, as this would confuse the provider's > trunked switching infrastructure > > So you can't just bridge all the VLANs together. Rather: > > 1. a broadcast from custX must appear on the service network, but not >on any of the other customer VLANs. More strongly, no packet from >custX may appear on any other VLAN apart from the service network. [*] > > 2. a broadcast from the service subnet should appear on all customer VLANs >(e.g. ARP from DHCP server or router) > > 3. an ARP request for custY from custX must be proxy-ARP responded to by >a device on the service network, otherwise customers wouldn't be able to >communicate with each other. > > 4. a unicast packet from the service network to a customer must be forwarded >to the correct customer VLAN > > Is that a reasonable summary? Taking that as the base: > > Point (4) implies that a bridge forwarding table must still be built, > because the device performing this function (labelled '*' in the above > diagram) needs to associate a MAC address with a VLAN, and do so by > learning rather than static configuration. > > Point (1) says that you can't just bridge all the VLANs together, because > otherwise a packet to a broadcast address or to an unknown MAC address would > be forwarded to all the other VLANs. We want this to happen for packets > originating from the service network (point (2)), but not for packets which > originate from the customer networks. So, some sort of L2 forwarding filter > should do the trick: configure it so that packets may only be forwarded to > customer VLANs if they originate from the service network. If this filter is > applied, you guarantee that a customer's MAC address will never appear as a > source on any other VLAN. > > Point (3), proxy ARP, is easy enough. You know all the possible customer IPs > - they are exactly the range assigned to the DHCP server to allocate - and > therefore you can proxy-ARP respond for any IP address within the DHCP > range, as long as the request originated from a customer VLAN (which can > also be determined by the ARP source IP). The router itself could perform > this proxy ARP function, or else any server on the service network running > something like choparp (which can give out the router's MAC address in the > ARP responses). IP datagrams from custX to custY then go > custX->router->custY. > > So actually, when thought about like this, the L2 masquerading requirement > vanishes, and what you really need is bridging plus some L2 filtering based > on ingress and egress interfaces. > > Unfortunately, I don't know if FreeBSD has this level of L2 filtering (I > note that the bridge(4) documentation says that ipf/ipfw filtering only > works for IP datagrams). However a frob on the bridging code should be > possible; call the first interface 'master' and the rest 'slaves', and have > a rule so that packets to a 'slave' interface are only forwarded if they > originated from the 'master' interface. > > Aside: the network as designed above has an obvious flaw that any customer > can DHCP for as many different machines as they wish, and therefore exhaust > your DHCP pool. You could have a separate mini DHCP server listening on each > VLAN and only handing out a single IP, but that doesn't stop customers > stealing other customer's IPs through static configuration. So actually, I > think you need anti-spoofing filters on each VLAN too. > > Doing that, you end up statically routing a separate IP down each VLAN, in > which case what you *really* want is to be able to configure each VLAN > subinterface as if it were a point-to-point interface. But I don't think > FreeBSD supports that
Re: arp-proxy
On Mon, Nov 21, 2005 at 01:45:44PM +0100, Jon Otterholm wrote: > The reason why I have to proxy-arp mac between VLANs is that one mac > cannot end up mapped to more than one port in the switches FDB. If they > do - we get something called "host-flapping" on IOS-language. Or put it another way - Cisco haven't properly virtualised their VLANs so that they have separate forwarding tables. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: arp-proxy
I think they do that when using standard 802.1Q, but for some reason theey don't when running QinQ... /Jon On Mon, 2005-11-21 at 13:00 +, Brian Candler wrote: > On Mon, Nov 21, 2005 at 01:45:44PM +0100, Jon Otterholm wrote: > > The reason why I have to proxy-arp mac between VLANs is that one mac > > cannot end up mapped to more than one port in the switches FDB. If they > > do - we get something called "host-flapping" on IOS-language. > > Or put it another way - Cisco haven't properly virtualised their VLANs so > that they have separate forwarding tables. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [CALL FOR TESTERS] ng_bridge(4) multithreaded
On Mon, Nov 21, 2005 at 11:45:48AM +0200, Ruslan Ermilov wrote: > On Sat, Nov 19, 2005 at 05:32:35PM +, Wojciech A. Koszek wrote: > > Hello, > > > > With Gleb's help I've written patch for ng_bridge(4) which makes it ready > > for running multithreaded. I think it would be better to let more people > > test it. Patch is here: > > > > http://freebsd.czest.pl/dunstan/FreeBSD/ng_bridge_locking.2 > > > > Comments and eventual reports from anyone who uses ng_bridge(4) on MP > > machine are welcome. > > > The comment preceding the ng_bridge_put() function should be > updated accordingly, to account for KASSERT() removal and a > function being "void" now. Otherwise, looks good. Thanks! Could you take a look at: http://freebsd.czest.pl/dunstan/FreeBSD/ng_bridge_locking.3 -- * Wojciech A. Koszek && [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
System-induced packetloss on FreeBSD 4.11?
Hi all, Running FreeBSD 4.11, we have noticed that some operations done on one physical network interface seems to cause packet drops on other interfaces on the system. For example, starting a dhclient process on interface em0 will cause a few packets to get dropped on the active interface em1. Doing "ifconfig em0 down ; ifconfig em0 up" will also have the same effect. Has anyone else experienced this and does anyone know why it happens? It's not a major problem but it would be nice to know what causes it so we'll know when to expect it as we're using the system for measurements of, among other things, packet loss. We're using Intel em(4) cards, on FreeBSD 4.11-RELEASE + Marko's network stack virtualization patch. Regards, /Ragnar ___ 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 broadcast
On Thu, Nov 17, 2005 at 02:42:13PM +0100, Dag-Erling Sm?rgrav wrote: > I have a box that amongst other tasks serves as a printer server and a > wlan bridge. The wired and wireless interfaces are members of the > bridge, and are unconfigured (except for ssid etc. on the wireless > interface). The bridge itself has an IP address, is subject to packet > filtering etc. > > There is a hitch, though: the bridge does not have the IFF_BROADCAST > flag set, so CUPS browsing (which is based on sending printer status > announcements to the broadcast address) doesn't work. I think this was just an oversight. > Is there any reason why a bridge can't have the IFF_BROADCAST set - if > not unconditionally, then at least when all its members have it? Since we are an ethernet bridge i'd say set it unconditionally, I will do it soon unless anyone says otherwise. Andrew ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
