Re: IPv6? Why, you are the first one to ask for it!
On 2011-3-2, at 5:03, JC Dill wrote: You can use their reply to an IPv6 request as a bit of a bozo filter A senior technical person at my local (consumer) ISP here just told me that their IPv6 plans are at an early stage and lots of work has to be done before they can start testing. (I asked if they had plans for a friendly user test I could join.) He also said that they understand that IPv6 is not ready because OS vendors have not implemented IPsec. Talk about a bozo filter... Lars PS: ISP is DNA/Welho. smime.p7s Description: S/MIME cryptographic signature
Postfix spam
Hello, I am being attacked by a lot of spams on my postfix box. What is the best way to block them and fix this for good? It is so bad some of my IPs have been black listed. Thanks for your help. -- Best Regards, Peter R. *** *
Re: Postfix spam
MAAWG best practices - please see http://www.maawg.org for several best practice documents. If your IPs are getting blacklisted - they are emitting spam. Please email me offlist and I'll try to help you with some suggestions On Wed, Mar 2, 2011 at 2:16 PM, Peter Rudasingwa peter.rudasin...@altechstream.rw wrote: I am being attacked by a lot of spams on my postfix box. What is the best way to block them and fix this for good? It is so bad some of my IPs have been black listed. -- Suresh Ramasubramanian (ops.li...@gmail.com)
Video explaining [RPKI] Resource Certification
Under the NRO flag, we have just released a short video about Resource Certification, giving a high-level explanation of what it is and why it is important for your organisation: http://youtu.be/rH3CPosGNjY I hope to release another video going into more detail, outlining what it means practically for an operator. To get an idea of the practical side for now, here is a video we released earlier on how to set up and use the hosted Resource Certification service the RIPE NCC provides: http://youtu.be/Q0C0kEYa1d8 Kind regards, Alex Band Product Manager, RIPE NCC
Re: IPv6? Why, you are the first one to ask for it!
On Wednesday 02 March 2011 03:03:22 JC Dill wrote: I *love* using Bozo filters. Anytime you can trick companies into revealing their true colors, you are a step ahead in the game. jc AKA the Brown MM gambit. -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them signature.asc Description: This is a digitally signed message part.
Re: IPv6? Why, you are the first one to ask for it!
On Tue, Mar 1, 2011 at 3:16 PM, Franck Martin fra...@genius.com wrote: Don't forget there is no commission for the salesperson to enable IPv6 for you, so definitively they are not interested and you asking them to deal with the issue, will just lower their pay at the end of the month because they could not use this valuable time to find customers with commissions... Well, if there is a sale to be made at all, and IPv6 is a requirement for that particular sale, then any (other) commission is dependant on enabling IPv6.So if you need to buy IPv6, make it a required condition before you agree to buy service, or let them know that $other_big_provider is offering IPv6. Sale = Possible commission. No sale = No commission, period. You were the very first to ask for it. Sounds like an excuse to me. No excuse validates a complete lack of cognisance of IPv6 at this point. Providers have had plenty of time to train their sales staff. One can only hope their technical staff are ready to deal with any IPv6 connectivity issues... You were the very first to ask for it does not instill much confidence or make a good impression of the provider, even if IPv6 does turn out to be available from them. -- -Jh
Re: What vexes VoIP users?
- Original Message - From: Michael Thomas m...@mtcc.com Yes, really. The only difference was which L2 channels the RTP packets were flowed onto, which was determined by the MGCP/SIP signalling and interaction with the telephony gateway. There is a **very** complicated state machine that deals with this using some bastardized IETF protocols (COPS IIRC). Ok, see, now I (like, I suspect, Frank Bulk) am confused again: when you say which L2 channels the RTP packets were flowed onto, that sounds to me a *whole* lot like which VLAN on the end-user drop carried the RTP packets from the terminal adapter in their cable box to our concentrator... which is pretty much the point I was originally trying to make, if perhaps in slightly different terms. Am I still misunderstanding you? Cheers, -- jra
Re: Switch with 24x SFP PVLAN QinQ Layer 2
Adam, Have you looked at the Calix E7 platform or the Adtran TA5000? Both are Layer 2 only. Nick Colton Allo Communications On Wed, Mar 2, 2011 at 3:19 AM, Adam Armstrong li...@memetic.org wrote: Hi All, I'm scouring the Internet for potential devices to use in a FTTB/FTTP scenario. Requirements are basically just 24/48 SFP ports, PVLAN and selective QinQ. Most devices that fit the requirements are Layer 3, which pushes the cost per port too high. Has anyone come across anything I've not found yet? Thanks, adam.
Re: What vexes VoIP users?
As I said, this second channel doesn't exist in almost all cases (its not cost effective nor needed in almost all cases). Having said that over the top VOIP providers do suffer in comparison because they don't get the benefit of prioritization in the local cable plant. Cost-effective? Could you expand on how the provisioning of a second virtual pipe down the hill to a cable box has any incremental costs at all? Cheers, -- jra Because it takes either another 6 MHz on the downstream side that could be used for a TV channel as well as 3.2 MHz (or 6.4 MHz for =D2) on the upstream side. It also takes the CMTS interfaces, which are not cheap even with the advent of high capacity cards QAMs for D3. On top of all this it also takes more time on the design and management side because you have to make sure all of your nodes are getting both sets of channels and you have to make sure your provisioning or CMTS config keeps the EMTA's on the right channels. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 http://twitter.com/kscotthelms
RE: Switch with 24x SFP PVLAN QinQ Layer 2
Rad ETX 1002 and ETX 201A as CPE -Original Message- From: Nick Colton [mailto:ncol...@allophone.net] Sent: Wednesday, March 02, 2011 9:17 AM To: Adam Armstrong Cc: nanog@nanog.org Subject: Re: Switch with 24x SFP PVLAN QinQ Layer 2 Adam, Have you looked at the Calix E7 platform or the Adtran TA5000? Both are Layer 2 only. Nick Colton Allo Communications On Wed, Mar 2, 2011 at 3:19 AM, Adam Armstrong li...@memetic.org wrote: Hi All, I'm scouring the Internet for potential devices to use in a FTTB/FTTP scenario. Requirements are basically just 24/48 SFP ports, PVLAN and selective QinQ. Most devices that fit the requirements are Layer 3, which pushes the cost per port too high. Has anyone come across anything I've not found yet? Thanks, adam.
Re: What vexes VoIP users?
Frank, No, not all. There seems to be some confusion here between the concept of PacketCable flows which everyone _should_ (but aren't) be using to prioritize their voice traffic and separate downstream and upstream channels which a few operators use for voice traffic only. On 3/2/2011 12:55 AM, Frank Bulk wrote: Scott: Are you saying that the large MSOs don't use CM configuration files that create separate downstream and upstream service flows for Internet, voice signaling, and voice bearer traffic? Frank -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 http://twitter.com/kscotthelms
RES: Switch with 24x SFP PVLAN QinQ Layer 2
We bought Extreme Networks Summit x350 for FTTx purposes. -- Eduardo Schoedler -Mensagem original- De: Adam Armstrong [mailto:li...@memetic.org] Enviada em: quarta-feira, 2 de março de 2011 07:20 Para: nanog@nanog.org Assunto: Switch with 24x SFP PVLAN QinQ Layer 2 Hi All, I'm scouring the Internet for potential devices to use in a FTTB/FTTP scenario. Requirements are basically just 24/48 SFP ports, PVLAN and selective QinQ. Most devices that fit the requirements are Layer 3, which pushes the cost per port too high. Has anyone come across anything I've not found yet? Thanks, adam. smime.p7s Description: S/MIME cryptographic signature
Re: What vexes VoIP users?
On Tue, 01 Mar 2011 23:55:16 CST, Frank Bulk said: Are you saying that the large MSOs don't use CM configuration files that create separate downstream and upstream service flows for Internet, voice signaling, and voice bearer traffic? So the cable company carves out a protected flow for its own triple-play telephone, while third-party VoIP vendors have to contend on the Internet flow? Why aren't the net-neutrality people busy having a cow over this? pgpgHw2hZpuxE.pgp Description: PGP signature
Issues with 23.1.64.0/20?
Anyone else see anything / know of any odd behavior on the prefix yesterday afternoon/today? Here in Miami (NAP) we saw some issues through one of our upstreams and ended up disabling the BGP session, then re-enabling it with a filter to block said prefix. We've since removed the filter and things are stable but would be nice to know what broke 'out there.' Ernesto M. Rubi Sr. Network Engineer AMPATH/CIARA Florida International Univ, Miami Reply-to: erne...@cs.fiu.edu Cell: 786-282-6783
Re: What vexes VoIP users?
What everyone is actually *selling* commercially, except for cable providers, is *not* VoIP; it's a subset of that: VoN; Voice Over Internet; where the IP transport *goes over the public internet*, and through whatever exchange points may be necessary to get from you to the provider. Hmm, I don't know if this is a useful distinction. I do know that is not the common usage for VoN. VoN is more commonly understood to be Voice over Network which is a superset of VOIP rather than a subset. http://en.wikipedia.org/wiki/Voip http://bit.ly/f9u08K Cable companies are selling you *one hop* (maybe 2 or 3; certainly not 12-18), over a link with bandwidth protected from whatever may be going on on the Internet IP link they're also selling you; and which is therefore guaranteed to have better quality than whatever VoIP service it might be competing with. That also depends. While the most common method for cable operators is Packet Cable using dedicated links to and from the softswitch/session border controller that is by no means universal. Here are two companies I know of that specialize in selling pure SIP solutions, which are often back hauled across the public Internet. http://xcastlabs.com/ https://www.momentumtelecom.com/ I wasn't suggesting QOS. I was suggesting *there's a completely separate pipe*, on non-Internet connected IP transport, carrying only the voice traffic, directly to a termination point, which is dedicated from the triple-play box and nailed up. Are you suggesting that's *not* how it's being done in production? In some cases, there is a dedicated connection to the underlying MGCP/SIP network and in others there is not. In some cases there is an MPLS connection with QoS over the public Internet and in others there is prioritization at all. (I don't recommend the latter, but its usually an economic issue.) Cheers, -- jra -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 http://twitter.com/kscotthelms
Re: What vexes VoIP users?
On 3/2/2011 10:40 AM, valdis.kletni...@vt.edu wrote: On Tue, 01 Mar 2011 23:55:16 CST, Frank Bulk said: Are you saying that the large MSOs don't use CM configuration files that create separate downstream and upstream service flows for Internet, voice signaling, and voice bearer traffic? So the cable company carves out a protected flow for its own triple-play telephone, while third-party VoIP vendors have to contend on the Internet flow? Why aren't the net-neutrality people busy having a cow over this? You mean besides the fact that most of the net neutrality wonks don't know nor want to know how stuff works? -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 http://twitter.com/kscotthelms
Re: IPv6? Why, you are the first one to ask for it!
On 02/03/11 2:55 AM, Alexander Harrowell wrote: On Wednesday 02 March 2011 03:03:22 JC Dill wrote: I *love* using Bozo filters. Anytime you can trick companies into revealing their true colors, you are a step ahead in the game AKA the Brown MM gambit. Exactly! Per Wikipedia: http://en.wikipedia.org/wiki/Rider_%28theater%29#Unreasonable_Requests Van Halen requested in the technical rider that a bowl of MMs be provided in their dressing room with the brown ones removed (failure to do so would not only mean that the band would not perform, but the venue would still have to pay the full fee). The objective of this wasn't due to any excesses on the part of the band, but was a method to determine how much attention to detail the crew at a local venue paid to the requests specified in the rider. Should the bowl be absent, or if brown MMs were present, it would give band members reason to suspect other, legitimate, technical and safety issues were also being performed poorly or were outright overlooked. David Lee Roth stated in his autobiography that this request was done as a result of faulty workmanship at a venue on an earlier tour which nearly cost the life of a member of Van Halen's road crew, as well as $85,000 damage to the venue and their own equipment.
RE: What vexes VoIP users?
Thanks for clarifying. I can't imagine an MSO using separate DS and US QAMs for their eMTAs. Regardless, the customer's Internet would flow over those same QAMs (unless it was a D3 channel-bonding eMTA, and even then I'm not sure if the CMTS could be provisioned to use one QAM for voice and the remaining QAMs for data). Frank -Original Message- From: Scott Helms [mailto:khe...@ispalliance.net] Sent: Wednesday, March 02, 2011 9:27 AM To: frnk...@iname.com Cc: nanog@nanog.org Subject: Re: What vexes VoIP users? Frank, No, not all. There seems to be some confusion here between the concept of PacketCable flows which everyone _should_ (but aren't) be using to prioritize their voice traffic and separate downstream and upstream channels which a few operators use for voice traffic only. On 3/2/2011 12:55 AM, Frank Bulk wrote: Scott: Are you saying that the large MSOs don't use CM configuration files that create separate downstream and upstream service flows for Internet, voice signaling, and voice bearer traffic? Frank -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 http://twitter.com/kscotthelms
Re: What vexes VoIP users?
On 03/02/2011 06:23 AM, Jay Ashworth wrote: - Original Message - From: Michael Thomasm...@mtcc.com Yes, really. The only difference was which L2 channels the RTP packets were flowed onto, which was determined by the MGCP/SIP signalling and interaction with the telephony gateway. There is a **very** complicated state machine that deals with this using some bastardized IETF protocols (COPS IIRC). Ok, see, now I (like, I suspect, Frank Bulk) am confused again: when you say which L2 channels the RTP packets were flowed onto, that sounds to me a *whole* lot like which VLAN on the end-user drop carried the RTP packets from the terminal adapter in their cable box to our concentrator... which is pretty much the point I was originally trying to make, if perhaps in slightly different terms. Am I still misunderstanding you? They're kind of like VLAN's, but not exactly. It's been a long time since I worked on this... The RTP is flowed over what is called unsolicited grants (UGS) which give slots on the upstream for transmission. There are several other types of qos treatment between the CM and CMTS... I think that packetcable flows the MGCP and SIP over nrt-PS, but I might be misremembering. The signalling between the CM (MTA) and CMS (eg MGCP) is what fields the requests for better qos treatment for the RTP stream, and the CMS talks to the CMTS via COPS to set up the UGS flows to the cable modem/voice box (ie, an embedded MTA). In any case, this is 100% IP end to end, with all kinds of goodies for LEA and privacy to boot, which make the entire problem of faithfully reproducing the PSTN over IP a giant headache. Mike, I should know about the LEA aspect since I was the first one at Cisco to find and then dutifully step on that mine
RE: What vexes VoIP users?
Yes, that's how PacketCable works. Here's some CLI output -- nothing like a quick example to make that clear. Here's a customer with 8M/512K Internet service: CMTS:7A#sh cable modem 0008.0ed2.0928 svc-flow-id Service flow id Interface Flow Direction Flow Max Rate 1 cable 0/0 Upstream 512000 2 cable 0/0 Downstream 800 CMTS:7A# Here's a customer with 128K/128K Internet service and two additional service flows for voice signaling: CMTS:7A#sh cable modem 0013.1192.f867 svc-flow-id Service flow id Interface Flow Direction Flow Max Rate 3593 cable 0/1 Upstream 128000 3594 cable 0/1 Upstream 12000 3595 cable 0/1 Downstream 128000 3596 cable 0/1 Downstream3 CMTS:7A# And here's a customer with 2M/2M Internet service with a call in progress. Note the additional service flows, with sufficient bandwidth and overhead for a G.711 call. CMTS:7A#show cable modem 0015.a275.efd3 svc-flow-id Service flow id Interface Flow Direction Flow Max Rate 4425 cable 1/1 Upstream2048000 4426 cable 1/1 Upstream 12000 4427 cable 1/1 Downstream 2048000 4428 cable 1/1 Downstream3 8745 cable 1/1 Upstream 92800 29314 cable 1/1 Downstream87200 CMTS:7A# Remember, PacketCable is not Internet VoIP and I don't think any MSO has claimed it is such. It doesn't run over the Internet connection and is not given priority within the Internet flow. That's why there should be no net neutrality concerns. Frank -Original Message- From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] Sent: Wednesday, March 02, 2011 9:40 AM To: frnk...@iname.com Cc: 'Scott Helms'; nanog@nanog.org Subject: Re: What vexes VoIP users? On Tue, 01 Mar 2011 23:55:16 CST, Frank Bulk said: Are you saying that the large MSOs don't use CM configuration files that create separate downstream and upstream service flows for Internet, voice signaling, and voice bearer traffic? So the cable company carves out a protected flow for its own triple-play telephone, while third-party VoIP vendors have to contend on the Internet flow? Why aren't the net-neutrality people busy having a cow over this?
Re: What vexes VoIP users?
Frank, It gets better (which is sad) in the case of Charter if a customer ordered voice and data they were given a normal Moto SB for Internet data and a separate Arris eMTA (with no CPEs allowed other than the TA and the Ethernet port disabled) for voice. The channels they were using for voice even terminated on a different CMTS altogether. On 3/2/2011 11:26 AM, Frank Bulk wrote: Thanks for clarifying. I can't imagine an MSO using separate DS and US QAMs for their eMTAs. Regardless, the customer's Internet would flow over those same QAMs (unless it was a D3 channel-bonding eMTA, and even then I'm not sure if the CMTS could be provisioned to use one QAM for voice and the remaining QAMs for data). Frank -Original Message- From: Scott Helms [mailto:khe...@ispalliance.net] Sent: Wednesday, March 02, 2011 9:27 AM To: frnk...@iname.com Cc: nanog@nanog.org Subject: Re: What vexes VoIP users? Frank, No, not all. There seems to be some confusion here between the concept of PacketCable flows which everyone _should_ (but aren't) be using to prioritize their voice traffic and separate downstream and upstream channels which a few operators use for voice traffic only. On 3/2/2011 12:55 AM, Frank Bulk wrote: Scott: Are you saying that the large MSOs don't use CM configuration files that create separate downstream and upstream service flows for Internet, voice signaling, and voice bearer traffic? Frank -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 http://twitter.com/kscotthelms
Re: What vexes VoIP users?
On 03/01/2011 11:50 PM, Owen DeLong wrote: It's worked out great for me in a number of places. OTOH, it was kind of dicey even without the torrents from other places. I found that bandwidth and jitter were the bigger issues than other applications I was sharing the link with. I even managed to get passable call quality (though far from ideal) calling the US on a US third party provider from my soft-phone on my laptop from Kigali, Rwanda. I think that's close to a worst case scenario, frankly. These days, voice is a very low-bandwidth service. On any decent link, it seems to get through just fine. Right, if it wasn't skype would be useless which it manifestly isn't. Which is why all the heavy machinery to dynamically provision qos for the rtp flows was, per typical, overwhelmed by moore's law. I floated that heresy about 10 years ago, but by then there was too much invested in seeing it through. Mike, skype shows you can do all manner of horrible things and still work... real time media over tcp!
RE: What vexes VoIP users?
The service class for the bearer stream, at least on modern configurations with Moto, is DefVoiceDown and DefUGS. The signaling is DefRRDown and DefRRUp. MSOs may create different service classes with unique names, so our (plain vanilla configuration which uses the default names) may not be representative of other implementations. Frank -Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Wednesday, March 02, 2011 10:36 AM To: Jay Ashworth Cc: NANOG Subject: Re: What vexes VoIP users? On 03/02/2011 06:23 AM, Jay Ashworth wrote: - Original Message - From: Michael Thomasm...@mtcc.com Yes, really. The only difference was which L2 channels the RTP packets were flowed onto, which was determined by the MGCP/SIP signalling and interaction with the telephony gateway. There is a **very** complicated state machine that deals with this using some bastardized IETF protocols (COPS IIRC). Ok, see, now I (like, I suspect, Frank Bulk) am confused again: when you say which L2 channels the RTP packets were flowed onto, that sounds to me a *whole* lot like which VLAN on the end-user drop carried the RTP packets from the terminal adapter in their cable box to our concentrator... which is pretty much the point I was originally trying to make, if perhaps in slightly different terms. Am I still misunderstanding you? They're kind of like VLAN's, but not exactly. It's been a long time since I worked on this... The RTP is flowed over what is called unsolicited grants (UGS) which give slots on the upstream for transmission. There are several other types of qos treatment between the CM and CMTS... I think that packetcable flows the MGCP and SIP over nrt-PS, but I might be misremembering. The signalling between the CM (MTA) and CMS (eg MGCP) is what fields the requests for better qos treatment for the RTP stream, and the CMS talks to the CMTS via COPS to set up the UGS flows to the cable modem/voice box (ie, an embedded MTA). In any case, this is 100% IP end to end, with all kinds of goodies for LEA and privacy to boot, which make the entire problem of faithfully reproducing the PSTN over IP a giant headache. Mike, I should know about the LEA aspect since I was the first one at Cisco to find and then dutifully step on that mine
RE: What vexes VoIP users?
Wow, I was not aware of that, what a management and maintenance nightmare. Do they still do this? Frank -Original Message- From: Scott Helms [mailto:khe...@ispalliance.net] Sent: Wednesday, March 02, 2011 10:49 AM To: frnk...@iname.com Cc: nanog@nanog.org Subject: Re: What vexes VoIP users? Frank, It gets better (which is sad) in the case of Charter if a customer ordered voice and data they were given a normal Moto SB for Internet data and a separate Arris eMTA (with no CPEs allowed other than the TA and the Ethernet port disabled) for voice. The channels they were using for voice even terminated on a different CMTS altogether. On 3/2/2011 11:26 AM, Frank Bulk wrote: Thanks for clarifying. I can't imagine an MSO using separate DS and US QAMs for their eMTAs. Regardless, the customer's Internet would flow over those same QAMs (unless it was a D3 channel-bonding eMTA, and even then I'm not sure if the CMTS could be provisioned to use one QAM for voice and the remaining QAMs for data). Frank -Original Message- From: Scott Helms [mailto:khe...@ispalliance.net] Sent: Wednesday, March 02, 2011 9:27 AM To: frnk...@iname.com Cc: nanog@nanog.org Subject: Re: What vexes VoIP users? Frank, No, not all. There seems to be some confusion here between the concept of PacketCable flows which everyone _should_ (but aren't) be using to prioritize their voice traffic and separate downstream and upstream channels which a few operators use for voice traffic only. On 3/2/2011 12:55 AM, Frank Bulk wrote: Scott: Are you saying that the large MSOs don't use CM configuration files that create separate downstream and upstream service flows for Internet, voice signaling, and voice bearer traffic? Frank -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 http://twitter.com/kscotthelms
Re: What vexes VoIP users?
Frank, I hope not, but the sales guy I knew (he was the one who sold all of the VOIP only CMTSs) is in a different field now. Their architecture was crummy and their reasoning for doing obtuse, but my friend was happy to sell them the gear. On 3/2/2011 11:52 AM, Frank Bulk wrote: Wow, I was not aware of that, what a management and maintenance nightmare. Do they still do this? Frank -Original Message- From: Scott Helms [mailto:khe...@ispalliance.net] Sent: Wednesday, March 02, 2011 10:49 AM To: frnk...@iname.com Cc: nanog@nanog.org Subject: Re: What vexes VoIP users? Frank, It gets better (which is sad) in the case of Charter if a customer ordered voice and data they were given a normal Moto SB for Internet data and a separate Arris eMTA (with no CPEs allowed other than the TA and the Ethernet port disabled) for voice. The channels they were using for voice even terminated on a different CMTS altogether. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 http://twitter.com/kscotthelms
Re: Switch with 24x SFP PVLAN QinQ Layer 2
Requirements are basically just 24/48 SFP ports, PVLAN and selective QinQ. Most devices that fit the requirements are Layer 3, which pushes the cost per port too high. Cisco ME6524 has a model with 32 SFP ports (24 with 3:1 oversubscription, 8 non-oversubscribed) and IP Base IOS which has very limited L3 features (RIP and EIGRP stub only), focused on Layer 2 deployments. Rubens
Re: Switch with 24x SFP PVLAN QinQ Layer 2
On 02/03/2011 18:26, Rubens Kuhl wrote: Requirements are basically just 24/48 SFP ports, PVLAN and selective QinQ. Most devices that fit the requirements are Layer 3, which pushes the cost per port too high. Cisco ME6524 has a model with 32 SFP ports (24 with 3:1 oversubscription, 8 non-oversubscribed) and IP Base IOS which has very limited L3 features (RIP and EIGRP stub only), focused on Layer 2 deployments. Hardware is still ridiculously expensive for purposes. adam.
TWTelecom DNS issues...
ns1.twtelecom.net and ns2.twtelecom.net (along with some other DNS servers, ns1.orng.twtelecom.net and ns1.ptld.twtelecom.net) suddenly stopped serving DNS for domains it's not authoritative for this morning. Requests are being actively refused from within their network. Caused a small issue for us, just thought I'd pass along. -wil
Re: TWTelecom DNS issues...
On Wed, Mar 2, 2011 at 1:38 PM, Wil Schultz wschu...@bsdboy.com wrote: ns1.twtelecom.net and ns2.twtelecom.net (along with some other DNS servers, ns1.orng.twtelecom.net and ns1.ptld.twtelecom.net) suddenly stopped serving DNS for domains it's not authoritative for this morning. Requests are being actively refused from within their network. Caused a small issue for us, just thought I'd pass along. they were recursing previously and are no longer? that seems like a win... or did I misconstrue what you said?
RE: Switch with 24x SFP PVLAN QinQ Layer 2
I would take a look at a Ciena 3940 and other models. They look to be cost effective for layer 2 deployments. -Original Message- From: Adam Armstrong [mailto:li...@memetic.org] Sent: Wednesday, March 02, 2011 4:20 AM To: nanog@nanog.org Subject: Switch with 24x SFP PVLAN QinQ Layer 2 Hi All, I'm scouring the Internet for potential devices to use in a FTTB/FTTP scenario. Requirements are basically just 24/48 SFP ports, PVLAN and selective QinQ. Most devices that fit the requirements are Layer 3, which pushes the cost per port too high. Has anyone come across anything I've not found yet? Thanks, adam.
Re: Switch with 24x SFP PVLAN QinQ Layer 2
On Wed, Mar 2, 2011 at 1:26 PM, Rubens Kuhl rube...@gmail.com wrote: Requirements are basically just 24/48 SFP ports, PVLAN and selective QinQ. Most devices that fit the requirements are Layer 3, which pushes the cost per port too high. Cisco ME6524 has a model with 32 SFP ports (24 with 3:1 oversubscription, 8 non-oversubscribed) and IP Base IOS which has very limited L3 features (RIP and EIGRP stub only), focused on Layer 2 deployments. Rubens The ME3600X might be more a more appropriate Cisco solution than the ME6524. The ME3600X is one of the current metro MDU access CPE device of choice. 2x10GE and 24xGE SFP or Copper versions with Metro Feature set. http://www.cisco.com/en/US/products/ps10956/index.html *In the spirit of full disclosure I am biased towards this vendor
Re: Switch with 24x SFP PVLAN QinQ Layer 2
On 02/03/2011 19:19, James Brown wrote: On Wed, Mar 2, 2011 at 1:26 PM, Rubens Kuhl rube...@gmail.com mailto:rube...@gmail.com wrote: Requirements are basically just 24/48 SFP ports, PVLAN and selective QinQ. Most devices that fit the requirements are Layer 3, which pushes the cost per port too high. Cisco ME6524 has a model with 32 SFP ports (24 with 3:1 oversubscription, 8 non-oversubscribed) and IP Base IOS which has very limited L3 features (RIP and EIGRP stub only), focused on Layer 2 deployments. Rubens The ME3600X might be more a more appropriate Cisco solution than the ME6524. The ME3600X is one of the current metro MDU access CPE device of choice. 2x10GE and 24xGE SFP or Copper versions with Metro Feature set. http://www.cisco.com/en/US/products/ps10956/index.html *In the spirit of full disclosure I am biased towards this vendor Still much too expensive :) adam.
Re: TWTelecom DNS issues...
On Mar 2, 2011, at 11:17 AM, Christopher Morrow wrote: On Wed, Mar 2, 2011 at 1:38 PM, Wil Schultz wschu...@bsdboy.com wrote: ns1.twtelecom.net and ns2.twtelecom.net (along with some other DNS servers, ns1.orng.twtelecom.net and ns1.ptld.twtelecom.net) suddenly stopped serving DNS for domains it's not authoritative for this morning. Requests are being actively refused from within their network. Caused a small issue for us, just thought I'd pass along. they were recursing previously and are no longer? that seems like a win... or did I misconstrue what you said? They definitely do use ns1.twtelecom.net and ns2.twtelecom.net for hosting purposes (which probably shouldn't recurse), but they also generically recommend their clients to use them for recursion. Whatever the issue, all of their DNS servers that I tested lost the ability to recurse for about an hour. They are *mostly* working at this point, but not consistently. Not a huge operational issue, but I'm sure there are some folks that this hit a little bit.
Re: Switch with 24x SFP PVLAN QinQ Layer 2
Requirements are basically just 24/48 SFP ports, PVLAN and selective QinQ. Most devices that fit the requirements are Layer 3, which pushes the cost per port too high. ... The ME3600X might be more a more appropriate Cisco solution than the ME6524. The ME3600X is one of the current metro MDU access CPE device of choice. 2x10GE and 24xGE SFP or Copper versions with Metro Feature set. http://www.cisco.com/en/US/products/ps10956/index.html *In the spirit of full disclosure I am biased towards this vendor Still much too expensive :) If the ME3600X is much too expensive, it's possible your expectations for pricing aren't realistic. Selective QinQ is pretty new, and tends to be found only in provider type equipment. If you can live without that, normal (non selective) QinQ is offered on most switches today. In that case several different Extreme switches might be of interest. Steinar Haug, Nethelp consulting, sth...@nethelp.no
RE: Switch with 24x SFP PVLAN QinQ Layer 2
If the ME3600X is much too expensive, it's possible your expectations for pricing aren't realistic. Selective QinQ is pretty new, and tends to be found only in provider type equipment. If you can live without that, normal (non selective) QinQ is offered on most switches today. In that case several different Extreme switches might be of interest. Steinar Haug, Nethelp consulting, sth...@nethelp.no Finding switches that will do private vlans, selective QinQ and the requirement for 24SFP ports is a combination that adds up to a switch in the $5,000 to $7,000 range even without layer 3 from most of the vendors whose products I use. Best one I have been able to come up with price-wise that seems to meet your requirements is Huawei Quidway S5300 (S5328C-EI-24S) which seems to be in the $3000 neighborhood but I have never used their gear.
Re: What vexes VoIP users?
- Original Message - From: Valdis Kletnieks valdis.kletni...@vt.edu On Tue, 01 Mar 2011 23:55:16 CST, Frank Bulk said: Are you saying that the large MSOs don't use CM configuration files that create separate downstream and upstream service flows for Internet, voice signaling, and voice bearer traffic? So the cable company carves out a protected flow for its own triple-play telephone, while third-party VoIP vendors have to contend on the Internet flow? Why aren't the net-neutrality people busy having a cow over this? Ok, see, Valdis; this was where I started this conversation, and -- I think because I was merely using terms they didn't like for the objects involved -- everyone told me no, that wasn't what was really going on. But it sure *sounds* like what I thought was going on, really is (ie: the condition about which you inquire, above). And it wouldn't be Net Neutrality: it would be common-carrier equal access. I think. Cheers, -- jra
Re: TWTelecom DNS issues...
On Mar 3, 2011, at 2:42 AM, Wil Schultz wrote: Not a huge operational issue, but I'm sure there are some folks that this hit a little bit. As Chris indicates, it would be a big win if recursion were disabled on the authoritative servers, and instead handled by dedicated caching-only recursors which would only answer queries from within their network. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
Re: TWTelecom DNS issues...
- Original Message - From: Christopher Morrow morrowc.li...@gmail.com On Wed, Mar 2, 2011 at 1:38 PM, Wil Schultz wschu...@bsdboy.com wrote: ns1.twtelecom.net and ns2.twtelecom.net (along with some other DNS servers, ns1.orng.twtelecom.net and ns1.ptld.twtelecom.net) suddenly stopped serving DNS for domains it's not authoritative for this morning. Requests are being actively refused from within their network. Caused a small issue for us, just thought I'd pass along. they were recursing previously and are no longer? that seems like a win... or did I misconstrue what you said? Not if you're an end user who was configured, for some reason, to use them as a recursive server... which is what I infer from the fact that he posted it. In which case, it would be useful for Wil to provide us the IP addresses of those servers as he understand them, since that is what such affected users would have programmed... Cheers, -- jra
Re: TWTelecom DNS issues...
On Mar 2, 2011, at 6:31 PM, Jay Ashworth wrote: - Original Message - From: Christopher Morrow morrowc.li...@gmail.com On Wed, Mar 2, 2011 at 1:38 PM, Wil Schultz wschu...@bsdboy.com wrote: ns1.twtelecom.net and ns2.twtelecom.net (along with some other DNS servers, ns1.orng.twtelecom.net and ns1.ptld.twtelecom.net) suddenly stopped serving DNS for domains it's not authoritative for this morning. Requests are being actively refused from within their network. Caused a small issue for us, just thought I'd pass along. they were recursing previously and are no longer? that seems like a win... or did I misconstrue what you said? Not if you're an end user who was configured, for some reason, to use them as a recursive server... which is what I infer from the fact that he posted it. In which case, it would be useful for Wil to provide us the IP addresses of those servers as he understand them, since that is what such affected users would have programmed... Cheers, -- jra Oh sure, here are the ones that I tested and can confirm were down. Well, not down but actively refusing queries. ns1.iplt.twtelecom.net (64.132.94.250) ns1.milw.twtelecom.net (216.136.95.2) ns1.orng.twtelecom.net (168.215.210.50) ns1.snan.twtelecom.net (168.215.165.186) ns1.twtelecom.net (216.136.95.2, 2001:4870:6082:3::5) ns2.twtelecom.net (64.132.94.250, 2001:4870:8000:3::5) ns1.twtelecom.net and ns2.twtelecom.net are well known to be authoritative for a number of domain, and I would have presumed that the rest would be their recursive servers. I found an old welcome letter from them that states ns1.twtelecom.net and ms2.twtelecom.net were the preferred forwarders on the circuit. Some other network segments use their other resolvers but weren't affected because our internal boxes cache. I can't speak as to why they have it set up this way, but that's the list I have and every single one wasn't working from within or outside of their network. From my testing authoritative requests were never denied, however. There was a complete outage for a bit over an hour, then it was intermittent for a couple hours after that. Also, good or bad, all of the above servers recurse from on and off their network once again. Their NOC gave me a resolution of Added an ACL to block an IP address. :-) Regardless, I'm not using their resolvers anymore but thought it would be helpful in case anyone else saw a segment of their network start yammering about facebook and twitter being down. -wil
Ranges announced by Level3 without permitions.
Hello All! Maybe somebody could help me with some issue: Ranges below are announced by Level3 79.110.224.0/20*[BGP/170] 08:23:34, MED 0, localpref 150, from 213.248.64.245 AS path: 3356 79.110.64.0/20 *[BGP/170] 08:25:07, MED 0, localpref 150, from 213.248.64.245 AS path: 3356 Both ranges are from RIPE region and couldn't be announced from ARIN ASN at all. We're sponsored LIR for both companies, I sent several emails to Level3 noc, made several calls but they still announce these ranges. -- Andrew
