- Test - lists.nanog.org

Any contact at VERIZON who manages @VTEXT.COM?
by Curtis Generous 04 Jul '19

04 Jul '19

We started seeing emails to @VTEXT.COM being periodically rejected earlier in the week, and now most/all our getting soft-bounced. Anyone here on the list have contact info at VERIZON who can assist in troubleshooting this? All normal channels to get hold of their support have failed Thanks --curtis

1 0

Microsoft SNDS contact
by Brian Rak 03 Jul '19

03 Jul '19

We've been trying to get SNDS access for our IP space, and we keep running into issues where the SNDS site is unable to determine what emails it should use to authorize access. SNDS support has so far been very unhelpful, they keep trying to tell us to submit the space as individual /24's, which is less then helpful when we have multiple /18s we're trying to set up. Does anyone have a contact at Microsoft that can help?

3 7

Re: few big monolithic PEs vs many small PEs
by James Bensley 03 Jul '19

03 Jul '19

On Wed, 19 Jun 2019 at 21:23, <adamv0025(a)netconsultings.com> wrote: > > Hi folks, > > Recently I ran into a peculiar situation where we had to cap couple of PE > even though merely a half of the rather big chassis was populated with > cards, reason being that the central RE/RP was not able to cope with the > combined number of routes/vrfs/bgp sessions/etc.. > > So this made me think about the best strategy in building out SP-Edge > nowadays (yes I'm aware of the centralize/decentralize pendulum swinging > every couple of years). > The conclusion I came to was that *currently the best approach would be to > use several medium to small(fixed) PEs to replace a big monolithic chasses > based system. > So what I was thinking is, > Yes it will cost a bit more (router is more expensive than a LC) > Will end up with more prefixes in IGP, more BGP sessions etc.. -don't care. > But the benefits are less eggs in one basket, simplified and hence faster > testing in case of specialized PEs and obviously better RP CPU/MEM to port > ratio. > Am I missing anything please? > > *currently, > Yes some old chassis systems or even multi-chassis systems used to support > additional RPs and offloading some of the processes (e.g. BGP onto those) > -problem is these are custom hacks and still a single OS which needs > rebooting LC/ASICs when being upgraded -so the problem of too many eggs in > one basket still exists (yes cisco NCS6k and recent ASR9k lightspeed LCs are > an exception) > And yes there is the "node-slicing" approach from Juniper where one can > offload CP onto multiple x86 servers and assign LCs to each server (virtual > node) - which would solve my chassis full problem -but honestly how many of > you are running such setup? Exactly. And that's why I'd be hesitant to > deploy this solution in production just yet. I don't know of any other > vendor solution like this one, but who knows maybe in 5 years this is going > to be the new standard. Anyways I need a solution/strategy for the next 3-5 > years. > > > Would like to hear what are your thoughts on this conundrum. > > adam > > netconsultings.com > ::carrier-class solutions for the telecommunications industry:: Hi Adam, Over the years I have been bitten multiple times by having fewer big routers with either far too many services/customers connected to them or too much traffic going through them. These days I always go for more smaller/more routers than fewer/larger routers. One experience I have made is that when there is an outage on a large PE, even when it still has spare capacity, is that the business impact can be too much to handle (the support desk is overwhelmed, customers become irate if you can't quickly tell them what all the impacted services are, when service will be restored, the NMS has so many alarms it’s not clear what the problem is or where it's coming from etc.). I’ve seen networks place change freeze on devices, with the exception of changes that migrate customers or services off of the PE, because any outage would create too great an impact to the business, or risk the customers terminating their contract. I’ve also seen changes freeze be placed upon large PEs because the complexity was too great, trying to work out the impact of a change on one of the original PEs from when the network was first built, which is somehow linked to virtually every service on the network in some obscure and unforeseeable way. This doesn’t mean there isn’t a place for large routers. For example, in a typical network, by the time we get to the P nodes layer in the core we tend to have high levels of redundancy, i.e. any PE is dual-homed to two or more P nodes and will have 100% redundant capacity. Down at the access layer customers may be connected to a single access layer device or the access layer device might have a single backhaul link. So technically we have lots of customers, services and traffic passing through larger P node devices, but these devices have a low rate of changes / low touch, perform a low number of functions, they are operationally simple, and are highly redundant. Adversely at the service edge, which I guess is your main concern here, I’m all about more smaller devices with single service dedicated devices. I’ve tried to write some of my experiences here (https://null.53bits.co.uk/index.php?page=few-larger-routers-vs.-many-smalle…) The tl;dr version though is that there’s rarely a technical restriction to having fewer large routers and it’s an operational/business impact problem. I'd like to hear from anyone who has had great success with fewer larger PEs. Cheers, James.

2 3

Intermittent "bad gateway"
by Stephen Satchell 02 Jul '19

02 Jul '19

Are we having another BGP problem this morning?

13 12

Re: Ideas to products (Shark Tank(-ish) @ Austin)
by Mehmet Akcin 01 Jul '19

01 Jul '19

Great point ;-) thanks Tom On Sat, Jun 29, 2019 at 09:29 Tom Daly <tjd(a)fastly.com> wrote: > Mehmet, > > Good idea, the opportunity for innovation and supporting ideas of others > in our operator groups is important, but NANOG is probably the wrong venue. > > Have you considered NANOG's 501c3 not-for-profit status in your analysis > of bringing this idea to the community? As a presenter, how would one > protect his/her intellectual property being shown to the proposed "sharks" > and/or the audience? (would an audience be permitted in the room?) > > I can't speak for the NANOG Board nor the Program Committee, but as an > interested party in NANOG's 501(c)3 not-for-profit status, I am pretty > certain this activity would jeopardize our recognized exemption with the > IRS. I think this is an important detail you explore before proceeding. > > HTH, > Tom > > On Sat, Jun 29, 2019 at 11:11 AM Mehmet Akcin <mehmet(a)akcin.net> wrote: > >> Hey there, >> >> I am trying to put together an event at NANOG Austin (will submit pc when >> CFP is open). So many of us had very interesting ideas over the years. Some >> of these ideas became products or companies making life easy for engineers >> and operators. Could there be other ideas waiting to be supported? Perhaps. >> I am sure you all watched shark tank! In simplest words i am trying to >> organize an event very similar to Shark Tank!( we will call it some other >> name tho) >> >> There will be some known investors on the stage and you will 5 mins for >> your pitch and 10 mins to answer questions, and hopefully make a deal. >> >> I will help those who want to pitch their idea with their p&l , >> presentation and other things as they needed. >> >> Please contact me if you have any questions offlist and want to pitch >> your idea. We need a single paragraph to get you started. >> >> Mehmet >> -- >> Mehmet >> +1-424-298-1903 >> > > > -- > Tom Daly - SVP, Infrastructure > tjd(a)fastly.com > -- Mehmet +1-424-298-1903

