Re: bgpd path selection seems broken at now

2020-10-16 Thread Bars Bars 
Thanks for your response.

# dmesg
OpenBSD 6.6-stable (VPN) #5: Fri Sep  4 18:52:23 CEST 2020
root@VPN:/usr/src/sys/arch/amd64/compile/VPN
real mem = 34297917440 (32709MB)
avail mem = 33245429760 (31705MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x7f6bd000 (85 entries)
bios0: vendor IBM Corp. version "-[D6E148BUS-1.08]-" date 06/25/2010
bios0: IBM 69Y5698
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S1 S5
acpi0: tables DSDT FACP TCPA APIC MCFG SLIC HPET SRAT SLIT SSDT SSDT ERST
DMAR
acpi0: wakeup devices UHC1(S4) UHC2(S4) UHC3(S4) UHC4(S4) UHC5(S4) EHC1(S4)
EHC2(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz, 2666.94 MHz, 06-2c-02
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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 133MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz, 2666.77 MHz, 06-2c-02
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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 18 (application processor)
cpu2: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz, 2666.77 MHz, 06-2c-02
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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 9, package 0
cpu3 at mainbus0: apid 20 (application processor)
cpu3: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz, 2666.77 MHz, 06-2c-02
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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 10, package 0
cpu4 at mainbus0: apid 32 (application processor)
cpu4: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz, 2666.77 MHz, 06-2c-02
cpu4:
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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 0, core 0, package 1
cpu5 at mainbus0: apid 34 (application processor)
cpu5: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz, 2666.77 MHz, 06-2c-02
cpu5:
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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu5: 256KB 64b/line 8-way L2 cache
cpu5: smt 0, core 1, package 1
cpu6 at mainbus0: apid 50 (application processor)
cpu6: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz, 2666.77 MHz, 06-2c-02
cpu6:
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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu6: 256KB 64b/line 8-way L2 cache
cpu6: smt 0, core 9, package 1
cpu7 at mainbus0: apid 52 (application processor)
cpu7: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz, 2666.77 MHz, 06-2c-02
cpu7:
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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu7: 256KB 64b/line 8-way L2 cache
cpu7: smt 0, core 10, package 1
cpu8 at mainbus0: apid 1 (application processor)
cpu8: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz, 2666.77 MHz, 06-2c-02
cpu8:
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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu8: 256KB 64b/line 8-way L2 cache
cpu8: smt 1,

Re: bgpd path selection seems broken at now

2020-10-15 Thread Sebastian Benoit 
Hi,

I think it would help if you could send your configuration file, or at least
the bgpctl commands that show the problem.
Also please send a dmesg so we know what version you are running.

Thanks,
Benno


Bars Bars(tutbara...@gmail.com) on 2020.10.12 15:10:11 +0300:
> To be more clear i mean this one commit on rde_rib.c, but again im not sure.
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/bgpd/rde_rib.c?rev=1.189=text/x-cvsweb-markup
> 
> 
> , 12 ??. 2020 ??. ?? 13:52, Bars Bars :
> 
> > Hi,
> >
> > Firstly, i have to say, that its really hard to understand prefix
> > comparison procedure
> > calls for me, because of there are so much ways where
> > different comparisons done inside, like
> > prefix_cmp()/prefix_compare()/pt_prefix_cmp()/path_compare()/etc. So, I
> > guess, I may be totally wrong here in decisions...
> >
> > But anyway, it seems currently (at 6.6-stable and 6.7-stable, at least)
> > that
> > path selection is not performing at least for VPNv4 (not tried other AIDs
> > yet) if we have the same
> > prefixes with different RD while importing them to FIB. Normally, at this
> > stage there should be path selection accomplished (or ECMP multipath
> > used, if supported). But instead, both prefixes are present in rdomain's
> > rib,
> > and the only newest one is used as active even if others have better
> > attributes (route-age evaluation is not enabled by default).
> > I tried to research is that caused by different rd, or by some broken
> > comparison itself, but i guess that things get broken somewhere with
> > commit
> > evision 1.189 (tagged as "bgpd adj-rib-out rewrite") or so around,
> > because of since that we have static prefix_cmp() in rde_rib translation
> > unit,
> > and so functions like prefix_add()/prefix_move()/prefix_update() are
> > missing
> > prefix_cmp() defined in rde_decide translation unit, which is actually do
> > bgp path selection.
> >
> > The peer setup is
> > ebgp-peer advertises multiple VPNv4 prefixes with different RD to the
> > bgpd-peer, say,
> > rd1:x.x.x.x/y
> > rd2:x.x.x.x/y
> > rd3:x.x.x.x/y
> > where x.x.x.x/y are equal but have different as-path length, or changed
> > lpref in bgpd config
> > with set attributes filter. Prefix which advertised last becomes active
> > prefix for the FIB.
> >
> > Again, may be I dont understand something, but it does not work.
> >
> >
> 

--

Re: bgpd path selection seems broken at now

2020-10-12 Thread Bars Bars 
To be more clear i mean this one commit on rde_rib.c, but again im not sure.
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/bgpd/rde_rib.c?rev=1.189=text/x-cvsweb-markup


пн, 12 окт. 2020 г. в 13:52, Bars Bars :

> Hi,
>
> Firstly, i have to say, that its really hard to understand prefix
> comparison procedure
> calls for me, because of there are so much ways where
> different comparisons done inside, like
> prefix_cmp()/prefix_compare()/pt_prefix_cmp()/path_compare()/etc. So, I
> guess, I may be totally wrong here in decisions...
>
> But anyway, it seems currently (at 6.6-stable and 6.7-stable, at least)
> that
> path selection is not performing at least for VPNv4 (not tried other AIDs
> yet) if we have the same
> prefixes with different RD while importing them to FIB. Normally, at this
> stage there should be path selection accomplished (or ECMP multipath
> used, if supported). But instead, both prefixes are present in rdomain's
> rib,
> and the only newest one is used as active even if others have better
> attributes (route-age evaluation is not enabled by default).
> I tried to research is that caused by different rd, or by some broken
> comparison itself, but i guess that things get broken somewhere with
> commit
> evision 1.189 (tagged as "bgpd adj-rib-out rewrite") or so around,
> because of since that we have static prefix_cmp() in rde_rib translation
> unit,
> and so functions like prefix_add()/prefix_move()/prefix_update() are
> missing
> prefix_cmp() defined in rde_decide translation unit, which is actually do
> bgp path selection.
>
> The peer setup is
> ebgp-peer advertises multiple VPNv4 prefixes with different RD to the
> bgpd-peer, say,
> rd1:x.x.x.x/y
> rd2:x.x.x.x/y
> rd3:x.x.x.x/y
> where x.x.x.x/y are equal but have different as-path length, or changed
> lpref in bgpd config
> with set attributes filter. Prefix which advertised last becomes active
> prefix for the FIB.
>
> Again, may be I dont understand something, but it does not work.
>
>