Getting netgraph stats

[Paul Thornton]

I am having a problem monitoring network stats on jails on a host.

Scenario:
One host, FreeBSD 12.1, with a small number of vnet jails.

I'm using netgraph to bridge two or more VLANs from physical NICs into 
each jail - so each jail has at least 2 ngether interfaces which are the 
only NICs in the jail.


All of this works well.

And then I wanted to see what each of my ngethX interface statistics 
were doing - from my host.  snmpd only sees the physical NICs (of 
course, because the ngeth ones don't appear any more since the jails are 
started - they all moved to the jails).


As another approach, is there any way for me to get the network stats 
(in/out packets and in/out bytes) from my ngeth netgraph nodes directly?


Or have I missed some other way?  I really need to monitor the jails 
from the outside as I cannot guarantee I can reach snmpd running inside 
the jail (think of the jail as being a private environment where I 
cannot route my SNMP requests to).


Thanks

Paul.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Netgraph VLANs on Hyper-V

[Paul Thornton]

Hi,

I have recently been testing with jails, vnet and netgraph on ESXi - so 
not Hyper-V - but to make this work I needed to:


ngctl msg vmx0: setpromisc 1
ngctl msg vmx0: setautosrc 0

outside of the jail when setting up netgraph (where vmx0 is the "real" 
NIC that the ng_vlans are part of).


and then I had to set the mac address for the ngeth interface that was 
set to be put into the jail


ifconfig ngeth0 ether 02:00:01:02:03:04

Once done, and the jail started, ngeth0 worked as expected.

In ESXi, the portgroup that vmx0 is connected to allowed spoofing and 
promiscuous mode.


Paul.


On 10/04/2020 08:07, Reshad Patuck wrote:

Hi,

I am trying to use ng_vlan on Hyper-V to deploy vnet jails.
The "Enable MAC address Spoofing" setting on the Hyper-V host is enabled.
However when I try to use ng_vlan I am not able to reach the jail.
If I change this to if_vlan instead everything works fine.

Is there something that creating a VLAN using ifconfig does that ng_vlan
does not.
The same setup works well on VMware ESXi, Xen and KVM.

I am not sure if this is relevant to my issue but the hn1 devices sysrc's
changes when I use different vlan methods:

no vlan:
dev.hn.1.rxfilter: 9
dev.hn.1.hwassist: 17

if_vlan:
dev.hn.1.rxfilter: 20
dev.hn.1.hwassist: 17

ng_vlan:
dev.hn.1.rxfilter: 9
dev.hn.1.hwassist: 0

All the other sysrc's either stay the same or seem to be counters.
I can provide you with scripts to setup vlans and jails with both if_vlan
and ng_vlan if that helps.

Any help understanding what these sysrc's do, or on how I could get ng_vlan
to work would be very appreciated.

Best,

Reshad
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


--
Paul Thornton

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: How can I send packets to 255.255.255.255 from the command line?

[Paul Thornton]

On 18/08/2016 21:55, Ryan Stone wrote:

On Thu, Aug 18, 2016 at 4:48 PM, Paul A. Procacci 
wrote:


You should be able to ping the local subnet.
Alternatively you can use net/arping.

~Paul



I'm specifically looking to test the handling of 255.255.255.255, so a
local broadcast address is out.  Unfortunately, arping doesn't seem to do
the right thing on FreeBSD.  It manages to get the kernel to try arp'ing
for 255.255.255.255.


This very likely comes under the heading of "horrible bodges" but when I 
needed to do this, after much experimenting I added a static route to 
255.255.255.0/24 pointing to the local LAN broadcast address.


For example, on a machine with address 192.168.10.10/24 the "fix" would be:
route add 255.255.255.0/24 192.168.10.255

My code could then happily send UDP to 255.255.255.255 without issue, 
and the packets make it out onto the wire with a broadcast destination 
MAC address.


This was under 10.1-RELEASE; things may have changed that make it no 
longer work.


I did warn you that it came under the heading of "horrible bodges" :)

Paul.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Frequent hickups on the networking layer

[Paul Thornton]

Hi,

On 28/04/2015 22:06, Rick Macklem wrote:

... If your
net device driver is one that allocates 9K jumbo mbufs for receive
instead of using a list of smaller mbuf clusters, I'd guess this is
what is biting you.


Apologies for the thread drift, but is there a list anywhere of what 
drivers might have this issue?


I've certainly seen performance decrease in the past between two 
machines with igb interfaces when the MTU was raised to use 9k frames.


Paul.
___
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: net.inet.ip.forwarding is mysteriously set to 0

[Paul Thornton]

Hi

On 27/04/2015 06:41, Julian Elischer wrote:


Basically all the setup scripts in /etc/rc.d (andaother setup scripts in
/etc and /usr/local/etc)
all source /etc/rc.conf and it's friends (defaults etc.)
if any of thse scripts gets called (for example by devd when it notices
a new interface),
then the entire chain of dependencies related to that chain will be run
**according to how the config files tell it to run* *
and not how the current sysctls are set.
if you think about it, this must be the case as htey need to change the
sysctls as part of
their operation.

maybe we should have a script to do what you want and also uses sysrc(8)
to make it permanent.


I don't think this is a major problem to be honest.

The issue I had back in January is that the behaviour changed with an 
upgrade to 10.1 from 8.something as the interaction with devd wasn't 
well known.


I don't know how this can be dealt with unless we have a load of 
special-cases that log warnings when, for example, forwarding is enabled 
in sysctl.conf but there isn't a gateway_enable in rc.conf.  That sounds 
like a messy solution to be honest.


Paul.
___
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: net.inet.ip.forwarding is mysteriously set to 0

[Paul Thornton]

Hi

This happens when any interface is created if you've enabled forwarding 
with the sysctl and not using gateway_enable in rc.conf.  It is easily 
fixed though.


See this thread from January:
https://docs.freebsd.org/cgi/getmsg.cgi?fetch=403720+0+archive/2015/freebsd-net/20150104.freebsd-net

Paul.

On 24/04/2015 17:47, Paul S. wrote:

Can confirm that anything to do with netif restart on a forwarding
interface also creates the same problem.

On 4/25/2015 午前 01:46, Nikos Vassiliadis wrote:

Hi,

Just saw this. Can somebody re-produce this?


root@m4fh2:~ # sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: 1
root@m4fh2:~ # ifconfig bridge0 create
root@m4fh2:~ # sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: 0


That's on GENERIC 10-STABLE from the day before yesterday.

Thanks,
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


___
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

___
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: ifconfig greX create disables IPv6 forwarding

[Paul Thornton]

On 09/02/2015 16:34, Daniel Corbe wrote:


