Re: SIP on FTTH systems
On Thursday, February 06, 2014 09:19:59 AM Måns Nilsson wrote: Or, one could make sure everything has a globally unique IP address and is using reasonably secured communications. The downside is that one then can't defend the existence of those empire-building middleboxes. It is not the telco way, so is of course unthinkable. Like anything beyond WAP was on cell phones a decade ago. There are, typically, three topology models for modern FTTH (wireline, really) networks that a service provider could deploy: 1. SVLAN N:1 model 2. CVLAN 1:1 model 3. Hybrid of both The SVLAN (N:1) model is simple; just have a single VLAN for each service (VLAN 10 for Internet/Unicast, VLAN 20 for VoIP, VLAN 30 for IPTv/Multicast). This is simple and easy to scale, but if one is using relatively dumb AN's (like GPON's or MSAN's), it can be difficult to control how much bandwidth customers need, and how they can roam between services in the home (given CPE ties services to ports). The CVLAN (1:1) model is good for identifying services and bandwidth requirements on a per-customer basis. The main problem with this model is that Multicast traffic gets treated like Unicast, because each customer has a unique VLAN for themselves, and as such, the upstream PE router ends up having to replicate the same linear video stream as many times as there are customers down the line. The Hybrid model, where CVLAN's are used for all Unicast traffic (Internet, VoIP and VoD, typically), and a single SVLAN is used for all customers to handle Multicast traffic (so-called MVLAN). The challenge here is if you're the type of operator that likes to have a consistent set of address per VLAN, it can become a little tricky if your VoIP service is a walled-garden running on private IP space, given it shares the same VLAN as Internet and VoD which would normally run on public IP space. The N:1 SVLAN model is quite simple and scalable for wholesale FTTH services. There is product from some vendors, now, that is built with FTTH in mind. 1U, dense switches (Active-E) that support (reasonably) proper QoS and bandwidth management controls on customer- and core-facing ports, at Layer 2. So that offers you a lot more capability at the AN, and you can manage bandwidth as close to the customer as possible, unlike typical GPON deployments which may not have these features, leaving you to apply bandwidth policy at the PE router - much too far up the line. These new products can also support split horizons across bridge domains (which GPON's and DSLAM's do today), meaning that customers can use the same SVLAN's, but can only communicate via the upstream router (Layer 3), eliminating risk associated with Layer 2 visibility between customers connected to the same bridge domain. Cheers, Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
Time for users to consider splitting L2 services from IP ? Christian de Larrinaga On 6 Feb 2014, at 08:01, Mark Tinka mark.ti...@seacom.mu wrote: On Thursday, February 06, 2014 09:19:59 AM Måns Nilsson wrote: Or, one could make sure everything has a globally unique IP address and is using reasonably secured communications. The downside is that one then can't defend the existence of those empire-building middleboxes. It is not the telco way, so is of course unthinkable. Like anything beyond WAP was on cell phones a decade ago. There are, typically, three topology models for modern FTTH (wireline, really) networks that a service provider could deploy: 1. SVLAN N:1 model 2. CVLAN 1:1 model 3. Hybrid of both The SVLAN (N:1) model is simple; just have a single VLAN for each service (VLAN 10 for Internet/Unicast, VLAN 20 for VoIP, VLAN 30 for IPTv/Multicast). This is simple and easy to scale, but if one is using relatively dumb AN's (like GPON's or MSAN's), it can be difficult to control how much bandwidth customers need, and how they can roam between services in the home (given CPE ties services to ports). The CVLAN (1:1) model is good for identifying services and bandwidth requirements on a per-customer basis. The main problem with this model is that Multicast traffic gets treated like Unicast, because each customer has a unique VLAN for themselves, and as such, the upstream PE router ends up having to replicate the same linear video stream as many times as there are customers down the line. The Hybrid model, where CVLAN's are used for all Unicast traffic (Internet, VoIP and VoD, typically), and a single SVLAN is used for all customers to handle Multicast traffic (so-called MVLAN). The challenge here is if you're the type of operator that likes to have a consistent set of address per VLAN, it can become a little tricky if your VoIP service is a walled-garden running on private IP space, given it shares the same VLAN as Internet and VoD which would normally run on public IP space. The N:1 SVLAN model is quite simple and scalable for wholesale FTTH services. There is product from some vendors, now, that is built with FTTH in mind. 1U, dense switches (Active-E) that support (reasonably) proper QoS and bandwidth management controls on customer- and core-facing ports, at Layer 2. So that offers you a lot more capability at the AN, and you can manage bandwidth as close to the customer as possible, unlike typical GPON deployments which may not have these features, leaving you to apply bandwidth policy at the PE router - much too far up the line. These new products can also support split horizons across bridge domains (which GPON's and DSLAM's do today), meaning that customers can use the same SVLAN's, but can only communicate via the upstream router (Layer 3), eliminating risk associated with Layer 2 visibility between customers connected to the same bridge domain. Cheers, Mark.
Need trusted NTP Sources
Hi ! I'm trying to help a company I work for to pass an audit, and we've been told we need trusted NTP sources (RedHat doesn't cut it). Being located in Nigeria, Africa, I'm not very knowledgeable about trusted sources therein. Please can anyone help with sources that wouldn't mind letting us sync from them? Thanks a lot!
Re: Need trusted NTP Sources
www.pool.ntp.org Oorspronkelijk bericht Van: Notify Me notify.s...@gmail.com Datum: Aan: nanog@nanog.org list nanog@nanog.org,af...@afnog.org Onderwerp: Need trusted NTP Sources Hi ! I'm trying to help a company I work for to pass an audit, and we've been told we need trusted NTP sources (RedHat doesn't cut it). Being located in Nigeria, Africa, I'm not very knowledgeable about trusted sources therein. Please can anyone help with sources that wouldn't mind letting us sync from them? Thanks a lot!
Re: Need trusted NTP Sources
On 06/02/2014 10:03, Notify Me wrote: I'm trying to help a company I work for to pass an audit, and we've been told we need trusted NTP sources (RedHat doesn't cut it). So presuming that your company is using RH or Fedora or CentOS something, the auditors are claiming that Red Hat, Inc is trusted enough to provide a precompiled based operating system with no feasible means of proving its reliability, but that they're not trustworthy enough to provide a clock synchronisation service? My head spins. Get new auditors. Your current ones are stupid. Nick
Re: SIP on FTTH systems
On Thursday, February 06, 2014 11:56:45 AM cdel.firsthand.net wrote: Time for users to consider splitting L2 services from IP ? But consumer broadband is all about IP; the Layer 2 is needed to transport that IP, and that's a network problem, not a user one. Mark. signature.asc Description: This is a digitally signed message part.
Re: Need trusted NTP Sources
We're a redhat shop, and we use redhat auth which by default uses redhat NTP sources. Sounds odd to me too. They claim this is what PCI DSS demands. On Feb 6, 2014 11:43 AM, Nick Hilliard n...@foobar.org wrote: On 06/02/2014 10:03, Notify Me wrote: I'm trying to help a company I work for to pass an audit, and we've been told we need trusted NTP sources (RedHat doesn't cut it). So presuming that your company is using RH or Fedora or CentOS something, the auditors are claiming that Red Hat, Inc is trusted enough to provide a precompiled based operating system with no feasible means of proving its reliability, but that they're not trustworthy enough to provide a clock synchronisation service? My head spins. Get new auditors. Your current ones are stupid. Nick
Re: Need trusted NTP Sources
According to the auditors, trusted means 1. Universities or Research facilities (nuclear/atomic facilities, space research (such as NASA) etc.) 2. Main country internet/telecom providers 3. Government departments 4. Satellites (using GPS module) Which is a bit of a tall order over here. On Thu, Feb 6, 2014 at 11:16 AM, Marc Storck msto...@voipgate.com wrote: You may start by checking who is providing NTP services in Africa via the NTP pool. In Africa there are 27 public servers (http://www.pool.ntp.org/zone/africa). But then all depends on your definition of trusted. Regards, Marc From: Notify Me [notify.s...@gmail.com] Sent: Thursday, February 06, 2014 11:03 To: nanog@nanog.org list; af...@afnog.org Subject: Need trusted NTP Sources Hi ! I'm trying to help a company I work for to pass an audit, and we've been told we need trusted NTP sources (RedHat doesn't cut it). Being located in Nigeria, Africa, I'm not very knowledgeable about trusted sources therein. Please can anyone help with sources that wouldn't mind letting us sync from them? Thanks a lot!
Re: Need trusted NTP Sources
On 06/02/2014 11:46, Notify Me wrote: We're a redhat shop, and we use redhat auth which by default uses redhat NTP sources. Sounds odd to me too. They claim this is what PCI DSS demands. PCI DSS states: 10.4.3 Time settings are received from industry-accepted time sources. The default RHEL time servers are defined as X.rhel.ntp.org. Many people would consider ntp.org as industry-accepted, and there are several PCI-DSS auditing companies out there who explicitly recommend using pool.ntp.org for this purpose. If that's not good enough, the PCI DSS standards explicitly state in the NTP interpretation section: More information on NTP can be found at www.ntp.org, including information about time, time standards, and servers. So, if PCI themselves view ntp.org as being authoritative about NTP I can't see any reason why the time servers they publish wouldn't pass an audit. Nick
Re: Need trusted NTP Sources
GPS time sources are pretty cheap ( US$500) and easy to set up nowadays. You could probably build your own for less that US$100: http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html Aled On 6 February 2014 11:51, Notify Me notify.s...@gmail.com wrote: According to the auditors, trusted means 1. Universities or Research facilities (nuclear/atomic facilities, space research (such as NASA) etc.) 2. Main country internet/telecom providers 3. Government departments 4. Satellites (using GPS module) Which is a bit of a tall order over here. On Thu, Feb 6, 2014 at 11:16 AM, Marc Storck msto...@voipgate.com wrote: You may start by checking who is providing NTP services in Africa via the NTP pool. In Africa there are 27 public servers ( http://www.pool.ntp.org/zone/africa). But then all depends on your definition of trusted. Regards, Marc From: Notify Me [notify.s...@gmail.com] Sent: Thursday, February 06, 2014 11:03 To: nanog@nanog.org list; af...@afnog.org Subject: Need trusted NTP Sources Hi ! I'm trying to help a company I work for to pass an audit, and we've been told we need trusted NTP sources (RedHat doesn't cut it). Being located in Nigeria, Africa, I'm not very knowledgeable about trusted sources therein. Please can anyone help with sources that wouldn't mind letting us sync from them? Thanks a lot!
Re: SIP on FTTH systems
On Thu, 6 Feb 2014, Mark Tinka wrote: There are, typically, three topology models for modern FTTH (wireline, really) networks that a service provider could deploy: 1. SVLAN N:1 model 2. CVLAN 1:1 model 3. Hybrid of both There are more. There are models where each ISP gets its own customer vlan and L2 equipment do inspection of ARP/ND and does security filtering on L2/L3 using this information. There are also L3 networks where the traffic is source-routed out to the correct ISP, or each ISP gets its own VRF in the equipment and it's VRF a long way out. 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. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: SIP on FTTH systems
On Thursday, February 06, 2014 02:15:57 PM Mikael Abrahamsson wrote: There are more. There are models where each ISP gets its own customer vlan and L2 equipment do inspection of ARP/ND and does security filtering on L2/L3 using this information. There are also L3 networks where the traffic is source-routed out to the correct ISP, or each ISP gets its own VRF in the equipment and it's VRF a long way out. Agree. The models I listed are typical to an operator that runs its own infrastructure (including the FTTH last mile), and does not necessarily wholesale out to other operators. I've seen certain countries that have given the incumbents leeway to wholesale at the IP level, which the incumbent likes because they perceive more control than if they had to hand-off Layer 2 wholesale. In such cases, VRF's and/or logical routers have been deployed. 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. Agree. DHCP really is the way to go, now. Plus, there is good support for IPv6 with vendors today re: DHCP-based subscriber management. Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On Thu, 6 Feb 2014, Mark Tinka wrote: The models I listed are typical to an operator that runs its own infrastructure (including the FTTH last mile), and does not necessarily wholesale out to other operators. I disagree on that one as well. It might be in some markets, but it's not in all. I've seen certain countries that have given the incumbents leeway to wholesale at the IP level, which the incumbent likes because they perceive more control than if they had to hand-off Layer 2 wholesale. In such cases, VRF's and/or logical routers have been deployed. This wasn't incumbents specifically, but just a different model to achieve the same thing, give end users access to multiple ISPs, multiple cable TV vendors, and multiple VOIP providers through a neutral network. Agree. DHCP really is the way to go, now. Plus, there is good support for IPv6 with vendors today re: DHCP-based subscriber management. What do you mean by subscriber management? This worked 10 years ago, what problem are you saying has been solved recently? -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: Need trusted NTP Sources
I'm trying to help a company I work for to pass an audit, and we've been told we need trusted NTP sources (RedHat doesn't cut it). Being located in Nigeria, Africa, I'm not very knowledgeable about trusted sources therein. Please can anyone help with sources that wouldn't mind letting us sync from them? given that you trust the US-government (well, ...) you might use your own stratum 1 server using a Raspberry Pi with GPS. here is a well done how-to: http://open.konspyre.org/blog/2012/10/18/raspberry-pi-time-server/ I still need some spare time to get it running, all parts are here, but within my office location I have a bad GPS signal reception, so I have to do it at home. So build your own stratum 1 server (maybe a second one with DCF77 or whatever you can use for redundancy), off from these servers build 2 or more stratum 2 timeservers for redistribution to offload your stratum 1 servers. http://clepsydratime.com/Products/Time-Server-NTS3000 is a cool alternative. They are located in Poland, IIRC. And this box sells for less than 2,000 euros (this price is 2 years old). And it gives you GPS (USA), Glonass (Russia) and DCF77 (land based). One of the best Timeservers are sold by meinberg.de just my 2 euro-cents. #m
Re: Need trusted NTP Sources
On 6 February 2014 12:30, Martin Hotze m.ho...@hotze.com wrote: I'm trying to help a company I work for to pass an audit, and we've been told we need trusted NTP sources (RedHat doesn't cut it). Being located in Nigeria, Africa, [...] So build your own stratum 1 server (maybe a second one with DCF77 or whatever you can use for redundancy), I don't think DCF77 is going to reach Nigeria. Aled
Re: SIP on FTTH systems
On Thursday, February 06, 2014 02:29:40 PM Mikael Abrahamsson wrote: I disagree on that one as well. It might be in some markets, but it's not in all. I keep using the word typical, but not sure if you're missing it. Typical, not limited to, i.e., common, but not the only option. I'm basing this on what I've seen in various countries across a few continents I've worked in. This wasn't incumbents specifically, but just a different model to achieve the same thing, give end users access to multiple ISPs, multiple cable TV vendors, and multiple VOIP providers through a neutral network. Again, just an example I gave, not to say it was the norm. The countries I was referring to is where the incumbents either owned the infrastructure and were reluctant to open it up to competitors, or were awarded national broadband projects to deploy and run the infrastructure but were not specifically governed to how low the OSI Layer they can open up the infrastructure to. In other places, it is a business model, in addition to more traditional ways of unbundling. These tend to be more evolved markets, but again, not limited to. What do you mean by subscriber management? This worked 10 years ago, what problem are you saying has been solved recently? End user authentication and management typically being done via PPPoE because that was the best and most secure way to manage customer connections (for some operators, still is). By DHCP I mean an alternative to PPPoE-based authentication where Option 82 and friends can allow service providers to authenticate customers based on AN port, MAC address, VLAN ID, e.t.c., instead of username/password a la PPPoE. This gets passed as part of initial DHCP transactions. Rethinking your comment (because I thought you meant DHCP as the way to go for subscriber management when you debunked PPPoE) I'm guessing you refer to simply assigning IP addresses to customer interfaces in FTTH scenarios? No? Mark. signature.asc Description: This is a digitally signed message part.
Re: Need trusted NTP Sources
On 06/02/2014 12:30, Martin Hotze wrote: here is a well done how-to: http://open.konspyre.org/blog/2012/10/18/raspberry-pi-time-server/ The OP had a question about standards compliance, not about something that made technical sense and would deliver a superior service. The two things aren't incompatible, but they're not especially closely related either. Nick
Re: Need trusted NTP Sources
Raspberries! Not common currency here either, but let's see! grateful for all the input and responses, this list is amazing as usual. On Thu, Feb 6, 2014 at 1:41 PM, Aled Morris al...@qix.co.uk wrote: On 6 February 2014 12:30, Martin Hotze m.ho...@hotze.com wrote: I'm trying to help a company I work for to pass an audit, and we've been told we need trusted NTP sources (RedHat doesn't cut it). Being located in Nigeria, Africa, [...] So build your own stratum 1 server (maybe a second one with DCF77 or whatever you can use for redundancy), I don't think DCF77 is going to reach Nigeria. Aled
Re: SIP on FTTH systems
On Thu, 6 Feb 2014, Mark Tinka wrote: End user authentication and management typically being done via PPPoE because that was the best and most secure way to manage customer connections (for some operators, still is). Why do you need to authenticate the customer? Don't your documentation system know the port/subscriber mapping? And why is this secure, instead of being tied to a physical connection the customer can now take the credentials and move? If the credentials are stolen, someone else can impersonate that customer. By DHCP I mean an alternative to PPPoE-based authentication where Option 82 and friends can allow service providers to authenticate customers based on AN port, MAC address, VLAN ID, e.t.c., instead of username/password a la PPPoE. This gets passed as part of initial DHCP transactions. This worked 10 years ago, it's nothing recent. Rethinking your comment (because I thought you meant DHCP as the way to go for subscriber management when you debunked PPPoE) I'm guessing you refer to simply assigning IP addresses to customer interfaces in FTTH scenarios? No? Yes? Since option 82 and friends gives you what port the DHCP request came in on, you now log IP/MAC connected to a port, and since you know to what apartment/house this port is physically connected to, nothing more is needed. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
Don't fight it. It's clear that implementation on a per-packet basis of RFC4824 (datagrams over Semaphore Flag Signaling System) would have prevented this entire situation. Refer to sections 3.3 and 3.4. -j On Mon, Feb 3, 2014 at 12:23 PM, Paul Ferguson fergdawgs...@mykolab.com wrote: On 2/2/2014 2:17 PM, Cb B wrote: And, i agree bcp38 would help but that was published 14 years ago. But what? Are you somehow implying that because BCP38 was ...published 14 years ago (RFC2267 was initially published in 1998, and it was subsequently replaced by RFC2827)?
Re: SIP on FTTH systems
On Thursday, February 06, 2014 02:58:14 PM Mikael Abrahamsson wrote: Why do you need to authenticate the customer? Don't your documentation system know the port/subscriber mapping? And why is this secure, instead of being tied to a physical connection the customer can now take the credentials and move? If the credentials are stolen, someone else can impersonate that customer. Which is why I said DHCP was better than PPPoE. Failing to see where we disagree. This worked 10 years ago, it's nothing recent. In my previous post, I didn't say it was recent. I said it was better than PPPoE if you're deploying FTTH now. What I said was recent was that DHCP_IA and DHCP_IA_PD implementation has improved significantly both in BNG's as well as CPE. Again, failing to see where we disagree. Yes? Since option 82 and friends gives you what port the DHCP request came in on, you now log IP/MAC connected to a port, and since you know to what apartment/house this port is physically connected to, nothing more is needed. Again, don't see where we disagree. This is a good thing. Some operators provide services with no subscriber management (i.e., no PPPoE, no DHCP; just a static IP address documented about where it is, what street, what building, what floor, what apartment, what customer), while other service providers have a subscriber management technique, PPPoE or DHCP, to log all the same information in concert with the backend. I'm just saying DHCP is better than PPPoE if you're greenfielding FTTH deployments today, and I'm not sure you entirely disagree. Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On Thu, 6 Feb 2014, Mark Tinka wrote: I'm just saying DHCP is better than PPPoE if you're greenfielding FTTH deployments today, and I'm not sure you entirely disagree. We're in violent agreement it seems. My only beef was that it seemed like you were implying this was something new. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: SIP on FTTH systems
On 2014-02-06 09:01, Mark Tinka wrote: 1. SVLAN N:1 model The SVLAN (N:1) model is simple; just have a single VLAN for each service (VLAN 10 for Internet/Unicast, VLAN 20 for VoIP, VLAN 30 for IPTv/Multicast). This is a deep hole, and basically does not work with IPv6. You need a bunch of stuff, proxy ND, proxy DAD, DHCPv6 inspection, RA guard and more. One VLAN per customer and a separate multicast is much simpler. Or do something bold, run L3 at the edge :) /Anders
Re: SIP on FTTH systems
On Thursday, February 06, 2014 03:46:54 PM Mikael Abrahamsson wrote: We're in violent agreement it seems. Tend to agree. My only beef was that it seemed like you were implying this was something new. In most of my travels, there is a healthy amount of resistance toward DHCP from new (but mostly, existing) broadband service providers when choosing between DHCP and PPPoE for Unicast traffic. And the reasons for this vary - we saw the OP is PPPoE-biased, for example. It is better in 2014 than it was in 2011 in those places, but by and large, DHCP adoption for subscriber management is not moving as quickly as one would think, especially when you consider all the FTTH work going on around the world. Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On Thursday, February 06, 2014 03:51:51 PM Anders Löwinger wrote: This is a deep hole, and basically does not work with IPv6. You need a bunch of stuff, proxy ND, proxy DAD, DHCPv6 inspection, RA guard and more. One VLAN per customer and a separate multicast is much simpler. If you have a reasonably intelligent AN (like some of today's Active-E devices), you can create so-called split horizons on the same bridge domain (VLAN, really) where customers will only communicate via the upstream BNG at Layer 3. At Layer 2, even though they are all sitting on the same VLAN, there is no inter-communication between them. I've also know Huawei OLT's support these split horizons too. Or do something bold, run L3 at the edge :) BNG's are too big to distributed that deeply, even in distributed BNG designs. This would get costly. Cheap switches that have decent IP/MPLS support are mostly geared toward Metro-E deployments, i.e., business-grade services. So they are quite poor with regard to susbcriber management features and capabilities. Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On Thu, 6 Feb 2014, Mark Tinka wrote: Or do something bold, run L3 at the edge :) BNG's are too big to distributed that deeply, even in distributed BNG designs. This would get costly. You don't need a BNG. You need an L3 switch as the first hop the customer is talking to. Cheap switches that have decent IP/MPLS support are mostly geared toward Metro-E deployments, i.e., business-grade services. So they are quite poor with regard to susbcriber management features and capabilities. If you have L3-in-vlan-per-customer at the first hop then you don't really need all of that. If you include rudimentary VRF support then you can even support wholesale. /64 per customer, DHCPv6(-PD) server support in the L3 switch and you're good to go. There is equipment that already claim to do this (I never got to test their implementation based on my requirements because I switched jobs, but they claimed to have implemented everything last year). -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Need trusted NTP Sources
PCI DSS only requires that all clocks be synchronized; It doesn't /require/ how. If you have servers getting time from external sources (authenticated always a plus) and peering with each other internally, then you comply with PCI DSS 2.0 (3.0 has no changes to this that I'm aware of). OTOH, I'm surprised nobody has mentioned http://www.team-cymru.org/ReadingRoom/Templates/secure-ntp-template.html -j On Thu, Feb 6, 2014 at 6:53 AM, Notify Me notify.s...@gmail.com wrote: Raspberries! Not common currency here either, but let's see! grateful for all the input and responses, this list is amazing as usual. On Thu, Feb 6, 2014 at 1:41 PM, Aled Morris al...@qix.co.uk wrote: On 6 February 2014 12:30, Martin Hotze m.ho...@hotze.com wrote: I'm trying to help a company I work for to pass an audit, and we've been told we need trusted NTP sources (RedHat doesn't cut it). Being located in Nigeria, Africa, [...] So build your own stratum 1 server (maybe a second one with DCF77 or whatever you can use for redundancy), I don't think DCF77 is going to reach Nigeria. Aled -- jamie rishaw // .com.arpa@j - reverse it. ish. Reality defeats prejudice. - Rep. Barney Frank
Re: Need trusted NTP Sources
Once upon a time, Nick Hilliard n...@foobar.org said: So presuming that your company is using RH or Fedora or CentOS something, the auditors are claiming that Red Hat, Inc is trusted enough to provide a precompiled based operating system with no feasible means of proving its reliability, but that they're not trustworthy enough to provide a clock synchronisation service? Red Hat does not provide an NTP service themselves. The default NTP config on a Red Hat Enterprise Linux system uses rhel.pool.ntp.org. I suppose some auditor could dislike the openness of pool.ntp.org (basically anybody can join). If that is the case, your best bet is to do some combination of the following: - As others have suggested, set up your own stratum-1 clock (can be done for around $100). Ideally you'd set up more than one. - Set up several servers with a static set of NTP servers rather than the general pool servers. See the lists on www.pool.ntp.org; look under the docs for setting up a server to join the pool. You don't have to actually join the pool, but following those docs is a good way to set up a stable server. After that, point the rest of your servers at your master servers, rather than the public pool. -- Chris Adams c...@cmadams.net
Re: SIP on FTTH systems
On Thursday, February 06, 2014 04:17:42 PM Mikael Abrahamsson wrote: You don't need a BNG. You need an L3 switch as the first hop the customer is talking to. Fine for FTTB, but not for FTTH where you're serving tens- to-hundreds-of-thousands of customers. If your FTTH deployments are low scale (measure of low or large scale depends on each operator's point of view), the case for doing without subscriber management technologies can be made. If you have L3-in-vlan-per-customer at the first hop then you don't really need all of that. If you include rudimentary VRF support then you can even support wholesale. /64 per customer, DHCPv6(-PD) server support in the L3 switch and you're good to go. I'm curious; in these deployments, what kind of customer scale are you talking about? When someone says FTTH, I'm thinking thousands and thousands of customers, in which case not having a scalable susbcriber management system as well as not having a scalable customer termination topology could be difficult. Unless I misunderstand... There is equipment that already claim to do this (I never got to test their implementation based on my requirements because I switched jobs, but they claimed to have implemented everything last year). Modern Metro-E switches that support full IP/MPLS in the Access have a lot of good IPv4 and IPv6 features, including DHCP_IA and DHCP_IA_PD, but again, these are more FTTB- than FTTH-focused, if you're talking about scale. Cheers, Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On Thu, 6 Feb 2014, Mark Tinka wrote: On Thursday, February 06, 2014 04:17:42 PM Mikael Abrahamsson wrote: You don't need a BNG. You need an L3 switch as the first hop the customer is talking to. Fine for FTTB, but not for FTTH where you're serving tens- to-hundreds-of-thousands of customers. Why? If your FTTH deployments are low scale (measure of low or large scale depends on each operator's point of view), the case for doing without subscriber management technologies can be made. Why is it different? I'm curious; in these deployments, what kind of customer scale are you talking about? When someone says FTTH, I'm thinking thousands and thousands of customers, in which case not having a scalable susbcriber management system as well as not having a scalable customer termination topology could be difficult. Unless I misunderstand... Yes, this is for hundreds of thousands of customers. Why do you need customer management? You document where a certain fiber goes to (what port), and then this port goes to a certain customer. That is the only customer management you need. So you provision your L3 switch with a protocol based 0x86dd vlan per port, put a static /64 L3 subinterface into this vlan, then you have a built in DHCPv6(-PD) server in the same switch that hands out a static /56 on this vlan, plus hands out DNS-resolver etc. No dynamics, just static. You provision ACLs to only allow the /56, /64 and LL in on the L3 interface. You set ND cache max size to 20-50 entries per L3 subinterface to protect the 1024-2048 entries or whatever the L3 switch can handle. For IPv4 you need to do all the L2/L3-inspection magic in a common vlan. This is now a standalone unit and you don't need any central system to stay up and running in order to move IPv6 packets, and you support both directly attached computer or a residential gateway that wants PD. I did this type of DSL deplayment early 2000nds with an L3 switch and an ethernet DSLAM as media converter. This was obviously IPv4 only, but worked very well. At the same time the guys with central DHCP systems had a lot of country wide outages when the DHCP system went belly-up. I only a few years later learnt what an LNS was when I talked to someone else who did more of a follow-the-whitepaper deployment of DSL. Modern Metro-E switches that support full IP/MPLS in the Access have a lot of good IPv4 and IPv6 features, including DHCP_IA and DHCP_IA_PD, but again, these are more FTTB- than FTTH-focused, if you're talking about scale. I would never want to have MPLS that far out into the network. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Need trusted NTP Sources
It has been a while since I have done anything with NTP, but I would start with ntp.org (which didn't exist when I WAS working with it) which I am led to believe has the stuff that used to be at U. Delaware, like the public servers lists: http://support.ntp.org/bin/view/Servers/WebHome Where I found http://support.ntp.org/bin/view/Servers/PublicTimeServer79 -- 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: Need trusted NTP Sources
After all these years I still can not get used to the non-standard NANOG response to reply. I wonder if there is a way for ne to fix that locally. On 2/6/2014 8:49 AM, Larry Sheldon wrote: On 2/6/2014 4:43 AM, Nick Hilliard wrote: On 06/02/2014 10:03, Notify Me wrote: I'm trying to help a company I work for to pass an audit, and we've been told we need trusted NTP sources (RedHat doesn't cut it). So presuming that your company is using RH or Fedora or CentOS something, the auditors are claiming that Red Hat, Inc is trusted enough to provide a precompiled based operating system with no feasible means of proving its reliability, but that they're not trustworthy enough to provide a clock synchronisation service? My head spins. Get new auditors. Your current ones are stupid. It has been a while since I have done anything with NTP, but I would start with ntp.org (which didn't exist when I WAS working with it) which I am led to believe has the stuff that used to be at U. Delaware, like the public servers lists: http://support.ntp.org/bin/view/Servers/WebHome -- 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: Need trusted NTP Sources
On 2/6/2014 9:02 AM, Nick Hilliard wrote: On 06/02/2014 14:57, Larry Sheldon wrote: http://support.ntp.org/bin/view/Servers/PublicTimeServer79 bear in mind that due to the vagaries of african peering weirdness, the actual path from there to the OP's network could be over multiple satellite links and peered in Asia, Europe or the US. The Internet in africa can be ... odd. If it was me (having made a living getting with auditors who had no idea what they were doing) I would look for some close-by reliable (my judgement) 1- and 2- level sources (including, usually) the router at the ISP that I talk-to to get good service then add one or two the auditor likes. Larry (long time responder-to-audits that demanded that my UNIVAC and HP hardware and software look like IBM) -- 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)
carrier comparison
Hi, We're a small ISP / datacenter with a Time Warner fiber-based DIA contract that is coming up for renewal. We're getting much better pricing offers from Cogent, and are finding out what Level 3 can do for us as well. Both providers will use Time Warner fiber for last mile. My questions are: - Will we be sacrificing quality if we spring for Cogent? (yesterday's Cogent/Verizon thread provided some cold chills for my spine) - Is there a risk with contracting a carrier that utilizes another carrier (such as Time Warner) for the last mile? (i.e. if there is a downtime situation, are we going to be caught in a web of confusion and finger-pointing that delays problem resolution)? - How are peoples' experiences with L3 vs TWC? Although I assume everyone on the list would be interested in what others have to say about these questions, out of respect for the carriers in question, I encourage you to email frank opinions off list. Or if there are third party tools or resources you know that I could consult to deduce the answers to these questions myself, they are most welcome. Thanks, Adam
Re: Need trusted NTP Sources
Hi Alexander, I think you or your consultant may have an overly strict reading of the PCI documents. Looking at section 10.4 of PCI DSS 3.0, and from having gone through PCI a few times... If you have your PCI hosts directly going against ntp.org or similar, then you are not in compliance. My understanding is that you need to: A) Run a local set of NTP servers - these are your 'trusted' servers, under your control, properly managed/secured, fully meshed, etc. These in turn (section 10.4.3) can get their time from 'industry-accepted time sources'. B) The rest of your PCI infrastructure in turn uses these NTP servers and only these NTP servers. - Michael DeMan On Feb 6, 2014, at 2:27 AM, Alexander Maassen outsi...@scarynet.org wrote: www.pool.ntp.org Oorspronkelijk bericht Van: Notify Me notify.s...@gmail.com Datum: Aan: nanog@nanog.org list nanog@nanog.org,af...@afnog.org Onderwerp: Need trusted NTP Sources Hi ! I'm trying to help a company I work for to pass an audit, and we've been told we need trusted NTP sources (RedHat doesn't cut it). Being located in Nigeria, Africa, I'm not very knowledgeable about trusted sources therein. Please can anyone help with sources that wouldn't mind letting us sync from them? Thanks a lot!
Re: SIP on FTTH systems
On Thursday, February 06, 2014 04:56:15 PM Mikael Abrahamsson wrote: Yes, this is for hundreds of thousands of customers. Why do you need customer management? You document where a certain fiber goes to (what port), and then this port goes to a certain customer. That is the only customer management you need. So you provision your L3 switch with a protocol based 0x86dd vlan per port, put a static /64 L3 subinterface into this vlan, then you have a built in DHCPv6(-PD) server in the same switch that hands out a static /56 on this vlan, plus hands out DNS-resolver etc. No dynamics, just static. You provision ACLs to only allow the /56, /64 and LL in on the L3 interface. You set ND cache max size to 20-50 entries per L3 subinterface to protect the 1024-2048 entries or whatever the L3 switch can handle. For IPv4 you need to do all the L2/L3-inspection magic in a common vlan. This is now a standalone unit and you don't need any central system to stay up and running in order to move IPv6 packets, and you support both directly attached computer or a residential gateway that wants PD. I won't lie, it is impressive that you strung the network this way. I can certainly see how it would work, although I'm not sure how well it would scale if you're diddling about with all sorts of kinky services beyond just access to the Internet (certinaly a concern for me, anyway). At previous job, we looked at various topologies and deployment techniques for how to support large scale FTTH installations, and one of the key issues is impact on the control plane for locally-ran DHCP servers on the routers, particularly when the same router is providing business services as well. Some vendors have seen the light and are finally running x86-based multi-core 64-bit CPU's for control plane processing, and while this may help, CPU horsepower is finite (although it would, most certainly, scale better than a Layer 3 switch doing the same thing). When you start to add services like Multicast for IPTv, and depending on whether you run these switches in a ring or not, and whether you're running Rosen MVPN vs. NG-MVPN, you can quickly start to hit platform limits or feature constraints. I did this type of DSL deplayment early 2000nds with an L3 switch and an ethernet DSLAM as media converter. This was obviously IPv4 only, but worked very well. At the same time the guys with central DHCP systems had a lot of country wide outages when the DHCP system went belly-up. I don't believe in centralized BNG's; mostly because traffic forwarding is not optimal. That and it's too much trust in one device. I prefer distributed BNG's (much like the topology you describe, only just less your deployment in number given how much you can scale a single Layer 3 switch to act as a service termination device). Along with distributed BNG's, you can also distribute DHCP servers, and multiple DHCP servers can maintain lease state amongst each other to allow for failover in case the primary DHCP server breaks. This is a known design tactic, and helps to take away from the issues of centralized architectures. I would never want to have MPLS that far out into the network. This is a different topic, but what we did was deploy MPLS all the way into the Metro-E access using Cisco's ME3600X because there had simply been to much pain doing legacy Layer 2-based Metro-E solutions (stringing VLAN's together between end points, keeping hands away from VTP, e.t.c.). This was in 2010, and by then, there wasn't any decent devices cheap enough with sufficient features to make this possible. I'd certainly recommend this architecture for Metro-E deployments focused on business-grade services. I don't expect most to follow it given there is a large Layer 2- based Metro-E installed base, but I think it will grow with time. Mark. signature.asc Description: This is a digitally signed message part.
Re: carrier comparison
We have had Cogent over Verizon's Fiber for more than a few years now. Cogent goes down once at year at minimum. They had 2 outages in a single day a couple days ago in Northern NJ. One in the AM ..caused by a power outage in a vendor data center where Cogent is collocated. They went on to have another outage at around 9:30 PM on the same day for which I'm still waiting for an RFO. During this outage, they still were advertising our BGP routes so we didn't fail over to our 2nd provider. I notice that happens alot with them. When they go down, they still advertise your routes. As far as price goes, for us Cogent is cheap but Lightpath is cheaper. Our college is kind of far from things so we don't have a lot of outside fiber coming. The last mile fiber for both of our connections are different from our Internet providers. I've never had a big issue with the two working with each other. The only issue we had is I suspected we weren't getting as much bandwidth as we paid for. They had to work out where the policer and/or bottle neck was. This is the only issue we had in 5 years with this set up and it got resolved. IME, when there is a full outage, it's always been clear who the responsible party is. On 2/6/2014 10:17 AM, Adam Greene wrote: Hi, We're a small ISP / datacenter with a Time Warner fiber-based DIA contract that is coming up for renewal. We're getting much better pricing offers from Cogent, and are finding out what Level 3 can do for us as well. Both providers will use Time Warner fiber for last mile. My questions are: - Will we be sacrificing quality if we spring for Cogent? (yesterday's Cogent/Verizon thread provided some cold chills for my spine) - Is there a risk with contracting a carrier that utilizes another carrier (such as Time Warner) for the last mile? (i.e. if there is a downtime situation, are we going to be caught in a web of confusion and finger-pointing that delays problem resolution)? - How are peoples' experiences with L3 vs TWC? Although I assume everyone on the list would be interested in what others have to say about these questions, out of respect for the carriers in question, I encourage you to email frank opinions off list. Or if there are third party tools or resources you know that I could consult to deduce the answers to these questions myself, they are most welcome. Thanks, Adam
Re: carrier comparison
Cogent always has the cheapest rates but they also have the most peering disputes of any operator. I've seen intra-data center hops between cogent and Verizon take over 150ms. As with all things Internet, your mileage may vary. I would not put something with a 5 9'a uptime requirement on cogent without a failover circuit. For less sensitive applications it seems like a win. The Internet is both incredibly robust and fragile simultaneously. Cheers, Joshua Sent from my iPhone On Feb 6, 2014, at 8:06 AM, Vlade Ristevski vrist...@ramapo.edu wrote: We have had Cogent over Verizon's Fiber for more than a few years now. Cogent goes down once at year at minimum. They had 2 outages in a single day a couple days ago in Northern NJ. One in the AM ..caused by a power outage in a vendor data center where Cogent is collocated. They went on to have another outage at around 9:30 PM on the same day for which I'm still waiting for an RFO. During this outage, they still were advertising our BGP routes so we didn't fail over to our 2nd provider. I notice that happens alot with them. When they go down, they still advertise your routes. As far as price goes, for us Cogent is cheap but Lightpath is cheaper. Our college is kind of far from things so we don't have a lot of outside fiber coming. The last mile fiber for both of our connections are different from our Internet providers. I've never had a big issue with the two working with each other. The only issue we had is I suspected we weren't getting as much bandwidth as we paid for. They had to work out where the policer and/or bottle neck was. This is the only issue we had in 5 years with this set up and it got resolved. IME, when there is a full outage, it's always been clear who the responsible party is. On 2/6/2014 10:17 AM, Adam Greene wrote: Hi, We're a small ISP / datacenter with a Time Warner fiber-based DIA contract that is coming up for renewal. We're getting much better pricing offers from Cogent, and are finding out what Level 3 can do for us as well. Both providers will use Time Warner fiber for last mile. My questions are: - Will we be sacrificing quality if we spring for Cogent? (yesterday's Cogent/Verizon thread provided some cold chills for my spine) - Is there a risk with contracting a carrier that utilizes another carrier (such as Time Warner) for the last mile? (i.e. if there is a downtime situation, are we going to be caught in a web of confusion and finger-pointing that delays problem resolution)? - How are peoples' experiences with L3 vs TWC? Although I assume everyone on the list would be interested in what others have to say about these questions, out of respect for the carriers in question, I encourage you to email frank opinions off list. Or if there are third party tools or resources you know that I could consult to deduce the answers to these questions myself, they are most welcome. Thanks, Adam
Re: carrier comparison
On Feb 6, 2014, at 11:22, Joshua Goldbard j...@2600hz.com wrote: Cogent always has the cheapest rates Objectively, provably false. -- TTFN, patrick but they also have the most peering disputes of any operator. I've seen intra-data center hops between cogent and Verizon take over 150ms. As with all things Internet, your mileage may vary. I would not put something with a 5 9'a uptime requirement on cogent without a failover circuit. For less sensitive applications it seems like a win. The Internet is both incredibly robust and fragile simultaneously. Cheers, Joshua Sent from my iPhone On Feb 6, 2014, at 8:06 AM, Vlade Ristevski vrist...@ramapo.edu wrote: We have had Cogent over Verizon's Fiber for more than a few years now. Cogent goes down once at year at minimum. They had 2 outages in a single day a couple days ago in Northern NJ. One in the AM ..caused by a power outage in a vendor data center where Cogent is collocated. They went on to have another outage at around 9:30 PM on the same day for which I'm still waiting for an RFO. During this outage, they still were advertising our BGP routes so we didn't fail over to our 2nd provider. I notice that happens alot with them. When they go down, they still advertise your routes. As far as price goes, for us Cogent is cheap but Lightpath is cheaper. Our college is kind of far from things so we don't have a lot of outside fiber coming. The last mile fiber for both of our connections are different from our Internet providers. I've never had a big issue with the two working with each other. The only issue we had is I suspected we weren't getting as much bandwidth as we paid for. They had to work out where the policer and/or bottle neck was. This is the only issue we had in 5 years with this set up and it got resolved. IME, when there is a full outage, it's always been clear who the responsible party is. On 2/6/2014 10:17 AM, Adam Greene wrote: Hi, We're a small ISP / datacenter with a Time Warner fiber-based DIA contract that is coming up for renewal. We're getting much better pricing offers from Cogent, and are finding out what Level 3 can do for us as well. Both providers will use Time Warner fiber for last mile. My questions are: - Will we be sacrificing quality if we spring for Cogent? (yesterday's Cogent/Verizon thread provided some cold chills for my spine) - Is there a risk with contracting a carrier that utilizes another carrier (such as Time Warner) for the last mile? (i.e. if there is a downtime situation, are we going to be caught in a web of confusion and finger-pointing that delays problem resolution)? - How are peoples' experiences with L3 vs TWC? Although I assume everyone on the list would be interested in what others have to say about these questions, out of respect for the carriers in question, I encourage you to email frank opinions off list. Or if there are third party tools or resources you know that I could consult to deduce the answers to these questions myself, they are most welcome. Thanks, Adam
Re: Need trusted NTP Sources
On (2014-02-06 07:24 -0800), Michael DeMan wrote: A) Run a local set of NTP servers - these are your 'trusted' servers, under your control, properly managed/secured, fully meshed, etc. I'm not sure if full-mesh is best practice, the external clients should have full view of as close to source data as possible. If in full-mesh you're already masking the data with inaccuracy, giving the clients less information to make decision? We used to have full-mesh in our meinbergs, until from their recommendation we removed it completely. It makes sense to me, but I don't understand the issue deeply. -- ++ytti
Re: carrier comparison
On 2/6/14, 7:17 AM, Adam Greene wrote: Hi, We're a small ISP / datacenter with a Time Warner fiber-based DIA contract that is coming up for renewal. We're getting much better pricing offers from Cogent, and are finding out what Level 3 can do for us as well. Both providers will use Time Warner fiber for last mile. My questions are: - Will we be sacrificing quality if we spring for Cogent? (yesterday's Cogent/Verizon thread provided some cold chills for my spine) - Is there a risk with contracting a carrier that utilizes another carrier (such as Time Warner) for the last mile? (i.e. if there is a downtime situation, are we going to be caught in a web of confusion and finger-pointing that delays problem resolution)? - How are peoples' experiences with L3 vs TWC? Although I assume everyone on the list would be interested in what others have to say about these questions, out of respect for the carriers in question, I encourage you to email frank opinions off list. Or if there are third party tools or resources you know that I could consult to deduce the answers to these questions myself, they are most welcome. Short answer: multihome. ~Seth
Re: SIP on FTTH systems
On 14-02-06 08:06, Mark Tinka wrote: I'm just saying DHCP is better than PPPoE if you're greenfielding FTTH deployments today, and I'm not sure you entirely disagree. When an incumbent already has PPPoE deployed for its DSL, putting FTTH on PPPoE makes it simpler. And PPPoE really simplifies wholesale systems. You do not want the incumbent/wholesaler to perform DHCP. This is a HUGE headache. We have that in Canada for cable wholesale (TPIA). The incumbent has to micromanage each ISPs IP blocks and carve subnets for each CMTS (for cable). For as much as everyone hates PPPoE, it makes for managememnt of a wholesale systems much much easier. Ideally, there would be some protocol where the CPE would setup a layer 2 SVC to the ISP, after which the ISP can provide DHCP services etc.
Re: carrier comparison
When I priced out providers 2 years ago for 500Mbps over 1 gig fiber link the list from most expensive to least expensive was: Verizon--XO--Cogent--Lightpath This is for Northern NJ. Abovenet and some of the other big providers couldn't reach our Campus. Lightpath ate the cost of running Fiber to our campus while the other weren't willing to do that. On 2/6/2014 11:28 AM, Patrick W. Gilmore wrote: On Feb 6, 2014, at 11:22, Joshua Goldbard j...@2600hz.com wrote: Cogent always has the cheapest rates Objectively, provably false.
Re: SIP on FTTH systems
On Thu, 6 Feb 2014, Jean-Francois Mezei wrote: You do not want the incumbent/wholesaler to perform DHCP. This is a HUGE headache. We have that in Canada for cable wholesale (TPIA). The incumbent has to micromanage each ISPs IP blocks and carve subnets for each CMTS (for cable). You could have the wholesaler do DHCP inspection and antispoofing etc based on that, but not actually do the DHCP servering. For as much as everyone hates PPPoE, it makes for managememnt of a wholesale systems much much easier. FTTH is supposed to be for higher speeds, putting PPPoE in there makes it a lot more expensive than it has to be. Ideally, there would be some protocol where the CPE would setup a layer 2 SVC to the ISP, after which the ISP can provide DHCP services etc. I don't see that needed, doesn't the wholesaler already know what port has chosen what ISP and can set up L2 to that ISP? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: SIP on FTTH systems
On Thursday, February 06, 2014 06:38:23 PM Jean-Francois Mezei wrote: When an incumbent already has PPPoE deployed for its DSL, putting FTTH on PPPoE makes it simpler. And that is the practical issue I saw (and still see). A lot of operators just continue with it because it is maturely deployed in their networks, and attempting DHCP may not be as easy. Would I recommend trying DHCP, hell yes! And PPPoE really simplifies wholesale systems. You do not want the incumbent/wholesaler to perform DHCP. This is a HUGE headache. We have that in Canada for cable wholesale (TPIA). The incumbent has to micromanage each ISPs IP blocks and carve subnets for each CMTS (for cable). For as much as everyone hates PPPoE, it makes for managememnt of a wholesale systems much much easier. In one country I worked, we pressured the incumbent to offer us Layer 2 backhaul instead of Layer 3, for the very same reasons. Co-managing IP address assignments, e.t.c., was problematic, especially because they were not sure how large their network was going to grow, which presented us with planning challenges in how we pre-assign address space for each of their service PoP's. Of course, because the regulator had done their job re: unbundling the fibre, they didn't care how wholesale services were actually provided over said fibre. And yes, the incumbent jumped at the chance not to offer Layer 2 backhaul, because then they knew everything we were up to (to some degree of measure). Ideally, there would be some protocol where the CPE would setup a layer 2 SVC to the ISP, after which the ISP can provide DHCP services etc. Some of the vendors I've worked with don't support LNS functionality on their current generation BNG's. Just LAC. In this scenario, for PPPoE-centric operators and wholesalers, VPLS has been used to backhaul customer traffic, as opposed to L2TP, and recently, some vendors are now able to do this over EoMPLS pw's instead. If you have some control over the AN's that go into the incumben's/wholesaler's CO, you can get that Layer 2 connection (VPLS or EoMPLS pw) between your backbone and the CPE, that way. Mark. signature.asc Description: This is a digitally signed message part.
RE: carrier comparison
My questions are: - Will we be sacrificing quality if we spring for Cogent? (yesterday's Cogent/Verizon thread provided some cold chills for my spine) Jehova! Popcorn! :-) We used Cogent for some time. We dropped them, but not for poor quality (au contraire) but for other more complex reasons. IMHO, Cogent is far better than many say (any many of them only from 'knowledge' from word of mouth), Cogent has some oddities that you have to deal with, yust like with almost all other transit providers. Having said that: I don't want to be single homed again. hth, martin
Fwd: SAFNOG 2014 - Call for Papers OPEN
FYI. Mark. ---BeginMessage--- The Southern Africa Network Operators Group (SAFNOG) Johannesburg, South Africa 22 April - 23 April, 2014 http://www.safnog.org CALL FOR PAPERS === The SAFNOG 2014 Programme Committee is now seeking contributions for Presentations and Tutorials for SAFNOG 2014. We are looking for presenters who would: - Offer a technical tutorial on an appropriate topic; - Participate in the technical conference sessions as a speaker; - Convene and chair panel sessions of relevant topics. Please submit on-line at: http://papers.safnog.org/user/login.php?event=10 CONFERENCE MILESTONES -- Call for Papers Opens 27 January 2014 First Draft Program Published 28 February 2014 Final Deadline for Submissions 10 April 2014 Final Program Published15 April 2014 Final Slides Received 18 April 2014 PROGRAMME MATERIAL -- The SAFNOG Programme Committee is organised in three parts, including workshops, tutorials and the conference. Topics for tutorials and the conference must be relevant to Internet Operations and Technologies: - IPv4 / IPv6 Routing and operations - IPv6 deployment and transition technologies - Internet backbone operations - ISP and Carrier services - IXPs and Peering - Research on Internet Operations and Deployment - The African Internet - Network security issues (NSP-SEC, DDoS, Anti-Spam, Anti-Malware) - DNS / DNSSEC - Internet policy (Security, Regulation, Content Management, Addressing, etc) - Access and Transport Technologies, including Cable/DSL, 3G/LTE, wireless, metro ethernet, fibre, MPLS - Content Service Delivery (Multicast, Voice, Video, telepresence, Gaming) and Cloud Computing CfP SUBMISSION --- Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions otherwise the Programme Committee will be unable to review the submission. For work in progress, the most current information available at time of submission is acceptable. All draft and complete slides must be submitted in PDF format only. Final slides are to be provided by the specified deadline for publication on the SAFNOG website. Prospective presenters should note that the majority of speaking slots will be filled well before the final submission deadline. The Programme Committee will retain a limited number of slots up to the final submission deadline for presentations that are exceptionally timely, important, or of critical operational importance. Please submit on-line at: http://papers.safnog.org/user/login.php?event=10 Any questions or concerns should be addressed to the Programme Committee co-chairs by e-mail at: safnog-pc-chairs at safnog.org We look forward to receiving your presentation proposals. On Behalf of Kevin Chege Co-Chair SAFNOG Programme Committee. ___ afnog mailing list http://afnog.org/mailman/listinfo/afnog---End Message--- signature.asc Description: This is a digitally signed message part.
Re: Need trusted NTP Sources
On Thu, 6 Feb 2014, Notify Me wrote: According to the auditors, trusted means 1. Universities or Research facilities (nuclear/atomic facilities, space research (such as NASA) etc.) 2. Main country internet/telecom providers 3. Government departments 4. Satellites (using GPS module) Which is a bit of a tall order over here. In general you should probably be asking news:comp.protocols.time.ntp. You could run your own NTP server using GPS as its reference clock (#4), at least I don't think it would be impossible for you to obtain such a device. But not cheap either. But then RHEL and an audit suggest you have some money to spend. You might even build your own using ntpd and a receiver, e.g., GNSS. See http://www.eecis.udel.edu/~mills/ntp/index.html for more information. Some stratum 1 or 2 servers (which are generally run by entities 1 thru 3 from your list) may allow you to obtain time (perhaps using crypto), but of course you'd need to contact them directly. ntp.org has a list: http://support.ntp.org/bin/view/Servers/WebHome. Generally speaking, you'll need at least 3 sources if you want stablity. Mark
Route Server Filters at IXPs and 4-byte ASNs
Food for thought: - ASNs can be reused at different locations by IXPs, barring perhaps certain business or administrative reasons. Ask Equinix. - For IXPs that already have 16-bit ASNs for route servers, this saves additional allocations from RIRs and mitigates concerns for the IXP getting potentially a 32-bit ASN, thus having trouble with BGP communities as described. Having a single ASN may raise other issues but it is an option. - I believe it would help if RIRs reserved 16-bit ASNs in addition to IPv4 micro allocations for IXPs, until a formal solution can be finally found about the 32-bit ASN BGP communities issue. Aris Lambrianidis
Re: SIP on FTTH systems
On 2014-02-06 15:08, Mark Tinka wrote: You need a bunch of stuff, proxy ND, proxy DAD, DHCPv6 inspection If you have a reasonably intelligent AN (like some of today's Active-E devices), you can create so-called split horizons on the same bridge domain (VLAN, really) where customers will only communicate via the upstream BNG at Layer 3. At Layer 2, even though they are all sitting on the same VLAN, there is no inter-communication between them. Ok, then you have not understood the problem with IPv6 in shared VLANs. You need to allow some communication between the user ports on L2, to get the IPv6 control procotol to work. You do this on IPv4 today, with proxy arp etc. Its much more complex in IPv6. I've also know Huawei OLT's support these split horizons too. Many devices support what Cisco calls Private VLAN or MACFF as specificed in RFC4562. There are IPv4 only implementations today - but not all these protocols are standardized, and are not interoperable between vendors. I have still not heard of any vendor shipping the same functionality to share VLANs with IPv6, in a secure way. Or do something bold, run L3 at the edge :) Cheap switches that have decent IP/MPLS support are mostly geared toward Metro-E deployments, i.e., business-grade services. So they are quite poor with regard to susbcriber management features and capabilities. You need a basic L3 access switch, with some tweaks. I've been working at and designing such devices for seven years at my former employeer PacketFront Networks. Whole bunch of standard protocols. OSPF, PIM-SM, IGMPv2/v3 in the edge, and now with OSPFv3, PIM-SMv6 and MLD/MLDv2. DHCPv4/v6 is relayed to the correct service provider, unless its management traffic and should be handled by the network. Very easy, very few security issues since no L2 is allowed between customers, no strange protocols (ARP inspection, proxy ARP, IP source guard, DHCP Snooping/option82 or their IPv6 counterparts). Open-access is done on the L3 layer, no VLANs. There are free seating in the CPE so all equipment in the home can talk to each other. Important with todays DLNA/TV sets and mobile phones. It is very scalable, since that is how Internet is built :) Of course, it needs a proper management system, so we built one as well. We also pushed Python into the access device, so DHCPv4/DHCPv6, radius, 802.1x functionality and how those are used can easily be adjusted in a script instead of trying to express programming in a CLI. On top of that some simple templates describing the services. The radius server just returns the service name with needed parameters (bandwidth, priority etc) and the python script installs/removes instances of the service as needed. I promise this access device has NO problems with spoofed packets, see the BCP38 discussion :) So, it's a small BNG in the access device. And no, it's not that expensive. We did look at sourcing a L2 switch from Taiwan, we could get the switch with L2 or L3 forwarding in a Broadcom switch ASIC, all the other features was equal. Cost difference was five dollars. (PacketFronts access device uses a NPU, much more flexible) Vendors charging both an arm and a leg for routers are doing that because they can, doing L3 is not more expensive than L2 with todays technology. PacketFront has sold over 1 miljon ports, and the largest installation is 5 ports, both in Sweden, Holland and Dubai. This can easily scale to much bigger networks. The biggest issue with selling L3 to the edge is not technical or economical, its religious - people are just so used to build their networks in a specific way and they don't want to change /Anders
Re: SIP on FTTH systems
On Thu, 6 Feb 2014, Anders Löwinger wrote: Ok, then you have not understood the problem with IPv6 in shared VLANs. You need to allow some communication between the user ports on L2, to get the IPv6 control procotol to work. You do this on IPv4 today, with proxy arp etc. Its much more complex in IPv6. 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. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Need trusted NTP Sources
On Thu, Feb 6, 2014 at 9:03 PM, Notify Me notify.s...@gmail.com wrote: I'm trying to help a company I work for to pass an audit, and we've been told we need trusted NTP sources (RedHat doesn't cut it). Being located in Nigeria, Africa, I'm not very knowledgeable about trusted sources therein. Obviously trusted time sources are important, but at the end of the day you have to trust someone who ultimately has the least risk (there is never no risk) you are able to achieve. I appreciate least level of risk is subjective to your auditors opinion (in this case) :-) Just wanted to mention, having a good number of servers (not blindly trusting = 3 unique sources) adds some additional protection against 'false-tickers'. Even trusted time-sources have their off-days due to a myriad of technical reasons. Configure multiple, relatively high stratum (taking into account how many stratum's you intend to serve downstream), low-jitter/rtt, good-quality, time-sources. Also, risk changes over time, so vigilant monitoring is important too! Regards, Chris.
Re: Need trusted NTP Sources
On Thu, Feb 6, 2014 at 8:28 AM, jamie rishaw j...@arpa.com wrote: PCI DSS only requires that all clocks be synchronized; It doesn't /require/ how. If you read requirement 10.4 more carefully, you will find that it Does require that time be synchronized from an INDUSTRY ACCEPTED external time source. The GPS reference clock, a radio timecode receiver, receiving NIST or USNO, Microsoft's time source (time.windows.com), Redhat's time source, various univerisities and other public time servers listed on NTP.org, the NIST time servers listed here: http://tf.nist.gov/tf-cgi/servers.cgi Are among the INDUSTRY ACCEPTED external time sources. This is not an exhaustive enumeration of industry-accepted external time sources. -- -JH
Re: SIP on FTTH systems
On Thursday, February 06, 2014 07:41:34 PM Anders Löwinger wrote: Ok, then you have not understood the problem with IPv6 in shared VLANs. You need to allow some communication between the user ports on L2, to get the IPv6 control procotol to work. You do this on IPv4 today, with proxy arp etc. Its much more complex in IPv6. No, it's not, and no, you don't. 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. 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. Many devices support what Cisco calls Private VLAN or MACFF as specificed in RFC4562. There are IPv4 only implementations today - but not all these protocols are standardized, and are not interoperable between vendors. I have still not heard of any vendor shipping the same functionality to share VLANs with IPv6, in a secure way. And that is why for modern Active-E kit, I prefer to enable split horizons using split horizon tech. against bridge domains, rather than Private VLAN's. Private VLAN's have lots of restrictions, and on AN's that support EVC (Cisco- style), you can enable split horizons on bridge domains, which works perfectly for Layer 2 and Layer 3 traffic. PacketFront has sold over 1 miljon ports, and the largest installation is 5 ports, both in Sweden, Holland and Dubai. This can easily scale to much bigger networks. The system specs. are impressive - basically, a little BNG in a switch, which I can't complain with. I suppose if I'm a business that wants to consolidate BNG and business services on a single platform, the existing routers I pay big money for to enable those business servics can double as BNG's. It's distributed, uniform and a single place where I can offer multiple services to different types of customers. 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? The biggest issue with selling L3 to the edge is not technical or economical, its religious - people are just so used to build their networks in a specific way and they don't want to change 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. So while I agree that there is a healthy amount of religion to these things, there is also room for change if the reasons are compelling. But yes, it can come down to personal taste by one person in the company. Cheers, Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On Thursday, February 06, 2014 09:04:40 PM 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. Yep. Mark. signature.asc Description: This is a digitally signed message part.
Re: SIP on FTTH systems
On Wed, Feb 5, 2014 at 11:52 PM, Jean-Francois Mezei jfmezei_na...@vaxination.ca wrote: Quick question: In the USA, do CLECs have access to homes served only by FTTH ? If so, how it is accomplisehd ? In practice CLECs do not have access. The TR order of the last decade mandated that access via FTTH was not a section 251 requirement under the Telco Act of 1996 except for a 64kbs stream which in theory could be used for voice. However, I believe there has been no widescale use of that feature because it is uneconomical compared to over-the-top VoIP. -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134
Re: Why won't providers source-filter attacks? Simple.
On Feb 5, 2014, at 2:46 AM, Saku Ytti s...@ytti.fi wrote: If we keep thinking this problem as last-mile port problem, it won't be solved in next 20 years. Because lot of those ports really can't do RPF and even if they can do it, they are on autopilot and next change is market forced fork-lift change. Company may not even employ technical personnel, only buy consulting when making changes. It can be solved, but not by NANOG. Imagine if Cable labs required all DOCSIS compliant cable modems to default to doing source address verification in the next version of DOCSIS? It would (eventually) get rolled out, and it would solve the problem. Even if it doesn't default to on, requiring the hardware to be capable would be a nice step. The consumer last mile is actually simpler in that there are a few organizations who control the standards. Efforts need to focus on getting the BCP38 stuff into those standards, ideally as mandatory defaults. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: TWC (AS11351) blocking all NTP?
On Feb 4, 2014, at 8:52 AM, William Herrin b...@herrin.us wrote: On Tue, Feb 4, 2014 at 11:23 AM, Jared Mauch ja...@puck.nether.net wrote: On Feb 4, 2014, at 11:04 AM, William Herrin b...@herrin.us wrote: If just three of the transit-free networks rewrote their peering contracts such that there was a $10k per day penalty for sending packets with source addresses the peer should reasonably have known were forged, this problem would go away in a matter of weeks. I've seen similar comments in other forums. We are all generally paid for moving packets, not filtering them. The speed at which you can forward packets can often cause increased $$. Using these features also impacts performance, so the cost may actually be 2x in capex+opex to provision ports due to reduced line-rate capability. Hi Jared, You're gonna need a bigger TCAM, but even so I think you're overstating the case. No, he's not. The intelligence required to analyze packets is in addition to the intelligence required to move them. More packets, more cost. Even if you take a RPSL-IRR approach to building filters, and even if the router can handle such long ACLs bug-free, you have some objects that expand to cover 50-90% of the internet. They may be someones backup route at some point because of 'something'. Yes, but that's OK. In order to make sure that they're aren't originating from the penalizing 10%, your peers will have to implement similar filtering downstream... where the breadth isn't 90%. So who determines this break point? Who is responsible for a full-table Tier-1 to Tier-1 peering link? Who polices it? Who arbitrates disputes? Clearly putting the filters as close to the source is helpful but detecting the actual spoofed packet is hard. At the customer boundary it's trivial: they'll tell you what they originate, and that's what you'll allow. If your customer lies, pass the penalty forward. At the peering boundary, you don't have to detect the forged packets. You can wait until someone complains, confirm it, and then apply the penalty. Packets coming from your peers won't go to your other peers, only to your customers. That's how you rigged your routing. More, evidence that the downstream was authorized to send those packets refutes the penalty. You know this is completely unworkable at scale right? Until you find yourself on the receiving end of these types of things, you may not ask for or pay for DDoS protection services, or advanced filtering, or even ask your vendor to support these features. I have to wait months for fixes in the features because no support from others in the industry on the platform, etc. DDoS is a bigger problem than spoofing and amplification. My suggestion only addresses spoofing and amplification, not botnets in general. But they have the same economic inputs, yes? As Jared said, providers get paid by the bit. Many (most?) Bad Actors get paid by the bit, Vendors get paid by the bit, mitigation vendors get paid by the bit. That's a lot of dollars for a lot of bits and they increase together. Those that are up in arms about this stuff seem to not be the ones asking the vendors for features and fixes. Like I said, the tier 1's can't be the source of the solution until they stop being part of the problem. You are asking the guys who build and maintain the highways to be responsible for checking every car on the road to see if it's carrying illegal drugs. How can that possibly work? Mike
Re: carrier comparison
IMHO Cogent bandwidth is fine so long as it isn’t your only bandwidth. Good, Cheap, Fast, Pick any two. -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 E: matt...@crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com On Feb 6, 2014, at 10:17 AM, Adam Greene maill...@webjogger.net wrote: Hi, We're a small ISP / datacenter with a Time Warner fiber-based DIA contract that is coming up for renewal. We're getting much better pricing offers from Cogent, and are finding out what Level 3 can do for us as well. Both providers will use Time Warner fiber for last mile. My questions are: - Will we be sacrificing quality if we spring for Cogent? (yesterday's Cogent/Verizon thread provided some cold chills for my spine) - Is there a risk with contracting a carrier that utilizes another carrier (such as Time Warner) for the last mile? (i.e. if there is a downtime situation, are we going to be caught in a web of confusion and finger-pointing that delays problem resolution)? - How are peoples' experiences with L3 vs TWC? Although I assume everyone on the list would be interested in what others have to say about these questions, out of respect for the carriers in question, I encourage you to email frank opinions off list. Or if there are third party tools or resources you know that I could consult to deduce the answers to these questions myself, they are most welcome. Thanks, Adam
Re: carrier comparison
+1 Same feeling here. Sam Moats On 2014-02-06 16:22, Matthew Crocker wrote: IMHO Cogent bandwidth is fine so long as it isn’t your only bandwidth. Good, Cheap, Fast, Pick any two. -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 E: matt...@crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com On Feb 6, 2014, at 10:17 AM, Adam Greene maill...@webjogger.net wrote: Hi, We're a small ISP / datacenter with a Time Warner fiber-based DIA contract that is coming up for renewal. We're getting much better pricing offers from Cogent, and are finding out what Level 3 can do for us as well. Both providers will use Time Warner fiber for last mile. My questions are: - Will we be sacrificing quality if we spring for Cogent? (yesterday's Cogent/Verizon thread provided some cold chills for my spine) - Is there a risk with contracting a carrier that utilizes another carrier (such as Time Warner) for the last mile? (i.e. if there is a downtime situation, are we going to be caught in a web of confusion and finger-pointing that delays problem resolution)? - How are peoples' experiences with L3 vs TWC? Although I assume everyone on the list would be interested in what others have to say about these questions, out of respect for the carriers in question, I encourage you to email frank opinions off list. Or if there are third party tools or resources you know that I could consult to deduce the answers to these questions myself, they are most welcome. Thanks, Adam
Re: carrier comparison
I use Cogent as well, no real issues other than I wouldn't single home to them. Personally, I don't understand why someone would depend on a single provider for connectivity however... -Blake On Thu, Feb 6, 2014 at 3:22 PM, Matthew Crocker matt...@corp.crocker.comwrote: IMHO Cogent bandwidth is fine so long as it isn't your only bandwidth. Good, Cheap, Fast, Pick any two. -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 E: matt...@crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com On Feb 6, 2014, at 10:17 AM, Adam Greene maill...@webjogger.net wrote: Hi, We're a small ISP / datacenter with a Time Warner fiber-based DIA contract that is coming up for renewal. We're getting much better pricing offers from Cogent, and are finding out what Level 3 can do for us as well. Both providers will use Time Warner fiber for last mile. My questions are: - Will we be sacrificing quality if we spring for Cogent? (yesterday's Cogent/Verizon thread provided some cold chills for my spine) - Is there a risk with contracting a carrier that utilizes another carrier (such as Time Warner) for the last mile? (i.e. if there is a downtime situation, are we going to be caught in a web of confusion and finger-pointing that delays problem resolution)? - How are peoples' experiences with L3 vs TWC? Although I assume everyone on the list would be interested in what others have to say about these questions, out of respect for the carriers in question, I encourage you to email frank opinions off list. Or if there are third party tools or resources you know that I could consult to deduce the answers to these questions myself, they are most welcome. Thanks, Adam
Re: carrier comparison
Vlade, When you say that they still advertise your routes, do you mean: A: That you were having them originate your routes, and they failed to stop doing so when they had problems? Or... B: That routes you were originating continued to be propagated by them, even though your session with them was down? Or... C: Something else. I ask, as we are considering some cheap Cogent bandwidth in the not-too-distant future, to allow us to keep commit rates low on higher quality connections. 'A' wouldn't be a real problem, since we run our own AS and originate our own routes; 'B' could be potentially devastating. On Thu, Feb 6, 2014 at 8:04 AM, Vlade Ristevski vrist...@ramapo.edu wrote: We have had Cogent over Verizon's Fiber for more than a few years now. Cogent goes down once at year at minimum. They had 2 outages in a single day a couple days ago in Northern NJ. One in the AM ..caused by a power outage in a vendor data center where Cogent is collocated. They went on to have another outage at around 9:30 PM on the same day for which I'm still waiting for an RFO. During this outage, they still were advertising our BGP routes so we didn't fail over to our 2nd provider. I notice that happens alot with them. When they go down, they still advertise your routes. As far as price goes, for us Cogent is cheap but Lightpath is cheaper. Our college is kind of far from things so we don't have a lot of outside fiber coming. The last mile fiber for both of our connections are different from our Internet providers. I've never had a big issue with the two working with each other. The only issue we had is I suspected we weren't getting as much bandwidth as we paid for. They had to work out where the policer and/or bottle neck was. This is the only issue we had in 5 years with this set up and it got resolved. IME, when there is a full outage, it's always been clear who the responsible party is. On 2/6/2014 10:17 AM, Adam Greene wrote: Hi, We're a small ISP / datacenter with a Time Warner fiber-based DIA contract that is coming up for renewal. We're getting much better pricing offers from Cogent, and are finding out what Level 3 can do for us as well. Both providers will use Time Warner fiber for last mile. My questions are: - Will we be sacrificing quality if we spring for Cogent? (yesterday's Cogent/Verizon thread provided some cold chills for my spine) - Is there a risk with contracting a carrier that utilizes another carrier (such as Time Warner) for the last mile? (i.e. if there is a downtime situation, are we going to be caught in a web of confusion and finger-pointing that delays problem resolution)? - How are peoples' experiences with L3 vs TWC? Although I assume everyone on the list would be interested in what others have to say about these questions, out of respect for the carriers in question, I encourage you to email frank opinions off list. Or if there are third party tools or resources you know that I could consult to deduce the answers to these questions myself, they are most welcome. Thanks, Adam
Re: carrier comparison
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. It sucks for us, because we're a small school and don't have someone in a NOC to monitor our networks 24x7. I literally had to get out of bed and disable our BGP session with them for us to get through the outage. I was getting around 90% packet loss from my home to our router. On 2/6/2014 4:57 PM, Eric Flanery (eric) wrote: Vlade, When you say that they still advertise your routes, do you mean: A: That you were having them originate your routes, and they failed to stop doing so when they had problems? Or... B: That routes you were originating continued to be propagated by them, even though your session with them was down? Or... C: Something else. I ask, as we are considering some cheap Cogent bandwidth in the not-too-distant future, to allow us to keep commit rates low on higher quality connections. 'A' wouldn't be a real problem, since we run our own AS and originate our own routes; 'B' could be potentially devastating. On Thu, Feb 6, 2014 at 8:04 AM, Vlade Ristevski vrist...@ramapo.edu mailto:vrist...@ramapo.edu wrote: We have had Cogent over Verizon's Fiber for more than a few years now. Cogent goes down once at year at minimum. They had 2 outages in a single day a couple days ago in Northern NJ. One in the AM ..caused by a power outage in a vendor data center where Cogent is collocated. They went on to have another outage at around 9:30 PM on the same day for which I'm still waiting for an RFO. During this outage, they still were advertising our BGP routes so we didn't fail over to our 2nd provider. I notice that happens alot with them. When they go down, they still advertise your routes. As far as price goes, for us Cogent is cheap but Lightpath is cheaper. Our college is kind of far from things so we don't have a lot of outside fiber coming. The last mile fiber for both of our connections are different from our Internet providers. I've never had a big issue with the two working with each other. The only issue we had is I suspected we weren't getting as much bandwidth as we paid for. They had to work out where the policer and/or bottle neck was. This is the only issue we had in 5 years with this set up and it got resolved. IME, when there is a full outage, it's always been clear who the responsible party is. On 2/6/2014 10:17 AM, Adam Greene wrote: Hi, We're a small ISP / datacenter with a Time Warner fiber-based DIA contract that is coming up for renewal. We're getting much better pricing offers from Cogent, and are finding out what Level 3 can do for us as well. Both providers will use Time Warner fiber for last mile. My questions are: - Will we be sacrificing quality if we spring for Cogent? (yesterday's Cogent/Verizon thread provided some cold chills for my spine) - Is there a risk with contracting a carrier that utilizes another carrier (such as Time Warner) for the last mile? (i.e. if there is a downtime situation, are we going to be caught in a web of confusion and finger-pointing that delays problem resolution)? - How are peoples' experiences with L3 vs TWC? Although I assume everyone on the list would be interested in what others have to say about these questions, out of respect for the carriers in question, I encourage you to email frank opinions off list. Or if there are third party tools or resources you know that I could consult to deduce the answers to these questions myself, they are most welcome. Thanks, Adam -- Vlad
ATT Security
Anyone have a contact for ATT security? I have a Denial of service attack going on for a customer with an ATT Fiber Circuit. I called ATT and they gave me an 888 number which is some security contractor. Justin -- Justin Wilson j...@mtin.net MTCNA CCNA MTCRE MTCWE - COMTRAIN Aol Yahoo IM: j2sw http://www.mtin.net/blog xISP News http://www.zigwireless.com High Speed Internet Options http://www.thebrotherswisp.com The Brothers Wisp
FW: Trusted Community Representation for Root KSK
Hi, People on this list might also want to submit responses. Regards, Leo From: dns-operations-boun...@mail.dns-oarc.net [mailto:dns-operations-boun...@mail.dns-oarc.net] On Behalf Of Kim Davies Sent: Thursday, February 06, 2014 12:38 PM To: DNS Operations Subject: [dns-operations] Trusted Community Representation for Root KSK Hi folks, ICANN is currently performing a consultation on how to evolve the participation of Trusted Community Representatives in the management of the root key signing key. I think this consultation is of particular interest to this group as ultimately these TCRs are there to instill trust in the DNS operations community that the KSK is being managed in a proper fashion. I'd encourage you to provide feedback to this consultation - available at http://www.icann.org/en/news/public-comment/tcr-dnssec-key-signing-21jan 14-en.htm - by 11th February. It is important we have a model of TCR participation that is satisfactory to the community. For convenience, here are the terms of reference replicated: Background Since July 2010, the DNS Root Zone has been secured using DNSSEC[1]. The model of using DNSSEC in the DNS Root Zone revolves around a key signing key (KSK) that is managed by ICANN in two secure facilities. Four times a year, a ceremony is conducted at these facilities to perform operations involving the KSK. As a key part of this process, a minimum of three from a pool of 21 trusted community representatives (TCRs) attend each ceremony to enable access to the secure materials, to witness the procedure, and to attest that the ceremony was conducted properly[2]. Each ceremony is attended by ICANN staff, the TCRs, representatives of the Root Zone Maintainer (Verisign), representatives of an independent audit firm retained by ICANN to monitor the process, and often additional external witnesses. Ceremonies are recorded by three audit cameras and webcast online. A typical ceremony lasts approximately four hours, and involves a process of temporarily removing the key signing key from a safe and performing key-signing operations in a secure manner following a formal script. The script is designed to perform each operation in a transparent manner to ensure the key signing key is only used for its proper purpose, and there is no ability for its contents to be disclosed for other purposes. Materials from each ceremony - such as the scripts, video recordings, and system output - are posted online[3]. De-briefings and discussions are conducted post-ceremony, where participants discuss how to improve future ceremonies. This feedback helps inform the evolution of the KSK ceremony to be both efficient and effective, while ensuring maximum trust in how ceremonies are performed. The TCRs were selected[4] from the global community based on a number of criteria[5]. These selection criteria relate to the volunteers ability to travel to ceremonies, conscientiously oversee the process, ensure transparency in its operation, and ultimately contribute to the broader community's trust that the private component of the key signing key has not been compromised. The TCRs are privately funded volunteers who are not reimbursed or compensated by ICANN for their participation nor their expenses. The original TCR proposal was silent on the length of service of individual TCRs. Of the 21 TCRs, seven are credentialed as crypto officers (COs) for each of the two facilities, and the remaining seven act as recovery key shareholders who only participate in ceremonies in the event the requisite number of COs are unable to participate or there is a need to rebuild the KSK following an unforeseen event. Of the seven COs for each facility, ICANN aims to have four attend each ceremony, with an absolute minimum of three required to successfully perform a ceremony. Each facility hosts two ceremonies per year, approximately once every six months. In practice, a TCR will attend at minimum one ceremony per year, and some will attend two in order to ensure sufficient attendance. Of the initial pool of 21 TCRs, one has resigned and been replaced from the pool of recovery key shareholders. No TCR has been removed owing to the other three criteria for replacement in the TCR selection document, relating to lack of integrity or trustworthiness; assumption of a conflicting role within a root management organization; or being unable to serve in their position. Based on feedback from the current TCRs and our experience from the first 14 ceremonies, we are reviewing what changes, if any, should be made to the current model of TCR participation. Comments Comments are welcome on any aspect of the consultation, and specifically on the following questions: 1. Is the current TCR model effectively performing its function of ensuring trust in the KSK management process? 2. Is the current size of the TCR pool appropriate to ensure sufficient participation in the ceremonies, while not overburdening the
RE: Need trusted NTP Sources
-Original Message- From: Notify Me [mailto:notify.s...@gmail.com] Sent: Thursday, February 06, 2014 4:54 AM To: Aled Morris Cc: nanog@nanog.org; Martin Hotze Subject: Re: Need trusted NTP Sources Raspberries! Not common currency here either, but let's see! While I would be using a Pi if I were doing it now, a few years ago I put together a circuit that used a $100 outdoor mast-mount GPS receiver* with a PPS out, to feed an RS232 connection to 3 FreeBSD 8.1 systems compiled with: options PPS_SYNC# I don't know if that is still required in 10.0, and I understand Linux has since fixed the kernel time resolution issues it was having, so research into current OS configuration is required. To make the local time reference preferred over external references, in ntp conf: server 127.127.20.1 mode 8 minpoll 4 maxpoll 4 prefer The diagram is at http://tndh.net/~tony/GPS-PPS-5v-ttl_232-box.pdf While there is 'some assembly required', the components to feed existing servers may be easier to come by than a Pi, and an outdoor receiver will have better reception than the Adafruit one stuck inside a datacenter. As others have said, several external references help protect against any one source having a bad day, but you should also be aware that network asymmetry WILL impact your results so factor topology into your source selection. Using this setup and OWAMP** I was able to track down a ~20ms peering asymmetry between HE Comcast inside the Seattle Westin colo, which still persists.*** It would appear from the time delay that one of their intermediaries is not really present in the building, but using a fiber loop to a city about 400 miles away (Boise, or Medford ??). I am not aware of the specific topology, other than traceroute shows different intermediaries in each direction at one IP hop, with one taking 20ms longer than the other to move between the same HE Comcast routers inside that colo. What I can see is the impact it has of showing the IPv6 connected NTP peers as ~10ms off of the local IPv4 ones the GPS receiver. Good luck * MR-350P http://www.amazon.com/Globalsat-Waterproof-External-Receiver-without/dp/B001 ENYWJC/ref=sr_sp-atf_title_1_1?ie=UTF8qid=1391734470sr=8-1keywords=mr-350 p ** OWAMP http://software.internet2.edu/owamp/ *** ntpq -p remote refid st t when poll reach delay offset jitter == xPPS(1) .PPS.0 l7 16 3770.0000.001 0.002 oGPS_NMEA(1) .GPS.0 l7 16 3770.0000.001 0.002 *bigben.cac.wash .GPS.1 u 69 64 372 13.0581.638 36.654 +clock.fmt.he.ne .CDMA. 1 u 15 64 373 32.6411.938 28.828 -chronos6.es.net .CDMA. 1 u9 64 377 92.321 10.473 2.335 -2001:4f8:2:d::1 129.6.15.29 2 u 31 64 377 35.5459.912 43.519 -time0.apple.com 17.150.142.121 2 u2 64 377 44.922 -1.275 26.193 grateful for all the input and responses, this list is amazing as usual. On Thu, Feb 6, 2014 at 1:41 PM, Aled Morris al...@qix.co.uk wrote: On 6 February 2014 12:30, Martin Hotze m.ho...@hotze.com wrote: I'm trying to help a company I work for to pass an audit, and we've been told we need trusted NTP sources (RedHat doesn't cut it). Being located in Nigeria, Africa, [...] So build your own stratum 1 server (maybe a second one with DCF77 or whatever you can use for redundancy), I don't think DCF77 is going to reach Nigeria. Aled
Re: Need trusted NTP Sources
- Original Message - From: Mark Milhollan m...@pixelgate.net Generally speaking, you'll need at least 3 sources if you want stablity. My usual practice is to set up two in house servers, each of which talks to: time.windows.com time.apple.com and one of the NIST servers 0.us.pool.ntp.org 1.us.pool.ntp.org 2.us.pool.ntp.org and each other. And then point everyone in house to both of them, assuming they accept multiple server names. But I am young, and not much travelled. :-) 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: Need trusted NTP Sources
On 2/6/2014 8:24 PM, Jay Ashworth wrote: Mailing lists aren't *supposed* to set Reply-To, Larry; your mail client is supposed to have a Reply To List command. It does. And does not light up for most of the lists I am on (including one I own). I am apparently not bright enough to notice when it does light up. Most consumer MUAs, of course, don't. Reply-All is a (usually) winked-upon subterfuge, or you can do like I do and just manually readjust the To header when you reply to the list. The later apparently requiring even more brain power than I able to bring to bear on the problem. A FB community I am part of has several people in it that work in the same company--much flapping about a message sent to all--including people on continents who have no capability of being interested. Much don't send replies to all--sent to all. Just don't do what I do and accidentally set it to NANOG when you're replying to a different list's message. :-) I was mildly chastised yesterday about a lengthy thread that I started about GPSs on MTRA when I could swear that I started on MTR. Old age has not been kind to me. Cheers, -- jra And I did consider sending this just to Jay, but decided the public humbling would be good. You need not bother everybody to tell me I was wrong. Again. It will get warm again someday. I'm pretty sure. -- 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: Need trusted NTP Sources
- Original Message - From: Larry Sheldon larryshel...@cox.net After all these years I still can not get used to the non-standard NANOG response to reply. I wonder if there is a way for ne to fix that. Noo!!! Everybody!!! Don't reply to that!!! :-) Mailing lists aren't *supposed* to set Reply-To, Larry; your mail client is supposed to have a Reply To List command. Most consumer MUAs, of course, don't. Reply-All is a (usually) winked-upon subterfuge, or you can do like I do and just manually readjust the To header when you reply to the list. Just don't do what I do and accidentally set it to NANOG when you're replying to a different list's message. :-) 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
Based on your description, it sounds like the outage did not bring your BGP session down, as such you were connected and advertising to the broken Service Provider. e.g. Cogent typically does multi-hop bgp, as such if there a network outage past the BGP router, you will experience the situation you described. 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. 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@nanog.org Sent: Thursday, February 6, 2014 5:25:53 PM Subject: Re: carrier comparison 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. It sucks for us, because we're a small school and don't have someone in a NOC to monitor our networks 24x7. I literally had to get out of bed and disable our BGP session with them for us to get through the outage. I was getting around 90% packet loss from my home to our router. On 2/6/2014 4:57 PM, Eric Flanery (eric) wrote: Vlade, When you say that they still advertise your routes, do you mean: A: That you were having them originate your routes, and they failed to stop doing so when they had problems? Or... B: That routes you were originating continued to be propagated by them, even though your session with them was down? Or... C: Something else. I ask, as we are considering some cheap Cogent bandwidth in the not-too-distant future, to allow us to keep commit rates low on higher quality connections. 'A' wouldn't be a real problem, since we run our own AS and originate our own routes; 'B' could be potentially devastating. On Thu, Feb 6, 2014 at 8:04 AM, Vlade Ristevski vrist...@ramapo.edu mailto:vrist...@ramapo.edu wrote: We have had Cogent over Verizon's Fiber for more than a few years now. Cogent goes down once at year at minimum. They had 2 outages in a single day a couple days ago in Northern NJ. One in the AM ..caused by a power outage in a vendor data center where Cogent is collocated. They went on to have another outage at around 9:30 PM on the same day for which I'm still waiting for an RFO. During this outage, they still were advertising our BGP routes so we didn't fail over to our 2nd provider. I notice that happens alot with them. When they go down, they still advertise your routes. As far as price goes, for us Cogent is cheap but Lightpath is cheaper. Our college is kind of far from things so we don't have a lot of outside fiber coming. The last mile fiber for both of our connections are different from our Internet providers. I've never had a big issue with the two working with each other. The only issue we had is I suspected we weren't getting as much bandwidth as we paid for. They had to work out where the policer and/or bottle neck was. This is the only issue we had in 5 years with this set up and it got resolved. IME, when there is a full outage, it's always been clear who the responsible party is. On 2/6/2014 10:17 AM, Adam Greene wrote: Hi, We're a small ISP / datacenter with a Time Warner fiber-based DIA contract that is coming up for renewal. We're getting much better pricing offers from Cogent, and are finding out what Level 3 can do for us as well. Both providers will use Time Warner fiber for last mile. My questions are: - Will we be sacrificing quality if we spring for Cogent? (yesterday's Cogent/Verizon thread provided some cold chills for my spine) - Is there a risk with contracting a carrier that utilizes another carrier (such as Time Warner) for the last mile? (i.e. if there is a downtime situation, are we going to be caught in a web of confusion and finger-pointing that delays problem resolution)? - How are peoples' experiences with L3 vs TWC? Although I assume everyone on the list would be interested in what others have to say about these questions, out of respect for the carriers in
RE: Need trusted NTP Sources
This doesn't address the full-mesh part, but this discussion suggests at least four servers, but better to have five. http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers#Section_5 .3.3. Frank -Original Message- From: Saku Ytti [mailto:s...@ytti.fi] Sent: Thursday, February 06, 2014 10:34 AM To: nanog@nanog.org Subject: Re: Need trusted NTP Sources On (2014-02-06 07:24 -0800), Michael DeMan wrote: A) Run a local set of NTP servers - these are your 'trusted' servers, under your control, properly managed/secured, fully meshed, etc. I'm not sure if full-mesh is best practice, the external clients should have full view of as close to source data as possible. If in full-mesh you're already masking the data with inaccuracy, giving the clients less information to make decision? We used to have full-mesh in our meinbergs, until from their recommendation we removed it completely. It makes sense to me, but I don't understand the issue deeply. -- ++ytti
RE: SIP on FTTH systems
And then you need MACFF to overcome the split-horizon to that customers in the same subnet can talk to each other. =) Frank -Original Message- From: Mark Tinka [mailto:mark.ti...@seacom.mu] Sent: Thursday, February 06, 2014 8:09 AM To: nanog@nanog.org Subject: Re: SIP on FTTH systems On Thursday, February 06, 2014 03:51:51 PM Anders Löwinger wrote: This is a deep hole, and basically does not work with IPv6. You need a bunch of stuff, proxy ND, proxy DAD, DHCPv6 inspection, RA guard and more. One VLAN per customer and a separate multicast is much simpler. If you have a reasonably intelligent AN (like some of today's Active-E devices), you can create so-called split horizons on the same bridge domain (VLAN, really) where customers will only communicate via the upstream BNG at Layer 3. At Layer 2, even though they are all sitting on the same VLAN, there is no inter-communication between them. I've also know Huawei OLT's support these split horizons too. Or do something bold, run L3 at the edge :) BNG's are too big to distributed that deeply, even in distributed BNG designs. This would get costly. Cheap switches that have decent IP/MPLS support are mostly geared toward Metro-E deployments, i.e., business-grade services. So they are quite poor with regard to susbcriber management features and capabilities. Mark.
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: SIP on FTTH systems
On Fri, 7 Feb 2014, Jay Ashworth wrote: 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. But creating a solution where you can talk to anyone else on the Internet but not the ones in your own neighborhood is broken, so it needs to be fixed. In IPv4 I've seen this solved with local-proxy-arp within the subnet, 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. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: SIP on FTTH systems
- Original Message - From: Mikael Abrahamsson swm...@swm.pp.se On Fri, 7 Feb 2014, Jay Ashworth wrote: 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. But creating a solution where you can talk to anyone else on the Internet but not the ones in your own neighborhood is broken, so it needs to be fixed. In IPv4 I've seen this solved with local-proxy-arp within the subnet, 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 did not show my work. I apologize. I will try again: If I am a commercial customer of an eyeball ISP like Road Runner: *I am entitled to expect that that ISP is technically capable of protecting me from possible attack traffic from that other customer*, who's outside my administrative span of control. If they can send me traffic directly across a local access subnet, that requires a much larger hammer than if such traffic must cross the edge concentrator first, the configuration I assert is a better choice. Does that help? 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 Fri, 7 Feb 2014, Jay Ashworth wrote: If I am a commercial customer of an eyeball ISP like Road Runner: *I am entitled to expect that that ISP is technically capable of protecting me from possible attack traffic from that other customer*, who's outside my administrative span of control. If they can send me traffic directly across a local access subnet, that requires a much larger hammer than if such traffic must cross the edge concentrator first, the configuration I assert is a better choice. Does that help? 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. -- Mikael Abrahamssonemail: swm...@swm.pp.se
