Re: LACP problem [SOLVED]

2017-10-08 Thread Charles Lecklider
Just in case someone has the same problem and finds this thread, the
solution was to reboot the switch.

That was it - no other changes required.



Re: LACP problem

2017-09-20 Thread Charles Lecklider
On 09/06/2017 04:07, Lyndon Nerenberg wrote:
> The first step is to have the switch display its idea of the LACP 
> configuration and status.  I haven't a clue how a TP-LINK does that, but on 
> our Junipers it's 'show lacp interfaces'.

So I finally found my serial cable


TL-SG3424#show lacp internal
Flags:  S - Device is requesting Slow LACPDUs
F - Device is requesting Fast LACPDUs
A - Device is in active mode   P - Device is in passive mode
[...]
Channel group 6
  LACP port   AdminOperPort   Port
Port  Flags  StatePriorityKey  Key Number State
Gi1/0/9   SP Up   32768   0x6  0xf60   0x90x3c
Gi1/0/10  SP Down 32768   0x6  0   0xa0x44

TL-SG3424#show lacp neighbor

Flags:  S - Device is requesting Slow LACPDUs
F - Device is requesting Fast LACPDUs
A - Device is in active mode   P - Device is in passive mode
[...]
Channel group 6
 LACP port  Admin  Oper   PortPort
Port  Flags  Priority   Dev ID  KeyKeyNumber  State
Gi1/0/9   SA 32768  0cc4.7ad9.ead0  0  0x405c 0x5 0x3d
Gi1/0/10  SP 0  ..  0  0  0   0


I'm not sure if any of that is informative in any way?



Re: LACP problem

2017-06-10 Thread Charles Lecklider
On 10/06/2017 19:15, Lyndon Nerenberg wrote:
> Not really, other than running tcpdump on the two interfaces and
> examining the LACP protocol packets to try to discover why the
> negotiation is acting the way it is.

OK, that sounds like an even deeper rabbit-hole.

> Also, if you don't have the enable password, how did you configure
> LACP on the switch to begin with?

Fair question: via the web UI. That would imply it's not just a
front-end for the CLI, which implies another set of potential security
issues. Not an issue for this network, but certainly something to
consider in future.



Re: LACP problem

2017-06-10 Thread Lyndon Nerenberg

> On Jun 10, 2017, at 10:44 AM, Charles Lecklider  
> wrote:
> 
> Is there no other diagnostic information I can get from the OpenBSD side?

Not really, other than running tcpdump on the two interfaces and examining the 
LACP protocol packets to try to discover why the negotiation is acting the way 
it is.

Also, if you don't have the enable password, how did you configure LACP on the 
switch to begin with?


Re: LACP problem

2017-06-10 Thread Charles Lecklider
On 09/06/2017 04:07, Lyndon Nerenberg wrote:
> The first step is to have the switch display its idea of the LACP
> configuration and status.

That's turning into a bit of a mission

Seems TP-LINK don't set an enable password by default so I can't get
what I need via ssh until I've set that. To set it I need to connect to
the console port, which means finding the cable and a serial-to-USB adapter.
I have all the above (somewhere), it's just going to take some time.

Is there no other diagnostic information I can get from the OpenBSD side?



Re: LACP problem

2017-06-08 Thread Lyndon Nerenberg

> On Jun 8, 2017, at 7:47 PM, Charles Lecklider  wrote:
> 
> The trunk is there, seems to be configured the right way, but the second
> port doesn't come up. If I pull the cable on em0, em1 comes up, put the
> cable back, em0 doesn't join the trunk.

What you're showing looks fine.  We run this all over the place in house.  This 
points to the switch being confused about the configuration of the trunk.

> Have I botched the config somewhere? Or is there some incompatibility
> going on between OpenBSD and the switch? And if it's the latter, how do
> I get some diagnostic information to work out what's going on?

The first step is to have the switch display its idea of the LACP configuration 
and status.  I haven't a clue how a TP-LINK does that, but on our Junipers it's 
'show lacp interfaces'. E.g.:

> show lacp interfaces 
Aggregated interface: ae0
LACP state:   Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  Activity
  ge-0/0/0   ActorNoNo   Yes  Yes  Yes   Yes FastActive
  ge-0/0/0 PartnerNoNo   Yes  Yes  Yes   Yes FastActive
  ge-1/0/0   ActorNoNo   Yes  Yes  Yes   Yes FastActive
  ge-1/0/0 PartnerNoNo   Yes  Yes  Yes   Yes FastActive