For some reason, every time I create a GRE interface on a FreeBSD IPv6
gateway, net.inet6.ip6.forwarding is disabled.  As long as I manually
re-enable it with sysctl, both the GRE tunnel and the IPv6 network
behind this machine will continue to work; however, it's certainly far
from ideal.

I stumbled acro

I discovered this in January.  See this thread:

http://lists.freebsd.org/pipermail/freebsd-net/2015-January/040797.html

Are you enabling forwarding using ipv6_gateway_enable in rc.conf, or are 
you just setting net.inet6.ip6.forwarding to 1 in sysctl.conf?


devd gets involved running /etc/rc.d/netif start and that seems to check 
(and set) the forwarding sysctls based on the rc.conf entries - so if 
you've set them manually they get reset when a new interface is 
brought up.


Adding ipv6_gateway_enable=YES in /etc/rc.conf should fix this.

Paul.
___
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: Issue with forwarding when creates new interface [was USB Tethering and forwarding]

[Paul Thornton]

Hi,

I can also replicate this behaviour on 10.1-RELEASE by simply creating 
an additional vlan interface.  It affects IPv4 and IPv6 forwarding.


This is taken from a test setup of FreeBSD boxes running Quagga as BGP 
routers - but with a default GENERIC kernel.  This machine has 2x ixgbe, 
4x igb and 2x bce physical interfaces, with a cloned lo1 and vlan0.


[root@test1 ~]# uname -a
FreeBSD test1.prtsystems.ltd.uk 10.1-RELEASE FreeBSD 10.1-RELEASE #0 
r274401: Tue Nov 11 21:02:49 UTC 2014 
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64



[root@test1 ~]# sysctl -a | grep forwarding
net.inet.ip.forwarding: 1
net.inet.ip.fastforwarding: 1
net.inet6.ip6.forwarding: 1

[root@test1 ~]# ifconfig vlan1 create

[root@test1 ~]# sysctl -a | grep forwarding
net.inet.ip.forwarding: 0
net.inet.ip.fastforwarding: 1
net.inet6.ip6.forwarding: 0


I haven't tried using 10.0 as a router, so don't know if this crept in 
between 10.0 and 10.1 or 9 and 10.


Paul.

On 03/01/2015 13:12, wishmaster wrote:


Hi,

I have been seeing strange behavior of my system lately. After creating new interface the 
system variable net.inet.ip.forwarding becomes 0.

  E.g. manually load if_ral kernel module, then rel0 interface appears and 
net.inet.ip.forwarding becomes 0.

  Previously this happened when I attached smartphone with USB tethering is on.
  May be this is VIMAGE-related... Any ideas?

Below my original first post.


Hi, list.

Server works as router for small network and some services in the jails. When I 
connect Android-based smartphone and attempt to use USB Tethering, the 
net.inet.ip.forwarding becomes 0 and I must change it to 1 every time.

Is this normal behavior?

FreeBSD server.local 10.1-STABLE FreeBSD 10.1-STABLE #1 r275636: Mon Dec 22 
11:05:33 EET 2014 wishmaster@server.local:/usr/obj/usr/src/sys/SMS i386

Kernel has been compiled with VIMAGE


Cheers,
Vitaliy


___
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: Issue with forwarding when creates new interface [was USB Tethering and forwarding]

[Paul Thornton]

Hi,

On 03/01/2015 18:06, Mike Tancsa wrote:


do you set forwarding via just /etc/sysctl.conf or in /etc/rc.conf via
ipv6_gateway_enable and gateway_enable. I seem to recall some discussion
about there being a difference.  Perhaps devd is calling something that
then fiddles with the setting ignoring whats in sysctl.conf ?


That seems to be what is happening.

In the earlier post, I was just setting the three sysctls in 
/etc/sysctl.conf - and observed that forwarding went away if an 
interface was added.


Doing it by setting fastforwarding only in sysctl.conf, and setting both 
gateway_enables to yes in rc.conf fixes the problem:


[root@test1 ~]# sysctl -a | grep forwarding
net.inet.ip.forwarding: 1
net.inet.ip.fastforwarding: 1
net.inet6.ip6.forwarding: 1

[root@test1 ~]# ifconfig vlan1 create

[root@test1 ~]# sysctl -a | grep forwarding
net.inet.ip.forwarding: 1
net.inet.ip.fastforwarding: 1
net.inet6.ip6.forwarding: 1

That's quite ... odd, to sat the least.  I can't see anything in 
devd.conf which would relate to a new interface being created, but that 
doesn't mean that there isn't some magic functionality in there.


Paul.
___
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: Broadcom BCM57765 support?

[Paul Thornton]

On 04/05/2011 18:05, YongHyeon PYUN wrote:
 
 FYI: Committed to HEAD(r221445).

I've been away from the machines with this chipset for the past week so
have not finished the testing, but can report that the initial tests I
did involving normal use, jumbo frames, v4 and v6 etc. all worked fine
and throughput was good.

Once I have done a thorough test of the NIC I will post a report here.

Paul.
___
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: Broadcom BCM57765 support?

[Paul Thornton]

On 19/04/2011 23:09, YongHyeon PYUN wrote:
 Here is experimental patch for BCM57765 family controllers. I
 don't have these controllers so the patch was not tested at all
 except compile. Recent Broadcom controllers like BCM57765 support
 EEE(Energy Efficient Ethernet) feature but it is not yet supported
 by the patch.

Many thanks for this patch.

The patch wouldn't apply cleanly to either the 8.2-release source or to
the latest if_bge / if_bgereg so I had to do it manually; but that
wasn't too much of a problem.  What revision should I have tried to
apply the patch to?

Things are not fully working yet after the patch is applied though.

The current state is that the device is recognised, MAC address detected
OK, link state detected OK; you can ifconfig up the interface without a
problem.  However, I'm seeing bge0: watchdog timeout -- resetting
messages shortly after attempting to ping something on the LAN.  The
machine being pinged doesn't show up in the ARP cache.

Looking at the switch that its connected to, I see the mac address
learned on the port, and the received packet and byte counts
incrementing with no errors so I believe that the machine is
successfully transmitting frames but not able to receive them properly.
 The switch stats show that the switch is transmitting frames to the
machine.

 Also it would good to see the output of pciconf -lcbv and dmesg
 after applying the patch.

