Re: DOCSIS 3.0 & PPPoE/L2TP compatibility
Hey Michael, Thanks for the feedback. From the scenarios below, I think that option 3 would be more feasible, i.e BSoD L2VPN, via pw. Our max expected number of sessions would not exceed 10k, so probably not an hw limiting issue for us. For option 4, we cannot accommodate this, as we are moving to ASR1K, which does not support PPTP, only L2TP. I am reading through the DOCSIS L2VPN specification to understand the model better. Thanks, On 7/31/2012 9:03 PM, Michael Bowe wrote: Hi iptech As others have said, early Cisco CMTS could do full bridging and/or PPPoE termination, but newer gear is typically L3 style only. For wholesale, the cableco could do one of these : * L2 solution : Change your customers to configured as DOCSIS BSoD L2VPN, and deliver you one dot1q VLAN per customer. You can continue to use PPPoE with this config (sessions landing directly on your LNS). Gotcha: don't know about Arris, but Cisco caps you at 4K VLANs per chassis which means this solution doesn't scale all that well. * L2 solution : Change your customers to be setup as DOCSIS BSoD L2VPN, and deliver you one MPLS pseudowire per customer. You can continue to use PPPoE with this config (sessions landing directly on your LNS). Gotcha: don't know about Arris, but Cisco caps you at 16K pw per chassis which means this solution only provides moderate scaling. Also you have to somehow terminate all these pw (which are "xconnect"s in Cisco-speak). * L3 soution : change your customers to land on a dedicated bundle and VRF. Apply policy based routing to force-forward all the CPE traffic up a VLAN to you. If you want to be able to authenticate/count/shape then you probably need to terminate this traffic as IPoE (Use a dedicated BNG, or maybe you could try Cisco ISG). Cableco would provide the DHCP for the CM, you would provide the DHCP for the CPE. CMTS would insert CM MAC as option 82 so you know which CPE belongs to which CM/customer. * L3 solution : last option is to do what they proposed. I would probably still implement this with a dedicated bundle and VRF. But rather than having to land the sessions as IPoE, you can now have them come in as PPTP. This allows you to authenticate/count/shape via your LNS. Hope that helps, Michael.
Re: Fwd: Re: DOCSIS 3.0 & PPPoE/L2TP compatibility
Hi Scott, Thanks for the feedback, yes this is how I understand it also, however I find it strange that the Cisco platform designated as the future LNS will not accommodate the DOCSIS 3.0requirements - not much collaboration. There is no roadmap for introcducing PPTP on the ASR1K that I can see, so i will not be holding out for one. I am veering towards using a L2 pw solution, but would be interested to hear what you have used in-house yourself to accommodate this change, care to share? Thanks On 7/31/2012 5:46 PM, Scott Helms wrote: I've actually run into this specific problem and the issue your running into is that at no time was PPPoE part of the DOCSIS specification. It was supported on several CMTSs because the Cisco UBR shares much of its OS with more mainline Cisco routers which support L2TP and a host of other non-DOCSIS related protocols. It was also widely supported on some of the earliest CMTSs which were bridges instead of routers (then you needed a separate box to be the LNS). The real problem isn't a change in DOCSIS version but that they choose a platform that doesn't share a code base with a general purpose router. This could have been happenstance or by design, but I can tell you your chances of getting PPPoE to work at all on that platform (even for the cable operator) are not high because the box will not operate as a bridge and there is no (AFAIK) way to relay the PPP discover packets. The D3 Arris is either a C4 or a C4C: http://www.arrisi.com/products/product.asp?id=3 On 7/30/2012 8:33 AM, iptech wrote: Hi, We are a small ISP and have a setup in place with the local cable company for terminating their users via L2TP for Internet access. However they have just announced to us that they are moving to a DOCSIS 3.0 compliant setup, and this standard no longer supports PPPoE via L2TP, and can now only offer PPTP for terminating with us. We have already begun replacing our Cisco 7206VXR LNS devices with Cisco ASR 1Ks and as you will be aware the older 7206 can do both L2TP and PPTP, whereas the ASR1k can do only L2TP. I do not have any experience in the cable arena, but from what I have read in the DOCSIS standards, each version has maintained backwards compatibility, therefore I am very surprised our CableCo has claimed they cannot do PPPoE/L2TP anymore. The CMTS they are currently using is a Cisco, and now they are moving to a new ARRIS CMTS. I have not been able to find any information on this device and what it can do or not. With the ASR1K marked as the natural upgrade path for LNS functions, therefore I cannot believe that it is not fully compatible with DOCSIS 3.0. From what I can tell the only way to accommodate the new CMTS PPTP connections will be to terminate them on the legacy 7206VXR, which at the end of the day is a backwards step. I would greatly appreciate if anyone can give me any pointers and/or suggestions on this matter, so I can understand it and move it forward. FYI: The driver for the CMTS upgrades is to offer higher bandwidth access speeds 15mb-20mb. Thank you.
Re: Fwd: Re: DOCSIS 3.0 & PPPoE/L2TP compatibility
We ended up using something like this to separate out the traffic at layer 2 for each ISP: http://www.cablelabs.com/cablemodem/downloads/specs/CM-SP-L2VPN-I03-061222.pdf Look at section 5.1.2 Multiple ISP L2VPNs Basically the modems get DHCP & their config from the cable operator but the CPEs get DHCP (and IP connectivity) from the individual ISPs. On 8/1/2012 10:17 AM, iptech wrote: Hi Scott, Thanks for the feedback, yes this is how I understand it also, however I find it strange that the Cisco platform designated as the future LNS will not accommodate the DOCSIS 3.0requirements - not much collaboration. There is no roadmap for introcducing PPTP on the ASR1K that I can see, so i will not be holding out for one. I am veering towards using a L2 pw solution, but would be interested to hear what you have used in-house yourself to accommodate this change, care to share? Thanks On 7/31/2012 5:46 PM, Scott Helms wrote: I've actually run into this specific problem and the issue your running into is that at no time was PPPoE part of the DOCSIS specification. It was supported on several CMTSs because the Cisco UBR shares much of its OS with more mainline Cisco routers which support L2TP and a host of other non-DOCSIS related protocols. It was also widely supported on some of the earliest CMTSs which were bridges instead of routers (then you needed a separate box to be the LNS). The real problem isn't a change in DOCSIS version but that they choose a platform that doesn't share a code base with a general purpose router. This could have been happenstance or by design, but I can tell you your chances of getting PPPoE to work at all on that platform (even for the cable operator) are not high because the box will not operate as a bridge and there is no (AFAIK) way to relay the PPP discover packets. The D3 Arris is either a C4 or a C4C: http://www.arrisi.com/products/product.asp?id=3 On 7/30/2012 8:33 AM, iptech wrote: Hi, We are a small ISP and have a setup in place with the local cable company for terminating their users via L2TP for Internet access. However they have just announced to us that they are moving to a DOCSIS 3.0 compliant setup, and this standard no longer supports PPPoE via L2TP, and can now only offer PPTP for terminating with us. We have already begun replacing our Cisco 7206VXR LNS devices with Cisco ASR 1Ks and as you will be aware the older 7206 can do both L2TP and PPTP, whereas the ASR1k can do only L2TP. I do not have any experience in the cable arena, but from what I have read in the DOCSIS standards, each version has maintained backwards compatibility, therefore I am very surprised our CableCo has claimed they cannot do PPPoE/L2TP anymore. The CMTS they are currently using is a Cisco, and now they are moving to a new ARRIS CMTS. I have not been able to find any information on this device and what it can do or not. With the ASR1K marked as the natural upgrade path for LNS functions, therefore I cannot believe that it is not fully compatible with DOCSIS 3.0. From what I can tell the only way to accommodate the new CMTS PPTP connections will be to terminate them on the legacy 7206VXR, which at the end of the day is a backwards step. I would greatly appreciate if anyone can give me any pointers and/or suggestions on this matter, so I can understand it and move it forward. FYI: The driver for the CMTS upgrades is to offer higher bandwidth access speeds 15mb-20mb. Thank you. -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 http://twitter.com/kscotthelms
Re: [c-nsp] DOCSIS 3.0 & PPPoE/L2TP compatibility
Ray, Yes PITA indeed. Our 7200 are G2, but we were still planning on moving away from them. I presume you guys are staying on the 7200s meantime, to accomodate the PPTP requirement? Thanks, On 7/31/2012 10:35 PM, Ray Burkholder wrote: As far as I can tell, and from my conversations with the guys at Cablevision, there isn't anything underhanded. The ARRIS gear simply doesn't do PPPOE stuff. They've looked at various scenarios, and PPTP seems to be the winner. Their Cisco CMTS gear was EOL'd a long time ago, and I don't think there is/was a migration path for handling recent DOCSIS and speeds. So they side stepped it. Their ARRIS box is a single chassis with a redundant cards in it. With DOCSIS 3, they get better speeds and stuff out of it. I havn't seen the numbers, but I gather it will handily handle all the traffic for all the ISP's. It does become a PITA for us as ISP's, as we have to convert all our subscribers over to PPTP. What are you doing with your old 7200's? Are they G2's? Ray. -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of iptech Sent: Tuesday, July 31, 2012 12:28 To: Brian Mengel Cc: cisco-...@puck.nether.net Subject: Re: [c-nsp] DOCSIS 3.0 & PPPoE/L2TP compatibility Thanks Brian, I am struggling with this one, as I suspect the cableco are skipping round a problem with their in house setup, and trying to make me bend to get it working, which I am reluctant to do, as its a big step backwards for us. They are moving from a Cisco CMTS to a Arris, therefore it is highly possible this will be a new box. What they have told me is that their CMTS setup will now be L3 as opposed to L2. The reasons behind this are not clear. Appreciate any pointers on this one. Thanks v much. On 7/31/2012 11:54 AM, Brian Mengel wrote: We run a mix of Cisco and Arris CMTS in our network and have found both to share the same feature set (at least for the features we need). If there is a problem with L2TP its not going to be the result of the DOCSIS 3.0 upgrade but rather an issue with the Arris CMTS. I would recommend getting a technical contact at Arris from your partner MSO and explaining your situation to them and seeing what they can provide as a resolution. Its possible that the Arris outright doesn't support L2TP, but I suspect there may be other things going on. On Sat, Jul 28, 2012 at 6:48 PM, iptech wrote: Hi, No takers? Would really appreciate some feedback/pointers. Thank you. On 7/27/2012 2:57 PM, iptech wrote: Hi, We are a small ISP and have a setup in place with the local cable company for terminating their users via L2TP for Internet access. However they have just announced to us that they are moving to a DOCSIS 3.0 compliant setup, and this standard no longer supports PPPoE via L2TP, and can now only offer PPTP for terminating with us. We have already begun replacing our Cisco 7206VXR LNS devices with Cisco ASR 1Ks and as you will be aware the older 7206 can do both L2TP and PPTP, whereas the ASR1k can do only L2TP. I do not have any experience in the cable arena, but from what I have read in the DOCSIS standards, each version has maintained backwards compatibility, therefore I am very surprised our CableCo has claimed they cannot do PPPoE/L2TP anymore. The CMTS they are currently using is a Cisco, and now they are moving to a new ARRIS CMTS. I have not been able to find any information on this device and what it can do or not. With the ASR1K marked as the natural upgrade path for LNS functions, therefore I cannot believe that it is not fully compatible with DOCSIS 3.0. From what I can tell the only way to accommodate the new CMTS PPTP connections will be to terminate them on the legacy 7206VXR, which at the end of the day is a backwards step. I would greatly appreciate if anyone can give me any pointers and/or suggestions on this matter, so I can understand it and move it forward. FYI: The driver for the CMTS upgrades is to offer higher bandwidth access speeds 15mb-20mb. Thank you. ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [c-nsp] DOCSIS 3.0 & PPPoE/L2TP compatibility
I did PPPoE for open access on cable networks starting back in DOCSIS 1.0 and that (and PPTP for that matter) is a dead end IMO. Get to BSoD/TLS which is a CableLabs (the guys who write and test the DOCSIS spec) standard and will be supported on all of the D3 chassis no matter if its Arris, Cisco, Motorola, or Casa. The guys at the cable company could have gone with a Cisco 10k or a 7225(smaller systems only) and I believe both of those still support being a LNS for PPPoE, but again Cisco is really the only one and good luck getting any help from their TAC on setting it up. On 8/1/2012 10:57 AM, iptech wrote: Ray, Yes PITA indeed. Our 7200 are G2, but we were still planning on moving away from them. I presume you guys are staying on the 7200s meantime, to accomodate the PPTP requirement? Thanks, On 7/31/2012 10:35 PM, Ray Burkholder wrote: As far as I can tell, and from my conversations with the guys at Cablevision, there isn't anything underhanded. The ARRIS gear simply doesn't do PPPOE stuff. They've looked at various scenarios, and PPTP seems to be the winner. Their Cisco CMTS gear was EOL'd a long time ago, and I don't think there is/was a migration path for handling recent DOCSIS and speeds. So they side stepped it. Their ARRIS box is a single chassis with a redundant cards in it. With DOCSIS 3, they get better speeds and stuff out of it. I havn't seen the numbers, but I gather it will handily handle all the traffic for all the ISP's. It does become a PITA for us as ISP's, as we have to convert all our subscribers over to PPTP. What are you doing with your old 7200's? Are they G2's? Ray. -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of iptech Sent: Tuesday, July 31, 2012 12:28 To: Brian Mengel Cc: cisco-...@puck.nether.net Subject: Re: [c-nsp] DOCSIS 3.0 & PPPoE/L2TP compatibility Thanks Brian, I am struggling with this one, as I suspect the cableco are skipping round a problem with their in house setup, and trying to make me bend to get it working, which I am reluctant to do, as its a big step backwards for us. They are moving from a Cisco CMTS to a Arris, therefore it is highly possible this will be a new box. What they have told me is that their CMTS setup will now be L3 as opposed to L2. The reasons behind this are not clear. Appreciate any pointers on this one. Thanks v much. On 7/31/2012 11:54 AM, Brian Mengel wrote: We run a mix of Cisco and Arris CMTS in our network and have found both to share the same feature set (at least for the features we need). If there is a problem with L2TP its not going to be the result of the DOCSIS 3.0 upgrade but rather an issue with the Arris CMTS. I would recommend getting a technical contact at Arris from your partner MSO and explaining your situation to them and seeing what they can provide as a resolution. Its possible that the Arris outright doesn't support L2TP, but I suspect there may be other things going on. On Sat, Jul 28, 2012 at 6:48 PM, iptech wrote: Hi, No takers? Would really appreciate some feedback/pointers. Thank you. On 7/27/2012 2:57 PM, iptech wrote: Hi, We are a small ISP and have a setup in place with the local cable company for terminating their users via L2TP for Internet access. However they have just announced to us that they are moving to a DOCSIS 3.0 compliant setup, and this standard no longer supports PPPoE via L2TP, and can now only offer PPTP for terminating with us. We have already begun replacing our Cisco 7206VXR LNS devices with Cisco ASR 1Ks and as you will be aware the older 7206 can do both L2TP and PPTP, whereas the ASR1k can do only L2TP. I do not have any experience in the cable arena, but from what I have read in the DOCSIS standards, each version has maintained backwards compatibility, therefore I am very surprised our CableCo has claimed they cannot do PPPoE/L2TP anymore. The CMTS they are currently using is a Cisco, and now they are moving to a new ARRIS CMTS. I have not been able to find any information on this device and what it can do or not. With the ASR1K marked as the natural upgrade path for LNS functions, therefore I cannot believe that it is not fully compatible with DOCSIS 3.0. From what I can tell the only way to accommodate the new CMTS PPTP connections will be to terminate them on the legacy 7206VXR, which at the end of the day is a backwards step. I would greatly appreciate if anyone can give me any pointers and/or suggestions on this matter, so I can understand it and move it forward. FYI: The driver for the CMTS upgrades is to offer higher bandwidth access speeds 15mb-20mb. Thank you. ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___
UCSF Network Admin??
Hello, Is there anyone with clue from UCSF on-list? Or if someone knows how to put me in contact with them, that would be great. We are not able to query their DNS servers from our network. We've got users not able to access anything UCSF due to this. Thus far, their response has been to manually put DNS entries into our users hosts file, not actually fix the real issue. Thanks, -Robert
Re: UCSF Network Admin??
On 08/01/12 10:51 , Robert Glover wrote: > We are not able to query their DNS servers from our network. We've got > users not able to access anything UCSF due to this. I am querying them OK. I am in US AZ. I am also able to reach manana.garlic.com. [hyperion]/usr/local# dig www.ucsf.edu @ucsfns2.ucsf.edu www.ucsf.edu. 3600IN A 64.54.132.50 ucsf.edu. 3600IN NS ucsfns1.ucsf.edu. ucsf.edu. 3600IN NS adns2.Berkeley.edu. ucsf.edu. 3600IN NS adns1.Berkeley.edu. ucsf.edu. 3600IN NS ucsfns2.ucsf.edu. adns1.Berkeley.edu. 172800 IN A 128.32.136.3 adns1.Berkeley.edu. 3600IN 2607:f140::fffe::3 adns2.Berkeley.edu. 172800 IN A 128.32.136.14 adns2.Berkeley.edu. 3600IN 2607:f140::fffe::e ucsfns1.ucsf.edu. 3600IN A 128.218.254.10 ucsfns2.ucsf.edu. 3600IN A 128.218.254.40 ;; Query time: 41 msec ;; SERVER: 128.218.254.40#53(128.218.254.40) ;; WHEN: Wed Aug 1 11:02:46 2012 ;; MSG SIZE rcvd: 270
Re: UCSF Network Admin??
Ditto on that from TWTC in Milwaukee, WI. # dig www.ucsf.edu @ucsfns2.ucsf.edu ; <<>> DiG 9.8.1-P1 <<>> www.ucsf.edu @ucsfns2.ucsf.edu ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49793 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 6 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.ucsf.edu. IN A ;; ANSWER SECTION: www.ucsf.edu. 3600IN A 64.54.132.50 ;; AUTHORITY SECTION: ucsf.edu. 3600IN NS adns1.Berkeley.edu. ucsf.edu. 3600IN NS ucsfns2.ucsf.edu. ucsf.edu. 3600IN NS adns2.Berkeley.edu. ucsf.edu. 3600IN NS ucsfns1.ucsf.edu. ;; ADDITIONAL SECTION: adns1.Berkeley.edu. 172800 IN A 128.32.136.3 adns1.Berkeley.edu. 3600IN 2607:f140::fffe::3 adns2.Berkeley.edu. 172800 IN A 128.32.136.14 adns2.Berkeley.edu. 3600IN 2607:f140::fffe::e ucsfns1.ucsf.edu. 3600IN A 128.218.254.10 ucsfns2.ucsf.edu. 3600IN A 128.218.254.40 ;; Query time: 63 msec ;; SERVER: 128.218.254.40#53(128.218.254.40) ;; WHEN: Wed Aug 1 13:48:51 2012 ;; MSG SIZE rcvd: 259 On Wed, Aug 1, 2012 at 1:07 PM, Henry Stryker wrote: > > > On 08/01/12 10:51 , Robert Glover wrote: > > We are not able to query their DNS servers from our network. We've got > > users not able to access anything UCSF due to this. > > > I am querying them OK. I am in US AZ. I am also able to reach > manana.garlic.com. > > [hyperion]/usr/local# dig www.ucsf.edu @ucsfns2.ucsf.edu > www.ucsf.edu. 3600IN A 64.54.132.50 > ucsf.edu. 3600IN NS ucsfns1.ucsf.edu. > ucsf.edu. 3600IN NS adns2.Berkeley.edu. > ucsf.edu. 3600IN NS adns1.Berkeley.edu. > ucsf.edu. 3600IN NS ucsfns2.ucsf.edu. > adns1.Berkeley.edu. 172800 IN A 128.32.136.3 > adns1.Berkeley.edu. 3600IN 2607:f140::fffe::3 > adns2.Berkeley.edu. 172800 IN A 128.32.136.14 > adns2.Berkeley.edu. 3600IN 2607:f140::fffe::e > ucsfns1.ucsf.edu. 3600IN A 128.218.254.10 > ucsfns2.ucsf.edu. 3600IN A 128.218.254.40 > ;; Query time: 41 msec > ;; SERVER: 128.218.254.40#53(128.218.254.40) > ;; WHEN: Wed Aug 1 11:02:46 2012 > ;; MSG SIZE rcvd: 270 > >
dnsmadeeasy.com
Looking for experiences regarding their DNS hosting services. Anyone have a story to share? Off-list replies would be great. thanks, ~matt
Re: Fwd: Re: DOCSIS 3.0 & PPPoE/L2TP compatibility
One thing to be mindful of is that BSoD support may not be prevelant in the installed modem base of your MSO. Replacing those modems would be costly for someone. On Wed, Aug 1, 2012 at 10:17 AM, iptech wrote: > Hi Scott, > > Thanks for the feedback, > > yes this is how I understand it also, however I find it strange that the > Cisco platform designated as the future LNS will not accommodate the DOCSIS > 3.0requirements - not much collaboration. There is no roadmap for > introcducing PPTP on the ASR1K that I can see, so i will not be holding out > for one. > > I am veering towards using a L2 pw solution, but would be interested to hear > what you have used in-house yourself to accommodate this change, care to > share? > > Thanks > > > On 7/31/2012 5:46 PM, Scott Helms wrote: >> >> >> >> >> >> >> >> >> >> >> >> >> I've actually run into this specific problem and the issue your running >> into is that at no time was PPPoE part of the DOCSIS specification. It >> was supported on several CMTSs because the Cisco UBR shares much of its >> OS with more mainline Cisco routers which support L2TP and a host of >> other non-DOCSIS related protocols. It was also widely supported on >> some of the earliest CMTSs which were bridges instead of routers (then >> you needed a separate box to be the LNS). The real problem isn't a >> change in DOCSIS version but that they choose a platform that doesn't >> share a code base with a general purpose router. This could have been >> happenstance or by design, but I can tell you your chances of getting >> PPPoE to work at all on that platform (even for the cable operator) are >> not high because the box will not operate as a bridge and there is no >> (AFAIK) way to relay the PPP discover packets. >> >> The D3 Arris is either a C4 or a C4C: >> http://www.arrisi.com/products/product.asp?id=3 >> >> On 7/30/2012 8:33 AM, iptech wrote: >>> >>> Hi, >>> >>> We are a small ISP and have a setup in place with the local cable >>> company for terminating their users via L2TP for Internet access. >>> However they have just announced to us that they are moving to a >>> DOCSIS 3.0 compliant setup, and this standard no longer supports PPPoE >>> via L2TP, and can now only offer PPTP for terminating with us. >>> >>> We have already begun replacing our Cisco 7206VXR LNS devices with >>> Cisco ASR 1Ks and as you will be aware the older 7206 can do both L2TP >>> and PPTP, whereas the ASR1k can do only L2TP. I do not have any >>> experience in the cable arena, but from what I have read in the DOCSIS >>> standards, each version has maintained backwards compatibility, >>> therefore I am very surprised our CableCo has claimed they cannot do >>> PPPoE/L2TP anymore. >>> >>> The CMTS they are currently using is a Cisco, and now they are moving >>> to a new ARRIS CMTS. I have not been able to find any information on >>> this device and what it can do or not. With the ASR1K marked as the >>> natural upgrade path for LNS functions, therefore I cannot believe >>> that it is not fully compatible with DOCSIS 3.0. >>> >>> From what I can tell the only way to accommodate the new CMTS PPTP >>> connections will be to terminate them on the legacy 7206VXR, which at >>> the end of the day is a backwards step. I would greatly appreciate if >>> anyone can give me any pointers and/or suggestions on this matter, so >>> I can understand it and move it forward. >>> >>> FYI: The driver for the CMTS upgrades is to offer higher bandwidth >>> access speeds 15mb-20mb. >>> >>> Thank you. >>> >>> >>> >>> >>> >> >> > >
Fyi...
It it is of interest... https://www.change.org/petitions/from-educause-higher-ed-wireless-networking-admin-group All the best. -- / * Dr. Robert Mathews, D.Phil. * Distinguished Senior Research Scholar * National Security Affairs & U.S Industrial Preparedness * Office of Scientific Inquiry and Applications * University of Hawai'i * E.mail: mathews at hawaii dot edu/
Re: UCSF Network Admin??
In message <50196c8e.60...@garlic.com>, Robert Glover writes: > Hello, > > Is there anyone with clue from UCSF on-list? Or if someone knows how to > put me in contact with them, that would be great. > > We are not able to query their DNS servers from our network. We've got > users not able to access anything UCSF due to this. > > Thus far, their response has been to manually put DNS entries into our > users hosts file, not actually fix the real issue. Please, please don't misuse "DNS entries". Host files DO NOT and NEVER HAVE taken "DNS entries". The contain hostname/address mappings but they are not and never bave been DNS entries. > Thanks, > -Robert > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: UCSF Network Admin??
On 08/01/2012 10:51 AM, Robert Glover wrote: > Hello, > > Is there anyone with clue from UCSF on-list? Or if someone knows how to > put me in contact with them, that would be great. > > We are not able to query their DNS servers from our network. We've got > users not able to access anything UCSF due to this. > > Thus far, their response has been to manually put DNS entries into our > users hosts file, not actually fix the real issue. > > Thanks, > -Robert > I should have been a little more forthcoming with information. We are having issues with getting responses from these servers: NSMEDCTR1.UCSFMEDICALCENTER.ORG NSMEDCTR2.UCSFMEDICALCENTER.ORG Which are authoritative for "ucsfmedctr.org" and "ucsfmedicalcenter.org". We ARE able to resolve ucsf.edu and things associated with that entity, just NOT the medical center. Thanks, -Robert
cost of misconfigurations
Hi all, I am looking for literature on the (monetary) costs of misconfigurations in an operational ISP network. Are there any such studies I can benefit from? In a larger context, are there any thorough studies exploring the cost of building and running a large ISP network? Best, -Murat Murat Yuksel Associate Professor Graduate Director Department of Computer Science and Engineering University of Nevada, Reno 1664 N. Virginia Street, MS 171, Reno, NV 89557. Phone: +1 (775) 327 2246, Fax: +1 (775) 784 1877 E-mail: yuk...@cse.unr.edu Web: http://www.cse.unr.edu/~yuksem
Re: cost of misconfigurations
Hi Murat, I never saw any literature about this topic. But I think it is not too difficult to calculate (or estimate). A misconfiguration will, at least, impact on two points: network outage and re-work. For the network outage, you have to use the SLAs to calculate the cost (how much you lost from the customers' revenue) due to that outage. On the other hand, there is the time efforts spent to fix the misconfiguration. Under the fix, it could be removing the misconfig and applying a new one correct. Or just fixing the misconfig targeting the correct config. This re-work will translate in time, and time can be translated in money spent. Regards On 8/2/12, Murat Yuksel wrote: > Hi all, > > I am looking for literature on the (monetary) costs of misconfigurations in > an operational ISP network. Are there any such studies I can benefit from? > > In a larger context, are there any thorough studies exploring the cost of > building and running a large ISP network? > > Best, > > -Murat > > Murat Yuksel > Associate Professor > Graduate Director > Department of Computer Science and Engineering > University of Nevada, Reno > 1664 N. Virginia Street, MS 171, Reno, NV 89557. > Phone: +1 (775) 327 2246, Fax: +1 (775) 784 1877 > E-mail: yuk...@cse.unr.edu > Web: http://www.cse.unr.edu/~yuksem > > > -- Sent from my mobile device ./diogo -montagner JNCIE-SP 0x41A
Re: cost of misconfigurations
On Wed, Aug 1, 2012 at 8:08 PM, Diogo Montagner wrote: > A misconfiguration will, at least, impact on two points: network > outage and re-work. For the network outage, you have to use the SLAs > to calculate the cost (how much you lost from the customers' revenue) > due to that outage. On the other hand, there is the time efforts spent > to fix the misconfiguration. Under the fix, it could be removing the > misconfig and applying a new one correct. Or just fixing the misconfig > targeting the correct config. This re-work will translate in time, and > time can be translated in money spent. Isn't the largest cost omitted (or at least glossed over) here? Namely, lost customers due to the outage. That's why people have SLAs and rework the network at all -- to avoid that cost. -- Darius Jahandarie
Re: cost of misconfigurations
> I am looking for literature on the (monetary) costs of > misconfigurations in an operational ISP network. Are there any such > studies I can benefit from? jgs, who should know, says 42 quatloos randy
Re: cost of misconfigurations
Hi Darius, You are right. The lost of a customer due to those things. However, I would classify this as an unknown situation (in terms of risk analisys) because the others I mentioned are possible to calculate and estimate (they are known). But it is very hard to estimate if a customer will cancel the contract because 1 or n network outages. In theory, if the customer SLA is not being met consecutively, there is a potential probability he will cancel the contract. Regards On 8/2/12, Darius Jahandarie wrote: > On Wed, Aug 1, 2012 at 8:08 PM, Diogo Montagner > wrote: >> A misconfiguration will, at least, impact on two points: network >> outage and re-work. For the network outage, you have to use the SLAs >> to calculate the cost (how much you lost from the customers' revenue) >> due to that outage. On the other hand, there is the time efforts spent >> to fix the misconfiguration. Under the fix, it could be removing the >> misconfig and applying a new one correct. Or just fixing the misconfig >> targeting the correct config. This re-work will translate in time, and >> time can be translated in money spent. > > Isn't the largest cost omitted (or at least glossed over) here? > Namely, lost customers due to the outage. That's why people have SLAs > and rework the network at all -- to avoid that cost. > > > -- > Darius Jahandarie > -- Sent from my mobile device ./diogo -montagner JNCIE-SP 0x41A
Re: UCSF Network Admin??
On 08/01/12 16:22 , Robert Glover wrote: > We are having issues with getting responses from these servers: > > NSMEDCTR1.UCSFMEDICALCENTER.ORG > NSMEDCTR2.UCSFMEDICALCENTER.ORG > > Which are authoritative for "ucsfmedctr.org" and "ucsfmedicalcenter.org". Those servers respond to my queries from here in AZ: # dig www.ucsfmedicalcenter.org @nsmedctr2.ucsfmedicalcenter.org www.ucsfmedicalcenter.org. 86400 IN CNAME webmcb06.ucsfmedicalcenter.org. webmcb06.ucsfmedicalcenter.org. 86400 IN A 64.54.46.99 ;; Query time: 41 msec ;; SERVER: 64.54.50.50#53(64.54.50.50) ;; WHEN: Wed Aug 1 17:36:36 2012 ;; MSG SIZE rcvd: 93 # dig www.ucsfmedicalcenter.org @nsmedctr1.ucsfmedicalcenter.org www.ucsfmedicalcenter.org. 86400 IN CNAME webmcb06.ucsfmedicalcenter.org. webmcb06.ucsfmedicalcenter.org. 86400 IN A 64.54.46.99 ;; Query time: 54 msec ;; SERVER: 64.54.42.50#53(64.54.42.50) ;; WHEN: Wed Aug 1 17:37:41 2012 ;; MSG SIZE rcvd: 93
Re: UCSF Network Admin??
also responds here in Ohio on TW On Wed, Aug 1, 2012 at 8:44 PM, Henry Stryker wrote: > > > On 08/01/12 16:22 , Robert Glover wrote: > > We are having issues with getting responses from these servers: > > > > NSMEDCTR1.UCSFMEDICALCENTER.ORG > > NSMEDCTR2.UCSFMEDICALCENTER.ORG > > > > Which are authoritative for "ucsfmedctr.org" and "ucsfmedicalcenter.org > ". > > > Those servers respond to my queries from here in AZ: > > # dig www.ucsfmedicalcenter.org @nsmedctr2.ucsfmedicalcenter.org > www.ucsfmedicalcenter.org. 86400 IN CNAME > webmcb06.ucsfmedicalcenter.org. > webmcb06.ucsfmedicalcenter.org. 86400 IN A 64.54.46.99 > ;; Query time: 41 msec > ;; SERVER: 64.54.50.50#53(64.54.50.50) > ;; WHEN: Wed Aug 1 17:36:36 2012 > ;; MSG SIZE rcvd: 93 > > # dig www.ucsfmedicalcenter.org @nsmedctr1.ucsfmedicalcenter.org > www.ucsfmedicalcenter.org. 86400 IN CNAME > webmcb06.ucsfmedicalcenter.org. > webmcb06.ucsfmedicalcenter.org. 86400 IN A 64.54.46.99 > ;; Query time: 54 msec > ;; SERVER: 64.54.42.50#53(64.54.42.50) > ;; WHEN: Wed Aug 1 17:37:41 2012 > ;; MSG SIZE rcvd: 93 > >
Re: cost of misconfigurations
On 8/1/12, Diogo Montagner wrote: I think it's more complicated than that, the cost of misconfiguration is almost inseparable in some cases from the cost of configuration in general.; not all misconfigs are equal, so you might want to concentrate on a specific kind of misconfiguration, or a specific misconfig impact "E.g. an erroneous filter is applied, causing routes to be accepted from an EGP peer without restriction". Esp. with misconfigurations that might not have an immediately discovered impact, business impact beyond cost to discover and resolve may not be apparent, which depend on details of themisconfig, such as how trivial or 'obvious' the error should be, how consistent the problems it causes. At least if you concetrate on a certain specific type of misconfig and specific impact, you can have a basis for comparison and approximation, for just that type though. The "fix" to some types of misconfigs might sometimes be to update the design documentation, so the "misconfig" is no longer a misconfiguration;so then you can start asking about how you define "misconfig" in the first place, and the costs of having erroneous or missing documentation. Which is hard, because the "costs" of updating documentation and finding errors, less than best/optimal practices, or improvements possible in configurations, are effected by long term "costs" or loss of efficiencies resulting from failing to correct documentation, and failing to review and improve arguably suboptimal configurations. Some misconfigs or suboptimal configs are discovered by review or other measures before there is any operational impact. Some misconfigs are "safe" or "harmless" by coincidence, but can cause issues later when the network is expanded farther according to design that does not anticipate the misconfig, so the cost there is increased risk. Not all possible misconfigurations of a network cause an outage, some misconfigurations are actually design errors, not operator errors; not all network issues are outages, some configuration errors are just things like "Some entries in an access-list that are dead-weight, e.g. can never be reached, or is not necessary"; and the impact of this error is wasted memory resources, or increased complexity / more unnecessary stuff for humans to look at. (The entry might not have been dead-weight when originally added.) Correcting the deadweight ACL entry situation then is an improvement in efficiency. Not all misconfigurations are detected, either, possibly, sometimes even misconfigs that caused issues. An example of a misconfiguration that would occur frequently in some kinds of environments and might not break an uptime SLA, would be suboptimal performance, less cost-effectiveness (E.g. early upgrade required due to an unrecognized misconfiguration). Or configuration deadweight utilizing so much memory, that hardware upgrades become needed. On some networks, there might not be a formal SLA, and the end user might not notice or take issue with it. Loss of fault resilience (E.g. failover path won't work); no SLA is violated if the fault tolerance wasn't required by the SLA, and the configuration error might go undetected for years if there was not regular failover testing performed. It might be corrected before there is an issue... then the cost of "Increased risk" during the period, in which the misconfig wasn't service-effecting could be quite nebulous. > I never saw any literature about this topic. But I think it is not too > difficult to calculate (or estimate). [snip] > A misconfiguration will, at least, impact on two points: network > outage and re-work. For the network outage, you have to use the SLAs > to calculate the cost (how much you lost from the customers' revenue) > due to that outage. On the other hand, there is the time efforts spent > to fix the misconfiguration. Under the fix, it could be removing the [snip] -- -JH
Re: cost of misconfigurations
On Wed, Aug 1, 2012 at 5:32 PM, Diogo Montagner wrote: > Hi Darius, > > You are right. The lost of a customer due to those things. However, I > would classify this as an unknown situation (in terms of risk > analisys) because the others I mentioned are possible to calculate and > estimate (they are known). But it is very hard to estimate if a > customer will cancel the contract because 1 or n network outages. In > theory, if the customer SLA is not being met consecutively, there is a > potential probability he will cancel the contract. > > Regards On the end customer side, I've done a bunch of reliability / risk cost assessments for various customers over the years. It's never easy. For an ISP... customers are fairly locked in, but for big networks and customers, especially multihoming customers, business goes where they want it. SLA costs are easy. Predicting the final financial impact is hard. -- -george william herbert george.herb...@gmail.com
Re: Update from the NANOG Communications Committee regarding recent off-topic posts
On 07/30/2012 10:57 AM, Steven Noble wrote: The fix for this issue is trivial. Every new signup should require a sponsor or a deposit of funds into a new member fund. Once a member has made a relevant post regarding a NANOG related item their funds are returned. If someone spams they forfeit the money and it is used to help defray the costs of attending NANOG for the 99%. If the poster has been sponsored by a current member, said member is flogged in public at the next meeting. ...runs Sent from my iPhone On Jul 30, 2012, at 10:42 AM, "Patrick W. Gilmore" wrote: I'm sorry Panashe is upset by this rule. Interestingly, "Your search - Panashe Flack nanog - did not match any documents." So my guess is that a post from that account has not happened before, meaning the post was moderated yet still made it through. Has anyone done a data mining experiment to see how many posts a month are from "new" members? My guess is it is a trivial percentage. -- TTFN, patrick On Jul 30, 2012, at 13:35 , valdis.kletni...@vt.edu wrote: On Mon, 30 Jul 2012 21:04:36 +0200, Panashe Flack said: list for continued activity. And just for reference - have you guys SEEN the "Linux Kernel Mailing List"? - it gets frequent spam posts and yet is perfectly able to ignore the spam/irrelevant posts and continue on its remit. For those who don't drink from the Linux-Kernel firehose, it averages 1 or 2 spams per day - and anywhere from 500 to 700 postings a day. As Linus Torvalds said, back when it was averaging 200 a day: "Note that nobody reads every post in linux-kernel. In fact, nobody who expects to have time left over to actually do any real kernel work will read even half. Except Alan Cox, but he's actually not human, but about a thousand gnomes working in under-ground caves in Swansea. None of the individual gnomes read all the postings either, they just work together really well." The list managers do an incredible job of stopping spam - but even if 50 or 75 a day got through, they'd just be lost in the noise. You're skipping several hundred messages a day, skipping a few more isn't any different. Would be an iPhone user to suggest such an idea. Thanks for not implementing this so us peons can learn a thing or two, too. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Re: Fyi...
On Wed, Aug 1, 2012 at 12:50 PM, Robert Mathews (OSIA) wrote: > > It it is of interest... > > > https://www.change.org/petitions/from-educause-higher-ed-wireless-networking-admin-group I was not aware of this limitation. Android and other Chrome devices do not have issues like these. Wow. --steve
Re: Fyi...
On 8/1/2012 10:32 PM, steve pirk [egrep] wrote: > On Wed, Aug 1, 2012 at 12:50 PM, Robert Mathews (OSIA) > mailto:math...@hawaii.edu>> wrote: > > > It it is of interest... > > > https://www.change.org/petitions/from-educause-higher-ed-wireless-networking-admin-group > > > > I was not aware of this limitation. Android and other Chrome devices > do not have issues like these. Wow. > > --steve If this subject is of interest to you/your organization, you might consider signing the petition. Although this started as an academy based effort, Lee Badman of Syracuse University as originator, welcomes all parties who appreciates the impact of the problem - to sign on. All the best -- / * Dr. Robert Mathews, D.Phil. * Distinguished Senior Research Scholar * National Security Affairs & U.S Industrial Preparedness * Office of Scientific Inquiry and Applications * University of Hawai'i * E.mail: mathews at hawaii dot edu/
Re: cost of misconfigurations
Quantifying the business costs would be very complex. Here are some reports and research papers that may be a starting point: [1] Juniper Networks, Inc., “What's Behind Network Downtime?,” pp. 1–12, May 2008. [2] R. Mahajan, D. Wetherall, and T. Anderson, “Understanding BGP misconfiguration,” Proceedings of the 2002 conference on Applications, 2002. [3] A. Medem, R. Teixeira, N. Feamster, and M. Meulle, “Joint analysis of network incidents and intradomain routing changes,” Network and Service Management (CNSM), 2010 International Conference on, pp. 198–205, 2010. [4] D. Turner, K. Levchenko, A. C. Snoeren, and S. Savage, “California fault lines: understanding the causes and impact of network failures,” presented at the SIGCOMM '10: Proceedings of the ACM SIGCOMM 2010 conference on SIGCOMM, 2010. [5] Z. Yin, X. Ma, J. Zheng, Y. Zhou, L. N. Bairavasundaram, and S. Pasupathy, “An empirical study on configuration errors in commercial and open source systems,” presented at the SOSP '11: Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles, 2011. [6] Z. Kerravala, “As the Value of Enterprise Networks Escalates, So Does the Need for Configuration Management ,” cs.princeton.edu, 01-Jan.-2004. [Online]. Available: https://www.cs.princeton.edu/courses/archive/fall10/cos561/papers/Yankee04.pdf. [Accessed: 09-May-2012]. [7] W. Enck, P. McDaniel, S. Sen, and P. Sebos, “Configuration management at massive scale: System design and experience,” USENIX '07, Jun. 2007. [8] R. D. Doverspike, K. K. Ramakrishnan, and C. Chase, “Structural overview of ISP networks,” Guide to Reliable Internet Services and Applications, pp. 19–93, 2010. On 2 August 2012 10:46, George Herbert wrote: > On Wed, Aug 1, 2012 at 5:32 PM, Diogo Montagner > wrote: >> Hi Darius, >> >> You are right. The lost of a customer due to those things. However, I >> would classify this as an unknown situation (in terms of risk >> analisys) because the others I mentioned are possible to calculate and >> estimate (they are known). But it is very hard to estimate if a >> customer will cancel the contract because 1 or n network outages. In >> theory, if the customer SLA is not being met consecutively, there is a >> potential probability he will cancel the contract. >> >> Regards > > On the end customer side, I've done a bunch of reliability / risk cost > assessments for various customers over the years. It's never easy. > > For an ISP... customers are fairly locked in, but for big networks and > customers, especially multihoming customers, business goes where they > want it. > > SLA costs are easy. Predicting the final financial impact is hard. > > > -- > -george william herbert > george.herb...@gmail.com >