3 2

Ideas to products (Shark Tank(-ish) @ Austin)
by Mehmet Akcin 01 Jul '19

01 Jul '19

Hey there, I am trying to put together an event at NANOG Austin (will submit pc when CFP is open). So many of us had very interesting ideas over the years. Some of these ideas became products or companies making life easy for engineers and operators. Could there be other ideas waiting to be supported? Perhaps. I am sure you all watched shark tank! In simplest words i am trying to organize an event very similar to Shark Tank!( we will call it some other name tho) There will be some known investors on the stage and you will 5 mins for your pitch and 10 mins to answer questions, and hopefully make a deal. I will help those who want to pitch their idea with their p&l , presentation and other things as they needed. Please contact me if you have any questions offlist and want to pitch your idea. We need a single paragraph to get you started. Mehmet -- Mehmet +1-424-298-1903

2 1

RE: few big monolithic PEs vs many small PEs
by adamv0025＠netconsultings.com 29 Jun '19

29 Jun '19

> From: James Bensley <jwbensley(a)gmail.com> > Sent: Thursday, June 27, 2019 9:56 AM > > One experience I have made is that when there is an outage on a large PE, > even when it still has spare capacity, is that the business impact can be too > much to handle (the support desk is overwhelmed, customers become irate > if you can't quickly tell them what all the impacted services are, when service > will be restored, the NMS has so many alarms it’s not clear what the problem > is or where it's coming from etc.). > I see what you mean, my hope is to address these challenges by having a "single source of truth" provisioning system that will have, among other things, also HW-customer/service mapping -so Ops team will be able to say that if particular LC X fails then customers/services X,Y,Z will be affected. But yes I agree with smaller PEs any failure fallout is minimized proportionally. > > This doesn’t mean there isn’t a place for large routers. For example, in a > typical network, by the time we get to the P nodes layer in the core we tend > to have high levels of redundancy, i.e. any PE is dual-homed to two or more P > nodes and will have 100% redundant capacity. Exactly, while the service edge topology might be dynamic as a result of horizontal scaling the core on the other hand I'd say should be fairly static and scaled vertically, that is I wouldn't want to scale core routers horizontally and as a result have core topology changing with every P scale out iteration at any POP, that would be bad news for capacity planning and traffic engineering... > > I’ve tried to write some of my experiences here > (https://null.53bits.co.uk/index.php?page=few-larger-routers-vs.-many- > smaller-routers). > The tl;dr version though is that there’s rarely a technical restriction to having > fewer large routers and it’s an operational/business impact problem. > I'll give it a read, cheers. adam

3 6

AS16509 (Amazon) peering contact
by Francois Lecavalier 28 Jun '19

28 Jun '19

Hi nanog, We just joined a IXP (QiX - Montreal) in the hope to offload >4Gbps of traffic to AWS, however it's been 2 weeks we sent a request to peering(a)amazon.com<mailto:peering@amazon.com> without any reply. Are they usually taking long to reply? Anyone have a direct contact? Thanks, -Frank This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier ?lectronique est confidentiel et prot?g?. L'exp?diteur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) d?sign?(s) est interdite. Si vous recevez ce courrier ?lectronique par erreur, veuillez m'en aviser imm?diatement, par retour de courrier ?lectronique ou par un autre moyen.

