Re: SIP on FTTH systems
On Friday, February 07, 2014 09:11:38 AM Mikael Abrahamsson wrote: Violent agreement. Customers should not talk L2 directly to each other using local switching, but they should be able to send IP packets to each other. And in fairness, given the positive security benefits (barring extreme corner cases or hardware/software bugs), the otherwise sub-optimal tromboning between homes via the BNG is an acceptable compromise. Mark. signature.asc Description: This is a digitally signed message part.
Re: carrier comparison
Hi Faisal, You might have to deploy some other means of (script ?) to bring your BGP session down from the 'broken' Service Provider. To the best of my knowledge, BGP does not have any mechanism to determine broken connectivity upstream past the router you are BGP session is up with. Well, technically there's BFD that might do the trick. But of course it won't be available; it's not usually, so specially with Cogent... :) But maybe its link was just overloaded in fact. -- Olivier
Re: carrier comparison
Hi Vlade, Well, if you are trying to balance the incoming traffic load with local-pref attribute, I can understand your disappointment :) Since it doesn't work at all this way: local-pref is local to an AS and deals with outgoing traffic only. B) We have our own AS and IP space. I advertise them to both Cogent and our other ISP. I use the local preference attribute to share the load for incoming traffic between both ISPs. In the last 5 outages over the last few years, this has happened twice. I'm waiting on the RFO so I can further investigate why this happened. I think someone mentioned this in a post a few months ago too. -- Olivier
Re: Need trusted NTP Sources
On (2014-02-06 21:14 -0500), Jay Ashworth wrote: My usual practice is to set up two in house servers, each of which talks to: And then point everyone in house to both of them, assuming they accept multiple server names. Two is worst possible amount of NTP servers to have. Either one fails and your timing is wrong, because you cannot vote false ticker. And chance of either of two failing is higher than one specific of them. -- ++ytti
Re: Need trusted NTP Sources
On Fri, Feb 7, 2014 at 5:35 AM, Saku Ytti s...@ytti.fi wrote: On (2014-02-06 21:14 -0500), Jay Ashworth wrote: My usual practice is to set up two in house servers, each of which talks to: Two is worst possible amount of NTP servers to have. Either one fails and your timing is wrong, because you cannot vote false ticker. And chance of either of two failing is higher than one specific of them. +1 to having at least 3 NTP servers. Because complete outage is only one kind of failure. Don't forget poor performance due to high latency, or Server X emitting corrupted or inaccurate data -- -JH
RE: SIP on FTTH systems
Rather than assign residential and business customers their own /30, to conserve space we give those customers a /32 out of a /24. But when one of these static IP customers wants to send email to another, or the employee wants to VPN into work, they can't. MACFF is supposed to solve that (we haven't turned it on, yet, because the vendor's implementation requires us to do some work on our provisioning system to make it easier). Frank -Original Message- From: Jay Ashworth [mailto:j...@baylink.com] Sent: Thursday, February 06, 2014 11:59 PM To: NANOG Subject: Re: SIP on FTTH systems - Original Message - From: Frank Bulk frnk...@iname.com And then you need MACFF to overcome the split-horizon to that customers in the same subnet can talk to each other. =) In my not-at-all humble opinion, in an eyeball network, you almost *never* want to make it easier for houses to talk to one another directly; there isn't any real traffic there. Just attack traffic. Well, ok; slim chance of P2P, but carriers hate that anyway, right? :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: carrier comparison
I'm not setting it on my router locally but sending it over to Cogent as a community string per page 22 of their user guide. http://cogentco.com/files/docs/customer_service/guide/global_cogent_customer_user_guide.pdf They use it to manipulate how traffic gets back to me so that is incoming from my routers view. I also pad the AS for the networks that I prefer to come back through the other ISP.. On 2/7/2014 5:27 AM, Olivier Benghozi wrote: Hi Vlade, Well, if you are trying to balance the incoming traffic load with local-pref attribute, I can understand your disappointment :) Since it doesn't work at all this way: local-pref is local to an AS and deals with outgoing traffic only. B) We have our own AS and IP space. I advertise them to both Cogent and our other ISP. I use the local preference attribute to share the load for incoming traffic between both ISPs. In the last 5 outages over the last few years, this has happened twice. I'm waiting on the RFO so I can further investigate why this happened. I think someone mentioned this in a post a few months ago too. -- Vlade Ristevski Network Manager IT Services Ramapo College (201)-684-6854
Re: carrier comparison
Based on my understanding on BFD, it will not help you... BFD will detect the direct connected port being down quicker and force the BGP session down, (faster than the time BGP session timers take to determine something is broken) This is the common issue / challenge in how to determine up-stream path outage and then doing appropriate route engineering on an automatic basis. Maybe a SLA monitor type scripting/configuration be useful in your case. Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net - Original Message - From: Olivier Benghozi olivier.bengh...@wifirst.fr To: nanog@nanog.org Sent: Friday, February 7, 2014 5:25:53 AM Subject: Re: carrier comparison Hi Faisal, You might have to deploy some other means of (script ?) to bring your BGP session down from the 'broken' Service Provider. To the best of my knowledge, BGP does not have any mechanism to determine broken connectivity upstream past the router you are BGP session is up with. Well, technically there's BFD that might do the trick. But of course it won't be available; it's not usually, so specially with Cogent... :) But maybe its link was just overloaded in fact. -- Olivier
Re: SIP on FTTH systems
On Friday, February 07, 2014 03:30:08 PM Frank Bulk wrote: Rather than assign residential and business customers their own /30, to conserve space we give those customers a /32 out of a /24. But when one of these static IP customers wants to send email to another, or the employee wants to VPN into work, they can't. This is akin to Private VLAN's where ports in a shared VLAN are assigned numbers from the same subnet, but they can only communicate via the BNG rather than directly at the bridge level. I prefer EVC Split Horizon to Private VLAN's, though. Mark. signature.asc Description: This is a digitally signed message part.
Re: carrier comparison
On Friday, February 07, 2014 04:49:09 PM Faisal Imtiaz wrote: Based on my understanding on BFD, it will not help you... BFD will detect the direct connected port being down quicker and force the BGP session down, (faster than the time BGP session timers take to determine something is broken) You would also need your provider to support BFD (and by support I mostly mean willing to run, as modern gear today is technically capable). Mark. signature.asc Description: This is a digitally signed message part.
Re: Need trusted NTP Sources
On 2/7/2014 3:35 AM, Saku Ytti wrote: On (2014-02-06 21:14 -0500), Jay Ashworth wrote: My usual practice is to set up two in house servers, each of which talks to: And then point everyone in house to both of them, assuming they accept multiple server names. Two is worst possible amount of NTP servers to have. Either one fails and your timing is wrong, because you cannot vote false ticker. And chance of either of two failing is higher than one specific of them. A man with a watch knows what time it is. A man with two watches is never sure.
Re: SIP on FTTH systems
I would assume that this whole mostly depends on which particular protocols and approaches your edge equipment can implement most efficiently - efficiently enough, that is, to be able to do it on every single port in a chassis. On February 7, 2014 10:20:08 AM EST, Mark Tinka mark.ti...@seacom.mu wrote: On Friday, February 07, 2014 03:30:08 PM Frank Bulk wrote: Rather than assign residential and business customers their own /30, to conserve space we give those customers a /32 out of a /24. But when one of these static IP customers wants to send email to another, or the employee wants to VPN into work, they can't. This is akin to Private VLAN's where ports in a shared VLAN are assigned numbers from the same subnet, but they can only communicate via the BNG rather than directly at the bridge level. I prefer EVC Split Horizon to Private VLAN's, though. Mark. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: SIP on FTTH systems
On Friday, February 07, 2014 05:41:44 PM Jay Ashworth wrote: I would assume that this whole mostly depends on which particular protocols and approaches your edge equipment can implement most efficiently - efficiently enough, that is, to be able to do it on every single port in a chassis. Well, Split Horizon would be enabled on all the customer- facing ports. I am not aware of any protocol restrictions when running Split Horizon. I haven't run into any issues yet. Mark. signature.asc Description: This is a digitally signed message part.
RE: Need trusted NTP Sources
Working in the financial world, the best practices is to have 4 ntp servers (if not using PTP). 1) You need 3 to determine the correct time (and detect bad tickers) 2) If you lose 1 of the 3 above, then you no longer can determine the correct time 3) Therefore with 4, you have redundancy. We have two Symmetricom Stratum 1 time servers synced via GPS with Rubidium oscillators, and two RHEL 6 servers running ntpd for our 4 servers. Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 -Original Message- From: Roy [mailto:r.engehau...@gmail.com] Sent: Friday, February 7, 2014 10:23 AM To: nanog@nanog.org Subject: Re: Need trusted NTP Sources On 2/7/2014 3:35 AM, Saku Ytti wrote: On (2014-02-06 21:14 -0500), Jay Ashworth wrote: My usual practice is to set up two in house servers, each of which talks to: And then point everyone in house to both of them, assuming they accept multiple server names. Two is worst possible amount of NTP servers to have. Either one fails and your timing is wrong, because you cannot vote false ticker. And chance of either of two failing is higher than one specific of them. A man with a watch knows what time it is. A man with two watches is never sure. attachment: Matthew Huff.vcf
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, LacNOG, TRNOG, 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 08 Feb, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 481577 Prefixes after maximum aggregation: 191369 Deaggregation factor: 2.52 Unique aggregates announced to Internet: 238471 Total ASes present in the Internet Routing Table: 46105 Prefixes per ASN: 10.45 Origin-only ASes present in the Internet Routing Table: 35582 Origin ASes announcing only one prefix: 16383 Transit ASes present in the Internet Routing Table:6020 Transit-only ASes present in the Internet Routing Table:167 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1861 Unregistered ASNs in the Routing Table: 496 Number of 32-bit ASNs allocated by the RIRs: 5908 Number of 32-bit ASNs visible in the Routing Table:4503 Prefixes from 32-bit ASNs in the Routing Table: 14343 Number of bogon 32-bit ASNs visible in the Routing Table:15 Special use prefixes present in the Routing Table: 12 Prefixes being announced from unallocated address space:450 Number of addresses announced to Internet: 2666891428 Equivalent to 158 /8s, 245 /16s and 136 /24s Percentage of available address space announced: 72.0 Percentage of allocated address space announced: 72.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 95.7 Total number of prefixes smaller than registry allocations: 168062 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 114263 Total APNIC prefixes after maximum aggregation: 34392 APNIC Deaggregation factor:3.32 Prefixes being announced from the APNIC address blocks: 116746 Unique aggregates announced from the APNIC address blocks:48907 APNIC Region origin ASes present in the Internet Routing Table:4881 APNIC Prefixes per ASN: 23.92 APNIC Region origin ASes announcing only one prefix: 1216 APNIC Region transit ASes present in the Internet Routing Table:840 Average APNIC Region AS path length visible:4.6 Max APNIC Region AS path length visible: 28 Number of APNIC region 32-bit ASNs visible in the Routing Table:827 Number of APNIC addresses announced to Internet: 729428480 Equivalent to 43 /8s, 122 /16s and 50 /24s Percentage of available APNIC address space announced: 85.2 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 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:164783 Total ARIN prefixes after maximum aggregation:82620 ARIN Deaggregation factor: 1.99 Prefixes being announced from the ARIN address blocks: 166088 Unique aggregates announced from the ARIN address blocks: 77127 ARIN Region origin ASes present in the Internet Routing Table:16132 ARIN
Re: Need trusted NTP Sources
On Feb 7, 2014, at 10:56 AM, Matthew Huff mh...@ox.com wrote: Working in the financial world, the best practices is to have 4 ntp servers (if not using PTP). 1) You need 3 to determine the correct time (and detect bad tickers) 2) If you lose 1 of the 3 above, then you no longer can determine the correct time 3) Therefore with 4, you have redundancy. We have two Symmetricom Stratum 1 time servers synced via GPS with Rubidium oscillators, and two RHEL 6 servers running ntpd for our 4 servers. Having a number of NTP servers will help you detect false tickers which may be critical. If you want something that is cheap as in you for your home, I can recommend this: ~$350 w/ antenna, etc.. http://www.netburnerstore.com/product_p/pk70ex-ntp.htm You can get the whole thing going quickly. Majdi has also had good luck with this unit (perhaps he wants to chime-in, heh pun unintended) regarding a few other devices. If you ask politely off-list, I will point you at where one of these is that you can talk to (in Dallas at the Infomart for your low-latency config). - Jared
Re: Why won't providers source-filter attacks? Simple.
On 2/5/14, 7:11 PM, Mark Andrews ma...@isc.org wrote: Well when industries don't self regulate governments step in. This industry is demonstratably incapble of regulating itself in this area despite lots of evidence of the problems being caused for lots of years. Which industry is that? App providers that have not implemented? Hosting providers that have not? Transit providers that have not? Access network ISPs that have not? Large enterprises and education networks that have not? ;-) I still prefer a list of specific networks that need to pay attention to improving anti-spoofing since otherwise I think most of us are in violent agreement on the need. This has been DOCUMENTED BEST CURRENT PRACTICE for 13.5 years. Everybody else is having to deal the problems caused by these bad actors. Hell, I suspect you could send the directors to gaol or make them pay a heavy fine today by properly examining the existing laws. A new law would just make the problem more explicit. In the U.S. one of the FCC Communications Security, Reliability, and Interoperability Council (CSRIC) working groups is focused on this issue. I do not know what is happening in other jurisdictions. Jason
Re: Why won't providers source-filter attacks? Simple.
On 2/7/2014 1:26 PM, Livingood, Jason wrote: I do not know what is happening in other jurisdictions. I find that seriously scary, if wide-spread. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
Re: Why won't providers source-filter attacks? Simple.
On 2/7/14, 2:30 PM, Larry Sheldon larryshel...@cox.net wrote: On 2/7/2014 1:26 PM, Livingood, Jason wrote: I do not know what is happening in other jurisdictions. I find that seriously scary, if wide-spread. Sorry - too many country-by-country regulators to keep track ofŠ
Re: Why won't providers source-filter attacks? Simple.
On 2/7/2014 1:44 PM, Livingood, Jason wrote: On 2/7/14, 2:30 PM, Larry Sheldon larryshel...@cox.net wrote: On 2/7/2014 1:26 PM, Livingood, Jason wrote: I do not know what is happening in other jurisdictions. I find that seriously scary, if wide-spread. Sorry - too many country-by-country regulators to keep track ofŠ Each and every and any one of which can put you and me out of business. Or worse. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
Re: carrier comparison
Did you verify your problem was announcements on the other side of the outage? This sounds to me like you are using a bgp announced default route from cogent which is always sent.I think the problem was you were sending traffic out a path that was broken. Since you mentioned your outbound balancing this would explain some packet loss and not 100% loss. Bryan Socha Network Engineer DigitalOcean
BCP38 (was: Re: Why won't providers source-filter attacks? Simple.)
On Feb 5, 2014, at 2:12 AM, Jimmy Hess mysi...@gmail.com wrote: On Wed, 05 Feb 2014 12:18:54 +1100, Mark Andrews said: Now if we could get equipement vendors to stop shipping models without the necessary support it would help but that also may require government intervention. ... A good start would be to get BCP38 revised to router the Host requirements RFCs, to indicate that ingress filtering should be considered mandatory on site-facing interfaces. ... It's also true that if a sizable group of network operators were to actually deploy source address validation (thus proving that it really is a reasonable approach and doesn't carry too much operational or vendor implications), then it would be quite reasonable for those operators to bring the results to NANOG and get it recognized as a best current operating practice for networks of similar design/purpose. If the standards documents still just call it a best practice what hope is there of having governments require it of the service providers that their networks are connected to, anyways? There is a significant difference between a best current practice (BCP) document from the IETF (a technical standards body) versus one which actually reflects the well-considered best practices of a large network operator forum. The latter would be of some interest to governments (and groups of governments) when they ask for any options that might help with their growing spam and DDoS concerns... FYI, /John
Re: Need trusted NTP Sources
With a quick and easy mod, another option for $35 is a Sure Electronics GPS board. GPS: http://www.sureelectronics.net/goods.php?id=99 Mod: http://www.satsignal.eu/ntp/Sure-GPS.htm -Alby On 2/7/2014 1:14 PM, Jared Mauch wrote: Having a number of NTP servers will help you detect false tickers which may be critical. If you want something that is cheap as in you for your home, I can recommend this: ~$350 w/ antenna, etc..
Re: BCP38 (was: Re: Why won't providers source-filter attacks? Simple.)
On Feb 8, 2014, at 3:37 AM, John Curran jcur...@arin.net wrote: It's also true that if a sizable group of network operators were to actually deploy source address validation (thus proving that it really is a reasonable approach and doesn't carry too much operational or vendor implications), then it would be quite reasonable for those operators to bring the results to NANOG and get it recognized as a best current operating practice for networks of similar design/purpose. Many already do - including operators of very large networks. There are operational, vendor, and topological considerations which mean that it's achieved utilizing various mechanisms in different scenarios. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: carrier comparison
We don't get a default route from them. At the time of the outage my bgp session was up and I had a full routing table from them. I didn't have much time to troubleshoot it in that state since we were down so I had to disable the session ASAP. Once the RFO comes in, I'll be asking a lot more questions about it. My only experience with BGP is as a customer so I'm not too familiar with the intricacies on the provider side. We had an outage in the AM the same day and we failed over just fine. I'm very curious why the same didn't happen in the evening. On 2/7/2014 3:03 PM, Bryan Socha wrote: Did you verify your problem was announcements on the other side of the outage? This sounds to me like you are using a bgp announced default route from cogent which is always sent.I think the problem was you were sending traffic out a path that was broken. Since you mentioned your outbound balancing this would explain some packet loss and not 100% loss. Bryan Socha Network Engineer DigitalOcean -- Vlade Ristevski Network Manager IT Services Ramapo College (201)-684-6854
Re: BCP38 (was: Re: Why won't providers source-filter attacks? Simple.)
On Fri, Feb 7, 2014 at 2:07 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Feb 8, 2014, at 3:37 AM, John Curran jcur...@arin.net wrote: It's also true that if a sizable group of network operators were to actually deploy source address validation (thus proving that it really is a reasonable approach and doesn't carry too much operational or vendor implications), then it would be quite reasonable for those operators to bring the results to NANOG and get it recognized as a best current operating practice for networks of similar design/purpose. Many already do - including operators of very large networks. There are operational, vendor, and topological considerations which mean that it's achieved utilizing various mechanisms in different scenarios. Documenting those various mechanisms which are actually utilized is the key here. =) $0.02 ~Chris -- @ChrisGrundemann http://chrisgrundemann.com
Re: BCP38 (was: Re: Why won't providers source-filter attacks? Simple.)
On Feb 8, 2014, at 4:25 AM, Chris Grundemann cgrundem...@gmail.com wrote: Documenting those various mechanisms which are actually utilized is the key here. =) Yes, as well as the various limitations and caveats, like the wholesale/retail issue (i.e., customers of my customer). --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: carrier comparison
This is exactly what I thought had happenedThe outage that affected you was one our two routers up-stream from your connection to that provider. I am not trying to defend any Carrier, but there is no 'routing protocol' what will react to this kind of an issue. Regards. Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net - Original Message - From: Vlade Ristevski vrist...@ramapo.edu Cc: nanog list nanog@nanog.org Sent: Friday, February 7, 2014 3:57:00 PM Subject: Re: carrier comparison We don't get a default route from them. At the time of the outage my bgp session was up and I had a full routing table from them. I didn't have much time to troubleshoot it in that state since we were down so I had to disable the session ASAP. Once the RFO comes in, I'll be asking a lot more questions about it. My only experience with BGP is as a customer so I'm not too familiar with the intricacies on the provider side. We had an outage in the AM the same day and we failed over just fine. I'm very curious why the same didn't happen in the evening. On 2/7/2014 3:03 PM, Bryan Socha wrote: Did you verify your problem was announcements on the other side of the outage? This sounds to me like you are using a bgp announced default route from cogent which is always sent.I think the problem was you were sending traffic out a path that was broken. Since you mentioned your outbound balancing this would explain some packet loss and not 100% loss. Bryan Socha Network Engineer DigitalOcean -- Vlade Ristevski Network Manager IT Services Ramapo College (201)-684-6854
The Cidr Report
This report has been generated at Fri Feb 7 21:13:36 2014 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
31-01-14491578 275802
01-02-14491660 275860
02-02-14491613 276047
03-02-14491838 275998
04-02-14491832 275909
05-02-14491982 276297
06-02-14492203 276288
07-02-14492404 276405
AS Summary
46262 Number of ASes in routing system
18980 Number of ASes announcing only one prefix
4471 Largest number of prefixes announced by an AS
AS7029 : WINDSTREAM - Windstream Communications Inc
119428352 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street
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').
--- 07Feb14 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 492602 276419 21618343.9% All ASes
AS28573 3408 84 332497.5% NET Serviços de Comunicação
S.A.
AS6389 3027 56 297198.1% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS7029 4471 1706 276561.8% WINDSTREAM - Windstream
Communications Inc
AS17974 2747 177 257093.6% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia
AS22773 2329 228 210190.2% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS4766 2934 889 204569.7% KIXS-AS-KR Korea Telecom
AS18881 1868 35 183398.1% Global Village Telecom
AS1785 2158 406 175281.2% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS36998 1810 97 171394.6% SDN-MOBITEL
AS10620 2722 1175 154756.8% Telmex Colombia S.A.
AS18566 2047 565 148272.4% MEGAPATH5-US - MegaPath
Corporation
AS4323 2929 1514 141548.3% TWTC - tw telecom holdings,
inc.
AS7303 1745 415 133076.2% Telecom Argentina S.A.
AS4755 1823 588 123567.7% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS7552 1261 157 110487.5% VIETEL-AS-AP Viettel
Corporation
AS7545 2178 1120 105848.6% TPG-INTERNET-AP TPG Telecom
Limited
AS22561 1264 227 103782.0% AS22561 - CenturyTel Internet
Holdings, Inc.
AS9829 1592 650 94259.2% BSNL-NIB National Internet
Backbone
AS18101 993 187 80681.2% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI
AS4808 1168 393 77566.4% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS35908 869 107 76287.7% VPLSNET - Krypt Technologies
AS24560 1106 372 73466.4% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS701 1495 765 73048.8% UUNET - MCI Communications
Services, Inc. d/b/a Verizon
Business
AS8151 1386 665 72152.0% Uninet S.A. de C.V.
AS6983 1299 582 71755.2% ITCDELTA - ITC^Deltacom
AS7738 847 148 69982.5% Telemar Norte Leste S.A.
AS4788 937 241 69674.3% TMNET-AS-AP TM Net, Internet
Service Provider
AS855749 57 69292.4% CANET-ASN-4 - Bell Aliant
Regional Communications, Inc.
AS4780 1027 371 65663.9% SEEDNET Digital United Inc.
AS6147
BGP Update Report
BGP Update Report Interval: 30-Jan-14 -to- 06-Feb-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS480083579 3.9% 363.4 -- LINTASARTA-AS-AP Network Access Provider and Internet Service Provider 2 - AS982963814 3.0% 64.7 -- BSNL-NIB National Internet Backbone 3 - AS35181 44454 2.1%3704.5 -- PWC Autonomous System Number for Public WareHouse Company 4 - AS840240917 1.9% 21.4 -- CORBINA-AS OJSC Vimpelcom 5 - AS31148 25755 1.2% 25.4 -- FREENET-AS Freenet Ltd. 6 - AS27738 24132 1.1% 41.8 -- Ecuadortelecom S.A. 7 - AS10620 22841 1.1% 17.4 -- Telmex Colombia S.A. 8 - AS13118 20696 1.0% 481.3 -- ASN-YARTELECOM OJSC Rostelecom 9 - AS41691 20336 0.9% 726.3 -- SUMTEL-AS-RIPE Summa Telecom LLC 10 - AS60349 18872 0.9% 299.6 -- PBL-KIEV-AS Partners. Business Law Ltd. 11 - AS477518843 0.9% 254.6 -- GLOBE-TELECOM-AS Globe Telecoms 12 - AS815117333 0.8% 17.0 -- Uninet S.A. de C.V. 13 - AS59217 15379 0.7% 15379.0 -- AZONNELIMITED-AS-AP Azonne Limited 14 - AS647 13326 0.6% 115.9 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center 15 - AS28573 13323 0.6% 11.1 -- NET Serviços de Comunicação S.A. 16 - AS50710 12631 0.6% 60.4 -- EARTHLINK-AS EarthLink Ltd. CommunicationsInternet Services 17 - AS11976 12505 0.6% 211.9 -- FIDN - Fidelity Communication International Inc. 18 - AS11139 12429 0.6% 30.2 -- CWRIN CW BARBADOS 19 - AS18747 11627 0.5% 37.4 -- 20 - AS671310822 0.5% 23.5 -- IAM-AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS59217 15379 0.7% 15379.0 -- AZONNELIMITED-AS-AP Azonne Limited 2 - AS194063793 0.2%3793.0 -- TWRS-MA - Towerstream I, Inc. 3 - AS35181 44454 2.1%3704.5 -- PWC Autonomous System Number for Public WareHouse Company 4 - AS544656971 0.3%2323.7 -- QPM-AS-1 - QuickPlay Media Inc. 5 - AS129221952 0.1%1952.0 -- MULTITRADE-AS CEDACRI S.P.A. 6 - AS624311863 0.1%1863.0 -- NCSC-IE-AS National Cyber Security Centre 7 - AS6629 9039 0.4%1807.8 -- NOAA-AS - NOAA 8 - AS322445133 0.2%1711.0 -- LIQUID-WEB-INC - Liquid Web, Inc. 9 - AS142879914 0.5%1652.3 -- TRIAD-TELECOM - Triad Telecom, Inc. 10 - AS165613247 0.1%1623.5 -- ARIBANETWORK Ariba Inc. Autonomous System 11 - AS304374316 0.2%1438.7 -- GE-MS003 - General Electric Company 12 - AS441531146 0.1%1146.0 -- SHTE Shirak Technologies LLC 13 - AS573641089 0.1%1089.0 -- KMARUDA-AS OJSC Kombinat KMAruda 14 - AS7202 1977 0.1% 988.5 -- FAMU - Florida A M University 15 - AS24959 877 0.0% 877.0 -- LINJEGODS-AS Schenker AS 16 - AS525713499 0.2% 874.8 -- G2G COM PROD ELETRO E SERV LTDA 17 - AS51075 843 0.0% 843.0 -- WOLFF-PL WYDAWNICTWO MULTIMEDIALNE KOWALEWSKI I WOLFF SPOLKA CYWILNA PIOTR GLADKI KRZYSZTOF KOWALEWSKI MACIEJ MANSKI 18 - AS41691 20336 0.9% 726.3 -- SUMTEL-AS-RIPE Summa Telecom LLC 19 - AS23019 662 0.0% 662.0 -- BGP1-BOH - BANK OF HAWAII 20 - AS37546 650 0.0% 650.0 -- MIA-TELECOMs TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 85.239.28.0/2422575 1.0% AS35181 -- PWC Autonomous System Number for Public WareHouse Company 2 - 85.239.24.0/2421832 0.9% AS35181 -- PWC Autonomous System Number for Public WareHouse Company 3 - 109.161.64.0/20 20484 0.9% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 4 - 103.243.164.0/22 15379 0.7% AS59217 -- AZONNELIMITED-AS-AP Azonne Limited 5 - 89.221.206.0/24 11680 0.5% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 6 - 216.109.107.0/24 10451 0.5% AS11486 -- COLO-PREM-VZB - Verizon Online LLC AS16561 -- ARIBANETWORK Ariba Inc. Autonomous System 8 - 222.127.0.0/24 9195 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 9 - 192.58.232.0/249031 0.4% AS6629 -- NOAA-AS - NOAA 10 - 85.249.160.0/208297 0.4% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 11 - 205.247.12.0/247715 0.3% AS6459 -- TRANSBEAM - I-2000, Inc. 12 - 206.152.15.0/246951 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc. 13 - 67.210.190.0/236879 0.3% AS11976 -- FIDN - Fidelity Communication International Inc. 14 - 200.23.126.0/245809 0.2% AS8151 -- Uninet S.A. de C.V. 15 - 67.210.188.0/235415 0.2% AS11976 -- FIDN - Fidelity Communication International Inc.
You need a VLAN to the foot of NIST ITS services - no problem - we got you covered. Re: Need trusted NTP Sources
Raspberry Pi --- This unfortunately doest give you trusted time. It gives you David's Raspberry Pi with an Adafruit Ultimate GPS breakout board which is a waste of time if you need an evidence grade of time service. It also means you assemble it and run it yourself. If you need access to NTP - we can handle that --- As to how to get NTP into your networks - why screw around??? What do you need - your own VLAN into the back of the switch hosting the NIST ITS server... yeah no problem. Go to the source and join USTiming.ORG and use our landing switch to cross connect your network into a VLAN type management network bringing NIST ITS services to the perimeter of your network - poof - no DDoS, and hey you get to work with us to expand the availability of the services across the US so its a win-win. We have them spread out through the US under USTiming and are looking for more sites that are telco hotels in particular - so if you have space and want to host is in a balance-of-trade type deal let us know. Todd On 2/7/2014 12:32 PM, Anthony Williams wrote: With a quick and easy mod, another option for $35 is a Sure Electronics GPS board. GPS: http://www.sureelectronics.net/goods.php?id=99 Mod: http://www.satsignal.eu/ntp/Sure-GPS.htm -Alby On 2/7/2014 1:14 PM, Jared Mauch wrote: Having a number of NTP servers will help you detect false tickers which may be critical. If you want something that is cheap as in you for your home, I can recommend this: ~$350 w/ antenna, etc.. -- - Personal Email - Disclaimers Apply
Cogeco in the house?
If someone from Cogeco could ping me, I'd like to have a chat about something odd and intermittent: It works: BlackBox:~ jlixfeld$ mtr -c 1 -rw 162.243.142.155 Start: Fri Feb 7 18:46:06 2014 HOST: BlackBox.localLoss% Drop Rcv Snt Last Best Avg 1.|-- 192.168.69.1 0.0%0 1 1 4.0 4.0 4.0 2.|-- 96-45-207-217.beanfield.net0.0%0 1 1 9.3 9.3 9.3 3.|-- gi0-1-0-2.bfr01.77mowatav01.yyz.beanfield.com 0.0%0 1 1 9.9 9.9 9.9 4.|-- be2.bfr01.60hudsonst01.jfk.beanfield.com 0.0%0 1 1 20.8 20.8 20.8 5.|-- nyk-b3-link.telia.net 0.0%0 1 1 19.3 19.3 19.3 6.|-- nyk-bb1-link.telia.net 0.0%0 1 1 19.5 19.5 19.5 7.|-- sjo-bb1-link.telia.net 0.0%0 1 1 92.5 92.5 92.5 8.|-- digitalocean-ic-302451-sjo-bb1.c.telia.net 0.0%0 1 1 93.9 93.9 93.9 9.|-- 198.199.99.238 0.0%0 1 1 94.6 94.6 94.6 10.|-- streetscapeplus.com0.0%0 1 1 94.2 94.2 94.2 BlackBox:~ jlixfeld$ Now it doesn't: BlackBox:~ jlixfeld$ mtr -c 1 -r 162.243.142.155 Start: Fri Feb 7 18:42:54 2014 HOST: BlackBox.local Loss% Drop Rcv Snt Last Best Avg 1.|-- 192.168.69.1 0.0%0 1 1 4.2 4.2 4.2 2.|-- 96-45-207-217.beanfield.n 0.0%0 1 1 9.0 9.0 9.0 3.|-- gi0-1-0-2.bfr01.77mowatav 0.0%0 1 1 9.8 9.8 9.8 4.|-- te0-0-0-1.bfr01.151fronts 0.0%0 1 1 9.5 9.5 9.5 5.|-- gw-mto.torontointernetxch 0.0%0 1 1 9.0 9.0 9.0 6.|-- tge-1-1.ar1.mtrlpq07.coge 0.0%0 1 1 17.1 17.1 17.1 7.|-- 206.223.224.2250.0%0 1 1 16.8 16.8 16.8 8.|-- ??? 100.01 0 1 0.0 0.0 0.0 BlackBox:~ jlixfeld$ Thanks!
Re: SIP on FTTH systems
- Original Message - From: Mikael Abrahamsson swm...@swm.pp.se To the original poster. People using PPPoE for FTTH makes me sad. When someone suggests this, please just say go back to the drawingboard, redo it right. FWIW, when I dug this ground a couple Thanksgivings ago, I was looking at AE over home-run to an MDF; that was 12,000 or so passings in about 3 sqmi, muni. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: SIP on FTTH systems
On 2014-02-06 20:04, Mikael Abrahamsson wrote: No, you don't. It works perfectly well without direct port-to-port communication, you just have to align L3 configuration with this L2 behavior (which can be done in IPv6 but not in IPv4). IPv6 can be made to work without on-link /64, with only DHCPv6 IA_NA (optional) and only DHCPv6-PD. This means all communication goes via the router which then is perfectly aligned with how the L2 looks like with port isolation/private vlan. Yes, you are of course correct. I was thinking about selective filtering information between ports, but that is stupid/way too complex and most hardware cannot do that in a good way. I guess you still need proxy-ND or similar as described in RFC4389, and you don't accept clients with IP addresses not assigned over DHCPv6. Fair tradeoffs, SLAAC does not work with abuse etc. /Anders
Odd Cogentco routing?
Hello - While doing some traceroutes, I have found a few destinations that I found a little odd. For example: 5.|-- bbr01aldlmi-bue-2.aldl.mi.charter.com 0.0%60 152.1 47.2 8.3 367.6 66.0 6.|-- bbr01sgnwmi-bue-5.sgnw.mi.charter.com 0.0%60 102.3 53.4 15.6 317.9 66.3 7.|-- be4041.nr21.b016069-0.dtw04.atlas.cogentco.com 0.0%60 78.9 58.3 19.6 267.9 62.1 8.|-- te0-5-0-5.rcr21.dtw04.atlas.cogentco.com0.0%60 32.6 58.2 20.3 218.3 54.6 9.|-- te4-2.ccr01.tol01.atlas.cogentco.com0.0%60 359.6 95.2 21.4 359.6 84.5 10.|-- te0-5-0-1.ccr21.cle04.atlas.cogentco.com0.0%60 24.3 70.0 24.3 219.3 52.5 11.|-- te7-2.ccr01.buf02.atlas.cogentco.com0.0%60 29.3 89.9 28.8 245.4 66.0 12.|-- te7-2.ccr01.yhm01.atlas.cogentco.com0.0%60 117.6 105.0 30.6 467.8 87.7 13.|-- te0-7-0-34.ccr21.yyz02.atlas.cogentco.com 0.0%60 167.5 65.8 32.0 316.7 51.7 14.|-- level3.yyz02.atlas.cogentco.com15.0%60 132.0 91.2 47.6 326.1 57.9 15.|-- ae-13-13.bar1.Toronto1.Level3.net 61.7%60 62.4 107.9 49.5 282.7 73.0 16.|-- ae-9-9.ebr1.Chicago1.Level3.net 0.0%60 92.4 116.8 69.6 315.0 59.2 17.|-- ae-1-100.ebr2.Chicago1.Level3.net 1.7%60 92.3 127.7 71.2 370.1 62.1 18.|-- ae-3-3.ebr2.Atlanta2.Level3.net 0.0%60 74.6 125.5 70.7 261.0 50.3 19.|-- ae-2-52.edge4.Atlanta2.Level3.net 0.0%60 75.0 121.0 71.0 252.4 45.6 Detroit - Toledo - Cleveland - Buffalo - Hamilton, ON - Toronto - Chicago.. Is it odd that Cogentco is routing USA traffic to Canada and handing it off there to Level3 just to bring it back in to the USA? There is also some packetloss at the exchange... Thanks, David signature.asc Description: OpenPGP digital signature
Re: SIP on FTTH systems
Active-E and GPON AN's support split horizons where shared VLAN's allow for simple service delivery to the CPE, but do not permit inter-customer communications at Layer 2. Yes. All communications happens upstream at the BNG, which works for IPv4 and IPv6. And no, Proxy ARP is recommended for my competitors. If you're not my competitor, suggest you turn it off if you want happiness. So, as I wrote to Mikael, don't you need to use proxy-ARP or proxy-ND to get devices in same L2 domain to be able to communicate? They are on same subnet so they will ARP/ND for each other. The system specs. are impressive - basically, a little BNG in a switch, which I can't complain with. There is no rocket science here. Scripting in routers/switches seems to be more common, Cisco has TCL and some Nexus and Arista boxes do Python. There is only some hooks into the control/forwarding plane needed to do advanced services in access. Forwarding plane is covered mostly by SDN so half the work is done. In a 24/48 port access switch there are few clients, so scripting performance is not a problem. But, if I'm a business with a low start-up budget focused on broadband services, or lots of cash with no plans to break into the enterprise or service provider markets, the PacketFront make sense. My only concern would be NG-MVPN support - does the PacketFront have that? They working on all the MPLS stuff to be able to sell L2 and L3 VPN services. Well: - I support DHCP instead of PPPoE for subscriber management. - I support decentralized rather than centralized BNG's. - I support Active-E rather than GPON. These are all relatively less-than-popular scenarios based on many of the deployments I've seen in previous years. Agree, the above list is music in my ears :) /Anders
Re: SIP on FTTH systems
On 2014-02-07 07:14, Mikael Abrahamsson wrote: and for IPv6 it's easily solvable by not announcing an on-link network so they won't even try to communicate directly with each other but instead everything is routed via the ISP upstream router and then down again to the other customer CPE/computer. I'm curious on the details: 1) Do you give the client 64 bit using RA (with the A and L bit cleared), 64 bit using DHCPv6, then force the traffic through the default since on-link is not set? Has there been any test if modern operating systems honor this? (I've seen some firewalls doing this, not sure it was by design, they changed the default in later code) 2) Do you only use link-local on the customer port, and use a L3 CPE DHCP-PD? Always a learning experience reading Nanog /Anders
Re: SIP on FTTH systems
On Sat, 8 Feb 2014, Anders Löwinger wrote: I guess you still need proxy-ND or similar as described in RFC4389, and you don't accept clients with IP addresses not assigned over DHCPv6. Fair tradeoffs, SLAAC does not work with abuse etc. No, you don't need to do Proxy-ND either. With this solution there is no need for the users to talk directly to each other, even though they're sitting in the same vlan. They have no clue about each other and don't need to know because they will have a prefix delegated to their LL address and a default gateway, and perhaps an IA_NA if the ISP wants to, but that's it. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Need trusted NTP Sources
On Fri, Feb 07, 2014 at 03:32:22PM -0500, Anthony Williams wrote: With a quick and easy mod, another option for $35 is a Sure Electronics GPS board. GPS: http://www.sureelectronics.net/goods.php?id=99 Mod: http://www.satsignal.eu/ntp/Sure-GPS.htm -Alby On 2/7/2014 1:14 PM, Jared Mauch wrote: Having a number of NTP servers will help you detect false tickers which may be critical. If you want something that is cheap as in you for your home, I can recommend this: ~$350 w/ antenna, etc.. The SureGPS is decent fun but i've had this device lose sync / crap out randomly as well. I am using the Garmin 18X-LVC + a low power server with pretty good success. (Requires PPS soldering + USB pigtail for power, pretty easy mod) [seitz@ntp-gps ~]$ ntpq -p remote refid st t when poll reach delay offset jitter == clock.fmt.he.ne .CDMA. 1 u 53 64 377 76.6920.976 0.291 time-a.timefreq .ACTS. 1 u 39 64 377 48.140 -0.896 0.348 time-b.timefreq .ACTS. 1 u 56 64 377 48.800 -0.986 0.430 time-b.nist.gov .ACTS. 1 u 48 64 3777.3333.630 0.562 oGPS_NMEA(1) .PPS.0 l4 16 3770.0000.002 0.000 * GPS is on a http://us.shuttle.com/barebone/Models/XS36VL.html - chosen for the dual external serial ports. -- Bryan G. Seitz
Re: SIP on FTTH systems
On Sat, 8 Feb 2014, Anders Löwinger wrote: I'm curious on the details: 1) Do you give the client 64 bit using RA (with the A and L bit cleared), 64 bit using DHCPv6, then force the traffic through the default since on-link is not set? Correct. Has there been any test if modern operating systems honor this? Well, they would be defective if they didn't. Also, you don't even need to announce the prefix at all, even with L-bit cleared. You can make RAs with M and O bit set that won't contain any prefix at all. Been there, done that. At least linux worked perfectly. Do you only use link-local on the customer port, and use a L3 CPE DHCP-PD? That's one way of doing it, or you give it an IA_NA as well if you want a WAN address. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: NANOG Digest, Vol 73, Issue 42
. I'm waiting on the RFO so I can further investigate why this happened. I think someone mentioned this in a post a few months ago too. -- Vlade Ristevski Network Manager IT Services Ramapo College (201)-684-6854 -- Message: 4 Date: Fri, 7 Feb 2014 14:49:09 + (GMT) From: Faisal Imtiaz fai...@snappytelecom.net To: Olivier Benghozi olivier.bengh...@wifirst.fr Cc: nanog@nanog.org Subject: Re: carrier comparison Message-ID: 693349979.661671.1391784549000.javamail.r...@snappytelecom.net Content-Type: text/plain; charset=utf-8 Based on my understanding on BFD, it will not help you... BFD will detect the direct connected port being down quicker and force the BGP session down, (faster than the time BGP session timers take to determine something is broken) This is the common issue / challenge in how to determine up-stream path outage and then doing appropriate route engineering on an automatic basis. Maybe a SLA monitor type scripting/configuration be useful in your case. Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net - Original Message - From: Olivier Benghozi olivier.bengh...@wifirst.fr To: nanog@nanog.org Sent: Friday, February 7, 2014 5:25:53 AM Subject: Re: carrier comparison Hi Faisal, You might have to deploy some other means of (script ?) to bring your BGP session down from the 'broken' Service Provider. To the best of my knowledge, BGP does not have any mechanism to determine broken connectivity upstream past the router you are BGP session is up with. Well, technically there's BFD that might do the trick. But of course it won't be available; it's not usually, so specially with Cogent... :) But maybe its link was just overloaded in fact. -- Olivier -- Message: 5 Date: Fri, 7 Feb 2014 17:20:08 +0200 From: Mark Tinka mark.ti...@seacom.mu To: nanog@nanog.org Subject: Re: SIP on FTTH systems Message-ID: 201402071720.12145.mark.ti...@seacom.mu Content-Type: text/plain; charset=us-ascii On Friday, February 07, 2014 03:30:08 PM Frank Bulk wrote: Rather than assign residential and business customers their own /30, to conserve space we give those customers a /32 out of a /24. But when one of these static IP customers wants to send email to another, or the employee wants to VPN into work, they can't. This is akin to Private VLAN's where ports in a shared VLAN are assigned numbers from the same subnet, but they can only communicate via the BNG rather than directly at the bridge level. I prefer EVC Split Horizon to Private VLAN's, though. Mark. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: http://mailman.nanog.org/pipermail/nanog/attachments/20140207/be185b23/attachment-0001.bin -- Message: 6 Date: Fri, 7 Feb 2014 17:21:46 +0200 From: Mark Tinka mark.ti...@seacom.mu To: nanog@nanog.org Subject: Re: carrier comparison Message-ID: 201402071721.47057.mark.ti...@seacom.mu Content-Type: text/plain; charset=us-ascii On Friday, February 07, 2014 04:49:09 PM Faisal Imtiaz wrote: Based on my understanding on BFD, it will not help you... BFD will detect the direct connected port being down quicker and force the BGP session down, (faster than the time BGP session timers take to determine something is broken) You would also need your provider to support BFD (and by support I mostly mean willing to run, as modern gear today is technically capable). Mark. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: http://mailman.nanog.org/pipermail/nanog/attachments/20140207/b2db7fc3/attachment-0001.bin -- Message: 7 Date: Fri, 07 Feb 2014 07:23:22 -0800 From: Roy r.engehau...@gmail.com To: nanog@nanog.org Subject: Re: Need trusted NTP Sources Message-ID: 52f4fa6a.60...@gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 2/7/2014 3:35 AM, Saku Ytti wrote: On (2014-02-06 21:14 -0500), Jay Ashworth wrote: My usual practice is to set up two in house servers, each of which talks to: And then point everyone in house to both of them, assuming they accept multiple server names. Two is worst possible amount of NTP servers to have. Either one fails and your timing is wrong, because you cannot vote false ticker. And chance of either of two failing is higher than one specific of them. A man with a watch knows what time it is. A man with two watches is never sure
GEO location issue with google
Hi, We are an ISP based in UK. We have got an ip block from RIPE which is 5.250.176.0/20. All the main search engines like yahoo shows we are based in UK. But Google thinks we are from Saudi Arabia and we redirected to www.google.com.sahttp://www.google.com.sa instead of googlw.co.uk. I have sent lot of emails to google but no luck. All the information from google are in Arabic and youtube shows some weird videos as well. Could anyone please help me to sort this out? Would be much appreciated for your time. Praveen Unnikrishnan Network Engineer PMGC Technology Group Ltd T: 020 3542 6401 M: 07827921390 F: 087 1813 1467 E: p...@pmgroupuk.commailto:p...@pmgroupuk.com [cid:image001.png@01CF2418.27F29CA0] [cid:image002.jpg@01CE1663.96B300D0] www.pmgroupuk.comhttp://www.pmgroupuk.com/ | www.pmgchosting.com http://www.pmgchosting.com/ How am I doing? Contact my manager, click heremailto:sha...@pmgroupuk.com?subject=How's%20Praveen%20doing?. [cid:image003.jpg@01CE1663.96B300D0] PMGC Managed Hosting is now live! After a successful 2012, PMGC continues to innovate and develop by offering tailored IT solutions designed to empower you through intelligent use of technologies. www.pmgchosting.comhttp://www.pmgchosting.com/. PMGC Technology Group Limited is a company registered in England and Wales. Registered number: 7974624 (3/F Sutherland House, 5-6 Argyll Street, London. W1F 7TE). This message contains confidential (and potentially legally privileged) information solely for its intended recipients. Others may not distribute copy or use it. If you have received this communication in error please contact the sender as soon as possible and delete the email and any attachments without keeping copies. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company or its associated companies unless otherwise specifically stated. All incoming and outgoing e-mails may be monitored in line with current legislation. It is the responsibility of the recipient to ensure that emails are virus free before opening. PMGC(r) is a registered trademark of PMGC Technology Group Ltd. inline: image001.pnginline: image002.jpginline: image003.jpg
Re: GEO location issue with google
Here's the FAQ on this topic: https://support.google.com/websearch/answer/873?hl=en It links to a contact form where you can ask for some redress. Cheers, jof On Fri, Feb 7, 2014 at 7:20 AM, Praveen Unnikrishnan p...@pmgroupuk.comwrote: Hi, We are an ISP based in UK. We have got an ip block from RIPE which is 5.250.176.0/20. All the main search engines like yahoo shows we are based in UK. But Google thinks we are from Saudi Arabia and we redirected to www.google.com.sahttp://www.google.com.sa instead of googlw.co.uk. I have sent lot of emails to google but no luck. All the information from google are in Arabic and youtube shows some weird videos as well. Could anyone please help me to sort this out? Would be much appreciated for your time. Praveen Unnikrishnan Network Engineer PMGC Technology Group Ltd T: 020 3542 6401 M: 07827921390 F: 087 1813 1467 E: p...@pmgroupuk.commailto:p...@pmgroupuk.com [cid:image001.png@01CF2418.27F29CA0] [cid:image002.jpg@01CE1663.96B300D0] www.pmgroupuk.comhttp://www.pmgroupuk.com/ | www.pmgchosting.com http://www.pmgchosting.com/ How am I doing? Contact my manager, click heremailto:sha...@pmgroupuk.com ?subject=How's%20Praveen%20doing?. [cid:image003.jpg@01CE1663.96B300D0] PMGC Managed Hosting is now live! After a successful 2012, PMGC continues to innovate and develop by offering tailored IT solutions designed to empower you through intelligent use of technologies. www.pmgchosting.com http://www.pmgchosting.com/. PMGC Technology Group Limited is a company registered in England and Wales. Registered number: 7974624 (3/F Sutherland House, 5-6 Argyll Street, London. W1F 7TE). This message contains confidential (and potentially legally privileged) information solely for its intended recipients. Others may not distribute copy or use it. If you have received this communication in error please contact the sender as soon as possible and delete the email and any attachments without keeping copies. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company or its associated companies unless otherwise specifically stated. All incoming and outgoing e-mails may be monitored in line with current legislation. It is the responsibility of the recipient to ensure that emails are virus free before opening. PMGC(r) is a registered trademark of PMGC Technology Group Ltd.
Re: SIP on FTTH systems
On Saturday, February 08, 2014 04:41:55 AM Anders Löwinger wrote: So, as I wrote to Mikael, don't you need to use proxy-ARP or proxy-ND to get devices in same L2 domain to be able to communicate? They are on same subnet so they will ARP/ND for each other. No, you don't, and you don't want to either. You customers will have visibility to one another at Layer 2 if you don't enable Split Horizon, MAC-FF, Private VLAN's, or whatever implementation your favorite vendor uses to prevent inter-communication between customers in a shared VLAN at the AN/bridge level. While it seems sensible, it normally isn't a good idea. The majority of what will take place between customers at Layer 2 is dirt. Best to run them through a Layer 3 device upstream and apply appropriate filtering. There is no rocket science here. Scripting in routers/switches seems to be more common, Cisco has TCL and some Nexus and Arista boxes do Python. There is only some hooks into the control/forwarding plane needed to do advanced services in access. Forwarding plane is covered mostly by SDN so half the work is done. In a 24/48 port access switch there are few clients, so scripting performance is not a problem. I'm more impressed by the braveness of this implementation, than the actual implementation itself, I mean. In our case, given the number of customers in question that would terminate on a BNG (be it a small switch or big router), long term control plane performance is a huge concern, as well as how the hardware handles Multicast and other corner-case services in various topologies. Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On Saturday, February 08, 2014 06:38:29 AM Mikael Abrahamsson wrote: That's one way of doing it, or you give it an IA_NA as well if you want a WAN address. We prefer DHCP_IA_NA to ND/RA. But yes, either option works. Just depends on operator choice as well as BNG and CPE support. Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On Sat, 8 Feb 2014, Mark Tinka wrote: On Saturday, February 08, 2014 06:38:29 AM Mikael Abrahamsson wrote: That's one way of doing it, or you give it an IA_NA as well if you want a WAN address. We prefer DHCP_IA_NA to ND/RA. I have never heard anyone refer to SLAAC as IA_NA. I meant the DHCP kind. When saying IA_NA and IA_PD, you should take for granted people mean DHCP. -- Mikael Abrahamssonemail: swm...@swm.pp.se
