Re: MPLS VPN design - RR in forwarding path?
Given that you assign unique RD per PE, RR out of the forwarding path provides you with a neat trick for fast convergence (and debugging purposes) when CE has redundant paths to different PEs. Routes to those CEs will be seen as different routes on RR. On Wed, Dec 31, 2014 at 1:08 PM, Marcin Kurek not...@marcinkurek.com wrote: Hi everyone, I'm reading Randy's Zhang BGP Design and Implementation and I found following guidelines about designing RR-based MPLS VPN architecture: - Partition RRs - Move RRs out of the forwarding path - Use a high-end processor with maximum memory - Use peer groups - Tune RR routers for improved performance. Since the book is a bit outdated (2004) I'm curious if these rules still apply to modern SP networks. What would be the reasoning behind keeping RRs out of the forwarding path? Is it only a matter of performance and stability? Thanks, Marcin
Re: MPLS VPN design - RR in forwarding path?
+100 Regards, Jeff On Jan 2, 2015, at 5:29 AM, Rob Shakir r...@rob.sh wrote: On 2 Jan 2015, at 01:54, Jeff Tantsura jeff.tants...@ericsson.com wrote: You don't need LDP on RR as long as clients support not on lsp flag (different implementation have different names for it) There are more and more reasons to run RR on a non router HW, there are many reasons to still run commercial code base, mostly feature set and resilience. And test coverage. As Saku alluded to earlier in the thread, rr-rr-client outages are painful. I’ve certainly seen a number of them caused by inter-op issues between implementations. Running at least one RR which matches the code-base of the client means that at least you’re likely to have fallen within the test-cases of that vendor’s implementation. r.
Re: MPLS VPN design - RR in forwarding path?
On 2 Jan 2015, at 01:54, Jeff Tantsura jeff.tants...@ericsson.com wrote: You don't need LDP on RR as long as clients support not on lsp flag (different implementation have different names for it) There are more and more reasons to run RR on a non router HW, there are many reasons to still run commercial code base, mostly feature set and resilience. And test coverage. As Saku alluded to earlier in the thread, rr-rr-client outages are painful. I’ve certainly seen a number of them caused by inter-op issues between implementations. Running at least one RR which matches the code-base of the client means that at least you’re likely to have fallen within the test-cases of that vendor’s implementation. r.
Contact request OOKLA Speedtester
Hi, I need direct contact off list please. Thanks ! Best regards, Marco Paesani M. +39 348 6019349
Re: MPLS VPN design - RR in forwarding path?
On Thursday, January 01, 2015 11:25:24 PM Tony Varriale wrote: Most vendors today have the performance numbers (sometimes they aren't published publically) for routers acting as RRs. Ask your vendor and pick one that suits you. We generally buy the middle or most memory and pick a reasonable processor. And, then we monitor :) With the major vendors now offering VM-based RR's, I'd discourage using routers as RR's just for pure long-term scale. As for peer groups, you should have a design that allows you to herd most of the config snips together. Use the features that make your life easier and allow you to simplify your routing policies. Suffice it to say that the Peer Group functionality in IOS and IOS XE has largely been replaced by Update Groups. We use peer and session templates, but really, as with Peer Groups in 2015, it's just to keep things neat and tidy. Junos, of course, has its way forever which still works nicely. Mark. signature.asc Description: This is a digitally signed message part.
Re: MPLS VPN design - RR in forwarding path?
On Friday, January 02, 2015 04:17:37 AM Ca By wrote: Ymmv. I have feeling that running a bgp rr on cheap / standard / commidity vm is pretty exotic from a support perspective. Not really. Since July last year. The worst I've had was the HP server shutting down in a London data centre due to environmental overheating. Beyond that, similar requirements as with a router, if you avoid the VM clustering goodness they all preach. So running a bgp rr on a vm may make sense in theory, but my network control planes are not too busy and vm bgp is a unique/ exotic support model. Amongst very many other things, running an RR on my core router means I need to touch my core router code if I want that exotic routing feature. I'd rather not, if my core router (in-path) is really just forwarding traffic between PoP's. But agree, our networks are probably quite different :-). Mark. signature.asc Description: This is a digitally signed message part.
Re: MPLS VPN design - RR in forwarding path?
On Thursday, January 01, 2015 11:37:25 PM Baldur Norddahl wrote: Is there a good reason to use actual router hardware for the route reflector role? Nope. It used to be code maturity - but major vendors are supporting service-grade code on VM's. Even a cheap server has more CPU and memory. If it is not in the forwarding path, this is a computing task - not a move packets at line speed task. Agree. Are anyone using Bird, Quagga etc. for this? Wish I could - to be honest, these don't give me enough comfort for a production network. We use Quagga on FreeBSD for Anycast-this--that - from that experience, I'd not use it for backbone routing. YMMV. Mark. signature.asc Description: This is a digitally signed message part.
Re: MPLS VPN design - RR in forwarding path?
On Thursday, January 01, 2015 12:46:23 PM Marcin Kurek wrote: I am also aware of products like vMX or CSR1000v/XRv and the example given by Saku makes me more interested in licensing/pricing options. Our network spans Africa, South Asia and Europe. We have 2x RR's in each PoP running Cisco's CSR1000v on x86_64 hardware under VMware ESXi. Pricing is not too bad; we use the Premium license which enables all features (BFD, e.t.c.) that you don't get with the Standard license. Been running this configuration since July 2014 - very happy. Mark. signature.asc Description: This is a digitally signed message part.
Re: MPLS VPN design - RR in forwarding path?
On Friday, January 02, 2015 03:54:32 AM Jeff Tantsura wrote: You don't need LDP on RR as long as clients support not on lsp flag (different implementation have different names for it) The hack needed when running a Junos-based RR in an MPLS network to allow route reflection of l3vpn routes on an RR not running MPLS. For IOS and IOS XE (and IOS XR, I think), this wouldn't be needed as unlike Juniper, Cisco don't treat MPLS signaling protocols as (pseudo) routing protocols. There are more and more reasons to run RR on a non router HW, there are many reasons to still run commercial code base, mostly feature set and resilience. +1. Mark. signature.asc Description: This is a digitally signed message part.
Re: MPLS VPN design - RR in forwarding path?
On Friday, January 02, 2015 12:16:26 PM Andriy Bilous wrote: Given that you assign unique RD per PE, RR out of the forwarding path provides you with a neat trick for fast convergence (and debugging purposes) when CE has redundant paths to different PEs. Routes to those CEs will be seen as different routes on RR. Not having to dump routes into FIB *really* speeds up convergence. It's not even funny :-)... Mark. signature.asc Description: This is a digitally signed message part.
Re: MPLS VPN design - RR in forwarding path?
On Friday, January 02, 2015 12:09:36 AM Nick Hilliard wrote: there are patches for both code-bases and some preliminary support for vpnv4 in quagga, but other than that neither currently supports either ldp or the vpnv4/vpnv6 address families in the main-line code. LDP support would not be necessary for an out-of-path RR, but lack of VPNv4/VPNv6 is hurdle. Mark. signature.asc Description: This is a digitally signed message part.
Re: MPLS VPN design - RR in forwarding path?
On Friday, January 02, 2015 03:57:41 AM Mike Hammett wrote: Running various functions on a couple small VM clusters makes a lot of sense. We treat our CSR1000v RR's as dedicated islands. No other functions run on them, nor do we cluster them. Don't want what fun could arise :-)... Mark. signature.asc Description: This is a digitally signed message part.
Level3 Contact - Non-customer
Does anyone have a contact for Level3 if you are a not a customer or can someone from level3 please contact me off list. We're seeing and issue with blocked subnets. All of their public addresses are being replied to with log into the portal, open a customer ticket. Thanks, Bryan Socha Network Engineer DigitalOcean
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. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith pfsi...@gmail.com. Routing Table Report 04:00 +10GMT Sat 03 Jan, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 524053 Prefixes after maximum aggregation (per Origin AS): 201599 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 256561 Total ASes present in the Internet Routing Table: 48968 Prefixes per ASN: 10.70 Origin-only ASes present in the Internet Routing Table: 36361 Origin ASes announcing only one prefix: 16299 Transit ASes present in the Internet Routing Table:6217 Transit-only ASes present in the Internet Routing Table:170 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 100 Max AS path prepend of ASN ( 55644) 93 Prefixes from unregistered ASNs in the Routing Table: 1641 Unregistered ASNs in the Routing Table: 432 Number of 32-bit ASNs allocated by the RIRs: 8291 Number of 32-bit ASNs visible in the Routing Table:6390 Prefixes from 32-bit ASNs in the Routing Table: 22960 Number of bogon 32-bit ASNs visible in the Routing Table:11 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:396 Number of addresses announced to Internet: 2718618692 Equivalent to 162 /8s, 10 /16s and 212 /24s Percentage of available address space announced: 73.4 Percentage of allocated address space announced: 73.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.0 Total number of prefixes smaller than registry allocations: 176798 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 129283 Total APNIC prefixes after maximum aggregation: 37681 APNIC Deaggregation factor:3.43 Prefixes being announced from the APNIC address blocks: 134136 Unique aggregates announced from the APNIC address blocks:54942 APNIC Region origin ASes present in the Internet Routing Table:5007 APNIC Prefixes per ASN: 26.79 APNIC Region origin ASes announcing only one prefix: 1215 APNIC Region transit ASes present in the Internet Routing Table:864 Average APNIC Region AS path length visible:4.5 Max APNIC Region AS path length visible:100 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1238 Number of APNIC addresses announced to Internet: 740595776 Equivalent to 44 /8s, 36 /16s and 152 /24s Percentage of available APNIC address space announced: 86.6 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 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:174308 Total ARIN prefixes after maximum aggregation:86308 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 176223 Unique aggregates announced from the ARIN address blocks: 82419 ARIN Region origin ASes present in the Internet Routing Table:16418 ARIN Prefixes per
Re: MPLS VPN design - RR in forwarding path?
On 02/01/2015 18:24, Mark Tinka wrote: Wish I could - to be honest, these don't give me enough comfort for a production network. It's not even possible for a vpn enabled network right now. Having said that, I use bird in anger for ixp route server functionality (i.e. ebgp route reflector) and have nothing but good to say about it. Quagga can be, uh, more temperamental. Nick
Re: MPLS VPN design - RR in forwarding path?
On 02/01/2015 02:17, Ca By wrote: I agree, it makes some sense, especially if you are control plane bound. But, nearly all my routers run between 1% and 10% cpu. 1% and 10% on what will generally be older, slower cpus. Modern servers have significantly faster CPUs than any RE/RP on the market, so you will see a benefit in terms of convergence speed by using virtualisation. Ymmv. I have feeling that running a bgp rr on cheap / standard / commidity vm is pretty exotic from a support perspective. not really, no. Standalone hypervisors are stable, predictable and easy to manage. They're also commercially supported and most companies these days have a good deal of internal experience in dealing with them. As Mark commented separately, you would need your head examined if you plan to enable hypervisor clustering for this sort of thing. Nick So running a bgp rr on a vm may make sense in theory, but my network control planes are not too busy and vm bgp is a unique/ exotic support model. Your network is probably different - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com - Original Message - From: Jeff Tantsura jeff.tants...@ericsson.com javascript:; To: Nick Hilliard n...@foobar.org javascript:; Cc: nanog@nanog.org javascript:; Sent: Thursday, January 1, 2015 7:54:32 PM Subject: Re: MPLS VPN design - RR in forwarding path? You don't need LDP on RR as long as clients support not on lsp flag (different implementation have different names for it) There are more and more reasons to run RR on a non router HW, there are many reasons to still run commercial code base, mostly feature set and resilience. Regards, Jeff On Jan 1, 2015, at 2:11 PM, Nick Hilliard n...@foobar.org javascript:; wrote: On 01/01/2015 21:37, Baldur Norddahl wrote: Are anyone using Bird, Quagga etc. for this? there are patches for both code-bases and some preliminary support for vpnv4 in quagga, but other than that neither currently supports either ldp or the vpnv4/vpnv6 address families in the main-line code. Nick
Re: MPLS VPN design - RR in forwarding path?
On Wed, Dec 31, 2014 at 11:14 AM, Jeff Tantsura jeff.tants...@ericsson.com wrote: Keep in mind - some architectures, such as seamless MPLS would require a RR to be in the fast path. +1 Also think physical topologies like ethernet rings. Where's the RR go in this topology? -Dan
The Cidr Report
This report has been generated at Fri Jan 2 21:14:20 2015 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/2.0 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
26-12-14529668 293468
27-12-14529797 293731
28-12-14529713 293924
29-12-14529791 292319
30-12-14529929 291995
31-12-14529985 291981
01-01-15529871 291855
02-01-15529540 291901
AS Summary
49250 Number of ASes in routing system
19745 Number of ASes announcing only one prefix
3060 Largest number of prefixes announced by an AS
AS10620: Telmex Colombia S.A.,CO
120376832 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN
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').
--- 02Jan15 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 529654 291913 23774144.9% All ASes
AS6389 2890 69 282197.6% BELLSOUTH-NET-BLK -
BellSouth.net Inc.,US
AS22773 2922 173 274994.1% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.,US
AS17974 2816 77 273997.3% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia,ID
AS28573 2308 307 200186.7% NET Serviços de Comunicação
S.A.,BR
AS3356 2631 770 186170.7% LEVEL3 - Level 3
Communications, Inc.,US
AS4755 1927 285 164285.2% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP,IN
AS4766 2942 1303 163955.7% KIXS-AS-KR Korea Telecom,KR
AS6147 1793 170 162390.5% Telefonica del Peru S.A.A.,PE
AS7303 1772 289 148383.7% Telecom Argentina S.A.,AR
AS10620 3060 1588 147248.1% Telmex Colombia S.A.,CO
AS9808 1515 56 145996.3% CMNET-GD Guangdong Mobile
Communication Co.Ltd.,CN
AS8402 1411 26 138598.2% CORBINA-AS OJSC Vimpelcom,RU
AS20115 1855 526 132971.6% CHARTER-NET-HKY-NC - Charter
Communications,US
AS7545 2502 1272 123049.2% TPG-INTERNET-AP TPG Telecom
Limited,AU
AS4323 1637 411 122674.9% TWTC - tw telecom holdings,
inc.,US
AS9498 1298 111 118791.4% BBIL-AP BHARTI Airtel Ltd.,IN
AS18566 2041 868 117357.5% MEGAPATH5-US - MegaPath
Corporation,US
AS7552 1131 57 107495.0% VIETEL-AS-AP Viettel
Corporation,VN
AS22561 1340 266 107480.1% AS22561 - CenturyTel Internet
Holdings, Inc.,US
AS34984 1925 868 105754.9% TELLCOM-AS TELLCOM ILETISIM
HIZMETLERI A.S.,TR
AS6983 1624 617 100762.0% ITCDELTA - Earthlink, Inc.,US
AS7738 1000 84 91691.6% Telemar Norte Leste S.A.,BR
AS38285 983 113 87088.5% M2TELECOMMUNICATIONS-AU M2
Telecommunications Group
Ltd,AU
AS4538 1775 907 86848.9% ERX-CERNET-BKB China Education
and Research Network
Center,CN
AS31148 1045 190 85581.8% FREENET-AS Freenet Ltd.,UA
AS24560 1179 374 80568.3% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services,IN
AS8151 1493 697 79653.3% Uninet S.A. de C.V.,MX
AS18881 856 65 79192.4% Global Village Telecom,BR
AS26615 930 142 78884.7% Tim Celular S.A.,BR
AS4780 1066 305 76171.4% SEEDNET Digital United Inc.,TW
Total 53667129864068175.8% Top 30 total
Possible Bogus
BGP Update Report
BGP Update Report Interval: 25-Dec-14 -to- 01-Jan-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS 821079 16.6% 68423.2 -- RUSERVICE-LLC-AS LLC RU-service,RU 2 - AS13105 350358 7.1% 15233.0 -- LUKOIL-INFORM-AS LUKOIL Technology Services GmbH,RU 3 - AS23752 282375 5.7%2031.5 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - AS9829 155694 3.1% 93.1 -- BSNL-NIB National Internet Backbone,IN 5 - AS53249 79833 1.6% 39916.5 -- LAWA-AS - Los Angeles World Airport,US 6 - AS36947 44151 0.9% 218.6 -- ALGTEL-AS,DZ 7 - AS3 42234 0.8%1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 8 - AS38197 32173 0.7% 27.8 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 9 - AS10620 29823 0.6% 9.7 -- Telmex Colombia S.A.,CO 10 - AS60725 29341 0.6%1630.1 -- O3B-AS O3b Limited,JE 11 - AS42456 28956 0.6%2632.4 -- CHMURTZ-AS CHMURTZ SARL,FR 12 - AS51964 28201 0.6% 59.0 -- ORANGE-BUSINESS-SERVICES-IPSN-ASN Equant Inc.,FR 13 - AS716227074 0.6% 338.4 -- Universo Online S.A.,BR 14 - AS17974 26257 0.5% 9.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID 15 - AS45899 25780 0.5% 48.2 -- VNPT-AS-VN VNPT Corp,VN 16 - AS2 24821 0.5% 250.0 -- UDEL-DCN - University of Delaware,US 17 - AS36691 23100 0.5% 11550.0 -- CSUP-AS - Colorado State University-Pueblo,US 18 - AS18399 22856 0.5%1269.8 -- YTCL-AS-AP Yatanarpon Teleport Company Limited,MM 19 - AS11054 22677 0.5% 629.9 -- LIVEPERSON - LivePerson, Inc.,US 20 - AS23342 21090 0.4% 540.8 -- UNITEDLAYER - Unitedlayer, Inc.,US TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS 821079 16.6% 68423.2 -- RUSERVICE-LLC-AS LLC RU-service,RU 2 - AS53249 79833 1.6% 39916.5 -- LAWA-AS - Los Angeles World Airport,US 3 - AS61039 16726 0.3% 16726.0 -- ZMZ OAO ZMZ,RU 4 - AS13105 350358 7.1% 15233.0 -- LUKOIL-INFORM-AS LUKOIL Technology Services GmbH,RU 5 - AS3 42234 0.8%1306.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 6 - AS36691 23100 0.5% 11550.0 -- CSUP-AS - Colorado State University-Pueblo,US 7 - AS37718 0.2% 246.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 8 - AS582527222 0.1%7222.0 -- ASN-RINGLOUD Netuity Limited,GB 9 - AS621745811 0.1%5811.0 -- INTERPAN-AS INTERPAN LTD.,BG 10 - AS337214422 0.1%4422.0 -- CCL-ASN2 - CARNIVAL CRUISE LINES,US 11 - AS318603008 0.1%3008.0 -- MACKAY-SHIELDS - MacKay Shields LLC,US 12 - AS42456 28956 0.6%2632.4 -- CHMURTZ-AS CHMURTZ SARL,FR 13 - AS527892630 0.1%2630.0 -- SILVA NET PROVEDOR DE INTERNET LTDA,BR 14 - AS23752 282375 5.7%2031.5 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 15 - AS476809769 0.2%1953.8 -- NHCS EOBO Limited,IE 16 - AS31935 0.0%1445.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 17 - AS607377511 0.1%1877.8 -- NEURONESIT NEURONESIT,FR 18 - AS60725 29341 0.6%1630.1 -- O3B-AS O3b Limited,JE 19 - AS456068025 0.2%1605.0 -- 20 - AS513632802 0.1%1401.0 -- TELEPATIYA-NET Telepatiya Ltd.,KZ TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 212.22.94.0/24 410720 8.1% AS -- RUSERVICE-LLC-AS LLC RU-service,RU 2 - 212.22.80.0/24 410138 8.1% AS -- RUSERVICE-LLC-AS LLC RU-service,RU 3 - 202.70.88.0/21 141463 2.8% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 202.70.64.0/21 138919 2.7% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 5 - 82.118.158.0/23 71540 1.4% AS13105 -- LUKOIL-INFORM-AS LUKOIL Technology Services GmbH,RU 6 - 82.118.146.0/23 70924 1.4% AS13105 -- LUKOIL-INFORM-AS LUKOIL Technology Services GmbH,RU 7 - 95.171.242.0/23 69812 1.4% AS13105 -- LUKOIL-INFORM-AS LUKOIL Technology Services GmbH,RU 8 - 95.171.236.0/23 69014 1.4% AS13105 -- LUKOIL-INFORM-AS LUKOIL Technology Services GmbH,RU 9 - 95.171.242.0/24 68980 1.4% AS13105 -- LUKOIL-INFORM-AS LUKOIL Technology Services GmbH,RU 10 - 130.0.192.0/2142230 0.8% AS3 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 11 - 198.140.115.0/24 39940 0.8% AS53249 -- LAWA-AS - Los Angeles World Airport,US 12 - 198.140.114.0/24 39893 0.8%