9 9

Weekly Routing Table Report
by cscora＠apnic.net 28 Jun '19

28 Jun '19

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats(a)lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith <pfsinoz(a)gmail.com>. Routing Table Report 04:00 +10GMT Sat 29 Jun, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 759623 Prefixes after maximum aggregation (per Origin AS): 292603 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 365009 Total ASes present in the Internet Routing Table: 64662 Prefixes per ASN: 11.75 Origin-only ASes present in the Internet Routing Table: 55628 Origin ASes announcing only one prefix: 23941 Transit ASes present in the Internet Routing Table: 9034 Transit-only ASes present in the Internet Routing Table: 275 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 42 Max AS path prepend of ASN ( 27978) 31 Prefixes from unregistered ASNs in the Routing Table: 24 Number of instances of unregistered ASNs: 27 Number of 32-bit ASNs allocated by the RIRs: 27602 Number of 32-bit ASNs visible in the Routing Table: 22515 Prefixes from 32-bit ASNs in the Routing Table: 101561 Number of bogon 32-bit ASNs visible in the Routing Table: 18 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 232 Number of addresses announced to Internet: 2839143808 Equivalent to 169 /8s, 57 /16s and 229 /24s Percentage of available address space announced: 76.7 Percentage of allocated address space announced: 76.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.3 Total number of prefixes smaller than registry allocations: 252664 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 205685 Total APNIC prefixes after maximum aggregation: 61187 APNIC Deaggregation factor: 3.36 Prefixes being announced from the APNIC address blocks: 201355 Unique aggregates announced from the APNIC address blocks: 83667 APNIC Region origin ASes present in the Internet Routing Table: 9846 APNIC Prefixes per ASN: 20.45 APNIC Region origin ASes announcing only one prefix: 2749 APNIC Region transit ASes present in the Internet Routing Table: 1465 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4851 Number of APNIC addresses announced to Internet: 770960512 Equivalent to 45 /8s, 243 /16s and 236 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-141625 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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, 133/8, 150/8, 153/8, 163/8, 171/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 225579 Total ARIN prefixes after maximum aggregation: 105582 ARIN Deaggregation factor: 2.14 Prefixes being announced from the ARIN address blocks: 224872 Unique aggregates announced from the ARIN address blocks: 106713 ARIN Region origin ASes present in the Internet Routing Table: 18512 ARIN Prefixes per ASN: 12.15 ARIN Region origin ASes announcing only one prefix: 6868 ARIN Region transit ASes present in the Internet Routing Table: 1905 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 42 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2778 Number of ARIN addresses announced to Internet: 1067893632 Equivalent to 63 /8s, 166 /16s and 195 /24s 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, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 209585 Total RIPE prefixes after maximum aggregation: 99235 RIPE Deaggregation factor: 2.11 Prefixes being announced from the RIPE address blocks: 205557 Unique aggregates announced from the RIPE address blocks: 122324 RIPE Region origin ASes present in the Internet Routing Table: 26163 RIPE Prefixes per ASN: 7.86 RIPE Region origin ASes announcing only one prefix: 11570 RIPE Region transit ASes present in the Internet Routing Table: 3717 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 8208 Number of RIPE addresses announced to Internet: 720094848 Equivalent to 42 /8s, 235 /16s and 198 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-210331 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 97355 Total LACNIC prefixes after maximum aggregation: 22240 LACNIC Deaggregation factor: 4.38 Prefixes being announced from the LACNIC address blocks: 98700 Unique aggregates announced from the LACNIC address blocks: 42870 LACNIC Region origin ASes present in the Internet Routing Table: 8557 LACNIC Prefixes per ASN: 11.53 LACNIC Region origin ASes announcing only one prefix: 2300 LACNIC Region transit ASes present in the Internet Routing Table: 1565 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 39 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 6106 Number of LACNIC addresses announced to Internet: 174090752 Equivalent to 10 /8s, 96 /16s and 106 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 21394 Total AfriNIC prefixes after maximum aggregation: 4339 AfriNIC Deaggregation factor: 4.93 Prefixes being announced from the AfriNIC address blocks: 28907 Unique aggregates announced from the AfriNIC address blocks: 9232 AfriNIC Region origin ASes present in the Internet Routing Table: 1292 AfriNIC Prefixes per ASN: 22.37 AfriNIC Region origin ASes announcing only one prefix: 454 AfriNIC Region transit ASes present in the Internet Routing Table: 255 Average AfriNIC Region AS path length visible: 4.9 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 572 Number of AfriNIC addresses announced to Internet: 105860096 Equivalent to 6 /8s, 79 /16s and 76 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 45/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7545 4789 559 544 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 3216 1467 29 VIETEL-AS-AP Viettel Group, VN 45899 3044 1761 112 VNPT-AS-VN VNPT Corp, VN 9808 2800 9043 62 CMNET-GD Guangdong Mobile Communication 9829 2693 1489 562 BSNL-NIB National Internet Backbone, IN 4766 2527 11119 760 KIXS-AS-KR Korea Telecom, KR 4755 2142 428 183 TATACOMM-AS TATA Communications formerl 9394 2095 4882 26 CTTNET China TieTong Telecommunications 9498 2078 427 171 BBIL-AP BHARTI Airtel Ltd., IN 7713 2056 608 611 TELKOMNET-AS-AP PT Telekomunikasi Indon Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7155 4064 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 11492 3678 240 618 CABLEONE - CABLE ONE, INC., US 6327 3567 1324 89 SHAW - Shaw Communications Inc., CA 22773 3425 2974 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2964 6374 1344 AMAZON-02 - Amazon.com, Inc., US 16625 2605 1370 1880 AKAMAI-AS - Akamai Technologies, Inc., 30036 2153 346 257 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 20115 2150 2760 525 CHARTER-20115 - Charter Communications, 18566 2098 405 107 MEGAPATH5-US - MegaPath Corporation, US 5650 2082 3074 1459 FRONTIER-FRTR - Frontier Communications Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 5431 1629 141 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3173 379 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2701 514 1933 AKAMAI-ASN1, US 12389 2253 2226 637 ROSTELECOM-AS, RU 34984 2095 344 546 TELLCOM-AS, TR 9121 1646 1692 18 TTNET, TR 13188 1604 100 47 TRIOLAN, UA 9009 1573 170 859 M247, GB 61317 1566 152 468 ASDETUK http://www.heficed.com, GB Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 6177 3369 572 Uninet S.A. de C.V., MX 10620 3410 534 435 Telmex Colombia S.A., CO 11830 2697 370 54 Instituto Costarricense de Electricidad 7303 1475 1022 275 Telecom Argentina S.A., AR 6503 1223 441 54 Axtel, S.A.B. de C.V., MX 28573 1154 2243 205 CLARO S.A., BR 6147 1095 377 31 Telefonica del Peru S.A.A., PE 3816 1039 524 114 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 13999 977 516 242 Mega Cable, S.A. de C.V., MX 11172 937 112 61 Alestra, S. de R.L. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1169 393 22 LINKdotNET-AS, EG 37611 969 107 9 Afrihost, ZA 24835 881 628 22 RAYA-AS, EG 36992 862 1535 71 ETISALAT-MISR, EG 36903 831 418 129 MT-MPLS, MA 8452 676 1859 20 TE-AS TE-AS, EG 29571 517 68 11 ORANGE-COTE-IVOIRE, CI 37492 489 470 57 ORANGE-, TN 15399 434 45 11 WANANCHI-, KE 37342 414 32 1 MOVITEL, MZ Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 6177 3369 572 Uninet S.A. de C.V., MX 12479 5431 1629 141 UNI2-AS, ES 7545 4789 559 544 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4064 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3778 203 20 ALJAWWALSTC-AS, SA 11492 3678 240 618 CABLEONE - CABLE ONE, INC., US 6327 3567 1324 89 SHAW - Shaw Communications Inc., CA 22773 3425 2974 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3410 534 435 Telmex Colombia S.A., CO 7552 3216 1467 29 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5431 5290 UNI2-AS, ES 7545 4789 4245 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4064 4039 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3567 3478 SHAW - Shaw Communications Inc., CA 22773 3425 3269 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 3216 3187 VIETEL-AS-AP Viettel Group, VN 8551 3173 3127 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 3678 3060 CABLEONE - CABLE ONE, INC., US 10620 3410 2975 Telmex Colombia S.A., CO Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 64500 DOCUMENT 45.43.56.0/24 45474 NEXUSGUARD-AS-AP Suite 2101~02 267804 UNALLOCATED 45.172.108.0/22 52361 ARSAT - Empresa Argentina de S 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 64011 UNALLOCATED 166.133.128.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.92.0/22 14988 BTC-GATE1, BW 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.220.48.0/20 36900 -Reserved AS-, ZZ 41.242.92.0/24 37643 -Reserved AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:10 /9:11 /10:37 /11:100 /12:294 /13:569 /14:1131 /15:1910 /16:13267 /17:7992 /18:13952 /19:25820 /20:40299 /21:47489 /22:94935 /23:76862 /24:434065 /25:880 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4384 5431 UNI2-AS, ES 6327 3357 3567 SHAW - Shaw Communications Inc., CA 7155 3156 4064 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2882 3678 CABLEONE - CABLE ONE, INC., US 22773 2659 3425 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 2626 3173 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11830 2045 2697 Instituto Costarricense de Electricidad y Telec 18566 1993 2098 MEGAPATH5-US - MegaPath Corporation, US 30036 1904 2153 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1692 2:1073 3:6 4:21 5:3179 6:45 7:1 8:1342 9:1 11:1 12:1805 13:361 14:2045 15:38 16:6 17:257 18:77 20:55 23:2796 24:2562 25:4 27:2456 31:2017 32:100 35:37 36:879 37:3060 38:1765 39:287 40:121 41:3220 42:823 43:2068 44:152 45:8492 46:3328 47:260 49:1354 50:1114 51:330 52:1009 54:279 55:632 56:6 57:47 58:1765 59:1070 60:529 61:2196 62:1956 63:1857 64:4997 65:2209 66:4847 67:2772 68:1172 69:3547 70:1377 71:654 72:2624 74:2726 75:1294 76:560 77:1799 78:1845 79:2292 80:1816 81:1492 82:1136 83:935 84:1131 85:2295 86:558 87:1543 88:1049 89:2553 90:214 91:6586 92:1434 93:2484 94:2475 95:3312 96:948 97:340 98:959 99:789 100:87 101:1192 102:631 103:21555 104:3621 105:268 106:782 107:1755 108:695 109:3683 110:1724 111:2045 112:1536 113:1382 114:1210 115:1737 116:1769 117:1925 118:2168 119:1650 120:1057 121:1037 122:2245 123:1786 124:1498 125:2018 128:1383 129:840 130:543 131:1819 132:819 133:221 134:1099 135:247 136:596 137:780 138:2079 139:896 140:600 141:895 142:794 143:1068 144:892 145:277 146:1295 147:829 148:1692 149:1098 150:785 151:1019 152:1092 153:337 154:4187 155:915 156:1629 157:1023 158:662 159:1945 160:1601 161:932 162:2969 163:833 164:1249 165:1492 166:478 167:1410 168:3393 169:899 170:4192 171:607 172:1653 173:2223 174:1044 175:976 176:2366 177:4083 178:2563 179:1385 180:2176 181:2380 182:2728 183:1097 184:2276 185:15303 186:3643 187:2488 188:2959 189:2018 190:8210 191:1463 192:10056 193:6731 194:5487 195:4143 196:2974 197:1621 198:5941 199:5981 200:7110 201:5148 202:10413 203:10200 204:4557 205:3065 206:3241 207:3244 208:3936 209:4273 210:3936 211:2048 212:3121 213:2959 214:1126 215:54 216:5887 217:2239 218:892 219:602 220:1879 221:976 222:980 223:1404 End of report