The machine in question is a 2010 Mac Mini (model rev A1347) - this has
a number of features that make FreeBSD an interesting challenge.  The
kernel I'm using is a normal 8.2-GENERIC with another very minor tweak
to stop the Nvidia MCP89 ata controller from being used in SATA mode
(this doesn't work - Linux has a workaround based on using UDMA).

Attached is a dmesg, pciconf, and the output of sysctl -a dev.bge.0
after the patch was applied.

If there is any other debugging information I need to get to help please
let me know.  Once we have this working I'll willingly give it some
thorough proper testing.

Thanks again,

Paul.
Copyright (c) 1992-2011 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.2-RELEASE #1: Wed Apr 20 08:58:24 UTC 2011
r...@badger.prt.org:/usr/src/sys/amd64/compile/GENERIC-TEST2 amd64
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM)2 Duo CPU P8600  @ 2.40GHz (2389.26-MHz K8-class CPU)
  Origin = GenuineIntel  Id = 0x1067a  Family = 6  Model = 17  Stepping = 10
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  
Features2=0x408e3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE
  AMD Features=0x20100800SYSCALL,NX,LM
  AMD Features2=0x1LAHF
  TSC: P-state invariant
real memory  = 2147483648 (2048 MB)
avail memory = 1780576256 (1698 MB)
ACPI APIC Table: APPLE  Apple00
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0: Changing APIC ID to 1
ioapic0 Version 1.1 irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: APPLE Apple00 on motherboard
acpi0: [ITHREAD]
acpi_ec0: Embedded Controller: GPE 0x57, ECDT port 0x62,0x66 on acpi0
acpi0: Power Button (fixed)
unknown: I/O range not supported
acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff irq 0,8 on 
acpi0
Timecounter HPET frequency 2500 Hz quality 900
Timecounter ACPI-fast frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0
cpu0: ACPI CPU on acpi0
cpu1: ACPI CPU on acpi0
acpi_button0: Power Button on acpi0
acpi_button1: Sleep Button on acpi0
pcib0: ACPI Host-PCI bridge on acpi0
pci0: ACPI PCI bus on pcib0
pci0: memory, RAM at device 0.1 (no driver attached)
pci0: memory, RAM at device 1.0 (no driver attached)
pci0: memory, RAM at device 1.1 (no driver attached)
pci0: memory, RAM at device 1.2 (no driver attached)
pci0: memory, RAM at device 1.3 (no driver attached)
pci0: memory, RAM at device 2.0 (no driver attached)
pci0: memory, RAM at device 2.1 (no driver attached)
isab0: PCI-ISA bridge port 0x2100-0x21ff at device 3.0 on pci0
isa0: ISA bus on isab0
pci0: memory, RAM at device 3.1 (no driver attached)
pci0: serial bus, SMBus at device 3.2 (no driver attached)
pci0: memory, RAM at device 3.3 (no driver attached)
pci0: processor at device 3.4 (no driver attached)
ohci0: OHCI (generic) USB controller mem 0x9358a000-0x9358afff irq 18 at 
device 4.0 on pci0
ohci0: [ITHREAD]
usbus0: OHCI (generic) USB controller on ohci0
ehci0: EHCI (generic) USB 2.0 controller mem 0x9358b100-0x9358b1ff irq 19 at 
device 4.1 on pci0
ehci0: [ITHREAD]
usbus1: EHCI version 1.10
usbus1: EHCI (generic) USB 2.0 controller on ehci0
ohci1: OHCI (generic) USB controller mem 

Re: Broadcom BCM57765 support?

[Paul Thornton]

Hi,

On 20/04/2011 14:16, Marius Strobl wrote:
 Looks like brgphy(4) also needs to be taught about this hardware. Could
 you please provide the corresponding part of a verbose dmesg?

Hopefully this covers everything that you might need:

pcib4: slot 0 INTA is routed to irq 18
found- vendor=0x14e4, dev=0x16bc, revid=0x00
domain=0, bus=4, slot=0, func=1
class=08-05-01, hdrtype=0x00, mfdev=1
cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=b, irq=7
powerspec 3  supports D0 D3  current D0
MSI supports 1 message, 64 bit
map[10]: type Prefetchable Memory, range 64, base 0x9312, size 16,
enabled
pcib4: requested memory range 0x9312-0x9312: good
pcib0: matched entry for 0.22.INTB (src \\_SB_.PCI0.Z00O:0)
pci_link13: Picked IRQ 19 with weight 1
pcib0: slot 22 INTB routed to irq 19 via \\_SB_.PCI0.Z00O
pcib4: slot 0 INTB is routed to irq 19
bge0: Broadcom unknown BCM57765, ASIC rev. 0x57785000 mem
0x9310-0x9310,0x9311-0x9311 irq 18 at device 0.0 on pci4
bge0: Reserved 0x1 bytes for rid 0x10 type 3 at 0x9310
bge0: attempting to allocate 1 MSI vectors (8 supported)
msi: routing MSI IRQ 256 to local APIC 0 vector 56
bge0: using IRQ 256 for MSI
bge0: CHIP ID 0x57785000; ASIC REV 0x57785; CHIP REV 0x577850; PCI-E
bge0: Disabling fastboot
bge0: Disabling fastboot
miibus0: MII bus on bge0
ukphy0: Generic IEEE 802.3u media interface PHY 1 on miibus0
ukphy0: OUI 0x00d897, model 0x0024, rev. 0
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
bge0: bpf attached
bge0: Ethernet address: c4:2c:03:08:0b:9d
bge0: [MPSAFE]
bge0: [FILTER]

Many thanks,

Paul.
___
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: Broadcom BCM57765 support?

[Paul Thornton]

Hi,

On 20/04/2011 14:44, Marius Strobl wrote:
 Hrm, looks like neither NetBSD nor OpenBSD support this variant so
 far, however Linux also doesn't seem to have special handling for it.
 Could you please give the attached patch in addition to the existing
 one a try?

I've added your patch to brgphy as well - but at a user level I'm still
seeing the same thing:
- Ethernet frames are transmitted by the box, switch sees them with no
errors.
- Frames received don't seem to make it to/beyond the driver.
- After I hit CTRL-C on the non-working ping, I get a bge0: watchdog
timeout -- resetting message.

If I tcpdump the interface, I see nothing, but the dev.bge.0.stats
counters are incrementing when I attempt to ping.

The switch is showing counts on both its tx and rx packets counters with
no errors.

Is there somewhere I need to add more debug in the driver to understand
what it is doing?

The current dmesg looks like:

