Re: wrong if used after adding new route - affects syslog, dhcrelay and more
On 29/01/18(Mon) 20:40, Remi Locherer wrote: > On Mon, Jan 29, 2018 at 07:33:47PM +0100, Remi Locherer wrote: > > > Problem Description > > Local originating traffic leaves the system on the wrong interface > > after a more specific route was added. This is problematic for services > > like dhcrelay and syslogd. > > > > I verified this on iced this on OpenBSD 6.1 but do not know how if was with > > older versions. The behaviour is still the same with current. > > What I wanted to write: > I verified this behaviour on OpenBSD 6.1, 6.2 and -current. I do not know > if it was different with older releases. I believe it's the same. When you're adding a most specific route there's no mechanism to "invalidate" less specific routes. What could be done when adding the new route is: - lookup the second most specific (default in your case). - insert the new route (172.30.1.0/24 in your case) - remove & reinsert the second most specific and its MPATH siblings. This should make the ip_output() realize the default route it was using is no longer valid (rt_isvalid() returns false), do a new route lookup and fetch the newly added entry.
Re: wrong if used after adding new route - affects syslog, dhcrelay and more
On Mon, Jan 29, 2018 at 07:33:47PM +0100, Remi Locherer wrote: > > Problem Description > Local originating traffic leaves the system on the wrong interface > after a more specific route was added. This is problematic for services > like dhcrelay and syslogd. > > I verified this on iced this on OpenBSD 6.1 but do not know how if was with > older versions. The behaviour is still the same with current. What I wanted to write: I verified this behaviour on OpenBSD 6.1, 6.2 and -current. I do not know if it was different with older releases. > > > Workaround: > Monitor the routing socket and restart affected services when the routing > table changes. > > > How to reproduce: > mistral ~# route -n show -inet > Routing tables > > Internet: > DestinationGatewayFlags Refs Use Mtu Prio Iface > default172.18.35.1UGS7 408 -12 iwm0 > 224/4 127.0.0.1 URS0 1898 32768 8 lo0 > 127/8 127.0.0.1 UGRS 00 32768 8 lo0 > 127.0.0.1 127.0.0.1 UHhl 14 32768 1 lo0 > 172.18.35/24 172.18.35.87 UCn1 634 - 8 iwm0 > 172.18.35.1cc:4e:24:82:88:42 UHLch 1 312 - 7 iwm0 > 172.18.35.87 5c:e0:c5:1f:ad:c4 UHLl 0 14 - 1 iwm0 > 172.18.35.255 172.18.35.87 UHb0 633 - 1 iwm0 > 172.30.1/24192.168.250.18 UGS00 - 8 > vether0 > 192.168.250/24 192.168.250.1 UCn10 - 4 > vether0 > 192.168.250.1 fe:e1:ba:d0:05:e2 UHLl 05 - 1 > vether0 > 192.168.250.18 fe:e1:bb:d1:a2:b9 UHLch 2 37 - 3 > vether0 > 192.168.250.255192.168.250.1 UHb1 105 - 1 > vether0 > mistral ~# > > $mistral 130 ~$ nc -u 172.30.1.1 > adsfsa > > --> do not press ^C, keep it open to generate traffic over the same > socket after changing routes > > --> as expected traffic leaves on vether0 > 16:24:00.676256 rule 0/(match) match out on vether0: 192.168.250.1.28812 > > 172.30.1.1.: udp 7 > > mistral ~# route del 172.30.1.0/24 > > --> now traffic leaves on iwm0. makes sense because of the default route. > 16:24:51.078621 rule 0/(match) match out on iwm0: 192.168.250.1.28812 > > 172.30.1.1.: udp 3 > > mistral ~# route add 172.30.1.0/24 192.168.250.18 > > --> traffic still leaves iwm0. expectations: vether0 > 16:28:09.440038 rule 0/(match) match out on iwm0: 192.168.250.1.28812 > > 172.30.1.1.: udp 4 > > > > dmesg > > OpenBSD 6.2-current (GENERIC.MP) #107: Tue Jan 16 21:58:15 CET 2018 > r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8473632768 (8081MB) > avail mem = 8209895424 (7829MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe (84 entries) > bios0: vendor Dell Inc. version "A13" date 06/16/2017 > bios0: Dell Inc. XPS 13 9343 > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! SSDT > SSDT SSDT SSDT PCCT SSDT SSDT SSDT SLIC MSDM DMAR CSRT BGRT > acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) > PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) > PXSX(S4) RP05(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) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.62 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT > cpu0: 256KB 64b/line 8-way L2 cache > acpitimer0: recalibrated TSC frequency 2194928041 Hz > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.22 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 1 (application processor) >
wrong if used after adding new route - affects syslog, dhcrelay and more
> Problem Description Local originating traffic leaves the system on the wrong interface after a more specific route was added. This is problematic for services like dhcrelay and syslogd. I verified this on iced this on OpenBSD 6.1 but do not know how if was with older versions. The behaviour is still the same with current. > Workaround: Monitor the routing socket and restart affected services when the routing table changes. > How to reproduce: mistral ~# route -n show -inet Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default172.18.35.1UGS7 408 -12 iwm0 224/4 127.0.0.1 URS0 1898 32768 8 lo0 127/8 127.0.0.1 UGRS 00 32768 8 lo0 127.0.0.1 127.0.0.1 UHhl 14 32768 1 lo0 172.18.35/24 172.18.35.87 UCn1 634 - 8 iwm0 172.18.35.1cc:4e:24:82:88:42 UHLch 1 312 - 7 iwm0 172.18.35.87 5c:e0:c5:1f:ad:c4 UHLl 0 14 - 1 iwm0 172.18.35.255 172.18.35.87 UHb0 633 - 1 iwm0 172.30.1/24192.168.250.18 UGS00 - 8 vether0 192.168.250/24 192.168.250.1 UCn10 - 4 vether0 192.168.250.1 fe:e1:ba:d0:05:e2 UHLl 05 - 1 vether0 192.168.250.18 fe:e1:bb:d1:a2:b9 UHLch 2 37 - 3 vether0 192.168.250.255192.168.250.1 UHb1 105 - 1 vether0 mistral ~# $mistral 130 ~$ nc -u 172.30.1.1 adsfsa --> do not press ^C, keep it open to generate traffic over the same socket after changing routes --> as expected traffic leaves on vether0 16:24:00.676256 rule 0/(match) match out on vether0: 192.168.250.1.28812 > 172.30.1.1.: udp 7 mistral ~# route del 172.30.1.0/24 --> now traffic leaves on iwm0. makes sense because of the default route. 16:24:51.078621 rule 0/(match) match out on iwm0: 192.168.250.1.28812 > 172.30.1.1.: udp 3 mistral ~# route add 172.30.1.0/24 192.168.250.18 --> traffic still leaves iwm0. expectations: vether0 16:28:09.440038 rule 0/(match) match out on iwm0: 192.168.250.1.28812 > 172.30.1.1.: udp 4 > dmesg OpenBSD 6.2-current (GENERIC.MP) #107: Tue Jan 16 21:58:15 CET 2018 r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8473632768 (8081MB) avail mem = 8209895424 (7829MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe (84 entries) bios0: vendor Dell Inc. version "A13" date 06/16/2017 bios0: Dell Inc. XPS 13 9343 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! SSDT SSDT SSDT SSDT PCCT SSDT SSDT SSDT SLIC MSDM DMAR CSRT BGRT acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(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) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.62 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache acpitimer0: recalibrated TSC frequency 2194928041 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.22 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.22 MHz cpu2:
