Re: BGP unsupported capability code
On Aug 17, 2006, at 10:57 PM, Joe Maimon wrote: If A tries to peer with B, and B sends a BGP capability 64 to A, if A does not support that capability what would proper and/or reasonable behavior for A be? Speaker A MAY send a NOTIFICATION message with Open Message Error/Error Subcode Unsupported Capability and a data field listing capability 64 as the trigger for the NOTIFICATION to speaker B (thereby terminating the session). However, RFC 3392 does NOT require that the local BGP speaker terminate the connection, which has particular utility when considering the implications such a hard requirement may otherwise impose on functions such as dynamic BGP capabilities. (a published source for it, if you could possibly do so.) a) send unsupported capability code 64 lengh 6 ## 2006-08-17 19:17:05 : [bgp/stack]: send NOTIFICATION msg code (Open-Error) subcode(Open Message Error: Unsupported Capability) to peer w9.x4.y7.z9 via socket 415 b) ignore it c) admin defined rfc3392.txt only appears to address the case where if A tries to peer with B, and B sends a BGP capability 64 to A, if A does not support that capability, B MAY terminate the connection with the above notification. (section 3 paragraph 5) If the peer doesn't support the capability and this is conveyed from A to B via a NOTIFICATION message (as illustrated in the log message above), then given the scenario you provide B SHOULD NOT include the capability (64) in any subsequent OPEN message sent to A when attempting to reestablish a BGP connection -- IF B so chooses to attempt to automatically reestablish a connection. Note that the above says SHOULD NOT, not MUST NOT. I'm not quite sure what your point above is, as I think the document sufficiently outlines the required behavior. Although BGP is perhaps (?) still of interest to the NANOG community, I suspect such protocol intricacies are not and would submit that queries of nature are best directed to [EMAIL PROTECTED] -danny
Re: GTSM - Do you use it?
On 17 Aug 2006, at 21:45, Pekka Savola wrote: [...] Enhancement Requests haven't gotten through, but maybe gripes on nanog will :-( IME, griping about something on a mailing list, while typically getting you an email from a techie at the company concerned (especially if the gripe was ferocious enough to strip paint), rarely actually gets the problem fixed. It's not unreasonable, I guess. Decision makers aren't likely to be reading operational mailing lists with a low S/N ratio.
BGP Update Report
Copies of this report are mailed to: nanog@merit.edu [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
The Cidr Report
This report has been generated at Fri Aug 18 21:44:55 2006 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
11-08-06192373 125579
12-08-06192469 125391
13-08-06192248 125495
14-08-06192399 125585
15-08-06192453 125795
16-08-06192642 125743
17-08-06192848 125900
18-08-06192996 125754
AS Summary
22814 Number of ASes in routing system
9554 Number of ASes announcing only one prefix
1464 Largest number of prefixes announced by an AS
AS7018 : ATT-INTERNET4 - ATT WorldNet Services
91538944 Largest address span announced by an AS (/32s)
AS721 : DISA-ASNBLK - DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 18Aug06 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 192964 1258566710834.8% All ASes
AS4134 1264 263 100179.2% CHINANET-BACKBONE
No.31,Jin-rong Street
AS4755 964 71 89392.6% VSNL-AS Videsh Sanchar Nigam
Ltd. Autonomous System
AS18566 955 145 81084.8% COVAD - Covad Communications
Co.
AS4323 979 282 69771.2% TWTC - Time Warner Telecom,
Inc.
AS721 1004 315 68968.6% DISA-ASNBLK - DoD Network
Information Center
AS22773 688 53 63592.3% CCINET-2 - Suddenlink
Communications
AS9498 786 179 60777.2% BBIL-AP BHARTI BT INTERNET
LTD.
AS6197 1018 486 53252.3% BATI-ATL - BellSouth Network
Solutions, Inc
AS7018 1464 951 51335.0% ATT-INTERNET4 - ATT WorldNet
Services
AS19262 684 185 49973.0% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS19916 563 65 49888.5% ASTRUM-0001 - OLM LLC
AS17488 522 47 47591.0% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS855559 88 47184.3% CANET-ASN-4 - Aliant Telecom
AS11492 725 284 44160.8% CABLEONE - CABLE ONE
AS3602 530 106 42480.0% AS3602-RTI - Rogers Telecom
Inc.
AS18101 437 27 41093.8% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS17676 492 96 39680.5% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS15270 451 57 39487.4% AS-PAETEC-NET - PaeTec.net -a
division of
PaeTecCommunications, Inc.
AS812414 46 36888.9% ROGERS-CABLE - Rogers Cable
Inc.
AS4766 670 307 36354.2% KIXS-AS-KR Korea Telecom
AS22047 456 94 36279.4% VTR BANDA ANCHA S.A.
AS6198 598 243 35559.4% BATI-MIA - BellSouth Network
Solutions, Inc
AS4812 413 59 35485.7% CHINANET-SH-AP China Telecom
(Group)
AS6467 393 47 34688.0% ESPIRECOMM - Xspedius
Communications Co.
AS16852 364 53 31185.4% FOCAL-CHICAGO - Focal Data
Communications of Illinois
AS9583 943 639 30432.2% SIFY-AS-IN Sify Limited
AS8151 768 466 30239.3% Uninet S.A. de C.V.
AS16814 329 46 28386.0% NSS S.A.
AS6517 409 128 28168.7% YIPESCOM - Yipes
Communications, Inc.
AS19115 363 92 27174.7% CHARTER-LEBANON - Charter
Communications
Total
Re: BGP unsupported capability code
Danny McPherson wrote: On Aug 17, 2006, at 10:57 PM, Joe Maimon wrote: If A tries to peer with B, and B sends a BGP capability 64 to A, if A does not support that capability what would proper and/or reasonable behavior for A be? Speaker A MAY send a NOTIFICATION message with Open Message Error/Error Subcode Unsupported Capability and a data field listing capability 64 as the trigger for the NOTIFICATION to speaker B (thereby terminating the session). However, RFC 3392 does NOT require that the local BGP speaker terminate the connection, which has particular utility when considering the implications such a hard requirement may otherwise impose on functions such as dynamic BGP capabilities. Unless there is actual utility gained by B learning the hard way that A doesnt support this capability, rather than by not receiving the same capability in A's OPEN, I would not consider this behavior reasonable. And rfc3392 specificaly says A BGP speaker determines the capabilities supported by its peer by examining the list of capabilities present in the Capabilities Optional Parameter carried by the OPEN message that the speaker receives from the peer. Not by hit or miss with NOTIFICATION messages. And as I read it, rfc3392 makes absolutely no mention of my case. (section 3 paragraph 5) If the peer doesn't support the capability and this is conveyed from A to B via a NOTIFICATION message (as illustrated in the log message above), then given the scenario you provide B SHOULD NOT include the capability (64) in any subsequent OPEN message sent to A when attempting to reestablish a BGP connection -- IF B so chooses to attempt to automatically reestablish a connection. Note that the above says SHOULD NOT, not MUST NOT. I'm not quite sure what your point above is, as I think the document sufficiently outlines the required behavior. Which document is this? Are you quoting? In any event the above is not observed behavior either, as the 500 log messages on the peer's (the one sending capability 64) support desk attest to. Does your paragraph also suggest that B SHOULD NOT send the capability when A automaticaly tries to reconnect? Should A (the peer that sent the notification upon receipt of capability 64) NOT try to automatically reconnect? Although BGP is perhaps (?) still of interest to the NANOG community, I suspect such protocol intricacies are not and would submit that queries of nature are best directed to [EMAIL PROTECTED] This isnt an intellectual excercise, its something that operationaly affects me. Perhaps it has, is, or will affect any of the operators who subscribe to this list. Since I may have to go to bat against the vendor on this one, I thought I would obtain some operator opinion beforehand. I hope that satsifies the on-topic police. -danny Thanks for your reply.
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to [EMAIL PROTECTED] For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith [EMAIL PROTECTED]. Routing Table Report 04:00 +10GMT Sat 19 Aug, 2006 Analysis Summary BGP routing table entries examined: 195444 Prefixes after maximum aggregation: 107128 Unique aggregates announced to Internet: 95305 Total ASes present in the Internet Routing Table: 22909 Origin-only ASes present in the Internet Routing Table: 19924 Origin ASes announcing only one prefix:9551 Transit ASes present in the Internet Routing Table:2985 Transit-only ASes present in the Internet Routing Table: 70 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 29 Max AS path prepend of ASN (36728) 27 Prefixes from unregistered ASNs in the Routing Table:26 Unregistered ASNs in the Routing Table: 5 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space: 9 Number of addresses announced to Internet: 1574577068 Equivalent to 93 /8s, 218 /16s and 35 /24s Percentage of available address space announced: 42.5 Percentage of allocated address space announced: 61.5 Percentage of available address space allocated: 69.1 Total number of prefixes smaller than registry allocations: 97295 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:42778 Total APNIC prefixes after maximum aggregation: 17444 Prefixes being announced from the APNIC address blocks: 40468 Unique aggregates announced from the APNIC address blocks:18700 APNIC Region origin ASes present in the Internet Routing Table:2674 APNIC Region origin ASes announcing only one prefix:757 APNIC Region transit ASes present in the Internet Routing Table:397 Average APNIC Region AS path length visible:3.5 Max APNIC Region AS path length visible: 24 Number of APNIC addresses announced to Internet: 260538976 Equivalent to 15 /8s, 135 /16s and 130 /24s Percentage of available APNIC address space announced: 81.5 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911 APNIC Address Blocks 58/7, 60/7, 121/8, 122/7, 124/7, 126/8, 202/7 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes: 98830 Total ARIN prefixes after maximum aggregation:58753 Prefixes being announced from the ARIN address blocks:72522 Unique aggregates announced from the ARIN address blocks: 27331 ARIN Region origin ASes present in the Internet Routing Table:10905 ARIN Region origin ASes announcing only one prefix:4114 ARIN Region transit ASes present in the Internet Routing Table:1017 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 29 Number of ARIN addresses announced to Internet: 295414528 Equivalent to 17 /8s, 155 /16s and 171 /24s Percentage of available ARIN address space announced: 76.6 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959 ARIN Address Blocks24/8, 63/8, 64/5, 72/6, 76/8, 199/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary Prefixes being announced by RIPE Region ASes: 39282 Total RIPE prefixes after maximum aggregation:26280 Prefixes being announced from the RIPE address blocks:36240 Unique aggregates announced from the RIPE address blocks: 24435 RIPE Region origin ASes present in the Internet Routing Table: 8387 RIPE Region origin ASes announcing only one prefix:4397 RIPE Region transit ASes present in the
Re: BGP unsupported capability code
On Aug 18, 8:31am [EMAIL PROTECTED] wrote: This isnt an intellectual excercise, its something that operationaly affects me. Perhaps it has, is, or will affect any of the operators who subscribe to this list. Since I may have to go to bat against the vendor on this one, I thought I would obtain some operator opinion beforehand. I can't see the on-topic police having any problems with this, unless network operations have degraded to a point marginally above machine-level automation. If it has, what is NANOG's purpose? As one who has both created a BGP implementation from scratch and have operated many, I think I can help you. It's easy to confuse the announcement of a particular capability with announcement of capabilities altogether. RFC3392 is clear enough, but doesn't underline the point, and also doesn't mention any administrative aspects. The idea is that if a speaker supports capabilities negotiation, it will include a BGP optional parameter in its OPEN message, listing the capabilities it supports [Sec 3 Para 1]. The receiving speaker may or may not support capability negotiation; if it doesn't it has no choice except to send an error notification with error code unsupported optional parameter, and the originator should restart but not send any capabilities parameter [Sec 3 Para 4]. (If that is actually acceptable is partly an administrative issue, but implementations vary.) Assuming both peers support capability announcements, they would each inspect the list of capabilities supported by the other [Sec 3 Para 2], and determine if this satisfies their needs [Sec 3 Para 3,5]. This is a partly administrative issue, and implementations have, well, varied. If one peer strictly requires a particular capability that the other doesn't support, it will send an error notification, terminate the session, and not restart [Sec 3 Para 5]. The idea here is that the problem is beyond protocol level negotiation (ie, it isn't eg just an optimization), and requires human intervention. Otherwise, assuming no strictly required capabilities are missing on either side, the session goes ahead on each side, with each peer respecting the capabilities it understands the other peer supports. The whole capability thing is very much an afterthought to BGP; proper negotiation could well require several transactions, but that would require obvious changes to the BGP protocol itself. Consequently, actual support and behaviour for capabilities has seen some variation between implementations and also between different versions and releases. Things should have been reasonably settled by now, though, so I suspect one of your peers is running old software. As for the capability you mention (code 64), this is Graceful Restart, see http://www.iana.org/assignments/capability-codes Graceful Restart is an optimization, and nothing prevents peering without it. Hence, you should not see repeated terminations and restarts, the session should simply go ahead without using Graceful Restart. Best, -- Per
Wikipedia/Cogent
So, lets kick this Friday off right... I don't suppose anybody has noticed that Wikipedia is being blackholed by Cogent, and that it seems to be intentional? :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Wikipedia/Cogent
On Fri, Aug 18, 2006 at 03:02:45PM -0400, Richard A Steenbergen wrote: So, lets kick this Friday off right... I don't suppose anybody has noticed that Wikipedia is being blackholed by Cogent, and that it seems to be intentional? :) I'm not able to reach 207.142.136.174 (also via Cogent) either, which is forums.miranda-im.org. 207.142.136.0/24 *[BGP/170] 01:57:05, localpref 100 AS path: 701 174 ? For Wikipedia: 207.142.131.0/24 *[BGP/170] 01:58:02, localpref 100 AS path: 701 174 ? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Re: Wikipedia/Cogent
Supposedly Cogent is working on this - I have space on this block 207.142.131.0/21 ( I believe is the allocation) which includes wiki, miranda Can someone on Cogent please comment on this . Thank you. Geoffrey Pan RHCE, CISSP, CISM gpanatcheetaweb.com Richard A Steenbergen wrote: So, lets kick this Friday off right... I don't suppose anybody has noticed that Wikipedia is being blackholed by Cogent, and that it seems to be intentional? :)
Re: Wikipedia/Cogent
Looks like some others may have noticed... 207.142.131.0/24 *[BGP/170] 00:26:46, localpref 100 AS path: 701 3356 30217 I -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Re: Wikipedia/Cogent
On Fri, 18 Aug 2006, Jeremy Chadwick wrote: Looks like some others may have noticed... 207.142.131.0/24 *[BGP/170] 00:26:46, localpref 100 AS path: 701 3356 30217 I so.. is the problem that wikipedia's ip address is in a block of PA space of Cogent's and they feel it's walked away without their consent?
Re: Wikipedia/Cogent
This space has been assigned to the same location, facility for years. The blocks affected that I know of are.. 207.142.131.0/24 - 207.142.136.0/24 Are all of them being reported as that now? so.. is the problem that wikipedia's ip address is in a block of PA space of Cogent's and they feel it's walked away without their consent?
Re: Wikipedia/Cogent
On Fri, 18 Aug 2006, Geoffrey Pan wrote: This space has been assigned to the same location, facility for years. same location/facility doesn't mean that that place/people/thing still has authority to route the PA block... Like say the decided to stop having Cogent as a provider? or stopped payments to Cogent? or some other sort of snafu... The blocks affected that I know of are.. 207.142.131.0/24 - 207.142.136.0/24 Are all of them being reported as that now? so.. is the problem that wikipedia's ip address is in a block of PA space of Cogent's and they feel it's walked away without their consent?
Re: Wikipedia/Cogent
Christopher L. Morrow wrote: same location/facility doesn't mean that that place/people/thing still has authority to route the PA block... Like say the decided to stop having Cogent as a provider? or stopped payments to Cogent? or some other sort of snafu... According to the lead developer, brion vibber: PowerMedium has assigned us a new IP space which is under their control (unlike the old IPs which were leased from Cogent under an older contract), and we will be transitioning to them over the weekend.
Re: Wikipedia/Cogent
Can someone from Cogent please contact me off list regarding to this issue. Thank you. Geoffrey Pan RHCE, CISSP, CISM gpanatcheetaweb.com
Re: Wikipedia/Cogent
On Fri, Aug 18, 2006 at 09:09:59PM +, Christopher L. Morrow wrote: On Fri, 18 Aug 2006, Geoffrey Pan wrote: This space has been assigned to the same location, facility for years. same location/facility doesn't mean that that place/people/thing still has authority to route the PA block... Like say the decided to stop having Cogent as a provider? or stopped payments to Cogent? or some other sort of snafu... Cogent seems to think that they terminated a relationship with said company (one of what looks like many different hostway names at any rate), and gave them several months to renumber out of the IP allocation. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Cox leaking 128.0.0.0/1
Seeing as this has been going on for over 2h30m, no one can seem to get ahold of any live bodies who can fix it, and the emails about it to the noc contacts have gone unanswered, I'm reduced to trying the old public embarassment approach... Would Cox please stop announcing 128.0.0.0/1. Thanks. route-views.oregon-ix.netsh ip bgp 128.0.0.1 BGP routing table entry for 128.0.0.0/1, version 471808 Paths: (14 available, best #14, table Default-IP-Routing-Table) Not advertised to any peer 852 22773 154.11.11.113 from 154.11.11.113 (154.11.11.113) Origin IGP, metric 0, localpref 100, valid, external Community: 852:180 852 22773 154.11.98.225 from 154.11.98.225 (154.11.98.225) Origin IGP, metric 0, localpref 100, valid, external Community: 852:180 3277 6820 3267 3343 174 174 174 22773 194.85.4.55 from 194.85.4.55 (194.85.4.55) Origin IGP, localpref 100, valid, external Community: 3277:6820 3277:65361 3277:65364 2493 3602 812 22773 206.186.255.223 from 206.186.255.223 (206.186.255.223) Origin IGP, localpref 100, valid, external Community: 812:2 3602:65011 3602:65535 7500 2516 22773 202.249.2.86 from 202.249.2.86 (203.178.133.115) Origin IGP, localpref 100, valid, external 6539 22773 216.18.63.137 from 216.18.63.137 (216.18.63.137) Origin IGP, localpref 100, valid, external 11608 3491 22773 207.246.129.13 from 207.246.129.13 (207.246.129.15) Origin IGP, localpref 100, valid, external Community: 3491:2000 3491:2007 3491:22773 11608:1004 11608:5504 22773:130 22773:60101 22773:64002 22773:64100 22773:64101 7660 2516 22773 203.181.248.233 from 203.181.248.233 (203.181.248.13) Origin IGP, localpref 100, valid, external 1221 4637 22773 203.62.252.26 from 203.62.252.26 (203.62.252.26) Origin IGP, localpref 100, valid, external 1103 1273 22773 193.0.0.56 from 193.0.0.56 (193.0.0.56) Origin IGP, localpref 100, valid, external 8001 22773 209.123.12.51 from 209.123.12.51 (209.123.12.51) Origin IGP, localpref 100, valid, external Community: 8001:3000 8001:3023 8001:6008 22773:130 22773:60101 22773:64002 22773:64100 22773:64101 12956 22773 213.140.32.146 from 213.140.32.146 (213.140.32.146) Origin IGP, localpref 100, valid, external Community: 12956:18500 12956:28200 12956:28201 22773:130 22773:60101 22773:64002 22773:64100 22773:64101 5650 22773 74.40.7.35 from 74.40.7.35 (207.173.112.63) Origin IGP, metric 0, localpref 100, valid, external 5650 22773 74.40.7.36 from 74.40.7.36 (74.40.0.11) Origin IGP, metric 0, localpref 100, valid, external, best Oh and if you are on this list (and therefore accepting that prefix), you may need better filters. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Wikipedia/Cogent
In a message written on Fri, Aug 18, 2006 at 03:02:45PM -0400, Richard A Steenbergen wrote: So, lets kick this Friday off right... I don't suppose anybody has noticed that Wikipedia is being blackholed by Cogent, and that it seems to be intentional? :) Maybe they don't like: http://en.wikipedia.org/wiki/Cogent_Communications -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp4h9GI95riM.pgp Description: PGP signature