bge0: Broadcom unknown BCM57765, ASIC rev. 0x57785000 mem
0x9310-0x9310,0x9311-0x9311 irq 18 at device 0.0 on pci4
bge0: Reserved 0x1 bytes for rid 0x10 type 3 at 0x9310
bge0: attempting to allocate 1 MSI vectors (8 supported)
msi: routing MSI IRQ 256 to local APIC 0 vector 56
bge0: using IRQ 256 for MSI
bge0: CHIP ID 0x57785000; ASIC REV 0x57785; CHIP REV 0x577850; PCI-E
bge0: Disabling fastboot
bge0: Disabling fastboot
miibus0: MII bus on bge0
brgphy0: BCM57785 10/100/1000baseTX PHY PHY 1 on miibus0
brgphy0: OUI 0x00d897, model 0x0024, rev. 0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
bge0: bpf attached
bge0: Ethernet address: c4:2c:03:08:0b:9d
bge0: [MPSAFE]
bge0: [FILTER]

Paul.
___
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

Broadcom BCM57765 support?

[Paul Thornton]

Hi,

The bge driver doesn't support this chipset yet and I was wondering if
anyone has looked at implementing it.

NetBSD looks like it has support for it.  Now I may be wrong here, but
it appears that the BCM57765 is similar to other devices based on the
NetBSD if_bge.c source version 1.194.

I've tried applying the NetBSD changes to the FreeBSD bge source but I
don't know enough about the hardware and the code is different enough
that I haven't made it very far.  I can get a patched 8.2 kernel to
detect the device, complain that the ASIC is unknown, read the MAC
address correctly and determine there is link but as soon as you attempt
to ifconfig up the interface the machine locks up.

I'm happy to try and port this over but need a nudge in the right
direction from someone who knows the code.

Thanks,

Paul.
___
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: Problems with 8.1, PPPoE server, and Cisco client

[Paul Thornton]

On 26/10/2010 18:55, Paul Thornton wrote:
 I've been taking another look at this after being dragged off onto other
 things for a few days, and hopefully have some more information that
 might help point in the right direction for a fix / where to debug next.

 On 20/10/2010 17:16, Julian Elischer wrote:
 have you tried to connect this cisco router to anything else pppoe?
 (take it home and make it connect to your ISP for example?)
 The Cisco client does work to a Cisco router acting as a PPPoE server -
 I used a 891 (client) to a 3945 (server) and using an established setup
 that is known to work, I collected a happy tcpdump.  Of course that
 doesn't tell us why there was such an issue with the FreeBSD ppp server
 and it looks very similar to me.

 I'm also going to give mpd a go and see if that works - but if it tries
 the same config options as pppoed then I may be straight back to where I
 am now.

 Thanks to everyone for their help with this.

 So here is the dump from a known good setup, IOS at both ends - starting
 from the CHAP success point again.  This time, both ends play the game
 and agree amongst themselves what they will and won't do as expected
 (many thanks to Ian here for the commentary as to what was going on in
 the exchanges I have):

 20:29:10.200860 PPPoE  [ses 0x13] CHAP, Response (0x02), id 1, Value 
 8f917e3cd84fd4b3a5e8b705655bf16772d0cd1462392eed8bb4ab0ccb7f75bb2d01695ac26cdc07127b4fb3435a279a01,
  Name vt123456...@vdsl01.v
 20:29:14.501312 PPPoE  [ses 0x13] CHAP, Success (0x03), id 1, Msg 
 20:29:14.501702 PPPoE  [ses 0x13] IPCP, Conf-Request (0x01), id 1, length 12
  encoded length 10 (=Option(s) length 6)
  0x:  8021 0101 000a
IP-Addr Option (0x03), length 6: 109.71.168.123
  0x:  6d47 a87b
 20:29:14.504344 PPPoE  [ses 0x13] IPCP, Conf-Request (0x01), id 1, length 12
  encoded length 10 (=Option(s) length 6)
  0x:  8021 0101 000a
IP-Addr Option (0x03), length 6: 0.0.0.0
  0x:   
 20:29:14.504497 PPPoE  [ses 0x13] unknown PPP protocol (0x8207) 
  0x:  0101 0004
 20:29:14.504669 PPPoE  [ses 0x13] IPCP, Conf-Ack (0x02), id 1, length 12
  encoded length 10 (=Option(s) length 6)
  0x:  8021 0201 000a
IP-Addr Option (0x03), length 6: 109.71.168.123
  0x:  6d47 a87b
 20:29:14.505200 PPPoE  [ses 0x13] IPCP, Conf-Nack (0x03), id 1, length 12
  encoded length 10 (=Option(s) length 6)
  0x:  8021 0301 000a
IP-Addr Option (0x03), length 6: 109.71.174.50
  0x:  6d47 ae32
 20:29:14.505290 PPPoE  [ses 0x13] LCP, Prot-Reject (0x08), id 2, length 12
  encoded length 10 (=Option(s) length 6)
  0x:  c021 0802 000a
Rejected unknown Protocol (0x8207)
Rejected Packet
  0x:  0101 0006  
 20:29:14.505800 PPPoE  [ses 0x13] IPCP, Conf-Request (0x01), id 2, length 12
  encoded length 10 (=Option(s) length 6)
  0x:  8021 0102 000a
IP-Addr Option (0x03), length 6: 109.71.174.50
  0x:  6d47 ae32
 20:29:14.506753 PPPoE  [ses 0x13] IPCP, Conf-Ack (0x02), id 2, length 12
  encoded length 10 (=Option(s) length 6)
  0x:  8021 0202 000a
IP-Addr Option (0x03), length 6: 109.71.174.50
  0x:  6d47 ae32
 20:29:23.247975 PPPoE  [ses 0x13] IP (tos 0x0, ttl 255, id 35, offset 0, 
 flags [none], proto ICMP (1), length 100)
 109.71.174.50  217.65.161.4: ICMP echo request, id 10, seq 0, length 80
 20:29:23.257872 PPPoE  [ses 0x13] IP (tos 0x0, ttl 61, id 51771, offset 0, 
 flags [none], proto ICMP (1), length 100)
 217.65.161.4  109.71.174.50: ICMP echo reply, id 10, seq 0, length 80
 The ping here is the start of real data flowing - I used this setup for
 about 30 minutes of web browsing with no problems.

 Paul.

 ___
 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
___
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: Problems with 8.1, PPPoE server, and Cisco client

[Paul Thornton]

Hi folks,

Keeping the list archives updated for any poor soul that has a similar
problem in future...

On 26/10/2010 18:55, Paul Thornton wrote:
 I'm also going to give mpd a go and see if that works - but if it tries
 the same config options as pppoed then I may be straight back to where I
 am now.

The verdict with mpd is exactly the same - the Cisco takes exception to
the IPCP request immediately following the successful auth, and tears
down the connection.

I'm going to take this to the Cisco TAC and see if they can suggest
anything that may be causing this as it makes no sense at all when all
other clients I try work.

Paul.
___
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: Problems with 8.1, PPPoE server, and Cisco client

[Paul Thornton]

