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 bgp-st...@lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 22 Aug, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 293735 Prefixes after maximum aggregation: 139010 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 146284 Total ASes present in the Internet Routing Table: 31976 Prefixes per ASN: 9.19 Origin-only ASes present in the Internet Routing Table: 27800 Origin ASes announcing only one prefix: 13547 Transit ASes present in the Internet Routing Table:4176 Transit-only ASes present in the Internet Routing Table:100 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 629 Unregistered ASNs in the Routing Table: 167 Number of 32-bit ASNs allocated by the RIRs:241 Prefixes from 32-bit ASNs in the Routing Table: 92 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:328 Number of addresses announced to Internet: 2089063616 Equivalent to 124 /8s, 132 /16s and 148 /24s Percentage of available address space announced: 56.4 Percentage of allocated address space announced: 64.5 Percentage of available address space allocated: 87.3 Percentage of address space in use by end-sites: 78.7 Total number of prefixes smaller than registry allocations: 140471 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:70153 Total APNIC prefixes after maximum aggregation: 24877 APNIC Deaggregation factor:2.82 Prefixes being announced from the APNIC address blocks: 69601 Unique aggregates announced from the APNIC address blocks:31611 APNIC Region origin ASes present in the Internet Routing Table:3747 APNIC Prefixes per ASN: 18.58 APNIC Region origin ASes announcing only one prefix: 1023 APNIC Region transit ASes present in the Internet Routing Table:579 Average APNIC Region AS path length visible:3.6 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 481521344 Equivalent to 28 /8s, 179 /16s and 110 /24s Percentage of available APNIC address space announced: 82.0 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:124497 Total ARIN prefixes after maximum aggregation:66423 ARIN Deaggregation factor: 1.87 Prefixes being announced from the ARIN address blocks: 125109 Unique aggregates announced from the ARIN address blocks: 52466 ARIN Region origin ASes present in the Internet Routing Table:13183 ARIN Prefixes per ASN: 9.49 ARIN Region origin ASes announcing only one prefix:5077 ARIN Region transit ASes present in the Internet Routing Table:1290 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 1012944512 Equivalent to 60 /8s, 96 /16s and 78 /24s Percentage of available ARIN address space announced: 88.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ER
Re: Alternatives to storm-control on Cat 6509.
On 22/08/2009 06:26, Andrew Parnell wrote: The 67xx series cards aren't supported by the sup32, though. Would 65xx line cards do the trick? unfortunately not: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/storm.html • The following LAN switching modules do not support traffic storm control: – WS-X6148A-GE-45AF – WS-X6148A-GE-TX – WS-X6148-GE-45AF – WS-X6148-GE-TX – WS-X6148V-GE-TX – WS-X6548-GE-45AF – WS-X6548-GE-TX – WS-X6548V-GE-TX Hmmm, expensive proposition to upgrade then - even though sup720 + ws-x67xx cards make a nice l2 platform for gig ethernet. Nick
Re: Redundancy & Summarization
Another option could be to announce one /17 to each upstream provider and use conditional BGP to announce the other /17 to the provider that's still active in the event that one provider goes down. On 8/21/2009 4:08 PM, Patrick W. Gilmore wrote: On Aug 21, 2009, at 3:47 PM, Brian Dickson wrote: My institution has a single /16 spread across 2 sites: the lower /17 is used at site A, the upper /17 at site B. Sites A & B are connected internally. Currently both sites have their own ISPs and only advertise their own /17's. For redundancy we proposed that each site advertise both their own /17 and the whole /16, so that an ISP failure at either site would trigger traffic from both /17s to reconverge towards the unaffected location. There are two different ways to achieve almost-identical results. As much as I like Brian, I am going to have to respectfully disagree. However, one is a 50% more "green" than the other, i.e. friendly to other network operators. These two choices are functionally equivalent, and possible, only because things currently work for both your /17's. Here are the two ways to do this: One is: - announce /17 "A" and /16 from uplink ISP-A - announce /17 "B" and /16 from uplink ISP-B - This results in 3 prefixes globally: A, B, and /16. The other is: - announce /17 "A" and /17 "B", with different policies (i.e. prepend your AS once or twice), at *both* ISPs. - This results in 2 prefixes globally: A and B. In all cases, as long as one ISP link is up, there is a path to both A and B. In most cases, the best path to A or B, is *mostly*, but not completely, under your influence. This is highly dependent on variables not in evidence. If your upstreams are, for instance, Sprint & Level 3, then a large percentage of the Internet will be traveling through one or the other. And once it hits your upstream, prepends are irrelevant. Every upstream (for values of "every" == "100%" to at least one decimal place) localprefs their downstreams' prefixes. In this case, anyone downstream of either L3 or Sprint will send _all_ traffic through that upstream's link. While not the whole Internet, it's still quite a bit. Moreover, many people do things like localpref Sprint _down_ because they are more expensive. So even someone multi-homed to both may send all traffic through L3. Etc., etc. A slight twist on Brian's idea would be to use communities and tell Upstream A to localpref Prefix B below that of peer routes. Then you only need two prefixes, and each site only receives its own traffic except when the other site fails. If Upstream B goes down, Upstream A will accept Prefix B and propagate it. Again, dependent upon your upstreams having communities able to do this. Or if they are "nimble", maybe a call to their operations department?
Re: Redundancy & Summarization
Sent from my iPhone, please excuse any errors. On Aug 22, 2009, at 9:52, Adam Greene wrote: Another option could be to announce one /17 to each upstream provider and use conditional BGP to announce the other /17 to the provider that's still active in the event that one provider goes down. Good idea. Still uses just two prefixes and allows for backup connectivity. Just be careful that the internal routing table does not stop the conditional announcement. -- TTFN, patrick On 8/21/2009 4:08 PM, Patrick W. Gilmore wrote: On Aug 21, 2009, at 3:47 PM, Brian Dickson wrote: My institution has a single /16 spread across 2 sites: the lower / 17 is used at site A, the upper /17 at site B. Sites A & B are connected internally. Currently both sites have their own ISPs and only advertise their own /17's. For redundancy we proposed that each site advertise both their own /17 and the whole /16, so that an ISP failure at either site would trigger traffic from both /17s to reconverge towards the unaffected location. There are two different ways to achieve almost-identical results. As much as I like Brian, I am going to have to respectfully disagree. However, one is a 50% more "green" than the other, i.e. friendly to other network operators. These two choices are functionally equivalent, and possible, only because things currently work for both your /17's. Here are the two ways to do this: One is: - announce /17 "A" and /16 from uplink ISP-A - announce /17 "B" and /16 from uplink ISP-B - This results in 3 prefixes globally: A, B, and /16. The other is: - announce /17 "A" and /17 "B", with different policies (i.e. prepend your AS once or twice), at *both* ISPs. - This results in 2 prefixes globally: A and B. In all cases, as long as one ISP link is up, there is a path to both A and B. In most cases, the best path to A or B, is *mostly*, but not completely, under your influence. This is highly dependent on variables not in evidence. If your upstreams are, for instance, Sprint & Level 3, then a large percentage of the Internet will be traveling through one or the other. And once it hits your upstream, prepends are irrelevant. Every upstream (for values of "every" == "100%" to at least one decimal place) localprefs their downstreams' prefixes. In this case, anyone downstream of either L3 or Sprint will send _all_ traffic through that upstream's link. While not the whole Internet, it's still quite a bit. Moreover, many people do things like localpref Sprint _down_ because they are more expensive. So even someone multi-homed to both may send all traffic through L3. Etc., etc. A slight twist on Brian's idea would be to use communities and tell Upstream A to localpref Prefix B below that of peer routes. Then you only need two prefixes, and each site only receives its own traffic except when the other site fails. If Upstream B goes down, Upstream A will accept Prefix B and propagate it. Again, dependent upon your upstreams having communities able to do this. Or if they are "nimble", maybe a call to their operations department?
Re: Redundancy & Summarization
On Sat, Aug 22, 2009 at 6:52 AM, Adam Greene wrote: > Another option could be to announce one /17 to each upstream provider and > use conditional BGP to announce the other /17 to the provider that's still > active in the event that one provider goes down. > Maybe I'm wrong, but I think this method will only work when handling local failures. If there is a failure in a remote network which causes ISP A to be unreachable from a third party, your routers will not adjust the announcements since ISP A and B are still reachable to you, but the third party will not be able to reach the network nearer to ISP A through the ISP B connection because ISP B doesn't have an announcement to that network. (This is assuming that ISP A and ISP B are not peers). Hector
Re: Alternatives to storm-control on Cat 6509.
On Fri, 21 Aug 2009, Roland Dobbins wrote: there are two things you care about: storm control and port security (mac address counting). Chopping up the layer-2 broadcast domain for a given VLAN into smaller pieces via pVLANs can't hurt, either, as long as the hosts have no need to talk to one another - and it has other benefits, as well. I understand why hosts need to send broadcasts. In a close/single customer environment, broadcasts could be useful. I hope most future protocol designers now think of using multicast or other discovery mechanisms besides broadcast. But in a service provider network (or any managed network), is there any reason why a customer needs to hear other customer's broadcasts? In practice, are there any useful broadcast messages in a multi-customer environment that can't/shouldn't be proxied by the network operator or handled other ways.
Re: Alternatives to storm-control on Cat 6509.
On Sat, 22 Aug 2009, Sean Donelan wrote: But in a service provider network (or any managed network), is there any reason why a customer needs to hear other customer's broadcasts? In practice, are there any useful broadcast messages in a multi-customer environment that can't/shouldn't be proxied by the network operator or handled other ways. Not that I know of, ISPs have successfully done L2 isolation of customers for 10 years and I haven't heard of any problems with it. Only bad part really is that if the customer is allowed several IPs and you use local-proxy-arp then traffic between customer computers will go via the ISP, which is one of the reasons I advocate the use of a home CPE router for IPv6, it's just a cleaner handoff. -- Mikael Abrahamssonemail: swm...@swm.pp.se
