> I have 2 machines connected on 2 ports of the same switch on which I try to
> pass a vlan 10 encapsulated in vlan 330 using dot1 q protocol. The
> configuration is very generic, but I cant ping each others machines
Did you want to have 802.1q (Ethertype 0x8100) for both inner and
outer tags? F
>> Not that I work at an ISP or tech company in a networking role, I don't.
>> Heck, adding even MPLS support has been on my bucket list for a while, but
>> am too lazy to get started. I do want to move to a networking-based role at
>> $DAYJOB, but we'll see about that.
>
> MPLS is outdated (pe
> After survey about solution for Broadcom bnxt driver issue with promiscous
> mode. I am not found any normal solution with that situation.
> Only workaround to using promiscous mode to have normal operations with these
> cards. This isn't normal by me!
>
> I look and do some debug on bnxt driv
>> I would prefer if the current behaviour stayed default (would also MFC
>> better)
>> and then flip if this will indeed go anywhere.
>
> I considered that, but I think that the current behavior is simply
> wrong. We broadcast packets to the lowest address on the net, but
> we don't receive the
> Here is eth0 which started out as bge0:
> bge0: mem
> 0x92b9-0x92b9,0x92ba-0x92ba,0x92bb-0x92bb
> at device 0.0 numa-domain 0 on pci15
> bge0: APE FW version: NCSI v1.3.7.0
> bge0: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E
...
> Surprisingly, although I
> However, while this allows all traffic sent via a specific interface to be
> marked with a PCP (priority code point), it defeats the purpose of PFC
> (priority flow control) which works by individually pausing different queues
> of an interface, provided there is an actual differentiation of t
> Partial success. The card is now able to use an SFP+ optic. It warns me
> when the optic is installed:
>
> Mar 22 16:49:45 r720-01 kernel: WARNING: Intel (R) Network Connections are
> quality tested using Intel (R) Ethernet Optics. Using untested modules is not
> supported and may cause unst
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231416
>
> Eric van Gyzen changed:
>
>What|Removed |Added
>
> CC||mar...@freebsd.org,
>> > >> And thank you for that suggestion! The packet loss during ARP refresh
>> > >> (of the destination address connected to the output interface) does
>> > >> *not* happen when the box is forwarding! It only happens with locally
>> > >> generated traffic.
>> > Should be fixed by r331098.
>>
Followup:
> > >> And thank you for that suggestion! The packet loss during ARP refresh
> > >> (of the destination address connected to the output interface) does
> > >> *not* happen when the box is forwarding! It only happens with locally
> > >> generated traffic.
> > Should be fixed by r33109
> >> And thank you for that suggestion! The packet loss during ARP refresh
> >> (of the destination address connected to the output interface) does
> >> *not* happen when the box is forwarding! It only happens with locally
> >> generated traffic.
> Should be fixed by r331098.
I can confirm tha
> > Side note: if one has monitoring which does ICMP checks, it will mask the
> > issue because icmp replies don't use route caching.
> > Typical story when the observer changes the state of an observed object
> > :-).
>
> Also perhaps why it has not been reported before, as other side effects
> >> And thank you for that suggestion! The packet loss during ARP refresh
> >> (of the destination address connected to the output interface) does
> >> *not* happen when the box is forwarding! It only happens with locally
> >> generated traffic.
> >
> > Checking once per second with "arp -n " I c
> > > > I have a reproducible problem on 11.1-STABLE where, during a longterm
> > > > iperf3 session, some packets are lost every time ARP is refreshed (every
> > > > net.link.ether.inet.max_age seconds). Checking with tcpdump, I can
> > > > indeed see that the packet loss is happening as the hosts
> > > I have a reproducible problem on 11.1-STABLE where, during a longterm
> > > iperf3 session, some packets are lost every time ARP is refreshed (every
> > > net.link.ether.inet.max_age seconds). Checking with tcpdump, I can
> > > indeed see that the packet loss is happening as the hosts are doi
ad 3 periods of packet loss, spaced 120 seconds apart.
Steinar Haug, Nethelp consulting, sth...@nethelp.no
--
# Before
sthaug@pondus% sysctl net.link.ether
net.link.ether.inet.allow_multicast: 0
net.link.ether.inet.log_arp_perm
> > I have a reproducible problem on 11.1-STABLE where, during a longterm
> > iperf3 session, some packets are lost every time ARP is refreshed (every
> > net.link.ether.inet.max_age seconds). Checking with tcpdump, I can
> > indeed see that the packet loss is happening as the hosts are doing
> > A
I have a reproducible problem on 11.1-STABLE where, during a longterm
iperf3 session, some packets are lost every time ARP is refreshed (every
net.link.ether.inet.max_age seconds). Checking with tcpdump, I can
indeed see that the packet loss is happening as the hosts are doing
ARP request/reply.
H
> > >>> The whole maintain_loopback_route should be KILLED from the kernel,
> > >>> it is simply the wrong thing to be doing.
> > >>
> > >> Only if you can supply alternative way to assign highest priority
> > >> (administrative distance = 0) for "directly connected" routes.
> > >> And ability to o
> Imagine this set up :
>
> freebsd host port0 <-> switch 1 <-> linux host port0
> freebsd host port1 <-> switch 2 <-> linux host port1
>
> On the linux box, port 0&1 are enslaved in a bond with a RR algorithm (Round
> Robin)
> On the freebsd box, port 0&1 are enslaved in a lagg.
>
> switchs 1&
Has anybody looked at Cisco VPP?
http://blogs.cisco.com/sp/a-bigger-helping-of-internet-please
It would be interesting to see comparisons with netmap.
Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
freebsd-net@freebsd.org mailing list
http
> > Plase note that by using link aggregation you can not achieve full speed
> > over
> > a single TCP stream. Onle when multiple streams are in operation you will
> > really get the aggregated speed.
>
> NP, I am have more then 40K TCP stream.
>
> PS: link aggregation with round-roubin policy
> > I don't see any problem using ULA with for instance /124 netmask:
> [...]
> > 96 bit works too:
> [...]
>
> FreeBSD version? Mine is 10.3-RELEASE-p3.
lab1 is 10.3-PRERELEASE r297313M
lab2 is 10.2-STABLE r288601M
Steinar Haug, Nethelp consulting, sth...@nethelp.no
> > Here lies the first problem. It seems that it's not legitimate to assign
> > /96 subnets when using unique local addresses (ULAs). I was right
> > getting some /48 subnet for my local IPv6 network; some easy way to get
> > one generated randomly is http://unique-local-ipv6.com/ . But instead of
> Silence means dead project? even the mpls site is dead :(
>
> linux and openbsd best choices for mpls implementation right now?
I'd probably say Juniper and Cisco myself :-) MPLS in FreeBSD is
only going to happen if there is sufficient interest *and* coding
resources. Somebody needs to do the
> it does not work with the link-local addr:
>
> $ ./ipv6-client fe80::20c:29ff:fe47:a38d
> host: fe80::20c:29ff:fe47:a38d
> ssh: connect: Network is unreachable
This is expected.
> but with appending %em0 it does work:
>
> $ ./ipv6-client fe80::20c:29ff:fe47:a38d%em0
> host: fe80::20c:29ff
> It depends on the spec of the XFP module, as well as the cabling. The spec of
> both types of modules needs to match. I asked the OP to test B2B to eliminate
> the XFP as the problem. If you have any suggestions, I'd be happy to hear
> them.
Obviously transceivers and cabling need to match
> Is there any way that you can try a reproduce this using a B2B
> configuration, or something that doesn't use XFP as a link partner? I'm
> thinking that you are correct regarding an incompatibility issue between SFP+
> and XFP.
Why do you believe that? The optical signals are the same for SF
> In short, no, I have no packet traces. Given that the DHCP code in the
> FreeBSD boot loader and NFS subsystem does not request those options, but
> that ISC-DHCP does provide them, I will go out on a limb and say that it
> must be serving them without being asked if they are configured.
In that
> Section 3.5 of RFC 2131 (the DHCP RFC) states that "...Second, in its
> initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the
> server with a list of specific parameters the client is interested in"
> and "...The client can inform the server which configuration parameters
> the cl
> It seems that the distribution includes a directory called db_sample
> with some tutorials/examples.
>
> But it also seems that the last release of wide-dhcp is 16 years old...
And I also strongly doubt that he's going to have any better luck
with his /8 net.
Steinar Haug, Nethelp consulting,
> you're right Olivier, but you know i have a user interface for dhcp and i
> should handle all the network and ranges which are inserted by user and
> logically are true. network with mask 8, logically is true and having
> million available ip address, too.
> i just wanna know if there is any solu
> Adrian, you're killing my spam filter! But yes, our use of FreeBSD at
> Netflix is hardly a science project. Http://openconnect.netflix.com
With my ISP hat on, I expect us to continue using LAGG with 10G member
links for many years - simply because 100G is so expensive. One can
hope that CFP2
> What I've intended to do, as jason is mentioned too, is assigning IP
> address to the interface but not let it works until a proper time. As I
> understand there is not any way just set the interface down besides adding
> IP! Still, any other solution?
Tested on 8.4-STABLE:
ifconfig em0 10.2.3.
> > > > However I'm only able to send IPv6 packets from my host that fit an MTU
> > > > of 1280 even though I've set the tunnel interface and per-route MTU to
> > > > 1480, based on the "outer" ethernet connection having an MTU of 1500.
> > > > Hurricane Electric supports this and I've set the MTU
> However I'm only able to send IPv6 packets from my host that fit an MTU
> of 1280 even though I've set the tunnel interface and per-route MTU to
> 1480, based on the "outer" ethernet connection having an MTU of 1500.
> Hurricane Electric supports this and I've set the MTU to 1480 on their
> s
> >> MM> ... and as far as I can tell none of them is currently usable
> >> MM> on an IPv6-only FreeBSD (like protecting a host with sshguard),
> >> MM> none of them supports stateful NAT64, nor IPv6 prefix translation :(
> >> IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will
> >
> This brings up a long standing sore point of our routing code
> which this patch makes more pronounced. When an interface link
> state is down I don't want the route to it to persist but to
> become inactive so another path can be chosen. This the very
> point of running a routing daemon. So o
> > 4BSD runs pretty well with an SMP kernel. I can test ULE and compare
> > easily. A no SMP kernel is problematic as the igb driver doesn't seem
> > to work and my onboard NICs are, sadly, igb.
> >
> this is bad luck. I know of the kernels as I have had SMP and single
> CPU machines since 4.x t
> every now and then the issue comes up on whether we still need
> to support non-contiguous masks in address lookups.
> I seem to remember someone (perhaps on this list) making a
> case for their presence, but forgot the details.
> So, does anyone know of a practical use of non contiguous masks ?
> > Are you sure? I have net.inet.tcp.signature_verify_input = 1 and only
> > one line in /etc/ipsec.conf for each BGP session using MD5 keys, on
> > 8.2-STABLE.
>
> Hmm, you are right, it seems that my second SAD entries are not used at all.
> However I'm now running with net.inet.tcp.signature_ve
> You are setting the keys with setkey for both directions of a single session,
> right?
> i.e.:
>
> add X.X.X.X Y.Y.Y.Y tcp 0x1000 -A tcp-md5 "SomePass";
> add Y.Y.Y.Y X.X.X.X tcp 0x1000 -A tcp-md5 "SomePass";
>
> As before it was only needed to set the "outgoing" direction key, which
> s
> Doug, does your kernel have TCP_SIGNATURE option? The patch[*] for
> net/openbgpd can be used as a workaround if it was due to TCP_MD5SIG
> option on the listening sockets.
>
> [*] http://people.allbsd.org/~hrs/FreeBSD/openbgpd.20120104-1.diff
>
> While this is an ugly hack and I will inv
> > I'm currently writing a driver to configure an ethernet switch chip (see
> > TL-WR1043ND on -embedded).
> >
> > I noticed that there doesn't seem to be a way to power down a phy right now
> > through the ifconfig media command.
> >
> > Would there be objections to extend the media subtype d
> > So there may have been some rc.d framework changes that address your
> > problem. Are you running -RELEASE? If so those fixes probably aren't
> > available.
>
> And here's the commit that fixed it (src/etc/network.subr, which is
> /etc/network.subr):
>
> http://www.freebsd.org/cgi/cvsweb.cg
FreeBSD 8.x (well, at least 8.2) has the very nice feature of letting
you set an interface *description* (just like you can on any Juniper/
Cisco/whatever router). This decription can contain spaces - so I can
do for instance:
xxx# ifconfig bge1 descr "abc def"
xxx# ifconfig bge1
bge1: flags=8843
> My interest is purely academic. I would like to experiment with different
> data structures to see if there is a way to increase routing performance
> with large number of routes and interfaces.
You're more likely to find routers with a large number of routes *or*
with a large number of interfac
> Is there any (no need to be official) information what is the number
> of different routes (for IPv4 and IPv6) on a default-free zone (DFZ)
> router in the Internet? I vaguely remember the number 450 000+
> distinct routes for IPv4? But what about IPv6?
See http://www.cidr-report.org - it has al
> > What we observe is:
> >
> > DHCP Request with UDP checksum set => Packet reaches DHCP Daemon and
> > is being
> > answered.
> > DHCP Request with UDP checksum 0x => ICMP Port Unreachable from
> > FreeBSD.
> >
> > Can someone confirm this non RFC conform behaviour and knows how to
> > fix
> > I do not recommend to use the rc.d/network_ipv6 script for manual
> > configuration because it often ends up an incomplete configuration as
> > you experienced. Rebooting the system would be better. The
> > rc.d/netif script on 9.X works well for that purpose without a
> > reboot, though
> > Is here any stateless dhcp6 solution for FreeBSD?
> >
> > I need only distribute IPv6 DNS server addresses to clients, but not
> > prefixes or address information.
> >
>
> DHCP is stateful. If you want stateless, you need IPv6 RDNSS router
> advertisements.
Claiming that DHCP is (alwa
> > Are you sure isc-dhcp doesn't support stateless? I was able to get it
> > working by creating subnet6 entries in dhcpd6.conf and telling rtadvd
> > to operate in other-stateful configuration mode (raflags="o"). At that
> > point, stateless autoconfiguration worked and the clients did a DHCP
> >
> How does a router that is using dhclient to get delegated a address
> prefix from an upstream router obtain its default route, since dhcpv6
> can't provide a default route.
> And since it is a router it can't get its default route from router
> advertisements from the upstream router?
It beha
> I'm trying to get a working freebsd workstation with an ipv6 network
> where addresses are received from DHCP.
Are you using IA_PD or IA_NA on your DHCPv6 server?
> ATM my IPv6 setup copies the IPv4 layout with vlans and /24 masks, so
> I'm using /120 prefixes.
> Is that even possible ?
> As
> As for me, I've got /64 network and I must split it for tunneling, etc.
> So I have more wide prefixlen for my home network. I spend a lot of time
> to get auto configuration work, but gave up and set static config on all
> my home computers. The system is really strong :)
Note that SLAAC wil
> > Does anybody have an idea of whether the patch in kern/145733 will be
> > incorporated into ip_fw2.c any time soon?
>
> That PR is mine. I've emailed people off list several times (last on
> 25 Jan) but have not made progress. To say I'm frustrated is an
> understatement.
Getting this fixed
The following reply was made to PR kern/153951; it has been noted by GNATS.
From: sth...@nethelp.no
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/153951: Intel 10GBase-LR Ethernet card detected as
10GBase-SR
Date: Sun, 06 Feb 2011 18:19:37 +0100 (CET)
> Checking some more I find that the
IPFW incorrectly handles IPv6 packets with a fragment header followed
by a last fragment only (i.e. the fragment header has fragment offset
= 0 and M bit = 0). Such packets are allowed by RFC 2460.
The problem is well described in kern/145733 from 16. April 2010, but
nothing seems to have happened
> > I'm seeing the same problem with Broadcom NetXtreme (bce) cards:
> >
> > bce0@pci0:3:0:0:class=0x02 card=0x03421014 chip=0x164c14e4
> > rev=0x12 hdr=0x00
> > vendor = 'Broadcom Corporation'
> > device = 'Broadcom NetXtreme II Gigabit Ethernet Adapter (BCM5708)'
> >
> > So, does anyone have an idea why the IP length field would be set to 0
> > for these TCP/IP packets?
> >
> > Here's some info from Ronald w.r.t. his hardware. (All I can think of is
> > that he could try disabling TSO, etc?)
> >
> > Thanks in advance for any help with this, rick
> >
>
> It
> > I have a couple of servers with Broadcom (bge) GigE interfaces. These
> > servers became completely unresponsive/unusable at high network traffic
> > (presumably due to the interrupt processing) but were able to handle the
> > same traffic with no problems after switching to polling. This was i
> > They have enough buffers (128 for each of tx and rx IIRC). The only thing
> > polling mode gave for them was lower latency, but this cost enabling
> > polling in the idle loop, which wastes 100% of at least 1 CPU and some
> > power. Without polling in idle, polling gives very high latency (ev
> The problem is that there is no mechanism right now to report on the
> fly which optics the adapter actually has. So for the ones that can
> differ I had just chosen the most likely value.
Yup, guessed as much.
> If it REALLY bothers you you can change your local code :)
Which is exactly what
> > If it has an SFP+, won't the it be LR or SR depending on the type of
> > SFP+ installed?
>
> The card is *sold* and *advertised* by Intel as a 10GBase-LR card. It
> may well be the case that it would also work with a 10GBase-SR SFP+.
> I don't have one of these lying around to test, unfortunat
> If it has an SFP+, won't the it be LR or SR depending on the type of
> SFP+ installed?
The card is *sold* and *advertised* by Intel as a 10GBase-LR card. It
may well be the case that it would also work with a 10GBase-SR SFP+.
I don't have one of these lying around to test, unfortunately. But I
h
> I have a server with an Intel X520-LR1 Ethernet card, which is a
> 10GBase-LR card:
...
> The problem is that this card is shown by ifconfig as a 10GBase-SR card:
...
> I made a 1-line patch to the 8.2-RC1 code, enclosed below, and now have
> ifconfig showing the expected value:
Problem report a
I have a server with an Intel X520-LR1 Ethernet card, which is a
10GBase-LR card:
http://ark.intel.com/Product.aspx?id=41164
The card contains the Intel 82599ES controller:
http://ark.intel.com/Product.aspx?id=41282
pciconf -lv shows:
ix0@pci0:28:0:0:class=0x02 card=0x00068086
> > I'm not surprised that it doesn't work with autonegotian if autonegotian
> > is disabled.
> > If Linux does full-duplex without autonegotiation then _they_ do it wrong
> > and Hetzner shouldn't rely on wrong behavour.
> As far as I understand, Linux does full-duplex without
> autonegotiation
> > May be linux driver defaults to full-duplex if autoneg fails?..
>
> I've seen some Linux drivers fail back to half-duplex under these
> circumstances.
>
> It may very well depend on driver version and hardware (firmware)?
>
> I admit, I don't know what layer is responsible for handling
> aut
> >> Oh I see. I haven't tried this case with FreeBSD configuring RA with
> >> default route info only. So, how your Juniper router coordinate your
> >> DHCPv6 server to inform the hosts or nodes where to get prefix info
> >> since then your router wasn't configured with pinfoflags options?
> >
> >
> > I would like to get rtadvd to send RAs completely *without* a prefix
> > info option. My Juniper routers at work can do this just fine...
>
> Oh I see. I haven't tried this case with FreeBSD configuring RA with
> default route info only. So, how your Juniper router coordinate your
> DHCPv6 ser
> >>> In IPv6 it should be possible to generate a Router Advertisement which
> >>> contains no prefix options (the idea being that I want the host to
> >>> populate its default router list but nothing else). However, I cannot
> >>> seem to get rtadvd to do this.
>
> Can you open a PR and get it as
> > You mean to say that you want your router to act as the default IPv6
> > gateway only advertising default route via RA and the IPv6 prefixes
> > are managed by other means such as DHCPv6 server? Because by its the
> > only way I can think of with your case now. You can specify
> > 'pinfoflags'
> > In IPv6 it should be possible to generate a Router Advertisement which
> > contains no prefix options (the idea being that I want the host to
> > populate its default router list but nothing else). However, I cannot
> > seem to get rtadvd to do this.
> >
> > If I start rtadvd with no /etc/rtadv
> > In IPv6 it should be possible to generate a Router Advertisement which
> > contains no prefix options (the idea being that I want the host to
> > populate its default router list but nothing else). However, I cannot
> > seem to get rtadvd to do this.
> >
> > If I start rtadvd with no /etc/rtadv
In IPv6 it should be possible to generate a Router Advertisement which
contains no prefix options (the idea being that I want the host to
populate its default router list but nothing else). However, I cannot
seem to get rtadvd to do this.
If I start rtadvd with no /etc/rtadvd.conf file, it sends R
> > So the question is - *why* would you want FreeBSD to support VPLS? And
> > what exactly do you mean by implementing VPLS on FreeBSD? If you want a
> > multipoint bridge across several interfaces, this can be done. If you want
> > something with MPLS support (labels etc) it's a completely differ
> > Are there any plans or ongoing work to implement VPLS in the network
> > stack?
> >
> > http://en.wikipedia.org/wiki/Virtual_Private_LAN_Service
>
> If you don't need interoperability with others, you can
> theoretically achieve something like VPLS using if_bridge,
> if_gif, EtherIP and the "
> I am not sure the right forum to ask this question - is there any effort done
> to find portable code between different OSes, particularly freebsd and linux?
> Specifically, the networking layer could be portable between the 2 and there
> could be some set of APIs to call into the OS specific
The following was done on a 7.3-STABLE system.
While debugging an IPv6 path MTU problem I discovered to my surprise
that the TCP host cache (use "sysctl net.inet.tcp.hostcache.list" to
see it) is also used by UDP and ICMP, at least for IPv6. Scenario:
- Run ping6 or traceroute6 (traceroute6 with
For IPv4 I have to be root to ping with a payload larger than 56 bytes:
sth...@lab1% ping -s 1472 ftp.funet.fi
ping: packet size too large: 1472 > 56: Operation not permitted
However, for IPv6 the corresponding operation works just fine:
sth...@lab1% ping6 -s 1452 -m ftp.funet.fi
PING6(1500=40+
> > We have asked Cisco repeatedly, through official channels, whether
> > they *support* /31 on Ethernet links. The answer is always that it
> > *may* work, use at your own peril.
>
> i have managed O(10^3) ciscos in isp backbone(s). /31s predominate for
> ether links in that space. though i su
> > A /31 subnet is only defined for point-to-point network links, per:
> >
> > http://www.rfc-editor.org/rfc/rfc3021.txt
> >
> > Ordinary ethernet links have BROADCAST flag set instead of POINTOPOINT.
> >
> > Regards,
> Well how do I set the POINTOPOINT flag and remove the BROADCAST-flag on
> e
> I hope this is the appropriate list. I am having issues using BPFs to
> filter out traffic captures. If I want to block a specific host by IP, the
> traffic is still recorded. I tried tcpdump and get the same results.
>
> Am I missing something?
Does your igb2 interface use VLAN encapsulatio
> Who has used tcpdump on FreeBSD 8.x and likes it? Is it just me or is
> it now far harder to investigate network problems using it?
>
> Prior to 8.x, the default output includes SEQ number ranges for any
> TCP packets with data, so a 'tcpdump -n' looks like the following and
> it's immediately
> From my perspective, putting it in a separate db outside the kernel
> kind of defeats the purpose. I thought the first patches had the
> right idea. though for me the current ability to rename an interface
> is good enough. I mean is you can cal your interface "Sydney0" or
> "Melbourne2" t
> My point has always been - if I have to add/do an ioctl I can always also
> use a library call that will read it from a .txt, .xml, .db file
> or whatever and I don't have to go to the kernel, handle all the
> string length problems there, ... especially as the kernel cannot do
> anything with th
> While playing with some OpenBSD installation I found that they have an
> interesting feature - adding description to a NIC. This is useful for
> system administrators to "tag" the interface, also, the ladvd program
> has a feature to use the SIOCSIFDESCR ioctl to document the remote CDP
> peer l
According to the comments for rev. 1.10 of netinet/ip_id.c, from
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_id.c
this is to be MFCed after 2 weeks (i.e. 2 weeks after 6. February 2008).
And yet here we are in July 2009, and 7-STABLE shows no sign of this
version of the IP id ge
> First, why is the kernel fragmenting this at all as it fits in the
> interface MTU?
Good question, I definitely disagree with this behavior and would say
that it breaks POLA. But it's documented (see the ping6 -m option).
> Can anyone fetch anything from ftp.funet.fi via IPv6? I suspect it is
>
> To my knowledge this wasn't around when the Kame guys were working on this
> stuff. I don't think a lot of time has been spent updating the v6 support
> applications since then and that's why we don't have this feature.
>
> This isn't a big deal in dual-stack networks because the clients just
> > I think you are rather confused about what Multiple FIBs is..
> > All it is is teh ability to make a packet use a particular
> > FIB on it's outgoing path. There is not such thing as an interface
> > being "In" a FIB. All interfaces are still visible to the routing code
> > by default, and The
> Perhaps the OP should rephrase his desire.
>
> To me, it sounds like he wants to turn the FBSD box into a VLAN
> aggregator, and then "trunk" the VLANs to an external router to route
> between the VLAN subnets.
It's more that I'd like my FreeBSD box to be able to handle multiple
routing tables
> I've poked about for weeks and asked similar questions in -questions and
> elsewhere without avail. Probably using the wrong keys to search and ask:
>
> I have set up a box with various vlan interfaces on it. I naively expected to
> be able to set individual "default" routes and route between
> > I changed it, and that worked like a dream. Now I get basically the
> > same throughput with IPv4 and IPv6. There are of course still issues
> > like lots of IPv6 tunnels that add extra latency - but that's not the
> > fault of FreeBSD.
> >
> > Anyway, thanks for your work. Below is a context d
> Ok, both versions had:< so->so_rcv.sb_hiwat)
>
> http://svn.freebsd.org/viewvc/base?view=revision&revision=166403
>
> changed it for IPv4 the first time,
>
> http://svn.freebsd.org/viewvc/base?view=revision&revision=172795
>
> changed it a second time for IPv4.
>
> Noone changed the
On 7-STABLE, with kern.ipc.maxsockbuf=2621440, both sides set a window
scaling factor of 6 (i.e. SYN wscale 6, SYN-ACK wscale 6) using IPv4.
With the same value of kern.ipc.maxsockbuf, using IPv6, the side which
sends the initial SYN sets a window scaling factor of only 1, while
the other side set
> Have you tried disabling speed and duplex negotiation and explicitly
> stating speed and duplex like so?
>
> ifconfig_em0="... media 1000baseTX mediaopt full-duplex"
Disagree with this piece of advice.
> Cisco switches have a notorious history of not being "friendly" with
> non-Cisco hardware.
> >I have got 96% of 100Mbps under real production load.
>
> Wouldn't the TCP/IP overhead + ethernet design (collisions) reduce this
> figure to more like 70Mbs max in the real world?
As has been pointed out, a lot of people run full duplex these days.
With FD ethernet, the maximum achievable b
> The hosts are Pentium III 900Mhz machines with 1GB of memory. How do you
> check the duplex configuration? On the switch? On the Windows NT machine?
On your FreeBSD host, you can check it with the "ifconfig" command. If
you have a managed switch, you should be able to get duplex information
thr
1 - 100 of 108 matches
Mail list logo