On 09/11/2010 20:16, Paul Thornton wrote:
 

Sorry for that unedited copy of the last mail to the list.  Finger
trouble in mail client.  Must try harder!

Paul.
___
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: Polling slows down bandwidth

[Paul Thornton]

Hi,

On 29/10/2010 18:23, Chuck Swiger wrote:
 On Oct 28, 2010, at 11:39 PM, Коньков Евгений wrote:
 so using polling on gigabit NICs is a bottle neck? and is cause of low 
 performance, is not?
 
 Simple answer is yes.  It should be possible that you could tune polling to 
 get similar performance, or at least better performance than you see now, but 
 the additional hardware capabilities of gigabit NICs are likely to outperform 
 polling mode, just as polling mode can generally outperform old 100MBs 
 ethernet NICs.

I have been using polling for a long time with em and fxp interfaces on
6.2 and 4.9 boxes that are working as routers.

I've been doing testing with FreeBSD 8 and em interfaces recently, and
my experience agrees with Chuck's statement - that polling makes things
worse when you use new (anything in the last 2 or 3 years) hardware with
good quality gigabit ethernet interfaces.

I've only really worked with bge and em but they have good high
performance without polling in 8.0 and 8.1

Paul.
___
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: Problems with 8.1, PPPoE server, and Cisco client

[Paul Thornton]

I've been taking another look at this after being dragged off onto other
things for a few days, and hopefully have some more information that
might help point in the right direction for a fix / where to debug next.

On 20/10/2010 17:16, Julian Elischer wrote:
 have you tried to connect this cisco router to anything else pppoe?
 (take it home and make it connect to your ISP for example?)

The Cisco client does work to a Cisco router acting as a PPPoE server -
I used a 891 (client) to a 3945 (server) and using an established setup
that is known to work, I collected a happy tcpdump.  Of course that
doesn't tell us why there was such an issue with the FreeBSD ppp server
and it looks very similar to me.

I'm also going to give mpd a go and see if that works - but if it tries
the same config options as pppoed then I may be straight back to where I
am now.

Thanks to everyone for their help with this.

So here is the dump from a known good setup, IOS at both ends - starting
from the CHAP success point again.  This time, both ends play the game
and agree amongst themselves what they will and won't do as expected
(many thanks to Ian here for the commentary as to what was going on in
the exchanges I have):

 20:29:10.200860 PPPoE  [ses 0x13] CHAP, Response (0x02), id 1, Value 
 8f917e3cd84fd4b3a5e8b705655bf16772d0cd1462392eed8bb4ab0ccb7f75bb2d01695ac26cdc07127b4fb3435a279a01,
  Name vt123456...@vdsl01.v
 20:29:14.501312 PPPoE  [ses 0x13] CHAP, Success (0x03), id 1, Msg 
 20:29:14.501702 PPPoE  [ses 0x13] IPCP, Conf-Request (0x01), id 1, length 12
   encoded length 10 (=Option(s) length 6)
   0x:  8021 0101 000a
 IP-Addr Option (0x03), length 6: 109.71.168.123
   0x:  6d47 a87b
 20:29:14.504344 PPPoE  [ses 0x13] IPCP, Conf-Request (0x01), id 1, length 12
   encoded length 10 (=Option(s) length 6)
   0x:  8021 0101 000a
 IP-Addr Option (0x03), length 6: 0.0.0.0
   0x:   
 20:29:14.504497 PPPoE  [ses 0x13] unknown PPP protocol (0x8207) 
   0x:  0101 0004
 20:29:14.504669 PPPoE  [ses 0x13] IPCP, Conf-Ack (0x02), id 1, length 12
   encoded length 10 (=Option(s) length 6)
   0x:  8021 0201 000a
 IP-Addr Option (0x03), length 6: 109.71.168.123
   0x:  6d47 a87b
 20:29:14.505200 PPPoE  [ses 0x13] IPCP, Conf-Nack (0x03), id 1, length 12
   encoded length 10 (=Option(s) length 6)
   0x:  8021 0301 000a
 IP-Addr Option (0x03), length 6: 109.71.174.50
   0x:  6d47 ae32
 20:29:14.505290 PPPoE  [ses 0x13] LCP, Prot-Reject (0x08), id 2, length 12
   encoded length 10 (=Option(s) length 6)
   0x:  c021 0802 000a
 Rejected unknown Protocol (0x8207)
 Rejected Packet
   0x:  0101 0006  
 20:29:14.505800 PPPoE  [ses 0x13] IPCP, Conf-Request (0x01), id 2, length 12
   encoded length 10 (=Option(s) length 6)
   0x:  8021 0102 000a
 IP-Addr Option (0x03), length 6: 109.71.174.50
   0x:  6d47 ae32
 20:29:14.506753 PPPoE  [ses 0x13] IPCP, Conf-Ack (0x02), id 2, length 12
   encoded length 10 (=Option(s) length 6)
   0x:  8021 0202 000a
 IP-Addr Option (0x03), length 6: 109.71.174.50
   0x:  6d47 ae32
 20:29:23.247975 PPPoE  [ses 0x13] IP (tos 0x0, ttl 255, id 35, offset 0, 
 flags [none], proto ICMP (1), length 100)
 109.71.174.50  217.65.161.4: ICMP echo request, id 10, seq 0, length 80
 20:29:23.257872 PPPoE  [ses 0x13] IP (tos 0x0, ttl 61, id 51771, offset 0, 
 flags [none], proto ICMP (1), length 100)
 217.65.161.4  109.71.174.50: ICMP echo reply, id 10, seq 0, length 80

The ping here is the start of real data flowing - I used this setup for
about 30 minutes of web browsing with no problems.

Paul.

___
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: Problems with 8.1, PPPoE server, and Cisco client

[Paul Thornton]

Hi,