1 0

few big monolithic PEs vs many small PEs
by adamv0025＠netconsultings.com 28 Jun '19

28 Jun '19

Hi folks, Recently I ran into a peculiar situation where we had to cap couple of PE even though merely a half of the rather big chassis was populated with cards, reason being that the central RE/RP was not able to cope with the combined number of routes/vrfs/bgp sessions/etc.. So this made me think about the best strategy in building out SP-Edge nowadays (yes I'm aware of the centralize/decentralize pendulum swinging every couple of years). The conclusion I came to was that *currently the best approach would be to use several medium to small(fixed) PEs to replace a big monolithic chasses based system. So what I was thinking is, Yes it will cost a bit more (router is more expensive than a LC) Will end up with more prefixes in IGP, more BGP sessions etc.. -don't care. But the benefits are less eggs in one basket, simplified and hence faster testing in case of specialized PEs and obviously better RP CPU/MEM to port ratio. Am I missing anything please? *currently, Yes some old chassis systems or even multi-chassis systems used to support additional RPs and offloading some of the processes (e.g. BGP onto those) -problem is these are custom hacks and still a single OS which needs rebooting LC/ASICs when being upgraded -so the problem of too many eggs in one basket still exists (yes cisco NCS6k and recent ASR9k lightspeed LCs are an exception) And yes there is the "node-slicing" approach from Juniper where one can offload CP onto multiple x86 servers and assign LCs to each server (virtual node) - which would solve my chassis full problem -but honestly how many of you are running such setup? Exactly. And that's why I'd be hesitant to deploy this solution in production just yet. I don't know of any other vendor solution like this one, but who knows maybe in 5 years this is going to be the new standard. Anyways I need a solution/strategy for the next 3-5 years. Would like to hear what are your thoughts on this conundrum. adam netconsultings.com ::carrier-class solutions for the telecommunications industry::

9 22