Re: Call for testers: RFC 5569 (6rd) support in stf(4)
Hello Hiroki, Thanks for your reply. I think I now see how you this is supposed to work. What I didn't (crucially) get first was that the BR IPv4 address is configured at the CE when adding the IPv6 default route. It is simpler to get when 6rdPrefixLen is 32 and IPv4MaskLen is 0. Now I'm trying to figure out how to configure a CE using different parameters (all else the same with your sample setup). For example: IPv4MaskLen = 8 6rdPrefix= 2001:db8:dd00:: 6rdPrefixLen = 40 6rdBRIPv4Address = 192.0.2.1 (c0 00 02 01) given: CE WAN IPv4 = 192.0.2.2 (c0 00 02 02) so we'll get: 6rd delegated prefix (at the CE LAN side) = 2001:db8:dd00:0202::/64 To configure the LAN side interface, stf, and route: # ifconfig fxp0 inet6 2001:db8:dd00:0202::1/64 # ifconfig stf0 inet6 2001:db8:dd00:0202::/32 # route add -inet6 default 2001:db8:ddc0:0002:0100::1 Is the above correct, or am I way off target? Regards, Ondoy PS. Please note that I refer to IPv4MaskLen, 6rdPrefix, 6rdPrefixLen and 6rdBRIPv4Address as defined in RFC 5969 (newly released doc for 6rd). On Fri, Sep 24, 2010 at 2:14 PM, Hiroki Sato wrote: > Ondoy wrote > in : > > lo> I haven't tried your patch yet but I need some clarifications. > lo> RFC 5969 has the following elements for 6rd configuration: > lo> IPv4MaskLen, 6rdPrefix, 6rdPrefixLen, 6rdBRIPv4Address. > lo> > lo> >From your example, I think the following takes care of > lo> 6rdPrefix and 6rdPrefixLen: > lo> # ifconfig stf0 inet6 2001:db8:c000:0202::/32 > lo> > lo> How can we configure the IPv4MaskLen and 6rdBRIPv4Address? > > 6rdBRIPv4Address is a part just after prefixlen of an IPv6 address on > the stf. In the case of 2001:db8:c000:0202::/32, it is c000:0202 = > 192.0.2.2. When a host wants to communicate with a BR router, just > specifying an IPv6 address with embedded BR IPv4 address is fine. No > configuration of stf on that host is needed. > > lo> I suspect IPv4MaskLen is fixed at zero (use all 32 bits) in this patch.(?) > > IPv4MaskLen can be set in the IPv6 routing table, not stf interface > itself. The stf interface accepts 6rd IPv4 packet with a whole IPv4 > source address range (this is equivalent to IPv4MaskLen=0 here) once, > but it delivers the decapsulated IPv6 packet with a valid route only. > So, if no route in 2001:db8::/32 which is more specific is added, no > IPv6 packet is delivered outside of the stf. > > For example, the router has a route 2001:db8:c000:0200::/56 to > outside of the stf, IPv4MaskLen is virtually equal to /24. > > lo> As I understand from the specs, this can be variable. > lo> It seems that at the CE, the IPv4 address of the BR is automatically > lo> calculated from the dst/src IPv6 address. But what if the embedded > lo> IPv4 address is not the whole 32 bits (IPv4MaskLen > 0)? > lo> > lo> Also, you mentioned that prefixlen of stf is from 0 to 32. Is this > lo> the same as 6rdPrefixLen? > lo> I think 6rdPrefixLen can be more than 32. > > No, 6rdPrefixLen is implemented as "stf's prefixlen + 32" in the > patch. So, the range is from 32 to 64 in terms of 6rdPrefixLen. > > In short, a prefix with IPv4MaskLen=0 is always set to the stf, and > IPv4MaskLen is handled in the routing table. Yes, I agree that this > is a bit confusing and maybe I will change the design and/or the way > to configure it in more intuitive fashion. It is due to some > limitations in the internal structure of stf. > > lo> Lastly, I'm a bit confused with the IPv6 default route at the CE > lo> (set to 2001:db8:c000:0201::1) since there's supposed to be > lo> no IPv6 connection between the CE and the BR, only IPv4. > > It works like following: the CE router has a route to 2001:db8::/32 > on its stf, so an IPv6 packet with no direct IPv6 connection goes to > stf, then it will be encapsuled as a 6rd IPv4 packet, delivered to > the BR via IPv4, and decapsuled there. The IPv4 address of the BR is > embedded in that address. > > -- Hiroki > ___ 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: Default gateway on different net
Hi, Thanks for the replies :) On 23/09/2010, at 18.15, bz=li...@zabbadoz.net wrote: > On Fri, 24 Sep 2010, Hiroki Sato wrote: >> la> 1) Is the hosting provider actually forcing me to do something "bad" >> la> og plain wrong? >> >> In that situation normally you get an IP address in the /59 network >> to communicate with the gateway router from ISP. An IP address in >> your /64 network cannot directly communicate with an address in /59. But I don't get that. I actually asked the hosting provider about this, and they told me specific not to use an ip on the /59 subnet. (I can tell you that it worked, I tried :)) >> If you do not have the /59 address, I think using link-local address >> is the easiest way. As long as the gateway works correctly, you can >> get its link-local address by using the following command: > > The drawback with that is if the hosting provider changes the interface > of your gateway, moves you to a different router, ... your default route > stops working. Let me just snippet the current (and working) configuration - this is what I got from the hosting provider: IPs: 2a01:::3183:: /64 Gateway: 2a01:::3180::1 /59 And this is my rc.conf: ipv6_enable=”YES” ipv6_static_routes=”defgw” ipv6_route_defgw=”2a01:::3180:: -prefixlen 59 -iface re0” ipv6_defaultrouter=”2a01:::3180::1” ipv6_default_interface=”re0” There is 2 "issues" at the moment. The first is that the static route and defaultrouter alone will not work - the packets will still not end up at the interface re0. The additional ipv6_default_interface=”re0” will actually do this: ndp -I re0 And thats the key (in my case) - after specifying the default interface, it works. But, I still don't think this is very elegant - first of, I need to accept route advertisements in sysctl.conf with: net.inet6.ip6.accept_rtadv=1 - not even sure why, but that check is made in /etc/network.subr. Secondly, and I am still unsure if this a feature or bug in FreeBSD, but as I mentioned in an earlier post, the defaultrouter is beeing set before the static routes - and that won't work either ( check /etc/network.subr line 1057 - i simply moved default to the end ). Best regards, Lasse Brandt___ 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: Default gateway on different net
On 2010-9-24, at 12:06, Lasse Brandt wrote: > IPs: 2a01:::3183:: /64 > Gateway: 2a01:::3180::1 /59 > > And this is my rc.conf: > > ipv6_enable=”YES” > ipv6_static_routes=”defgw” > ipv6_route_defgw=”2a01:::3180:: -prefixlen 59 -iface re0” > ipv6_defaultrouter=”2a01:::3180::1” > ipv6_default_interface=”re0” This seems very complex. Have you simply tried: ipv6_defaultrouter="2a01:::3180::1" ipv6_ifconfig_re0="2a01:::3183::1 prefixlen 64" Lars
Re: Call for testers: RFC 5569 (6rd) support in stf(4)
Ondoy wrote in : lo> Hello Hiroki, lo> lo> Thanks for your reply. lo> I think I now see how you this is supposed to work. lo> What I didn't (crucially) get first was that the BR IPv4 address is configured lo> at the CE when adding the IPv6 default route. lo> lo> It is simpler to get when 6rdPrefixLen is 32 and IPv4MaskLen is 0. lo> Now I'm trying to figure out how to configure a CE using different lo> parameters (all else the same with your sample setup). lo> lo> For example: lo> IPv4MaskLen = 8 lo> 6rdPrefix= 2001:db8:dd00:: lo> 6rdPrefixLen = 40 lo> 6rdBRIPv4Address = 192.0.2.1 (c0 00 02 01) lo> lo> given: lo> CE WAN IPv4 = 192.0.2.2 (c0 00 02 02) lo> so we'll get: lo> 6rd delegated prefix (at the CE LAN side) = 2001:db8:dd00:0202::/64 lo> lo> To configure the LAN side interface, stf, and route: lo> # ifconfig fxp0 inet6 2001:db8:dd00:0202::1/64 lo> # ifconfig stf0 inet6 2001:db8:dd00:0202::/32 lo> # route add -inet6 default 2001:db8:ddc0:0002:0100::1 lo> Is the above correct, or am I way off target? Ahh, no, the embedded IPv4 address only supports exactly 32-bit length currently. I am working on the shorter case (i.e. 6rdBRIPv4Address cannot be extracted from 6rdPrefix in a simple way), so please wait for the next patch ;) The current implementation is limited to the cases of "0 < 6rdPrefixLen < 32" and BR IPv4 address is embedded in the same way as 6to4. -- Hiroki pgpwg6ZMCNENf.pgp Description: PGP signature
Re: bge watchdog timeout errors FreeBSD 7.3
Quoting Pyun YongHyeon : Please apply patch at the following URL and let me know how it goes. http://svn.freebsd.org/viewvc/base/stable/7/sys/dev/bge/if_bge.c?r1=207862&r2=208995&view=patch http://svn.freebsd.org/viewvc/base/head/sys/dev/bge/if_bge.c?r1=212302&r2=212755&view=patch Thanks for the reply! So I have to apply both of these patchs in the order you posted them? thanks Andy. ___ 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: Call for testers: RFC 5569 (6rd) support in stf(4)
On Fri, Sep 24, 2010 at 7:30 PM, Hiroki Sato wrote: > > Ahh, no, the embedded IPv4 address only supports exactly 32-bit > length currently. I am working on the shorter case > (i.e. 6rdBRIPv4Address cannot be extracted from 6rdPrefix in a simple > way), so please wait for the next patch ;) > > The current implementation is limited to the cases of "0 < > 6rdPrefixLen < 32" and BR IPv4 address is embedded in the same way as > 6to4. > OK, thanks for clarifying that. Regards, Ondoy ___ 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: bge watchdog timeout errors FreeBSD 7.3
On Fri, Sep 24, 2010 at 12:39:38PM +0100, a.sm...@ukgrid.net wrote: > Quoting Pyun YongHyeon : > > >Please apply patch at the following URL and let me know how it goes. > > > >http://svn.freebsd.org/viewvc/base/stable/7/sys/dev/bge/if_bge.c?r1=207862&r2=208995&view=patch > >http://svn.freebsd.org/viewvc/base/head/sys/dev/bge/if_bge.c?r1=212302&r2=212755&view=patch > > > > Thanks for the reply! > So I have to apply both of these patchs in the order you posted them? > Order wouldn't be important but you have to apply both patches. > thanks Andy. > > > > ___ 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: bce(4) - com_no_buffers (Again)
On 09/23/2010 02:33 PM, Tom Judge wrote:
> The throttle command I am using in the tests is the one from here:
>
> http://klicman.org/throttle/
>
>
> On 09/23/2010 02:26 PM, Tom Judge wrote:
>
>> On 09/23/2010 01:21 PM, David Christensen wrote:
>>
>>
>> Under testing I have yet to see a memory fragmentation issue with
>>
>>
>>
this
>> driver. I follow up if/when I find a problem with this again.
>>
>>
>>
>>
>>
So here we are again. The system is locking up again because of 9k
mbuf
allocation failures.
>>> Failure to allocate a new buffer should cause the driver to
>>> drop the received frame and reuse the buffer, not lock up the
>>> system. Are you seeing the lockup come from bce(4) or does
>>> it come from somewhere else due to the dropped data?
>>>
>>>
>>>
>>>
>> The lockup is not from the NIC as such, the systems have the appearance
>> of locking up as home directories are on NFS and the user information is
>> stored in a remote LDAP server. When the system starts to drop frames
>> due to lack of 9k memory regions it tends to last for a few minutes
>> (when it is really bad) and stop all traffic into the system. This
>> appears to the average user as a complete system pause.
>>
>>
>>
>>
>> Is there a way to fix the RX buffer shortage issues (when header
>> splitting is turned on) so that they are guarded by flow control.
>>
>>
>>
Maybe
>> change the low watermark for flow control when its enabled?
>>
>>
>>
>>
>>
> I'm not sure how much it would help but try changing RX low
> watermark. Default value is 32 which seems to be reasonable value.
> But it's only for 5709/5716 controllers and Linux seems to use
> different default value.
>
>
>
>
These are: NetXtreme II BCM5709 Gigabit Ethernet
So my next task is to turn the watermark related defines into sysctls
and turn on header splitting so that I can try to tune them without
having to reboot.
>>> Do you have flow control enabled? There are arguments both for
>>> and against flow control. For bce(4), I haven't tested flow control
>>> for quite a while and it's behavior may have changed since it is
>>> controlled by firmware. Keep an eye on the hardware statistics
>>> to see that's it's actively generating pause frames.
>>>
>>>
>>>
>> 3) With flow control enabled and header splitting on flood the server
>> with very small frames (200 bytes). (Using the same test as in case 1).
>> My aim is to tune the watermark here so that there are no frames dropped
>> due to BD shortages.
>>
>>
Card info unhidden:
bce0: ASIC (0x57092003); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.2);
Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.8)
So having done lots of testing with flow control turned on as well as
header splitting it seems like flow control may be broken with header
splitting?
I have been using the patch attached to play with the flow control water
marks.
I have tried with with following data points and am finding it difficult
to get flow control to kick in before the card runs out of descriptors
and starts dropping frames:
low:16high:127
low:32high:127
low:64high:127
low:96high:127
low:32high:196
low:64high:196
low:128 high:256
None of these seem to have any noticeable or effect on the drop rate or
the number of dev.bce.0.stat_FlowControlDone's in the sample period.
Thoughs?
Tom
--
TJU13-ARIN
Index: if_bce.c
===
--- if_bce.c(revision 949)
+++ if_bce.c(working copy)
@@ -511,6 +511,21 @@
SYSCTL_UINT(_hw_bce, OID_AUTO, msi_enable, CTLFLAG_RDTUN, &bce_msi_enable, 0,
"MSI-X|MSI|INTx selector");
+
+/* Tunable RX flow control low water mark. */
+/* Without header splitting the default is 32 */
+static int bce_rx_low_water_mark = BCE_L2CTX_RX_LO_WATER_MARK_DEFAULT;
+TUNABLE_INT("hw.bce.rx_low_water_mark", &bce_rx_low_water_mark);
+SYSCTL_UINT(_hw_bce, OID_AUTO, rx_low_water_mark, CTLFLAG_RDTUN,
&bce_rx_low_water_mark, 0,
+"Default RX Flow Control Low Water Mark");
+
+/* Tunable RX flow control high water mark. */
+/* Without header splitting the default is 32 */
+static int bce_rx_high_water_mark = USABLE_RX_BD / 4;
+TUNABLE_INT("hw.bce.rx_high_water_mark", &bce_rx_high_water_mark);
+SYSCTL_UINT(_hw_bce, OID_AUTO, rx_high_water_mark, CTLFLAG_RDTUN,
&bce_rx_high_water_mark, 0,
+"Default RX Flow Control High Water Mark");
+
/* ToDo: Add tunable to enable/disable strict MTU handling. */
Re: Server network interface problem?
On 2010-Sep-22 14:32:52 -0400, Carlos Kamtha wrote: >To solve this problem, i plugged out the network cable and plugged it back in. >... >a.) Could this be an issue with the driver on this release for em0? Possibly - there have been some issues with em(4) and some chipsets. Alternatively, it could equally well have been a glitch on the associated switchport. >b.) Why was I not able to ssh to the client servers while the NFS server was >down? Logging into a client entails filesystem accesses and if any of those filesystems are NFS mounted then those accesses will block if the NFS server is non-responding. Note that by default, sshd will search /lib, /usr/lib and /usr/local/lib (as well as subordinate compat libraries) to dlopen() nss modules - which means that a local root and /usr could still block if you have a NFS mounted /usr/local. -- Peter Jeremy pgphPQD1bqcxe.pgp Description: PGP signature