On 19/10/2010 22:06, Julian Elischer wrote:
 Wireshark understands all the protocols in question so get packet
 captures of good and
 bad sessions (as similar as you can) and see what is different.
 (wireshark reads
 tcpdump files so it's easy to capture).

As is often the case, the packets on the wire start telling the story of
what is happening... still not sure about the why, but progress is being
made.  Thanks for that nudge.

With a Windows XP client (I know, it was nearby though) the following
things happen:

Server - Client  PPP CHAP Success (Welcome!! message).
Server - Client  PPP CCP config request
Server - Client  IPCP Config request (setting IP address of server end)
Client - Server  PPP CCP config request
- and they carry on here working fine -

With the Cisco client, things break at this point:
Server - Client  PPP CHAP Success (Welcome!! message).
Server - Client  PPP CCP Config request
Server - Client  IPCP Config Request (setting IP address of server end)
Client - Server  Termination request
Server - Client  Termination ack

So either that CCP request or the IPCP request is upsetting the Cisco.
However, even with its debugging fully on for PPP, it isn't clear why.
Initially, my server was requesting deflate compression and VJ
compression - so I disabled all compression options in ppp.conf but it
made no difference.  The tcpdumps were taken after compression was disabled.

The cisco config being used on the WAN interface and Dialer interface
for testing is as follows.  This is an 891 and so is an Ethernet WAN
port (no VDSL or other cable interface to add problems):

interface GigabitEthernet0
 no ip address
 ip accounting output-packets
 duplex auto
 speed auto
 pppoe enable group global
 pppoe-client dial-pool-number 1
 !
interface Dialer0
 description PPPoE dialer
 mtu 1492
 ip address negotiated
 no ip redirects
 no ip proxy-arp
 ip accounting output-packets
 encapsulation ppp
 ip tcp adjust-mss 1452
 dialer pool 1
 dialer-group 1
 ppp mtu adaptive
 ppp authentication chap callin optional
 ppp chap hostname vt123456...@vdsl01
 ppp chap password 0 LetMeIn123
 !
!
ip route 0.0.0.0 0.0.0.0 Dialer0
!
dialer-list 1 protocol ip permit
!


In terms of the routing, the route being added as a result of the
Framed-Route radius attribute does have the correct syntax.  For some
reason, it had failed to add the /29 route to the routing table in my
logs taken yesterday - although that now works fine.  That may still be
a potential issue but I don't think it is relevant now.

To describe what addresses are what (and two of these have changed since
yesterday as I was using some that were already occasionally used
elsewhere on the network):

WAN IP address of router: 217.65.167.128 /32 - set by RADIUS
Framed-IP-Address value.
LAN subnet of router: 217.65.167.160 /29 - set by RADIUS Framed-Route
value.  Router's LAN interface has 217.65.167.161/29.
IP address of PPPoE server's end of PPP link: 217.65.168.254

VLAN 1005 is just the access side; it has the clients attached to it and
has no IP address.  Everything happening on there is PPPoE only.  The
server has another interface which is network side that carries traffic
to and from the rest of the world.


 also for fun you might look at the documentation for running mpd.. I
 dont' remember if it
 can do a pppoe SERVER but I vaguely remember that it can.

I did once try mpd in the past - I remember it being hard to find any
decent documentation for it; especially around PPPoE as a server.  It
looks very flexible as an option so I may have another crack at it if I
can't make the standard ppp work.  Does anyone know of any good howto
for mpd and pppoe servers?  My google skills have lacked severely so far.


Here is part of the tcpdump with the XP client, starting at the CHAP
success message.  I've included quite a lot as there seems to be
something going on with IPCP and setting DNS addresses - is this normal?
(address ending 5e:ed is the server):

 14:40:27.733755 d8:d3:85:c1:5e:ed  18:a9:05:db:8e:5c, ethertype PPPoE S 
 (0x8864), length 35: PPPoE  [ses 0x20] CHAP (0xc223), length 15: CHAP, 
 Success (0x03), id 1, Msg Welcome!!
 14:40:27.733764 d8:d3:85:c1:5e:ed  18:a9:05:db:8e:5c, ethertype PPPoE S 
 (0x8864), length 26: PPPoE  [ses 0x20] unknown (0x80fd), length 6: unknown 
 ctrl-proto (0x80fd), Conf-Request (0x01), id 1, length 6
 14:40:27.733770 d8:d3:85:c1:5e:ed  18:a9:05:db:8e:5c, ethertype PPPoE S 
 (0x8864), length 32: PPPoE  [ses 0x20] IPCP (0x8021), length 12: IPCP, 
 Conf-Request (0x01), id 1, length 12
   encoded length 10 (=Option(s) length 6)
   0x:  8021 0101 000a
 IP-Addr Option (0x03), length 6: 217.65.168.254
   0x:  d941 a8fe
 14:40:27.741765 18:a9:05:db:8e:5c  d8:d3:85:c1:5e:ed, ethertype PPPoE S 
 (0x8864), length 60: PPPoE  [ses 0x20] unknown (0x80fd), length 12: unknown 
 ctrl-proto (0x80fd), Conf-Request (0x01), id 6, length 12
   encoded length 10 (=Option(s) length 6)
   0x:  80fd 

Problems with 8.1, PPPoE server, and Cisco client

[Paul Thornton]

Hi all,

I'm hoping that someone can point me in the right direction to get
enough debug to troubleshoot a very annoying connection problem with
PPPoE to a Cisco.

I have a freshly installed 8.1-RELEASE amd64 box with a very simple
PPPoE daemon setup on it.  This works fine for a test WinXP and Mac OS X
client so I know that fundamentally that side of things should be OK. I
have also used a similar setup (under 7.0) with all sorts of consumer
routers doing PPPoE and it just works.  The server I'm testing with
has VLANs on top of igb interfaces, and I haven't seen any other network
issues.

Using a Cisco 800 series as the client, however, things start off
working fine - connects up OK, authenticates, etc. but then it
immediately disconnects.
There is no clear error as to why the disconnect happens at either end -
hence my confusion.  I've tried several routers (some direct Ethernet
link, some via VDSL) and have upgraded to the latest IOS in an attempt
to make this work, nothing changes.

Have also tried with 7.2-RELEASE in case it was an 8.X issue - again,
same problem seen.

Any hints to help debug this (from either end) would be much appreciated.

Thanks,

Paul.


Info follows:


FreeBSD vdsl02a 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Tue Oct 19 14:48:21
UTC 2010 r...@vdsl01a:/usr/src/sys/amd64/compile/PPPOE-ROUTER-2  amd64

ppp.conf:

default:
 set log Chat Command Phase#turn on some logging. See man ppp.conf
 enable pap#turn on chap and pap accounting
 enable chap
 allow mode direct #turn on ppp bridging
 disable proxy #turn on ppp proxyarping
 disable ipv6cp#don't currently support v6
 set mru 1492  #set mru below 1500 (PPPoE MTU issue)
 set mtu 1492  #set mtu below 1500 (PPPoE MTU issue)
 set timeout 0
 enable lqr echo
 set echoperiod 5
 accept dns
 set dns 217.65.160.42
 set radius /etc/ppp/radius.conf
 set ifaddr 217.65.168.254/32

# access VLAN PPPoE definitions

cv1004e:
 set device PPPoE:vlan1004:test

cv1005e:
 set device PPPoE:vlan1005:test


The daemon is running with the following command:

 /usr/libexec/pppoed -P /var/run/pppoed-1005.pid -a test -l cv1005e vlan1005