LACP protocol:Receive State  Transmit State  Mux State 
  ge-0/0/0  Current   Fast periodic Collecting distributing
  ge-1/0/0  Current   Fast periodic Collecting distributing

Aggregated interface: ae1
LACP state:   Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  Activity
  ge-0/0/7   ActorNoNo   Yes  Yes  Yes   Yes FastActive
  ge-0/0/7 PartnerNoNo   Yes  Yes  Yes   Yes SlowActive
  ge-1/0/7   ActorNoNo   Yes  Yes  Yes   Yes FastActive
  ge-1/0/7 PartnerNoNo   Yes  Yes  Yes   Yes SlowActive
LACP protocol:Receive State  Transmit State  Mux State 
  ge-0/0/7  Current   Slow periodic Collecting distributing
  ge-1/0/7  Current   Slow periodic Collecting distributing

[...]


Re: LACP problem

2017-06-08 Thread Lyndon Nerenberg

> On Jun 8, 2017, at 7:54 PM, Lyndon Nerenberg  wrote:
> 
> Why do em0 and em1 have the same MAC address?

Oh shit, never mind - it's the trunk interface :-P  Sorry ...



Re: LACP problem

2017-06-08 Thread Lyndon Nerenberg

> On Jun 8, 2017, at 7:47 PM, Charles Lecklider  wrote:
> 
> em0: flags=8b43
> mtu 9000
>lladdr 0c:c4:7a:d9:ea:d0
>index 5 priority 0 llprio 3
>trunk: trunkdev trunk0
>media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
>status: active
> em1: flags=8b43
> mtu 9000
>lladdr 0c:c4:7a:d9:ea:d0
>index 6 priority 0 llprio 3
>trunk: trunkdev trunk0
>media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
>status: active

Why do em0 and em1 have the same MAC address?



LACP problem

2017-06-08 Thread Charles Lecklider
I'm trying to get LACP working over 2 ports (em0, em1). I've done this
successfully with FreeBSD and 4 ports on the same switch so I know it
can be done, I just can't get it working with OpenBSD. I'm hoping I've
just botched the config somewhere.

