Re: Question on the topology of Internet Exchange Points
Greg VILLAIN wrote: > I'm not saying one should convert every single IX peering into a PNI, as > I feel both are pretty much required: your smallest peers shall be > secured on as many IXes as possible, your biggest ones via PNI. IX > peering is mandatory to keep internet routing diversity up to par - and > enable small ASes to grow. The converse can also be true - we have a number of members who use the IX fabric as a backup to their PIs with larger peering partners. If you lose a PI carrying a GE of traffic, where does that traffic go? -- Will Hargrave [EMAIL PROTECTED] Technical Director LONAP Ltd
Re: Question on the topology of Internet Exchange Points
On Feb 15, 2008, at 8:04 AM, Greg VILLAIN wrote: Obvious as it is, if one of your peerings on an IX gets big in terms of in/out volumes, you HAVE to secure it by PNI. You need a way to prevent the IX's equipments from being a SPoFs between you and that peer. "HAVE to" is such a strong phrase. First, who said the switch is a SPoF? And since when is a PNI not a SPoF? If the peer is that big, you should peer in more than one place. For instance, LINX has two LANs, or you can use PAIX and Equinix. Connecting to a "big peer" in a single location, whether over PNI or shared switch, creates a SPoF. Peering in multiple locations removes the SPoF, regardless of the method. I'm not saying one should convert every single IX peering into a PNI, as I feel both are pretty much required: your smallest peers shall be secured on as many IXes as possible, your biggest ones via PNI. IX peering is mandatory to keep internet routing diversity up to par - and enable small ASes to grow. Using shared for small peers and direct for big peers is a time honored practice on the Internet. But you can justify this in finance, not just engineering. A fiber x-conn costs less than an IX port (usually). Any peer big enough to take up a significant fraction of the IX port probably justifies the CapEx for a dedicated router port. Does this make things more reliable? Many would argue it does. I would argue that large IXes have amazing uptime these days. The MAEs & GigaSwitches are long gone, public IXes are no longer guaranteed to give you problems. Also, it is a wrong assumption to state that IX will make you spare money on transit, from my perspective they should be seen as securing multiple narrower paths to the internet. Do you mean "save money on transit" when you say "make you spare money on transit"? Just want to make sure we are on the same page. That is not an assumption, it is a provable - or disprovable! - fact. If you run the numbers and the IX saves you money, well, it saves you money. If it does not, it does not. Where does the word "assumption" come in? That doesn't mean they are not also additional vectors. But Item #1 does not conflict with Item #2. -- TTFN, patrick
Re: Looking for Verizon-GNI network engineer
It has been my experience that data center engineers doing NOC support at Verizon do speak to paying customers about routing issues for premium data center services. -Henry - Original Message From: K. Scott Bethke <[EMAIL PROTECTED]> To: nanog@merit.edu Sent: Thursday, February 14, 2008 6:49:13 PM Subject: Looking for Verizon-GNI network engineer Sorry if this is off-topic frustration has set in. I've got what looks like a routing loop or a wedge in your network and I cant get past tier2 saying it is an "internet problem". I asked to speak with an engineer directly was told Verizon engineers don't talk directly with customers. Issue going on for 4 days. $ traceroute www.tickerforum.org traceroute to www.tickerforum.org (70.169.168.7), 64 hops max, 40 byte packets 1 10.254.123.1 (10.254.123.1) 3.219 ms 1.085 ms 0.915 ms 2 L301.VFTTP-02.CLPPVA.verizon-gni.net (71.171.93.1) 6.329 ms 6.281 ms 5.036 ms 3 P2-3.LCR-02.CLPPVA.verizon-gni.net (130.81.37.194) 4.885 ms 4.091 ms 6.490 ms 4 so-7-0-0-0.PEER-RTR1.ASH.verizon-gni.net (130.81.10.94) 4.731 ms 8.248 ms 5.167 ms 5 130.81.15.238 (130.81.15.238) 5.926 ms 130.81.15.190 (130.81.15.190) 6.586 ms 9.158 ms 6 * * * 7 * * * 8 * $ traceroute www.google.com traceroute: Warning: www.google.com has multiple addresses; using 64.233.169.104 traceroute to www.l.google.com (64.233.169.104), 64 hops max, 40 byte packets 1 10.254.123.1 (10.254.123.1) 1.774 ms 1.117 ms 0.909 ms 2 L301.VFTTP-02.CLPPVA.verizon-gni.net (71.171.93.1) 5.820 ms 4.029 ms 4.861 ms 3 P2-3.LCR-01.CLPPVA.verizon-gni.net (130.81.37.192) 8.036 ms 6.346 ms 7.671 ms 4 so-6-3-1-0.BB-RTR2.RES.verizon-gni.net (130.81.29.82) 6.524 ms 8.161 ms 8.408 ms 5 * * * 6 * * * Ticket # is VAD01QVDW -Scott