The RADIUS plumbing works as expected, and the router gets past
authentication and gets the correct IP address.

ppp.log shows:

 Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: Using interface: tun0
 Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: Created in closed state
 Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: enable pap
 Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: enable chap
 Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: disable proxy
 Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: disable ipv6cp
 Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set mru 1492
 Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set mtu 1492
 Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set timeout 0
 Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: enable lqr echo
 Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set echoperiod 5
 Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: accept dns
 Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set dns 217.65.160.42
 Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set radius 
 /etc/ppp/radius.conf
 Oct 19 20:05:33 vdsl02a ppp[2234]: Command: default: set ifaddr 
 217.65.168.254/32
 Oct 19 20:05:33 vdsl02a ppp[2234]: Command: cv1005e: set device 
 PPPoE:vlan1005:test
 Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: PPP Started (direct mode).
 Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: bundle: Establish
 Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: closed - opening
 Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: Link is a netgraph node
 Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: Connected!
 Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: opening - carrier
 Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: carrier - lcp
 Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: bundle: Authenticate
 Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: deflink: his = none, mine = CHAP 
 0x05
 Oct 19 20:05:33 vdsl02a ppp[2234]: Phase: Chap Output: CHALLENGE
 Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Chap Output: CHALLENGE
 Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Chap Input: RESPONSE dropped (got 
 id 1, not 2)
 Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Chap Input: RESPONSE (16 bytes from 
 vt123456...@vdsl01)
 Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Radius: Request sent
 Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Radius(auth): ACCEPT received
 Oct 19 20:05:36 vdsl02a ppp[2234]: Phase:  IP 217.65.167.1
 Oct 19 20:05:36 vdsl02a ppp[2234]: Phase:  Route: 217.65.167.64/29 
 217.65.167.1 1
 Oct 19 20:05:36 vdsl02a ppp[2234]: Phase:  MTU 1492
 Oct 19 20:05:36 vdsl02a ppp[2234]: Phase:  Netmask 255.255.255.255
 Oct 19 20:05:36 vdsl02a ppp[2234]: Phase: Chap Output: SUCCESS
 Oct 19 20:05:36 vdsl02a ppp[2234]: Warning: iface add: ioctl(SIOCAIFADDR, 
 

Current best version for router use

[Paul Thornton]

Hi list,

A bit of advice please, folks.

We currently use 6.2-release + Quagga as a router on a number of boxes.  
These are stable but we have seen some CPU issues recently and clearly 
the code is all getting old now, and so I'm starting to look at updating 
them.


Specifically, the hardware consists of a single dual-core Xeon at 2GHz 
with 2G RAM, containing 10x em interfaces (2x quad PCI-X cards, plus 2 
onboard) .  IRQ sharing is a bit of an issue and only 8 of those 1G 
ports can be used without re-using an interrupt.

They run with polling enabled, with kern.polling.user_frac = 22
These routers run Quagga 0.99.7 doing v4 and v6 OSPF/BGP.
We do use a number of vlans and a couple of gif tunnels.
Total throughput varies quite a lot - from 50M to about 200M - but 
usually isn't high.


There seem to be a lot of issues that have appeared around 8.0 and the 
em code, and although patches have quickly appeared, I know that a lot 
of the forwarding and routing code in 8 is new  - so whilst I would 
normally have just tested this with 8 and not considered anything else, 
I am thinking that maybe sticking with 7 is a better plan.


I'd appreciate any input from anyone who is using 8.0 in a similar 
environment, any advice and suggestions would be gratefully received.


Thanks,

Paul.

___
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: ipfw problems using divert and fwd at the same time with 6.3-release

[Paul Thornton]

I have found the error of my ways...

For the purposes of the archives, I'm posting what actually made this 
work. It is a very simple fix and I don't quite know how I missed trying 
this out during my frustrations.


Before the ipfw fwd... line you need one or more ipfw skipto... 
lines to ensure that you don't accidentally match the more specific 
addresses on the fwd.


What's interesting is that I'd had ipfw allow... lines before the 
ipfe fwd... line doing a similar thing to skipto, and it didn't work.


So I amended the ruleset to the following (other rules stay the same):


06000   515  153945 divert 8668 ip from any to me via em0
07000485472 skipto 32000 ip from 10.81.0.0/16 to 217.65.161.4 dst-port 
80
07100 0   0 skipto 32000 ip from 10.81.129.0/24 to any
0800094   10434 fwd 127.0.0.1,8000 tcp from 10.81.0.0/16 to any dst-port 80
32000   499  230890 allow ip from any to any


Paul.
___
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

ipfw problems using divert and fwd at the same time with 6.3-release

[Paul Thornton]

Hi folks,

I'm having trouble using NAT and forward in the same ipfw ruleset.  It 
appears that the forward wins over the NAT regardless of ordering in 
the ipwf ruleset.  I'm hoping that I'm missing something obvious; but is 
there a way to use these two together?


Some background - I'm testing in the lab a potential setup to provide 
limited network access to a few subnets in 10.X address space, but if 
you aren't going to an approved address then you get forwarded to a 
web page running on port 8000 on the same box.  This box is running 
6.3-RELEASE-p9 and has two em interfaces.


In this setup, 10.81.0.0/16 are my subnets.  They are presented to the 
machine as a bunch of VLANs physically on em1, one /24 subnet per VLAN. 
 The machine also does DHCP and DNS for each of these VLANs, and is the 
default gateway.


em0 is the external IP address for the machine, currently 192.91.199.5
The machine has no problem accessing the 'net.  If I remove the clever 
divert rules and the fwd rule, and make it a vanilla NAT setup, the 
client has no problem accessing the 'net.


In this setup, I expect to be able to browse to www.prt.org (on 
217.65.161.4) and that a machine in the 10.81.129.0/24 subnet has 
unrestricted NATted access to the 'net.  Any other attempt at browsing 
should hit the forward and display the no access page from the server 
on the gateway machine.


Using the following ruleset:


[r...@xrg1 /var/tmp]# ipfw show
00010 0   0 allow ip from any to any via lo0
00020 0   0 deny ip from any to 127.0.0.1
00022 0   0 deny ip from 127.0.0.1 to any
00050 0   0 allow udp from any 67-68 to 255.255.255.255 dst-port 67-68
00052 0   0 allow udp from 10.81.0.0/16 67-68 to me dst-port 67-68
00054 0   0 allow udp from me 67-68 to 10.81.0.0/16 dst-port 67-68
00056 0   0 allow udp from 10.81.0.0/16 to me dst-port 53
00058 0   0 allow udp from me 53 to 10.81.0.0/16
00060 0   0 allow icmp from 10.81.0.0/16 to me
00062 0   0 allow icmp from me to 10.81.0.0/16
00100 0   0 allow ip from 192.91.199.5 to any
02000 0   0 divert 8668 ip from 10.81.0.0/16 to 217.65.161.4 dst-port 
80 via em0
05000 0   0 divert 8668 ip from 10.81.129.0/24 to any via em0
06000 0   0 divert 8668 ip from any to me via em0
08000 0   0 fwd 127.0.0.1,8000 tcp from 10.81.0.0/16 to any dst-port 80
32000 0   0 allow ip from any to any


If I browse www.prt.org on the client machine (10.81.2.246) I hit the 
fwd rule and I get my Sorry you can't view this webpage from the local 
server, and neither of the NAT rules are hit.

(DNS on the client correctly resolves to 217.65.161.4) :


[r...@xrg1 /var/tmp]# ipfw show
00010 0   0 allow ip from any to any via lo0
00020 0   0 deny ip from any to 127.0.0.1
00022 0   0 deny ip from 127.0.0.1 to any
00050 0   0 allow udp from any 67-68 to 255.255.255.255 dst-port 67-68
00052 0   0 allow udp from 10.81.0.0/16 67-68 to me dst-port 67-68
00054 0   0 allow udp from me 67-68 to 10.81.0.0/16 dst-port 67-68
00056 2 119 allow udp from 10.81.0.0/16 to me dst-port 53
00058 2 356 allow udp from me 53 to 10.81.0.0/16
00060 0   0 allow icmp from 10.81.0.0/16 to me
00062 0   0 allow icmp from me to 10.81.0.0/16
00100 3 214 allow ip from 192.91.199.5 to any
02000 0   0 divert 8668 ip from 10.81.0.0/16 to 217.65.161.4 dst-port 
80 via em0
05000 0   0 divert 8668 ip from 10.81.129.0/24 to any via em0
06000 3 601 divert 8668 ip from any to me via em0
08000434796 fwd 127.0.0.1,8000 tcp from 10.81.0.0/16 to any dst-port 80
3200058   55935 allow ip from any to any


If I remove rule 8000, then I can browse to www.prt.org as expected, and 
I hit the divert rules:



00010 0   0 allow ip from any to any via lo0
00020 0   0 deny ip from any to 127.0.0.1
00022 0   0 deny ip from 127.0.0.1 to any
00050 0   0 allow udp from any 67-68 to 255.255.255.255 dst-port 67-68
00052 0   0 allow udp from 10.81.0.0/16 67-68 to me dst-port 67-68
00054 0   0 allow udp from me 67-68 to 10.81.0.0/16 dst-port 67-68
00056 7 460 allow udp from 10.81.0.0/16 to me dst-port 53
00058 71247 allow udp from me 53 to 10.81.0.0/16
00060 0   0 allow icmp from 10.81.0.0/16 to me
00062 0   0 allow icmp from me to 10.81.0.0/16
00100453375 allow ip from 192.91.199.5 to any
02000385096 divert 8668 ip from 10.81.0.0/16 to 217.65.161.4 dst-port 
80 via em0
05000 0   0 divert 8668 ip from 10.81.129.0/24 to any via em0
0600075   37498 divert 8668 ip from any to me via em0
32000   273  142906 allow ip from any to any


The natd config is trivial - I'm just launching it with:
 natd -port 8668 -same_ports -verbose interface em0

Does anyone have any ideas?  I've spent the whole weekend trying various 
things (like extra 

Re: pppoed problem with reconnections

[Paul Thornton]

Hi Luiz,

Luiz Otavio O Souza wrote:


Change the enable lqr to:

enable lqr echo
set echoperiod 5

The ppp will check the remote peer at echoperiod  and after five 
consecutive fails the ppp link will be closed.


That does exactly what I want, thank you.

Paul.
___
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: pppoed problem with reconnections

[Paul Thornton]

Hi,

Eugene Perevyazko wrote:

You have to look at keep-alive settings to terminate dead connections.
And why don't you try an mpd (/usr/ports/net/mpd) that is perfectly suited
to manage hundreds and thousands of simultaneous ppp (and PPPoE in particular)
connections? It's fast, flexible and easy to setup both as server and client.


As Luiz suggested, I've changed the config to:

enable lqr echo
set echoperiod 5

which sorts my problem out just fine.

I did look into using mpd - mainly to compare which works best for our 
situation.  However, I was having trouble making any PPPoE connections 
come up when using mpd; I suspect that this is me not fully 
understanding what I'm doing - and although I've done quite a bit of 
looking, I can't find any good example configurations for a PPPoE server 
using mpd (I'm sure they exist!).  Do you have any pointers for this?


Regards,

Paul.
___
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

pppoed problem with reconnections

[Paul Thornton]

Hi folks,

I am currently doing some lab testing with 6.3-release and a pppoe setup 
where each user has their own VLAN.  On the termination box have an em 
interface with about 200 VLANs configured on it, and have a ppp.conf 
looking like this:


default:
 set log Chat Command Phase
 enable pap
 enable chap
 allow mode direct
 set mru 1462
 set mtu 1462
 set timeout 0
 enable lqr
 accept dns
 set dns 192.168.1.1 192.168.1.2
 set radius /etc/ppp/radius.conf
 set ifaddr 192.168.254.254/32

cv1001e:
 set device PPPoE:vlan1001:cv1001

cv1002e:
 set device PPPoE:vlan1002:cv1002

cv1003e:
 set device PPPoE:vlan1003:cv1003

cv1004e:
 set device PPPoE:vlan1004:cv1004

(and so on for several pages)


There are multiple pppoed processes running, one for each VLAN (this 
might seem wasteful but there are other reasons for doing it this way).


All user authentication and IP address assignment is handled by the 
radius server, and each user ID has a static IP address.


The problem I'm seeing is as follows:
- PPPoE connection comes in, is authenticated, and a ppp process is 
exec()ed by pppoed.

- This connection has the user's IP address, say 192.168.254.1.
- Everything works as expected.  This is a Good Thing.
- The PPPoE connection is then not disconnected cleanly (say network 
cable pulled out, or machine reboots, etc)
- Back on the termination box, there is still a ppp process running 
using that address.
- When you try and reconnect as the original user, it fails because the 
address cannot be assigned (already in use).  Things then stay like this 
for ever until I kill the ppp process that was connected with the pppoed 
running on that VLAN.


I don't want to set a timeout as I want these sessions to be always on. 
 Is there any way to configure pppoed to kill the old ppp process 
before trying to launch the new one, so the IP address is released?


I guess I'm asking the reverse of the age old how do I deny multiple 
logins question - how do I allow it, but have the new one boot the old 
one off?


Thanks,

Paul.

___
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