Re: BGPd filter puzzle
Rod Whitworth(glis...@witworx.com) on 2013.08.07 16:14:50 +1000: > On Wed, 7 Aug 2013 07:30:49 +0200, Claudio Jeker wrote: > > >This is from the network stack, it does not mean that bgpd added routes > >for this. For that you should check bgpctl show rib, bgpctl show fib and > >route(8) output. > I'll have to check when some traffic is passing. Pity the error line > doesn't have a timestamp 8-) check /var/log/messages > >The problem here is that somebody on sis0 is sending you > >packets using link local addresses as source IP to a global IP as > >destination. This is not allowed since there is no way to send packets > >back. So if sis0 is upstream then something is seriously wrong on that > >upstream. > > I dig all that and my attitude was that they should not be doing that > but why is my filter not blocking it anyway? > > deny from any prefix fe80::/10 prefixlen >= 10 # link local > unicast > > Am I missing something there? yes, this: > >This is from the network stack bgpd got nothing to do with it: the box on the other end of your link is sending you this traffic. The network stack sees it (on rcvif sis0), it knows it would have to forward it (through outif vr1) and decides that it cannot do that because link-local -> global unicast is not allowed. All your bgp rule above does is to say "my peer is not allowed to send me link-local routes" via bgp and it probably isnt doing that at all. bgpd does just the route filtering, not the traffic filtering that happens here in the network stack (and that is not configurable). /Benno
Re: BGPd filter puzzle
On Wed, 7 Aug 2013 07:30:49 +0200, Claudio Jeker wrote: >This is from the network stack, it does not mean that bgpd added routes >for this. For that you should check bgpctl show rib, bgpctl show fib and >route(8) output. I'll have to check when some traffic is passing. Pity the error line doesn't have a timestamp 8-) >The problem here is that somebody on sis0 is sending you >packets using link local addresses as source IP to a global IP as >destination. This is not allowed since there is no way to send packets >back. So if sis0 is upstream then something is seriously wrong on that >upstream. I dig all that and my attitude was that they should not be doing that but why is my filter not blocking it anyway? deny from any prefix fe80::/10 prefixlen >= 10 # link local unicast Am I missing something there? > > >All went to shit when they added link local addressing to IPv6 in the >ivory tower. All this because DHCP was considered bad. So we ended up >with this mess that is worse by at least 50dB. > It's a case of NIBU* as opposed to NIH. * Not Invented By Us. Thanks for the fast reply. I'll see you at EuroBSDcon if I survive the close to 30 hours in transit. ;-) *** NOTE *** Please DO NOT CC me. I subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Re: BGPd filter puzzle
On Wed, Aug 07, 2013 at 01:58:42PM +1000, Rod Whitworth wrote: > I logged in to an OpenBGPd router which I maintain remotely as I needed to > check something from dmesg. > > The command "dmesg|less" resulted in 150 lines, none of which was what I > expected to see. > > Here are some samples: > cannot forward src fe80:0005::0420:77e7:f6bf:3550, dst 2406:a000::0006:0d08, > nxt 6, rcvif sis0, outif vr1 > cannot forward src fe80:0005::92f6:52ff:fe02:4734, dst 2406:a000::0005, nxt > 17, rcvif sis0, outif vr1 > cannot forward src fe80:0005::0420:77e7:f6bf:3550, dst 2406:a000::0006:0d08, > nxt 17, rcvif sis0, outif vr1 > cannot forward src fe80:0005::0224:21ff:fe29:eaca, dst 2406:a000::0005, nxt > 17, rcvif sis0, outif vr1 > > The link-local address of the rcvif is inet6 fe80::200:24ff:feca:3ad4%sis0 > prefixlen 64 scopeid 0x5 > so it isn't involved. > > Furthermore the bgpd.conf ends with: > deny from any prefix fe80::/10 prefixlen >= 10 # link local unicast > deny from any prefix fec0::/10 prefixlen >= 10 # old site local > unicast > deny from any prefix ff00::/8 prefixlen >= 8# multicast > #EOF > > Simple(?) question first: Why is traffic coming via a transit provider > getting past the link-local filter rule? > > Secondly what do the "nxt 6" and "nxt 17" mean? > This is from the network stack, it does not mean that bgpd added routes for this. For that you should check bgpctl show rib, bgpctl show fib and route(8) output. The problem here is that somebody on sis0 is sending you packets using link local addresses as source IP to a global IP as destination. This is not allowed since there is no way to send packets back. So if sis0 is upstream then something is seriously wrong on that upstream. All went to shit when they added link local addressing to IPv6 in the ivory tower. All this because DHCP was considered bad. So we ended up with this mess that is worse by at least 50dB. -- :wq Claudio
BGPd filter puzzle
I logged in to an OpenBGPd router which I maintain remotely as I needed to
check something from dmesg.
The command "dmesg|less" resulted in 150 lines, none of which was what I
expected to see.
Here are some samples:
cannot forward src fe80:0005::0420:77e7:f6bf:3550, dst 2406:a000::0006:0d08,
nxt 6, rcvif sis0, outif vr1
cannot forward src fe80:0005::92f6:52ff:fe02:4734, dst 2406:a000::0005, nxt 17,
rcvif sis0, outif vr1
cannot forward src fe80:0005::0420:77e7:f6bf:3550, dst 2406:a000::0006:0d08,
nxt 17, rcvif sis0, outif vr1
cannot forward src fe80:0005::0224:21ff:fe29:eaca, dst 2406:a000::0005, nxt 17,
rcvif sis0, outif vr1
The link-local address of the rcvif is inet6 fe80::200:24ff:feca:3ad4%sis0
prefixlen 64 scopeid 0x5
so it isn't involved.
Furthermore the bgpd.conf ends with:
deny from any prefix fe80::/10 prefixlen >= 10 # link local unicast
deny from any prefix fec0::/10 prefixlen >= 10 # old site local unicast
deny from any prefix ff00::/8 prefixlen >= 8# multicast
#EOF
Simple(?) question first: Why is traffic coming via a transit provider getting
past the link-local filter rule?
Secondly what do the "nxt 6" and "nxt 17" mean?
Mandatory dmesg from dmesg.boot:
OpenBSD 5.2 (GENERIC) #1: Fri Nov 30 17:27:14 EST 2012
r...@nero.witworx.com:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 500
MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
real mem = 536408064 (511MB)
avail mem = 516780032 (492MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 20/80/26, BIOS32 rev. 0 @ 0xfac40
pcibios0 at bios0: rev 2.0 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc8000/0xa800
cpu0 at mainbus0: (uniprocessor)
amdmsr0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
io address conflict 0x6100/0x100
io address conflict 0x6200/0x200
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, address
00:00:24:ca:d9:1c
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
vr1 at pci0 dev 7 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 5, address
00:00:24:ca:d9:1d
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
vr2 at pci0 dev 8 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 9, address
00:00:24:ca:d9:1e
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
vr3 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12, address
00:00:24:ca:d9:1f
ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
ppb0 at pci0 dev 14 function 0 "TI PCI2250 PCI-PCI" rev 0x02
pci1 at ppb0 bus 1
sis0 at pci1 dev 0 function 0 "NS DP83815 10/100" rev 0x00, DP83816A: irq 10,
address 00:00:24:ca:3a:d4
nsphyter0 at sis0 phy 0: DP83815 10/100 PHY, rev. 1
sis1 at pci1 dev 1 function 0 "NS DP83815 10/100" rev 0x00, DP83816A: irq 7,
address 00:00:24:ca:3a:d5
nsphyter1 at sis1 phy 0: DP83815 10/100 PHY, rev. 1
sis2 at pci1 dev 2 function 0 "NS DP83815 10/100" rev 0x00, DP83816A: irq 10,
address 00:00:24:ca:3a:d6
nsphyter2 at sis2 phy 0: DP83815 10/100 PHY, rev. 1
sis3 at pci1 dev 3 function 0 "NS DP83815 10/100" rev 0x00, DP83816A: irq 7,
address 00:00:24:ca:3a:d7
nsphyter3 at sis3 phy 0: DP83815 10/100 PHY, rev. 1
glxpcib0 at pci0 dev 20 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit
3579545Hz timer, watchdog, gpio, i2c
gpio0 at glxpcib0: 32 pins
iic0 at glxpcib0
pciide0 at pci0 dev 20 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 1-sector PIO, LBA, 1907MB, 3906560 sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 21 function 0 "AMD CS5536 USB" rev 0x02: irq 15, version 1.0,
legacy support
ehci0 at pci0 dev 21 function 1 "AMD CS5536 USB" rev 0x02: irq 15
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "AMD EHCI root hub" rev 2.00/1.00 addr 1
isa0 at glxpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 9: GPIO VLM TMS
gpio1 at nsclpcsio0: 29 pins
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 "AMD OHCI root hub" rev 1.00/1.00 addr 1
mtrr: K6-family MTRR support (2 registers)
vscsi0 at root
scsibus0 at vscsi0
