Re: OpenBGPD Flaps, 32bit ASn in the wild.
Just to add my vote. I'm with Claudio on this one. Surely it's Input Validation 101 . Validate the input yes, but don't tamper with what's not yours It is not what we do and IMO trying to fiddle out bad path attributes and still use the crippled rest smells like routing loops comming soon to a network near you.
Re: OpenBGPD Flaps, 32bit ASn in the wild
There are, by the way, one or two interesting threads out there from the commercial router world about the same topic.. http://www.merit.edu/mail.archives/nanog/msg14345.html
Re: OpenBGPD Flaps, 32bit ASn in the wild.
Hi, On Fri, 30.01.2009 at 04:08:34 -0800, OpenBSD User gb10hkzo-open...@yahoo.co.uk wrote: Just to add my vote. I'm with Claudio on this one. me too. Validate the input yes, but don't tamper with what's not yours After reading the thread on idr, I'm under the impression that the suggested fix is suggested in order to cope for a bug in some versions of JunOS. Some people don't seem to have any interest in standardized interoperations, as it seems. It seems to be just too convenient for the big guys to strongarm their way into the standards, at the expense of at least everyone else. Kind regards, --Toni++
Re: OpenBGPD Flaps, 32bit ASn in the wild.
Hi, On Sat, 10.01.2009 at 12:11:03 -0600, tico t...@raapid.net wrote: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/bgpd/rde.c looking at CVS, it seems that multiple patches are needed, right? And we get the joy of threading them together ourselves, understanding OpenBGPd's code in the process... maybe. Kind regards, --Toni++
Re: OpenBGPD Flaps, 32bit ASn in the wild.
Hi, On Thu, 29.01.2009 at 14:47:30 +0100, Toni Mueller openbsd-m...@oeko.net wrote: And we get the joy of threading them together ourselves, understanding OpenBGPd's code in the process... maybe. can I just plug in a bgpd from -current into a 4.4, or preferably 4.3 system, assuming that I compile the code from source? Or did any kernel structures or system calls change that would cause problems? Overall, the code from -current looks like having been much improved, but unfortunately, just swapping out the box is currently not an attractive option (despite having capable standby hardware). TIA! -- Kind regards, --Toni++
Re: OpenBGPD Flaps, 32bit ASn in the wild.
On Thu, Jan 29, 2009 at 03:28:14PM +0100, Toni Mueller wrote: Hi, On Thu, 29.01.2009 at 14:47:30 +0100, Toni Mueller openbsd-m...@oeko.net wrote: And we get the joy of threading them together ourselves, understanding OpenBGPd's code in the process... maybe. can I just plug in a bgpd from -current into a 4.4, or preferably 4.3 system, assuming that I compile the code from source? Or did any kernel structures or system calls change that would cause problems? Overall, the code from -current looks like having been much improved, but unfortunately, just swapping out the box is currently not an attractive option (despite having capable standby hardware). Will most probably not work. The -current bgpd has a reworked kroute.c that needs a -current kernel. -- :wq Claudio
Re: OpenBGPD Flaps, 32bit ASn in the wild.
On 2009-01-29, Toni Mueller openbsd-m...@oeko.net wrote:
Hi,
On Sat, 10.01.2009 at 12:11:03 -0600, tico t...@raapid.net wrote:
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/bgpd/rde.c
looking at CVS, it seems that multiple patches are needed, right?
And we get the joy of threading them together ourselves, understanding
OpenBGPd's code in the process... maybe.
This should work, but I run -current everywhere, I have no 4.4 boxes
to test it on.
Incidentally this looks like the same approach suggested by the
draft RFC4893bis
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.232
diff -u -p -r1.232 rde.c
--- rde.c 15 Jun 2008 10:03:46 - 1.232
+++ rde.c 29 Jan 2009 16:51:04 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: rde.c,v 1.232 2008/06/15 10:03:46 claudio Exp $ */
+/* $OpenBSD: rde.c,v 1.234 2008/12/28 15:19:21 claudio Exp $ */
/*
* Copyright (c) 2003, 2004 Henning Brauer henn...@openbsd.org
@@ -797,8 +797,10 @@ rde_update_dispatch(struct imsg *imsg)
/*
* if either ATTR_NEW_AGGREGATOR or ATTR_NEW_ASPATH is present
* try to fixup the attributes.
+* XXX do not fixup if F_ATTR_LOOP is set.
*/
- if (asp-flags F_ATTR_AS4BYTE_NEW)
+ if (asp-flags F_ATTR_AS4BYTE_NEW
+ !(asp-flags F_ATTR_LOOP))
rde_as4byte_fixup(peer, asp);
/* enforce remote AS if requested */
@@ -1347,10 +1349,17 @@ bad_flags:
ATTR_PARTIAL))
goto bad_flags;
if (aspath_verify(p, attr_len, 1) != 0) {
- /* XXX draft does not specify how to handle errors */
- rde_update_err(peer, ERR_UPDATE, ERR_UPD_ASPATH,
- NULL, 0);
- return (-1);
+ /*
+* XXX
+* XXX RFC does not specify how to handle errors.
+* XXX Instead of dropping the session because of a
+* XXX bad path just mark the full update as not
+* XXX loop-free the update is no longer eligible and
+* XXX will not be considered for routing or
+* XXX redistribution. Something better is needed.
+*/
+ a-flags |= F_ATTR_LOOP;
+ goto optattr;
}
a-flags |= F_ATTR_AS4BYTE_NEW;
goto optattr;
Re: OpenBGPD Flaps, 32bit ASn in the wild.
Hi Stuart, On Thu, 29.01.2009 at 16:52:55 +, Stuart Henderson s...@spacehopper.org wrote: This should work, but I run -current everywhere, I have no 4.4 boxes to test it on. thanks! I'll try that first, although I hoped to also bag the other improvements while I'm at it. Incidentally this looks like the same approach suggested by the draft RFC4893bis I should dig this one up. In any case, the patch looks much like the minimal patch that Claudio floated on the list in December. Can someone please promote it to errata? -- Kind regards, --Toni++
Re: OpenBGPD Flaps, 32bit ASn in the wild.
Hi Claudio, On Thu, 29.01.2009 at 17:13:32 +0100, Claudio Jeker cje...@diehard.n-r-g.com wrote: Will most probably not work. The -current bgpd has a reworked kroute.c that needs a -current kernel. thanks for confirming my doubts. Now I can try to find out whether the changes in kroute.c are sufficiently isolated from the rest... Btw, I've just rebuilt bgpd with code tagged OPENBSD_4_3_BASE, but the checksum is different from that in the distribution. The difference shown with cmp -l is way too large to be just a different timestamp and/or what(1) info. Now I'm a bit scared... -- Kind regards, --Toni++
Re: OpenBGPD Flaps, 32bit ASn in the wild.
On Thu, Jan 29, 2009 at 04:52:55PM +, Stuart Henderson wrote: On 2009-01-29, Toni Mueller openbsd-m...@oeko.net wrote: Hi, On Sat, 10.01.2009 at 12:11:03 -0600, tico t...@raapid.net wrote: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/bgpd/rde.c looking at CVS, it seems that multiple patches are needed, right? And we get the joy of threading them together ourselves, understanding OpenBGPd's code in the process... maybe. This should work, but I run -current everywhere, I have no 4.4 boxes to test it on. Incidentally this looks like the same approach suggested by the draft RFC4893bis I just glanced over it and I'm very unhappy with the direction they're taking. It is not what we do and IMO trying to fiddle out bad path attributes and still use the crippled rest smells like routing loops comming soon to a network near you. Bad prefixes should not get redistributed this will also ensure that only the originator of the problem is affected. -- :wq Claudio
Re: OpenBGPD Flaps, 32bit ASn in the wild.
On 2009-01-29, Claudio Jeker cje...@diehard.n-r-g.com wrote: On Thu, Jan 29, 2009 at 04:52:55PM +, Stuart Henderson wrote: On 2009-01-29, Toni Mueller openbsd-m...@oeko.net wrote: Hi, On Sat, 10.01.2009 at 12:11:03 -0600, tico t...@raapid.net wrote: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/bgpd/rde.c looking at CVS, it seems that multiple patches are needed, right? And we get the joy of threading them together ourselves, understanding OpenBGPd's code in the process... maybe. This should work, but I run -current everywhere, I have no 4.4 boxes to test it on. Incidentally this looks like the same approach suggested by the draft RFC4893bis I just glanced over it and I'm very unhappy with the direction they're taking. It is not what we do and IMO trying to fiddle out bad path attributes and still use the crippled rest smells like routing loops comming soon to a network near you. Bad prefixes should not get redistributed this will also ensure that only the originator of the problem is affected. Oh yeuch, I misinterpreted it. More discussion at http://permalink.gmane.org/gmane.ietf.idr/5354
Re: OpenBGPD Flaps, 32bit ASn in the wild.
Am 10.12.2008 um 23:32 schrieb Claudio Jeker: The best thing we can do is to mark the update as ineligible so it will not propaget further and will not be used but this is a quite radical measure. On the other hand this is porbably the safest way to handle this error. Sound good for me. Is there any patch I can download and compile bgpd on my own? :wq Claudio Regards, Falk
Re: OpenBGPD Flaps, 32bit ASn in the wild.
Falk Brockerhoff wrote: Am 10.12.2008 um 23:32 schrieb Claudio Jeker: The best thing we can do is to mark the update as ineligible so it will not propaget further and will not be used but this is a quite radical measure. On the other hand this is porbably the safest way to handle this error. Sound good for me. Is there any patch I can download and compile bgpd on my own? Regards, Falk Falk, Read the rest of the thread to which you've just responded: http://marc.info/?l=openbsd-miscm=122894875212174w=2 http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/bgpd/rde.c -Tico
Re: OpenBGPD Flaps, 32bit ASn in the wild.
Claudio Jeker wrote: On Wed, Dec 10, 2008 at 04:47:31PM -0500, Ted Unangst wrote: On Wed, Dec 10, 2008 at 4:38 PM, Claudio Jeker cje...@diehard.n-r-g.com wrote: I looked at the porblem and I'm currently unsure what the best way is to handle such bad AS4_* attributes. The RFC in all its glory does not mention how to handle errors. So at the moment I'm in favor of just dropping/ignoring the bad optional attribute but I need to recheck with the BGP RFC to see if this is valid. Another solution is to ignore the full update but I have a bad feeling about that. Can you ignore just the route with the bad attribute? We don't want to propagate it more. The best thing we can do is to mark the update as ineligible so it will not propaget further and will not be used but this is a quite radical measure. On the other hand this is porbably the safest way to handle this error. Comments? My thinking is in line with yours. RFC4271 doesn't appear to specify how to handle this scenario gracefully, as already mentioned here: http://www.merit.edu/mail.archives/nanog/msg13422.html Apparently there are already enough BGP speakers on the net that don't check for a valid AS4_PATH before announcing it onwards to cause problems for OpenBGPd users, if not others. I'd rather be missing a route than missing an entire feed and/or propagating attributes that will kill others' BGP sessions. -tico
Re: OpenBGPD Flaps, 32bit ASn in the wild.
tico wrote: Claudio Jeker wrote: On Wed, Dec 10, 2008 at 04:47:31PM -0500, Ted Unangst wrote: On Wed, Dec 10, 2008 at 4:38 PM, Claudio Jeker cje...@diehard.n-r-g.com wrote: I looked at the porblem and I'm currently unsure what the best way is to handle such bad AS4_* attributes. The RFC in all its glory does not mention how to handle errors. So at the moment I'm in favor of just dropping/ignoring the bad optional attribute but I need to recheck with the BGP RFC to see if this is valid. Another solution is to ignore the full update but I have a bad feeling about that. Can you ignore just the route with the bad attribute? We don't want to propagate it more. The best thing we can do is to mark the update as ineligible so it will not propaget further and will not be used but this is a quite radical measure. On the other hand this is porbably the safest way to handle this error. Comments? My thinking is in line with yours. RFC4271 doesn't appear to specify how to handle this scenario gracefully, as already mentioned here: http://www.merit.edu/mail.archives/nanog/msg13422.html Apparently there are already enough BGP speakers on the net that don't check for a valid AS4_PATH before announcing it onwards to cause problems for OpenBGPd users, if not others. I'd rather be missing a route than missing an entire feed and/or propagating attributes that will kill others' BGP sessions. -tico I concur.
Re: OpenBGPD Flaps, 32bit ASn in the wild.
Ditto. This has just caused me the same problems. Alex at Hurricane Electric found this for me, and my ipv4 BGP sessions have *only* stabilized after filtering out this prefix (4.4-RELEASE on i386). I'll post up MRT dumps if anyone's interested. -Tico Peter Bristow wrote: Hi All, The AS at the company I work for running (OpenBSD 4.2 and 4.3) as well as the AS run by a associate of mine (OpenBSD 4.4) experienced rather wild route flaps earlier today. Quoted from Andy Davidson's post to nanog. It seems that the prefix causing OpenBGPd speakers to die is 91.207.218.0/23, which is originated by a 4-byte ASN speaker. OpenBGPd is checking AS4_PATH to ensure that it contains only AS_SET and AS_SEQUENCE types, as per RFC4893. When processing the UPDATE for 91.207.218.0/23 it sees : 91.207.218.0/23 Path Attributes - Origin: Incomplete Flags: 0x40 (Well-known, Transitive, Complete) Origin: Incomplete (2) AS_PATH: xx xx 35320 23456 (13 bytes) AS4_PATH: (65044 65057) 196629 (7 bytes) RFC4893 is clear on the matter : To prevent the possible propagation of confederation path segments outside of a confederation, the path segment types AS_CONFED_SEQUENCE and AS_CONFED_SET [RFC3065] are declared invalid for the AS4_PATH attribute. OpenBGPd is therefore dropping the sessions when this update is received. Unideal if this attribute is learned on multiple upstreams... The impact today is fairly limited as there are relatively few bgp speakers honouring the 4-byte ASN protocol extension rules, but as code that support these features creeps around the internet, the next time this happens the impact could be much greater, so we need to understand which implementation of which BGP software caused this illegal origination. Modifying the OpenBGPd software to permit AS_CONFED_SEQUENCE, AS_CONFED_SET in an as4_path causes the path to be accepted and the session is not torn down. This isn't a great fix. From looking at the source this would appear to be 'expected' behavior however it does leave you without any internet connectivity. I'm not as much of a BGP guru as I should be but what would be the impact of dropping the route/update rather than dropping the session? Pete Bristow
Re: OpenBGPD Flaps, 32bit ASn in the wild.
Hi all
We were one of the AS's affected by this -- it took down both of our
(otherwise very reliable!) OpenBSD 4.4 routers, and I spent much of this
afternoon diagnosing and then working around the problem.
The problem is that the AS4_PATH value being transmitted for prefix
91.207.218.0/23 contained a path segment of type AS_CONFED_SEQUENCE, which as
RFC4893 declares to be an invalid value.
OpenBGPd checks this attribute, finds it to be invalid, and drops the entire
BGP session. On the face of it, this action seems to be a reasonable thing
to do, but in practice it is only reasonable if all BGP speakers do this; in
that instance the BGP speakers closest to the router emitting the faulty
attributes would close the conversations, the faulty AS4_PATH would not
propagate, the admins of those routers would then be under some pressure to
fix the problem (since their BGP sessions would be down).
However, since most BGP speakers apparently do NOT examine the AS4_PATH it
propagates out until it reaches a speaker who does examine it, and they then
promptly terminate the BGP session with a BGP NOTIFICATION type 3 (UPDATE
message error) subcode 11 (Malformed AS_PATH).
The intervening routers, which do not examine but do pass on the AS4_PATH
attribute, are unaffected. Thus the problem manifests itself far from the
real source, and as Peter says unless one is unreasonably left without any
BGP session at all (and thus most likely no internet connection).
Since 32-bit ASNs are being retrofitted to the existing BGP4 system and the
situation of AS4_PATH not being validated by the majority of BGP speakers
will persist for some time, OpenBGPd's behaviour should probably be changed.
OpenBGPd 4.2 and 4.3 are affected. OpenBGPd 4.0 did not verify the AS4_PATH
attribute and appears to be unaffected.
Here's my patch that modifes OpenBGPd to (silently) accept these malformed
AS4_PATH attributes; this is recommended solely as a workaround for affected
systems until a proper patch to OpenBGPd is developed:
http://sowerbutts.com/tmp/bgpd-wrs.patch
Here's the broken update we were seeing, viewed in wireshark:
http://sowerbutts.com/tmp/broken-update.png
Thanks
Will Sowerbutts
Deus Ex Machina Ltd
On Wed, Dec 10, 2008 at 08:36:58PM +, Peter Bristow wrote:
Hi All,
The AS at the company I work for running (OpenBSD 4.2 and 4.3) as well as
the AS run by a associate of mine (OpenBSD 4.4) experienced rather wild
route flaps earlier today. Quoted from Andy Davidson's post to nanog.
It seems that the prefix causing OpenBGPd speakers to die is
91.207.218.0/23, which is originated by a 4-byte ASN speaker.
OpenBGPd is checking AS4_PATH to ensure that it contains only AS_SET and
AS_SEQUENCE types, as per RFC4893. When processing the UPDATE for
91.207.218.0/23 it sees :
91.207.218.0/23
Path Attributes - Origin: Incomplete
Flags: 0x40 (Well-known, Transitive, Complete)
Origin: Incomplete (2)
AS_PATH: xx xx 35320 23456 (13 bytes)
AS4_PATH: (65044 65057) 196629 (7 bytes)
RFC4893 is clear on the matter :
To prevent the possible propagation of confederation path segments
outside of a confederation, the path segment types AS_CONFED_SEQUENCE
and AS_CONFED_SET [RFC3065] are declared invalid for the AS4_PATH
attribute.
OpenBGPd is therefore dropping the sessions when this update is received.
Unideal if this attribute is learned on multiple upstreams...
The impact today is fairly limited as there are relatively few bgp speakers
honouring the 4-byte ASN protocol extension rules, but as code that support
these features creeps around the internet, the next time this happens the
impact could be much greater, so we need to understand which implementation
of which BGP software caused this illegal origination.
Modifying the OpenBGPd software to permit AS_CONFED_SEQUENCE, AS_CONFED_SET
in an as4_path causes the path to be accepted and the session is not torn
down. This isn't a great fix.
From looking at the source this would appear to be
'expected' behavior however it does leave you without any internet
connectivity. I'm not as much of a BGP guru as I should be but what would be
the impact of dropping the route/update rather than dropping the session?
Pete Bristow
_
William R Sowerbutts [EMAIL PROTECTED]
Carpe post meridiem http://sowerbutts.com
main(){char*s=#=0 [EMAIL PROTECTED]@^7=,c=0,m;for(;c15;c++)for
(m=-1;m7;putchar(m++/6c%3/2?10:s[c]-311m?42:32));}
Re: OpenBGPD Flaps, 32bit ASn in the wild.
tico wrote: Ditto. This has just caused me the same problems. Alex at Hurricane Electric found this for me, and my ipv4 BGP sessions have *only* stabilized after filtering out this prefix (4.4-RELEASE on i386). I'll post up MRT dumps if anyone's interested. -Tico Peter Bristow wrote: Hi All, The AS at the company I work for running (OpenBSD 4.2 and 4.3) as well as the AS run by a associate of mine (OpenBSD 4.4) experienced rather wild route flaps earlier today. Quoted from Andy Davidson's post to nanog. It seems that the prefix causing OpenBGPd speakers to die is 91.207.218.0/23, which is originated by a 4-byte ASN speaker. OpenBGPd is checking AS4_PATH to ensure that it contains only AS_SET and AS_SEQUENCE types, as per RFC4893. When processing the UPDATE for 91.207.218.0/23 it sees : 91.207.218.0/23 Path Attributes - Origin: Incomplete Flags: 0x40 (Well-known, Transitive, Complete) Origin: Incomplete (2) AS_PATH: xx xx 35320 23456 (13 bytes) AS4_PATH: (65044 65057) 196629 (7 bytes) RFC4893 is clear on the matter : To prevent the possible propagation of confederation path segments outside of a confederation, the path segment types AS_CONFED_SEQUENCE and AS_CONFED_SET [RFC3065] are declared invalid for the AS4_PATH attribute. OpenBGPd is therefore dropping the sessions when this update is received. Unideal if this attribute is learned on multiple upstreams... The impact today is fairly limited as there are relatively few bgp speakers honouring the 4-byte ASN protocol extension rules, but as code that support these features creeps around the internet, the next time this happens the impact could be much greater, so we need to understand which implementation of which BGP software caused this illegal origination. Modifying the OpenBGPd software to permit AS_CONFED_SEQUENCE, AS_CONFED_SET in an as4_path causes the path to be accepted and the session is not torn down. This isn't a great fix. From looking at the source this would appear to be 'expected' behavior however it does leave you without any internet connectivity. I'm not as much of a BGP guru as I should be but what would be the impact of dropping the route/update rather than dropping the session? Pete Bristow Here's more information about my setup, just for completeness' sake: dmesg: OpenBSD 4.4 (GENERIC) #1021: Tue Aug 12 17:16:55 MDT 2008 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Pentium(R) 4 CPU 2.80GHz (GenuineIntel 686-class) 2.80 GHz cpu0: FPU,V86,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,SBF,CNXT-ID,xTPR real mem = 1072132096 (1022MB) avail mem = 1028272128 (980MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 08/16/06, BIOS32 rev. 0 @ 0xfb6d0, SMBIOS rev. 2.3 @ 0xf0800 (41 entries) bios0: vendor Phoenix Technologies, LTD version 6.00 PG date 08/16/2006 bios0: Supermicro P4SC8 apm0 at bios0: Power Management spec V1.2 (slowidle) apm0: AC on, battery charge unknown acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 2.1 @ 0xf/0xdf64 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfde80/224 (12 entries) pcibios0: PCI Exclusive IRQs: 5 9 10 11 12 pcibios0: PCI Interrupt Router at 000:31:0 (Intel 6300ESB LPC rev 0x00) pcibios0: PCI bus #3 is the last bus bios0: ROM list: 0xc/0x8000 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82875P Host rev 0x02 ppb0 at pci0 dev 3 function 0 Intel 82875P CSA rev 0x02 pci1 at ppb0 bus 1 em0 at pci1 dev 1 function 0 Intel PRO/1000CT (82547GI) rev 0x00: irq 11, address 00:30:48:8a:26:8e ppb1 at pci0 dev 28 function 0 Intel 6300ESB PCIX rev 0x02 pci2 at ppb1 bus 2 uhci0 at pci0 dev 29 function 0 Intel 6300ESB USB rev 0x02: irq 12 uhci1 at pci0 dev 29 function 1 Intel 6300ESB USB rev 0x02: irq 10 Intel 6300ESB WDT rev 0x02 at pci0 dev 29 function 4 not configured Intel 6300ESB APIC rev 0x02 at pci0 dev 29 function 5 not configured ehci0 at pci0 dev 29 function 7 Intel 6300ESB USB rev 0x02: irq 5 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb2 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0x0a pci3 at ppb2 bus 3 vga1 at pci3 dev 9 function 0 ATI Rage XL rev 0x27 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) drm at vga1 unsupported em1 at pci3 dev 10 function 0 Intel PRO/1000MT (82541GI) rev 0x00: irq 10, address 00:30:48:8a:26:8f ichpcib0 at pci0 dev 31 function 0 Intel 6300ESB LPC rev 0x02: 24-bit timer at 3579545Hz pciide0 at pci0 dev 31 function 1 Intel 6300ESB IDE rev 0x02: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: WDC WD2500JB-57REA0 wd0: 16-sector PIO, LBA48, 238475MB, 488397168 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 pciide0: channel 1 disabled (no
Re: OpenBGPD Flaps, 32bit ASn in the wild.
Hi So either of you should contact the ukranian ISP who is at that prefix; that is the problem, right? Yes we've been in contact with said ISP. They have called out their on call engineer and their upstreams are applying pressure. This time it was unintentional. A rouge isp DoSing all OpenBGPD routers doesn't seem like an attractive idea to me. Then henning and claudio can help. Excellent. Pete
Re: OpenBGPD Flaps, 32bit ASn in the wild.
On Wed, Dec 10, 2008 at 09:19:42PM +, Peter Bristow wrote: Hi So either of you should contact the ukranian ISP who is at that prefix; that is the problem, right? Yes we've been in contact with said ISP. They have called out their on call engineer and their upstreams are applying pressure. This time it was unintentional. A rouge isp DoSing all OpenBGPD routers doesn't seem like an attractive idea to me. Then henning and claudio can help. Excellent. I looked at the porblem and I'm currently unsure what the best way is to handle such bad AS4_* attributes. The RFC in all its glory does not mention how to handle errors. So at the moment I'm in favor of just dropping/ignoring the bad optional attribute but I need to recheck with the BGP RFC to see if this is valid. Another solution is to ignore the full update but I have a bad feeling about that. All in all it should be a defined and accepted way so that it is not possible that injecting rogue BGP updates is causing session flaps around the world. This is why I think just ignoring the attribute should be save. -- :wq Claudio
Re: OpenBGPD Flaps, 32bit ASn in the wild.
So either of you should contact the ukranian ISP who is at that prefix; that is the problem, right? Yes we've been in contact with said ISP. They have called out their on call engineer and their upstreams are applying pressure. This time it was unintentional. A rouge isp DoSing all OpenBGPD routers doesn't seem like an attractive idea to me. I've already contacted both AS35320 and AS3.21 as well. No response (to me) yet. Then henning and claudio can help. Excellent. Pete
Re: OpenBGPD Flaps, 32bit ASn in the wild.
On Wed, Dec 10, 2008 at 4:38 PM, Claudio Jeker [EMAIL PROTECTED] wrote: I looked at the porblem and I'm currently unsure what the best way is to handle such bad AS4_* attributes. The RFC in all its glory does not mention how to handle errors. So at the moment I'm in favor of just dropping/ignoring the bad optional attribute but I need to recheck with the BGP RFC to see if this is valid. Another solution is to ignore the full update but I have a bad feeling about that. Can you ignore just the route with the bad attribute? We don't want to propagate it more.
Re: OpenBGPD Flaps, 32bit ASn in the wild.
On Wed, Dec 10, 2008 at 04:47:31PM -0500, Ted Unangst wrote:
On Wed, Dec 10, 2008 at 4:38 PM, Claudio Jeker [EMAIL PROTECTED] wrote:
I looked at the porblem and I'm currently unsure what the best way is to
handle such bad AS4_* attributes. The RFC in all its glory does not
mention how to handle errors. So at the moment I'm in favor of just
dropping/ignoring the bad optional attribute but I need to recheck with
the BGP RFC to see if this is valid. Another solution is to ignore the
full update but I have a bad feeling about that.
Can you ignore just the route with the bad attribute? We don't want
to propagate it more.
The best thing we can do is to mark the update as ineligible so it will
not propaget further and will not be used but this is a quite radical
measure. On the other hand this is porbably the safest way to handle this
error.
Comments?
--
:wq Claudio
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.232
diff -u -p -r1.232 rde.c
--- rde.c 15 Jun 2008 10:03:46 - 1.232
+++ rde.c 10 Dec 2008 22:30:38 -
@@ -797,8 +797,10 @@ rde_update_dispatch(struct imsg *imsg)
/*
* if either ATTR_NEW_AGGREGATOR or ATTR_NEW_ASPATH is present
* try to fixup the attributes.
+* XXX do not fixup if F_ATTR_LOOP is set.
*/
- if (asp-flags F_ATTR_AS4BYTE_NEW)
+ if (asp-flags F_ATTR_AS4BYTE_NEW
+ !(asp-flags F_ATTR_LOOP))
rde_as4byte_fixup(peer, asp);
/* enforce remote AS if requested */
@@ -1347,10 +1349,16 @@ bad_flags:
ATTR_PARTIAL))
goto bad_flags;
if (aspath_verify(p, attr_len, 1) != 0) {
- /* XXX draft does not specify how to handle errors */
- rde_update_err(peer, ERR_UPDATE, ERR_UPD_ASPATH,
- NULL, 0);
- return (-1);
+ /*
+* XXX RFC does not specify how to handle errors.
+* XXX Instead of dropping the session because of a
+* XXX bad path just mark the full update as not
+* XXX loop-free the update is no longer eligible and
+* XXX will not be considered for routing or
+* XXX redistribution. Something better is needed.
+*/
+ a-flags |= F_ATTR_LOOP;
+ goto optattr;
}
a-flags |= F_ATTR_AS4BYTE_NEW;
goto optattr;
