So... I have FRR OSPF and OSPF6 up on my lan. As I've got a few VMs that
(say) act as a VPN sever, I want OSPF and OSPF6 to pick up from the bridge
that serves the VMs.
Both OSPF and OSPF6 work fine on the physical lan interfaces (in fact, on
vlan interfaces that attach to regular lan interfaces)
For everyone having lockup problems with IGB, I'd like to ask if they could
try disabling hyperthreads --- this worked for me on one system but has
been unnecessary on others.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listi
I have a FreeBSD-8.3 machine with an em0 interface in it.
em0: port 0xd400-0xd43f
mem 0xcffa-0xcffb,0xcff8-0xcff9 irq 12 at device 17.0 on
pci0
em0: [FILTER]
em0: Ethernet address: 00:0e:0c:bc:6f:87
For various reasons, I have more than one DSL interface, and for some time
I have
Heh. VirtualBox has (in my experience) been buggy as heck. Beyond buggy
as heck.
I have 3 virtualization platforms at my disposal (and the host here is win
7). VirtualBox, VMWare and Windows Virtual PC. I can report that under
VirtualBox, every major type of guest caused stability problems wit
I have a FreeBSD 9.1-RELEASE vmware guest running. It is using the
"bridged" type of networking with VMWare. It gets it's IPv4 address from
DHCP (successfully) and then fails to initialize IPv6. The relevant
rc.conf is:
ipv6_activate_all_interfaces="YES"
ifconfig_em0_ipv6="inet6 accept_rtadv"
ip
On Sun, Jun 30, 2013 at 10:39 PM, Kevin Day wrote:
>
> On Jun 30, 2013, at 6:48 PM, Zaphod Beeblebrox wrote:
>
> > I have a FreeBSD 9.1-RELEASE vmware guest running. It is using the
> > "bridged" type of networking with VMWare. It gets it's IPv4 address f
2013 at 9:21 PM, Zaphod Beeblebrox wrote:
>
>
>
> On Sun, Jun 30, 2013 at 10:39 PM, Kevin Day wrote:
>
>>
>> On Jun 30, 2013, at 6:48 PM, Zaphod Beeblebrox wrote:
>>
>> > I have a FreeBSD 9.1-RELEASE vmware guest running. It is using the
>> >
done?
If VMWare is reflecting the packet back, I'm curious as to how we can fix
this.
On Mon, Jul 22, 2013 at 1:22 AM, Zaphod Beeblebrox wrote:
> I've further narrowed this down. According to the output:
>
> em0 DAD detected duplicate IPv6 address fe80:2::250:56ff:fe2e:45fd: N
, Kimmo Paasiala wrote:
> On Tue, Jul 23, 2013 at 8:44 AM, Zaphod Beeblebrox
> wrote:
> > What to do when you don't trust the interface? VMWare is obviously
> > emulating the hardware and their interpretation of what the hardware "is"
> > is possibly differ
only one MAC per station
> and do not do the right thing in some places.
>
> I don't have an answer for you, but I'd look at the physical networking
> card/adapter on the host OS first if I were troubleshooting this. Updated
> driver/replace with something else/etc.
>
&g
Doesn't my original suggestion still stand... regardless of how this
particular problem is fixed?
That is: if the sending MAC address is _our_ MAC address, then the address
is not duplicate. It seems a simple change (unless the function that
processes the packet would have difficulty determining
I'd like to advocate implementing
http://www.freebsd.org/cgi/query-pr.cgi?pr=180893
Quoting the PR:
Some errant network equipment (including the simulation of a network
by VMware, as an example) will reflect back multicast packets to the sender.
This breaks protocols such as DAD and makes IPv6 ne
On Sat, Jul 27, 2013 at 6:46 PM, Mike Karels wrote:
> > Sure, but it would be nice to file bugs with VMware and such to ensure
> > they fix their bugs.
>
There's quite a bit of chatter about this problem on the VMWare lists.
Linux complains when these packets show up, so it isn't going unnoticed
On several machines with large numbers of IGBx interfaces, I've found that
hw.igb.enable_msix=0 is necessary to ensure proper operation.
On Fri, Aug 2, 2013 at 11:49 AM, Freddie Cash wrote:
> On Fri, Aug 2, 2013 at 12:36 AM, Steve Read wrote:
>
> > On 01.08.2013 20:07, Joe Moog wrote:
> >
> >>
Whether you feel it right, or not, net.inet.ip.forwarding must be 1 for gif
to work (even for IPv6).
On Mon, Sep 2, 2013 at 2:42 AM, Martin Laabs wrote:
> Hi,
>
> I tried to set up my raspberry PI as an ipv6 router. As a tunnel broker I
> use sixxs. Now I observed an interesting behavior:
>
> Ev
I have a network of computers at home. The gateway/firewall is FreeBSD 9.2
running mpd5. The host requesting the service is FreeBSD 9.2. The
misbehaving host is FreeBSD 10.0p6 running mpd5. So the details:
ssh is listening (output of netstat -an)
tcp4 0 0 *.22 *.*
I'm going to post again with some new information. I have a 10.0p6 machine
running mpd5 terminating a bunch of l2tp tunnels from subscribers (not
encrypted).
The specific regression between 9.2 and 10.0 is that hosts on the tunnels
cannot communicate with local services. They can ping local IPs,
It could do some good to think of the scale of the problem and maybe
the driver can tune to the hardware.
First, is 8k packet buffers a reasonable default on a GigE port?
Well... on a GigE port, you could have from 100k pps (packets per
second) at 1500 bytes to 500k pps at around 300 bytes to trul
I have had diskless FreeBSD machines before. I started this project
with an eye to booting iscsi disks, but there seems to be no way to
communicate the root disk path (and parameters) to FreeBSD ---
something that might be solvable, but I need practical at the moment.
So I fall back on NFS diskles
Replying to my own message, I add more below...
On Sun, Apr 1, 2012 at 8:44 PM, Zaphod Beeblebrox wrote:
> I have had diskless FreeBSD machines before. I started this project
> with an eye to booting iscsi disks, but there seems to be no way to
> communicate the root disk path (and p
Apr 3, 2012 at 1:27 AM, Zaphod Beeblebrox wrote:
> Replying to my own message, I add more below...
>
> On Sun, Apr 1, 2012 at 8:44 PM, Zaphod Beeblebrox wrote:
>> I have had diskless FreeBSD machines before. I started this project
>> with an eye to booting iscsi disks, but t
On Sun, Apr 29, 2012 at 8:03 PM, Michael MacLeod wrote:
> Every once and a while I run into an issue wherein the symmetric NAT of pf
> causes me grief. I've found some older mailing list entries asking about PF
> and Cone or Full Cone NAT (such as this one from 2005:
> http://www.mail-archive.com
I was wondering if anyone had considered adding "CoDel" to the queuing
infrastructure in FreeBSD. The ACM paper on it is
http://queue.acm.org/detail.cfm?id=2209336 .
The "short" of it is that current TCP behaviour encourages
router/switch buffers to always be "full" and that other solutions
like
On Sun, Sep 16, 2012 at 6:00 PM, Mike Tancsa wrote:
> On 9/16/2012 10:41 AM, Ivan Alexandrovich wrote:
>>
>> We are running freebsd9.0 on a router with
>> more than 1000 of subscriber's vlan interfaces.
>> Outgoing packet rate is approximately 40 kpps.
>>
>> There's a need to collect bytes and pac
I've got an Intel server motherboard with 4x igb (and 1x em) on it.
The motherboard in question is the S3420GPRX and the IGB's show up as:
igb0: port
0x3020-0x303f mem 0xb1b2-0xb1b3,0xb1bc4000-0xb1bc7fff irq 19
at device 0.0 on pci3
igb0: Using MSIX interrupts with 9 vectors
igb0: Etherne
A further update to my problem: it only seems to occur when there is
largely traffic "out" ie: the window is active with ... but typing in
the window seems to prevent the effect.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/li
To Jack Vogel's comment, this problem only seems to occur on systems
that are exceedingly lightly loaded (in this case, not yet in
production and I'm the only one using it).
On Tue, Nov 27, 2012 at 6:21 PM, Andre Oppermann wrote:
> r243570 in CURRENT should likely fix this issue. It's only 27 h
On Tue, Nov 27, 2012 at 9:25 PM, Mike Tancsa wrote:
> Are you using pf ? Also, did you confirm it is the igb nic and not
> something more general ? e.g. if you put in a different nic, does the
> problem go away ?
No pf, the motherboard em-driver NIC does not have this problem.
In reply to anoth
On Thu, Dec 13, 2012 at 2:31 PM, John-Mark Gurney wrote:
> > The MTU in this case is set in the ifconfig_em0 rc.conf entry and the
> > machine has been rebooted.
>
> Are you sure that the mtu is set before the ipv6 address is assigned
> to the interface? The route inherits what ever MTU was on
It seems I'm being outclassed by bug 191975. Simply put:
1. packet arrives on ngX interface (ng_iface)
2. packet destination is local
3. AFAICT packet disappears.
This is not true of packet destination is non-local. Routed packets work
as advertised. Local services (say, ssh) are also working
Urm ... question: is NS how, then, a client should be getting an IP over
PPP? I have an l2tp server configured with mpd ... and I've noticed that
mpd will allow me to turn on ipv6, but it won't assign addresses like ipv4.
On Fri, Oct 17, 2014 at 2:28 PM, prabhakar lakhera <
prabhakar.lakh...@gmai
So, as background, the minimum packet size for ethernet packets is 64
bytes. According to at least cisco, the minimum size, then, for 802.1q
(vlan, etc) packets is 68 bytes. On at least BGE and BCE interfaces, it
seems (according to counters on my switch) that FreeBSD doesn't honour this.
"show
window behavior remains.
On Mon, Nov 6, 2017 at 2:56 PM, Sean Bruno wrote:
>
>
> On 05/29/17 00:50, Zaphod Beeblebrox wrote:
> > so... I have some really OCD window scaling behavior on a GigE local
> > network. The protocol is BGP, this is one session recorded. Nearly
>
I've been trying to track this problem down for awhile now. I have two
different router servers with two different chipset on board NICs. One
server has BGE and the other server has BCE. Both are running a full
650k-odd route BGP table with quagga and they're joined internally with
OSPF (also qu
I'm interested in taking a whack at this. Where's the Linux driver? I
tried searching for aquantia in the linux kernel and didn't get a hit.
On Sun, Jun 24, 2018 at 12:51 PM Grzegorz Junka wrote:
> Hello,
>
> As far as I could check FreeBSD doesn't yet support this card. It's
> supported in Li
So... my home router has a trunked relationship to the home switch.
BGE0.31 is the guest network and has 172.17.31.1/24.
BGE0.221 is the home network and has 192.168.221.1/24.
Now on the switch, the "access" (untagged) VLAN is 1. This works: BGE0 is
192.168.110.1 and the switch's management is
So... if I choose live CD and type "ifconfig em0 up" followed by "dhclient
em0" ... everything works... but if I go through the install, select
something that isn't on the media and continue, selecting em0 as my
network, and ipv4->DHCP ... I see "sendmeg on em0: No buffer space
available" ...
If I
I suppose he could be asking, in his way, about a type of universal driver
(not unlike ndis used to be). Not knowing anything about the UEFI
environment, but recalling that PXE requires one of the more restrictive
processor modes ... would make that quite a challenge for a universal
driver.
... b
I just wanted to say that I got several Intel 10 GBE cards:
vendor = 'Intel Corporation'
device = 'Ethernet Controller 10G X550T'
and while FreeBSD support seems strong, they will not hold a 10G connection
with my UniFi swtich. The talk 1G just fine, but even with the most
expens
While my mp5 servers are possibly less busy (I havn't had common crashes),
I have noticed a "group" of problems.
1. The carrier dropping communication (ie: fiber cut or l2 switch breakage)
of the L2TP streams can leave mpd5 in a state where it will not die and
will not destroy interfaces (requires
I have an if-up mpd5 rule that says:
route -n6 add $route -iface $interface
where $route is something like 1001:abcd:1::/64 and $interface is something
like ng2.
When I go into quagga, I see:
my.router.ca# sh ipv6 route 1001:abcd:1::1
Routing entry for 1001:abcd:1::/64
Known via "kernel", dis
down bce0.
Then, quagga claims:
my.other.router.ca# sh ipv6 route 1001:abcd:1::1
Routing entry for 1001:abcd:1::/64
Known via "kernel", distance 0, metric 0, tag 0, vrf 0, best, fib
>* fe80::212:3fff:fe41:72fd, via lo0
... which is somewhat ridiculous.
On Sun, Nov 13, 2016 at
so... I have some really OCD window scaling behavior on a GigE local
network. The protocol is BGP, this is one session recorded. Nearly every
payload packet is answered by both an 'ACK' and a 2nd window scaling
packet. I have examined the packet counters: no errors reported by the box
or the man
Don't forget that, generally, as I understand it, the network stack suffers
from the same problem for 9k buffers.
On Sun, Jun 25, 2017 at 12:56 PM, Ben RUBSON wrote:
> > On 25 Jun 2017, at 17:32, Ryan Stone wrote:
> >
> > Having looking at the original email more closely, I see that you showed
Most of the cell modems (over the years) that I have seen show up as serial
devices and emulate a basic AT command set. In most cases, you need to
know the dial string for your carrier --- it's often something goofball
like "ATDT pppservice.mycarrier.com" ... and then, after connecting
speaking pp
I would also like to be on the list of possible beta testers.
On Tue, Dec 7, 2021 at 11:27 AM Santiago Martinez
wrote:
> Hi Neel, it is exciting to see the topic coming alive again.
>
> Once you think is good/ready for testing, or when you require it, i can
> avail hardware , routers and traffi
46 matches
Mail list logo