The switch is a TP-LINK TL-SG3424, latest firmware available, and LACP
is set to passive for the two ports (I've tried active, too).

hostname.em0:
mtu 9000 up

hostname,em1:
mtu 9000 up

hostname.trunk0:
trunkport em0 trunkport em1 trunkproto lacp
inet 10.1.2.1 255.255.255.0 NONE


>From my reading of the man pages that's all I need to do, and ifconfig
seems to agree:

em0: flags=8b43
mtu 9000
lladdr 0c:c4:7a:d9:ea:d0
index 5 priority 0 llprio 3
trunk: trunkdev trunk0
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
em1: flags=8b43
mtu 9000
lladdr 0c:c4:7a:d9:ea:d0
index 6 priority 0 llprio 3
trunk: trunkdev trunk0
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active

trunk0: flags=8843 mtu 9000
lladdr 0c:c4:7a:d9:ea:d0
index 11 priority 0 llprio 3
trunk: trunkproto lacp
trunk id: [(8000,0c:c4:7a:d9:ea:d0,405C,,),
 (8000,30:b5:c2:07:81:4a,0CF3,,)]
trunkport em1
trunkport em0 active,collecting,distributing
groups: trunk
media: Ethernet autoselect
status: active
inet 10.1.2.1 netmask 0xff00 broadcast 10.1.2.255


The trunk is there, seems to be configured the right way, but the second
port doesn't come up. If I pull the cable on em0, em1 comes up, put the
cable back, em0 doesn't join the trunk.


Have I botched the config somewhere? Or is there some incompatibility
going on between OpenBSD and the switch? And if it's the latter, how do
I get some diagnostic information to work out what's going on?

Thanks!




OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr  1 13:45:56 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17134788608 (16341MB)
avail mem = 16610807808 (15841MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7f4d8000 (53 entries)
bios0: vendor American Megatrends Inc. version "1.1a" date 08/27/2015
bios0: Supermicro A1SAi
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP FPDT FIDT SPMI MCFG WDAT UEFI APIC BDAT HPET
SSDT HEST BERT ERST EINJ
acpi0: wakeup devices PEX1(S0) PEX2(S0) PEX3(S0) PEX4(S0) EHC1(S0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU C2550 @ 2.40GHz, 2400.44 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: TSC frequency 2400438240 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU C2550 @ 2.40GHz, 2400.01 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Atom(TM) CPU C2550 @ 2.40GHz, 2400.01 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu2: 1MB 64b/line 16-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Atom(TM) CPU C2550 @ 2.40GHz, 2400.01 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu3: 1MB 64b/line 16-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins

LACP problem

2009-12-22 Thread BARDOU Pierre
Hello,

I use an LACP trunk on my openBSD firewall since 4.5
It worked during more than a year, but since I upgraded to 4.6 the trunk
went down two times.
I cant do anything to fix it except reboot the firewall.

The switch is a HP Procurve 8412zl.

I tried a workaround, to test it I did on my slave firewall :
ifconfig trunk0 trunkproto none # simulation of trunk down
ifconfig trunk0

= This systematically leads to a kernel panic

There was code changes on LACP between 4.5 and 4.6 ?
Should I downgrade to 4.5/upgrade to -stable ?

TYVM

--
Cordialement,
 
Pierre BARDOU
CSIM - Bureau 012
 
MiPih
12 rue Michel Labrousse
BP93668
F-31036 Toulouse CEDEX 1
 
Til : 05 67 69 71 84
Fax : 05 34 61 51 00
Mail : bardo...@mipih.fr

[demime 1.01d removed an attachment of type application/x-pkcs7-signature which 
had a name of smime.p7s]



Re: LACP problem

2009-12-22 Thread BARDOU Pierre
 /bsd: pciide0 at pci0 dev 15 function 1
ServerWorks CSB5 IDE rev 0x93: DMA

Dec 22 11:00:17 fw-intra-slave /bsd: atapiscsi0 at pciide0 channel 1 drive 0

Dec 22 11:00:17 fw-intra-slave /bsd: scsibus0 at atapiscsi0: 2 targets

Dec 22 11:00:17 fw-intra-slave /bsd: cd0 at scsibus0 targ 0 lun 0: TEAC,
CD-224E, K.9A ATAPI 5/cdrom removable

Dec 22 11:00:17 fw-intra-slave /bsd: cd0(pciide0:1:0): using PIO mode 4, DMA
mode 2, Ultra-DMA mode 2

Dec 22 11:00:17 fw-intra-slave /bsd: ohci0 at pci0 dev 15 function 2
ServerWorks OSB4/CSB5 USB rev 0x05: apic 8 int 11 (irq 11), version 1.0,
legacy support

Dec 22 11:00:17 fw-intra-slave /bsd: pcib0 at pci0 dev 15 function 3
ServerWorks CSB5 LPC rev 0x00

Dec 22 11:00:17 fw-intra-slave /bsd: pchb3 at pci0 dev 16 function 0
ServerWorks CIOB-E rev 0x12

Dec 22 11:00:17 fw-intra-slave /bsd: pchb4 at pci0 dev 16 function 2
ServerWorks CIOB-E rev 0x12

Dec 22 11:00:17 fw-intra-slave /bsd: pci3 at pchb4 bus 2

Dec 22 11:00:17 fw-intra-slave /bsd: bge0 at pci3 dev 0 function 0 Broadcom
BCM5704C rev 0x02, BCM5704 A2 (0x2002): apic 9 int 0 (irq 7), address
00:11:43:5a:86:d1

Dec 22 11:00:17 fw-intra-slave /bsd: brgphy0 at bge0 phy 1: BCM5704
10/100/1000baseT PHY, rev. 0

Dec 22 11:00:17 fw-intra-slave /bsd: bge1 at pci3 dev 0 function 1 Broadcom
BCM5704C rev 0x02, BCM5704 A2 (0x2002): apic 9 int 1 (irq 5), address
00:11:43:5a:86:d2

Dec 22 11:00:17 fw-intra-slave /bsd: brgphy1 at bge1 phy 1: BCM5704
10/100/1000baseT PHY, rev. 0

Dec 22 11:00:17 fw-intra-slave /bsd: pchb5 at pci0 dev 17 function 0
ServerWorks CIOB-X2 PCIX rev 0x05

Dec 22 11:00:17 fw-intra-slave /bsd: pchb6 at pci0 dev 17 function 2
ServerWorks CIOB-X2 PCIX rev 0x05

Dec 22 11:00:17 fw-intra-slave /bsd: pci4 at pchb6 bus 4

Dec 22 11:00:17 fw-intra-slave /bsd: ami0 at pci4 dev 3 function 0 Dell
PERC 4/Di Verde rev 0x02: apic 9 int 2 (irq 7)

Dec 22 11:00:17 fw-intra-slave /bsd: ami0: Dell 14a, 32b, FW 412W, BIOS
vH406, 128MB RAM

Dec 22 11:00:17 fw-intra-slave /bsd: ami0: 2 channels, 0 FC loops, 1 logical
drives

Dec 22 11:00:17 fw-intra-slave /bsd: scsibus1 at ami0: 40 targets

Dec 22 11:00:17 fw-intra-slave /bsd: sd0 at scsibus1 targ 0 lun 0: AMI,
Host drive #00,  SCSI2 0/direct fixed

Dec 22 11:00:17 fw-intra-slave /bsd: sd0: 34680MB, 512 bytes/sec, 71024640
sec total

Dec 22 11:00:17 fw-intra-slave /bsd: scsibus2 at ami0: 16 targets

Dec 22 11:00:17 fw-intra-slave /bsd: safte0 at scsibus2 targ 6 lun 0:
PE/PV, 1x3 SCSI BP, 1.1 SCSI2 3/processor fixed

Dec 22 11:00:17 fw-intra-slave /bsd: scsibus3 at ami0: 16 targets

Dec 22 11:00:17 fw-intra-slave /bsd: usb0 at ohci0: USB revision 1.0

Dec 22 11:00:17 fw-intra-slave /bsd: uhub0 at usb0 ServerWorks OHCI root
hub rev 1.00/1.00 addr 1

Dec 22 11:00:17 fw-intra-slave /bsd: isa0 at pcib0

Dec 22 11:00:17 fw-intra-slave /bsd: isadma0 at isa0

Dec 22 11:00:17 fw-intra-slave /bsd: com0 at isa0 port 0x3f8/8 irq 4:
ns16550a, 16 byte fifo

Dec 22 11:00:17 fw-intra-slave /bsd: pckbc0 at isa0 port 0x60/5

Dec 22 11:00:17 fw-intra-slave /bsd: pckbd0 at pckbc0 (kbd slot)

Dec 22 11:00:17 fw-intra-slave /bsd: pckbc0: using irq 1 for kbd slot

Dec 22 11:00:17 fw-intra-slave /bsd: wskbd0 at pckbd0: console keyboard,
using wsdisplay0

Dec 22 11:00:17 fw-intra-slave /bsd: pmsi0 at pckbc0 (aux slot)

Dec 22 11:00:17 fw-intra-slave /bsd: pckbc0: using irq 12 for aux slot

Dec 22 11:00:17 fw-intra-slave /bsd: wsmouse0 at pmsi0 mux 0

Dec 22 11:00:17 fw-intra-slave /bsd: pcppi0 at isa0 port 0x61

Dec 22 11:00:17 fw-intra-slave /bsd: midi0 at pcppi0: PC speaker

Dec 22 11:00:17 fw-intra-slave /bsd: spkr0 at pcppi0

Dec 22 11:00:17 fw-intra-slave /bsd: npx0 at isa0 port 0xf0/16: reported by
CPUID; using exception 16

Dec 22 11:00:17 fw-intra-slave /bsd: fdc0 at isa0 port 0x3f0/6 irq 6 drq 2

Dec 22 11:00:17 fw-intra-slave /bsd: fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2
head, 18 sec

Dec 22 11:00:17 fw-intra-slave /bsd: mtrr: Pentium Pro MTRR support

Dec 22 11:00:17 fw-intra-slave /bsd: softraid0 at root

Dec 22 11:00:17 fw-intra-slave /bsd: root on sd0a swap on sd0b dump on sd0b



--

Cordialement,

Pierre BARDOU



De : Iqigo Ortiz de Urbina [mailto:tarom...@gmail.com]
Envoyi : mardi 22 dicembre 2009 12:45
@ : BARDOU Pierre
Objet : Re: LACP problem



On Tue, Dec 22, 2009 at 11:22 AM, BARDOU Pierre bardo...@mipih.fr wrote:

Hello,

I use an LACP trunk on my openBSD firewall since 4.5
It worked during more than a year, but since I upgraded to 4.6 the trunk
went down two times.
I can t do anything to fix it except reboot the firewall.

The switch is a HP Procurve 8412zl.

I tried a workaround, to test it I did on my slave firewall :
ifconfig trunk0 trunkproto none # simulation of trunk down
ifconfig trunk0

= This systematically leads to a kernel panic



Curious



There was code changes on LACP between 4.5 and 4.6 ?



See it for yourself

http://www.openbsd.org/plus46.html

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/if_trunk.c

Recently there's been some activity on trunk.c maybe