Re: Question on peering strategies
I'm glad we are having this discussion. I want to clarify something, since I'm not sure I'm following the terminology. What Max referred to as "VLAN exchange" is what Equinix markets as "*private VLAN"*, right? I just copy-pasted a portion of Equinix's IX brochure that covers the services that they offer [ http://www.equinix.com/resources/data-sheets/equinix-internet-exchange/] Standard Equinix Internet Exchange Features • Public VLAN — offers access to all peering participants • Supports industry standard IEEE 802.1Q trunking encapsulation • Redundant MLPE route servers at each IX Point enabling efficient open peering • *Private VLAN* (Required: Unicast Peering VLAN enabled) — create a private broadcast domain over the public switched infrastructure that can be used for direct bi-lateral peering or to create a community of interest My question is what is the point of having such an option for peering? I understand the argument that Owen and Leo have, which is to move the bigger portion of traffic away from the IX fabric and keep the IX for smaller flows. but why would a pair of networks want a private point-to-point connection on a shared switching fabric. Is this just because that shared fabric has geographical reach, as in the case of IXReach? I also see that links provided in this discussion show Europe based networks that are using this peering type more often. Is this widely accepted that US market is totally different from Europe? Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon On Mon, May 23, 2016 at 9:50 AM, Owen DeLong <o...@delong.com> wrote: > As mentioned by others, they do exist, but usually not for exactly the > reason you state. > > In most cases, peers go to PNI instead of peering via the exchange when it > does not make > sense to grow laterally at the exchange for significant bilateral traffic. > It’s much > less expensive to get a cross-connect from my router to your router than > for both of > us to add a cross-connect to the exchange and each pay for an additional > exchange port. > > Example: If I have 12.5 gigs of traffic to the exchange and 8 gigs of that > is to > autonomous system X while the remaining 4.5 G goes to random other peers, > then it > makes much more sense for both X and I to connect directly (PNI) than for > each of > us to order an additional exchange port to support that traffic. > > Owen > > > On May 21, 2016, at 23:33 , Max Tulyev <max...@netassist.ua> wrote: > > > > Hi All, > > > > I wonder why a "VLAN exchange" does not exists. Or I do not know any? > > > > In my understanding it should be a switch, and people connected can > > easily order a private VLAN between each other (or to private group) > > through some kind of web interface. > > > > That should be a more easy and much less expensive way for private > > interconnects than direct wires. > > > > On 16.05.16 20:46, Reza Motamedi wrote: > >> Dear Nanogers, > >> > >> I have a question about common/best network interconnection practices. > >> Assume that two networks (let's refer to them as AS-a and AS-b) are > present > >> in a colocation facility say Equinix LA. As many of you know, Equininx > runs > >> an IXP in LA as well. So AS-as and AS-b can interconnct > >> 1) using private cross-connect > >> 2) through the public IXP's switching fabric. > >> Is it a common/good practice for the two networks to establish > connections > >> both through the IXP and also using a private cross-connect? > >> > >> I was thinking considering the cost of cross-connects (my understanding > is > >> that the colocation provider charges the customers for each > cross-connect > >> in addition to the rent of the rack or cage or whatever), it would not > be > >> economically reasonable to have both. Although, if the cross-connect is > the > >> primary method of interconnection, and the IXP provides a router-server > the > >> public-peering over IXP would essentially be free. So it might makes > sense > >> to assume that for the private cross-connect, there exists a back-up > >> connection though the IXP. Anyway, I guess some discussion may give more > >> insight about which one is more reasonable to assume and do. > >> > >> Now my last question is that if the two connections exist (one private > >> cross-connect and another back-up through the IXP), what are the chances > >> that periodically launched traceroutes that pass the inter-AS > connection in > >> that colo see both types of connection in a week. I guess what I'm > asking > >> is how often back-up routes are taken? Can the networks do load > balancing > >> on the two connection and essentially use them as primary routes? > >> > >> Best Regards > >> Reza Motamedi (R.M) > >> Graduate Research Fellow > >> Oregon Network Research Group > >> Computer and Information Science > >> University of Oregon > >> > >
Re: Question on peering strategies
Hi Nick, Thanks for the reply. Let me clarify another issue first, since I thought the colo's business model is different at least in the US. So if AS-a puts its router in Equinix, it should pay the same amount in the following two scenario (only considering the interconnection cost and not the rent for racks and remote hands and )? 1) AS-a only connects to the IX and establishes all inter-AS connections through the IX. 2) AS-a connects to the IX, in addition to privately connecting to bunch of other colo customers (these private connections can be either transit or settlement-free peerings). My understanding was that colos in the US charge per cross connect, so the more you connect privately, the more you pay. This article may be old, but I don't think much has changed: https://www.telegeography.com/press/press-releases/2015/02/26/colocation-cross-connect-price-disparities-remain-between-u-s-europe/index.html With respect to my second question, I was asking if is practical/reasonable to keep both the connection types to same network (say AS-b) at the same time, i.e., connect privately over a cross-connect and keep the public connection over the IX. Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon On Mon, May 16, 2016 at 11:10 AM, Nick Ellermann <nellerm...@broadaspect.com > wrote: > Reza, > You maybe overthinking this one a bit. The economics are something to > consider, however all public exchanges have different economics. With > Equinix you pay pretty much a flat rate for a single 1Gbps/10Gbps link that > includes the cost of facility cross-connect and public exchange access. It > is a nice one to many connection for all those various network and content > networks your end users would appreciate direct connectivity. Depending on > the public exchange you either have a single BGP session or a BGP session > per network you are peering. Really after that, it's just BGP routing and > route management. You do need to be careful about not being too overly > dependent on a single public switch link, in some cases like at Equinix you > may want multiple connections to redundant public exchange switches at that > site. There is a balance you want to seek of number of paid upstream > network transit providers you are connected to versus how many direct > peering arrangements you have setup. It's not usually practical for a > smaller network to have loads of BGP peers. There are lots of good > articles online about this fine balance and some good advice from > experienced network operators. > > To your later questions. For your simple example, if AS-a and AS-b were > both already on the public IX, and the link wasn't too overly critical then > using the public IX switch maybe a good first step. However as that > relationship matures, they most likely in a real world example may look to > split the cost of the private cross-connect. If it was mutually beneficial. > There is much more to public peering and transit than the technical > conversation. Most of the larger networks on the public switches won't peer > privately with anyone or only with extremely larger networks. To get a > provider such as this to peer both privately and on the public exchange is > not a technical issue, it's more of a business overhead and management > issue. > If you have a couple of quality upstream transit providers, they will be > excellent failovers to a public switch outage. Plan for the public switch > to have as many problems as any upstream provider. > > > Sincerely, > Nick Ellermann – CTO & VP Cloud Services > BroadAspect > > E: nellerm...@broadaspect.com > P: 703-297-4639 > F: 703-996-4443 > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you > received this in error, please contact the sender and delete the e-mail and > its attachments from all computers. > > -Original Message- > From: NANOG [mailto:nanog-bounces+nellermann=broadaspect@nanog.org] > On Behalf Of Reza Motamedi > Sent: Monday, May 16, 2016 1:46 PM > To: nanog@nanog.org > Subject: Question on peering strategies > > Dear Nanogers, > > I have a question about common/best network interconnection practices. > Assume that two networks (let's refer to them as AS-a and AS-b) are > present in a colocation facility say Equinix LA. As many of you know, > Equininx runs an IXP in LA as well. So AS-as and AS-b can interconnct > 1) using private cross-connect > 2) through the public IXP's switching fabric. > Is it a common/good practice for the two networks to establish connections > both through the IXP and also using a private cross-connect? > > I was th
Question on peering strategies
Dear Nanogers, I have a question about common/best network interconnection practices. Assume that two networks (let's refer to them as AS-a and AS-b) are present in a colocation facility say Equinix LA. As many of you know, Equininx runs an IXP in LA as well. So AS-as and AS-b can interconnct 1) using private cross-connect 2) through the public IXP's switching fabric. Is it a common/good practice for the two networks to establish connections both through the IXP and also using a private cross-connect? I was thinking considering the cost of cross-connects (my understanding is that the colocation provider charges the customers for each cross-connect in addition to the rent of the rack or cage or whatever), it would not be economically reasonable to have both. Although, if the cross-connect is the primary method of interconnection, and the IXP provides a router-server the public-peering over IXP would essentially be free. So it might makes sense to assume that for the private cross-connect, there exists a back-up connection though the IXP. Anyway, I guess some discussion may give more insight about which one is more reasonable to assume and do. Now my last question is that if the two connections exist (one private cross-connect and another back-up through the IXP), what are the chances that periodically launched traceroutes that pass the inter-AS connection in that colo see both types of connection in a week. I guess what I'm asking is how often back-up routes are taken? Can the networks do load balancing on the two connection and essentially use them as primary routes? Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon
Figuring out traceroute
Hi guys, This might seem a bit of a trivial question, but I guess there is no harm in asking. I am looking at a collection of traceroutes all go through the following consecutive hops (* >> 213.248.98.238), as shown here (I kept the DNSname just for completeness): + From >> To + (213.155.130.125:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (213.155.130.127:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (213.155.131.75:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (213.155.131.83:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (213.155.131.85:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (213.155.134.251:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (213.155.134.253:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (213.155.134.77:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (213.155.137.57:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (213.155.137.59:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (62.115.114.111:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (62.115.116.168:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (62.115.116.170:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (62.115.116.174:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (62.115.116.176:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (62.115.116.178:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (62.115.116.180:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (62.115.116.182:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (62.115.116.184:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (62.115.116.186:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (62.115.116.188:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (62.115.116.190:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (62.115.140.253:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) + (62.115.140.255:las-b3-link.telia.net) >> (213.248.98.238:b harti-ic-140621-las-b3.c.telia.net) Given the way traceroute works (most of the times), which reports back the ingress port of the router it hits, do you think it fair to assume that all the hops that I see on the `From` hop are all different ports of one router? I think the other explanation is that there is switch (or something that does not have IP footprint) between `From` side and `To` side. How probable do you think this second explanation is? Best Regards Reza Motamedi (R.M)
Re: Inferring the location points of traffic exchange between two networks
Thanks Joel. I like examples. :) So say I issue the command on a router that is not the gateway. Would I get the following? Network Next Hop Metric LocPref Weight Path * > 8.8.8.0/24 96 56 0 15169 i With respect to "show bgp summary", if I know the location of the router and the router shows the BGP neighbor in the output, can I just rely on this info and say the point of exchange is where the router is located? For example the following show output from a router in city say "X" BGP4 Summary Router ID: 192.65.184.1 Local AS Number: 513 Confederation Identifier: not configured Confederation Peers: Cluster ID: 513 Maximum Number of IP ECMP Paths Supported for Load Sharing: 4 Number of Neighbors Configured: 18, UP: 18 Number of Routes Installed: 997637, Uses 85796782 bytes Number of Routes Advertising to All Neighbors: 2196009 (569816 entries), Uses 27351168 bytes Number of Attribute Entries Installed: 305962, Uses 27536580 bytes Neighbor Address AS# State Time Rt:Accepted Filtered Sent ToSend 62.40.124.157 20965 ESTAB 76d23h58m 140497 0 28 0 83.97.88.33 21320 ESTAB 49d 5h11m 0 0 28 0 192.65.184.2 513 ESTAB 365d12h24m243346 0 493626 0 192.65.184.3 513 ESTAB 405d12h31m70100 562695 0 192.65.184.4 513 ESTAB 317d 9h 1m0 0 569704 0 192.65.184.24 513 ESTAB 54d16h26m 0 0 569704 0 tells me that 513 is peering with 20965 that city, right? Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon On Wed, Jan 13, 2016 at 10:02 AM, joel jaeggli <joe...@bogus.com> wrote: > On 1/13/16 9:36 AM, Reza Motamedi wrote: > > Hi NANOG, > > > > I am researcher at the University of Oregon and my question is rather > > primitive. My research background is in networked systems and Internet > > measurement so I know how things work in theory. > > > > My question is about BGP and what can be inferred from the output of > > different "show" commands, regarding the point of traffic exchange of two > > networks with different ASNs. I tried going through the some samples on > > Juniper and Cisco documentations but I did not get my answer. > > > > Consider the following scenario; Say the point of traffic exchange > between > > AS_a and AS_b is in San Francisco and we run "show bgp summary" > > show bgp summary just tells you about your bgp neighbors. > > > and "show > > ip bgp "on a BGP router of AS_a in LA. Do we see the peering > > between AS_a and AS_b in San Francisco using any of the two commands. > > You see AS path, and the nexthop the route was learned from (which is > probably (nexthop self) the router on which the prefix is learned) in > san francisco. that route is probably resolved by your igp. > > so in an extremely simple example > >Network Next Hop Metric LocPref Weight Path > * > 8.8.8.0/24 72.14.202.50 96 56 0 15169 > i > > the nexthop happens to be an attached google peer > > the as path is > 15169 i > > > If > > yes is there a way to infer that in fact the traffic is not exchanged > > locally in LA? I think there should be a flag to differentiate records > > showing iBGP vs eBGP. > > If the router in LA sees the path as being through a router in san > francisco that is the direction it will forward it in. > > > On the same note, if we issue the commands on a router other than the > > border router in San Fran, is there any difference in the output of show > > commands? > > > > Now how are things different if we actually run the commands on that > > gateway router in SF? > > > > Best Regards > > Reza Motamedi (R.M) > > Graduate Research Fellow > > Oregon Network Research Group > > Computer and Information Science > > University of Oregon > > > > >
Inferring the location points of traffic exchange between two networks
Hi NANOG, I am researcher at the University of Oregon and my question is rather primitive. My research background is in networked systems and Internet measurement so I know how things work in theory. My question is about BGP and what can be inferred from the output of different "show" commands, regarding the point of traffic exchange of two networks with different ASNs. I tried going through the some samples on Juniper and Cisco documentations but I did not get my answer. Consider the following scenario; Say the point of traffic exchange between AS_a and AS_b is in San Francisco and we run "show bgp summary" and "show ip bgp "on a BGP router of AS_a in LA. Do we see the peering between AS_a and AS_b in San Francisco using any of the two commands. If yes is there a way to infer that in fact the traffic is not exchanged locally in LA? I think there should be a flag to differentiate records showing iBGP vs eBGP. On the same note, if we issue the commands on a router other than the border router in San Fran, is there any difference in the output of show commands? Now how are things different if we actually run the commands on that gateway router in SF? Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon
Re: interconnection costs
Thanks James, I totally missed that section. Sorry about that. I think the picture is becoming more clear in my head now. Let me first make sure my terminology is right. - With respect to peering, there are "transit" in which you pay the other AS in 95-5 fashion or whatever, and "settlement-free" in which two ASes agree not to charge each other for traffic exchange. In the latter, the exchanged traffic is limited to the customer cone of the two ASes. - Peering can happen either "publicly" though an IXP or "privately" through directly linking the ports of two routers and exchanging BGP traffic. Now, if I understood correctly, the difference between the cost of public and private peering is that in public, one AS pays to be connected to the IXP fabric, perhaps to the IXP provider and the colo provider. I'm assuming IXP and colo provider are not always the same organization as it is the case in SIX (Seattle IXP) and colo providers in Westin Building including Equinix, ZAYO, etc. So the AS is being charged for becoming an IXP member, and also to be allowed to take a line from its rack to the IXP's "meet me room". Additionally if one decides to buy transit over the IXP it has to pay the transit providers. In Private peering however the AS pays the colo provider for the xconnect per ASes that it wants to peer with. The cost of transit would be additional if the peering is in fact a transit and not settlement free. All the costs of HW, SW, personnel, administration, and perhaps transmission between colos (including remote peering, being waved to another location, tethering) would be the same, right? Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon On Wed, Dec 23, 2015 at 9:07 AM, James Bensley <jwbens...@gmail.com> wrote: > On 22 December 2015 at 19:11, Reza Motamedi <motam...@cs.uoregon.edu> > wrote: > > Thanks guys for the replies. > > > > I wanted to clarify two things in my questions. First by peering I did > not > > necessarily mean "settlement free" interconnection. I meant any inter-AS > > connection. My understanding is that in addition to the cost of transit > that > > should be paid to the transit provider, there also exists the cost of the > > xconnect that is charged by the colocation provider. Secondly, my > question > > was more about the expenses, as opposed to the technical costs/benefits. > I > > have browsed through the "Peering Playbook", but I think its more about > > providing a case "settlement free" peering. > > Dude, how are you going to weigh up the costs and benefits of peering > if you don't include the "costs". I refer you back to the same > documented I referred you to yesterday... > > > On Tue, Dec 22, 2015 at 9:33 AM, James Bensley <jwbens...@gmail.com> > wrote: > >> > https://docs.google.com/document/d/1i2bPZDt75hAwcR4iKMqaNSGIeM-nJSWLZ6SLTTnuXNs/edit?pref=2=1# > > > This time look at section 4 of this huge and hard to navigate > document, "4. Peering Costs": > > > https://docs.google.com/document/d/1i2bPZDt75hAwcR4iKMqaNSGIeM-nJSWLZ6SLTTnuXNs/edit#heading=h.nqqauszv8vj > > > Loosely extrapolating: > > Network transport: You need to be physically connected unless you > blagged space in the same rack and can patch in for free. > > Hardware: You need tin to route packets. > > Software: You need software to monitor the packet routing. > > Colocation: You need space/power/cooler/security in which the tin can > operate. > > Staffing costs: Someone has to configure that tin. > > Admin/engineering overhead: Someone has to manage the peering process > > Peering port: You probably have to pay to peer. > > Reseller ports: You might need remote connectivity to the LAN and > "network transport" above would refer to a cross connect to the remote > peering provider instead of directly into the IXP LAN. > > > > James. > >
Re: interconnection costs
Aren't availability, guaranteed service and remote hands an incentive to do peering inside a third party colocation? I see very large numbers for xconnects for instance in Equnix [ https://blog.equinix.com/2013/08/equinix-cross-connects-hit-11/] and it made me believe buying xconnect is still a normal practice. Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon On Wed, Dec 23, 2015 at 2:12 PM, Baldur Norddahl <baldur.nordd...@gmail.com> wrote: > > > On 23 December 2015 at 20:05, Reza Motamedi <motam...@cs.uoregon.edu> > wrote: > >> In Private peering however the AS pays the colo provider for the xconnect >> per ASes that it wants to peer with. The cost of transit would be >> additional if the peering is in fact a transit and not settlement free. >> > > You are still assuming there is a colo. But perhaps the most common case > is a multihomed company buying transit from two independent service > providers. The customer is at his office and the two service providers will > have their end somewhere in the city, perhaps even terminating their end of > the circuit in a street cabinet. The customer is multihomed and therefore > has his own AS. This is a peering situation with three AS numbers that fits > your description, it is private peering and there is no xconnect. Instead > there is usually a leased line cost, but this cost is often hidden from the > customer. Also the ISP might own the line (physical fiber) and the cost is > not a simple $/month. > > But also two ISPs might peer in this way. Residual internet providers have > a ton of points of presences, so why choose a place where there is a > xconnect fee? We can peer anywhere in the city, including at a random > street cabinet. Often the cost of renting a dark fiber somewhere is lower > than a xconnect fee (a sign that datacenter owners are too greedy). > > If one party is a content provider I give you that the peering point is > usually at a datacenter somewhere. But still, if the content provider is > big enough to run their own datacenter, we are back at the leased line case > again. Some content providers, even if small, prefer to just run their own > datacenter in the basement of their offices. > > Regards, > > Baldur > >
Re: interconnection costs
Thanks guys for the replies. I wanted to clarify two things in my questions. First by peering I did not necessarily mean "settlement free" interconnection. I meant any inter-AS connection. My understanding is that in addition to the cost of transit that should be paid to the transit provider, there also exists the cost of the xconnect that is charged by the colocation provider. Secondly, my question was more about the expenses, as opposed to the technical costs/benefits. I have browsed through the "Peering Playbook", but I think its more about providing a case "settlement free" peering. Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon On Tue, Dec 22, 2015 at 9:33 AM, James Bensley <jwbens...@gmail.com> wrote: > On 22 December 2015 at 16:44, Reza Motamedi <motam...@cs.uoregon.edu> > wrote: > > I think there is no single answer as different businesses may have > > different pricing models. I hope the discussion can help me understand > the > > whole ecosystem a little bit better. > > > Hi Reza, > > I have a list of example items that need to be costed in below, it is > by no means a definitive list though: > > > https://docs.google.com/document/d/1i2bPZDt75hAwcR4iKMqaNSGIeM-nJSWLZ6SLTTnuXNs/edit?pref=2=1# > > > Cheers, > James. > >
interconnection costs
Hi NANOG We are a group of researchers and our focus is on the economy of interconnection in the Internet. My question is mainly about the various costs of an AS establishing a connection with another AS, including the costs charged by the colocation providers. I am familiar with most of the connection options such as public peering on IXP, and private peering through xconnects. My understanding is that in addition to the cost of transit that the smaller AS pays to the larger AS, in the former you pay a monthly fee to establish a link to the switching fabric and then you can connect to as many ASes that are member in the IXP, and in the later you need to pay for as many xconnects that you need to connect to as many ASes that you plan to peer with. Obviously in both cases there is the cost of being in the colocation and renting a rack or whatever. What are the other costs involved? How should the AS reach the colocation center in the first place? I don't think every network can dig a hole an lay cables. Who should they pay to get from one PoP to another? Do ASes have to pay for xconnect to connect their PoP in a data center to the rest of their network? I think there is no single answer as different businesses may have different pricing models. I hope the discussion can help me understand the whole ecosystem a little bit better. Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon
Re: distinguishing eBGP from show ip BGP
Thanks again, Mark. So I guess the short answer is that I can't infer anything about the location of physical connectivity having this level of information from the control plane. Is that a fair statement? What if the Next Hop is inside the neighbor AS. I know it is a rather odd and uncommon case, but can it help? Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon On Wed, Mar 11, 2015 at 3:50 PM, Mark Tinka mark.ti...@seacom.mu wrote: On 11/Mar/15 21:42, Reza Motamedi wrote: What I ultimately want to determine, is the location of the AS connection. I know for example the router is in, say LA. If hot potato lets me to send the packet to the neighbor AS then they have an AS connection in LA, right? Going back to my example does the fact that the entry does not have 'i' mean that I can send it to AS2828 on the next hop. Yes - the route was not learned via iBGP; which means it was learned via eBGP. But that is just routing. It does not necessarily paint the forwarding topology (remember, routing and forwarding are two different operations). The next-hop may be local to this router, but it could also be a tunnel (which may be cold-potato forwarded before exiting the local AS), or the eBGP session could be eBGP Multi-Hop. Mark.
Re: distinguishing eBGP from show ip BGP
What I ultimately want to determine, is the location of the AS connection. I know for example the router is in, say LA. If hot potato lets me to send the packet to the neighbor AS then they have an AS connection in LA, right? Going back to my example does the fact that the entry does not have 'i' mean that I can send it to AS2828 on the next hop. Network Next HopMetric LocPrf Weight Path * 207.108.0.0/15 216.156.2.1643 0 2828 209 i * 65.106.7.101 2 0 2828 209 i * 65.106.7.246 3 0 2828 209 i * 65.106.7.55 3 0 2828 209 i * 216.156.2.1622 0 2828 209 i Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon On Wed, Mar 11, 2015 at 3:30 PM, Mark Tinka mark.ti...@seacom.mu wrote: On 11/Mar/15 21:22, Reza Motamedi wrote: Thanks Mark for the reply. Let me try to check what I understood is correct. Does the 'i' on the left (status code) only shows whether the prefix belongs to this AS? Status-code i just means the entry was learned by this router via iBGP. It does not mean the entry belongs to this AS. A locally-generated route can be thought of as belonging to this AS, however, a router cannot assert that a locally-generated route belongs to this AS. It just asserts that the route was locally-generated within the AS. Ownership of the route is data that needs to be gleaned from other sources, e.g., RIR WHOIS data, speaking to the operator, e.t.c. Whatever the case, a locally-generated route would not have an AS_PATH. That is an easy way to tell for such a use-case. What I want to figure out is if this two ASes (the owner of the router and and the first one on the AS-PATH) connect at the location of the router, or if packets need to stay for some hops in the local AS. So you want to determine whether traffic is hot- or cold-potato forwarding from the point of view of your reference router? Mark.
Re: distinguishing eBGP from show ip BGP
Thanks Mark for the reply. Let me try to check what I understood is correct. Does the 'i' on the left (status code) only shows whether the prefix belongs to this AS? What I want to figure out is if this two ASes (the owner of the router and and the first one on the AS-PATH) connect at the location of the router, or if packets need to stay for some hops in the local AS. On Wed, Mar 11, 2015, 2:51 PM Mark Tinka mark.ti...@seacom.mu wrote: On 11/Mar/15 20:32, Reza Motamedi wrote: Hi Nanog, For a research I want to distinguish the external AS peering from show ip BGP. In other words I want to see which entry show a path that immediately sends packets to another AS. My understanding is that *status code* shows if the route is internal, right? Does this mean if the *'i' *is not present, the route is goes out of the AS in the next hop. On the same note, can I use Next Hop to identify such entries? I just included a sample report from a public looking glass in XO. show ip bgp 207.108.0.0/15 longer-prefixes BGP table version is 529230540, local router ID is 65.106.7.145 * * *Status codes: s suppressed, d damped, h history, * valid, best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter, a additional-path Origin codes: i - IGP, e - EGP, ? - incomplete Network Next HopMetric LocPrf Weight Path * 207.108.0.0/15 216.156.2.1643 0 2828 209 i * 65.106.7.101 2 0 2828 209 i * 65.106.7.246 3 0 2828 209 i * 65.106.7.55 3 0 2828 209 i * 216.156.2.1622 0 2828 209 i * 65.106.7.54 3 0 2828 209 i * 65.106.7.252 2 0 2828 209 i * 216.156.2.1602 0 2828 209 i * 65.106.7.56 3 0 2828 209 i * 216.156.2.1652 0 2828 209 i * 65.106.7.144 2 0 2828 209 i There are two uses of the i code in IOS: 1. i for Status codes refers to the route being learned via iBGP. 2. i for Origin codes refers to the route being learned via a locally-generated route at the origin (or more historically, the IGP). In IOS show ip bgp output, the i for Status code (iBGP) is to the left of the prefix. On the other hand, the i for Origin code (IGP-originated route) is to the right of the originating AS in the AS_PATH. So you need to be more interested in the i to the left of the prefix. In your output above, no such i exists; ergo, these are eBGP-learned routes from this router's point of view. Use of the NEXT_HOP attribute to identify whether a route is eBGP-learned is not reliable, especially if you do not own the network you're getting your data from. Mark.
distinguishing eBGP from show ip BGP
Hi Nanog, For a research I want to distinguish the external AS peering from show ip BGP. In other words I want to see which entry show a path that immediately sends packets to another AS. My understanding is that *status code* shows if the route is internal, right? Does this mean if the *'i' *is not present, the route is goes out of the AS in the next hop. On the same note, can I use Next Hop to identify such entries? I just included a sample report from a public looking glass in XO. show ip bgp 207.108.0.0/15 longer-prefixes BGP table version is 529230540, local router ID is 65.106.7.145 * * *Status codes: s suppressed, d damped, h history, * valid, best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter, a additional-path Origin codes: i - IGP, e - EGP, ? - incomplete Network Next HopMetric LocPrf Weight Path * 207.108.0.0/15 216.156.2.1643 0 2828 209 i * 65.106.7.101 2 0 2828 209 i * 65.106.7.246 3 0 2828 209 i * 65.106.7.55 3 0 2828 209 i * 216.156.2.1622 0 2828 209 i * 65.106.7.54 3 0 2828 209 i * 65.106.7.252 2 0 2828 209 i * 216.156.2.1602 0 2828 209 i * 65.106.7.56 3 0 2828 209 i * 216.156.2.1652 0 2828 209 i * 65.106.7.144 2 0 2828 209 i Best Regards Reza Motamedi (R.M) Graduate Research Fellow Oregon Network Research Group Computer and Information Science University of Oregon
What can I infer from show ip route and similar BGP commands?
Hello NANOG, I’m a researcher and I was trying to understand the data I collected from some BGP Looking Glasses. Basically, I was hoping to see if BGP records can tell me where my university’s provider (AS3701) is peering with its providers. I issued two BGP queries to Level3’s LGs, one in Seattle and one in Amsterdam for my school’s prefix. My strong guess was that our provider (AS3701) peers with Level3 in Seattle. I was hoping to conclude something like this: if the peering occurs in Seattle, the Seattle LG should reveal it, but Amsterdam should not. AS3701 is Nero (Network for Education and Research in Oregon) which I assume is a small regional AS. I don't think Nero peers with Level3 in Amsterdam, however, I get this AS for my next hop even when I issue the command from Amsterdam. On the other hand “car1.Sacramento1” suggests that the peering happens in Sacramento. This result makes me think what I get is from a combination of iBGP and eBGP, which is also apparent from “Internal/External” keywords in the data. My main issue is that the keywords are not always available. In some other LG I just get a next hop IP and an AS path. How can I make sure that the peering information comes from an eBGP peering? I think the next hop IP might be the answer, right? I included the results of the command for both LGs here, hopefully somebody could explain to me - Route results for 128.223.0.0/16 from Amsterdam, Netherlands BGP routing table entry for 128.223.0.0/16 Paths: (2 available, best #1) 3701 3582 AS-path translation: { OREGONUNIV UONET } car1.Sacramento1 (metric 58341) Origin IGP, metric 0, localpref 100, valid, internal, best Community: North_America Lclprf_100 Level3_Customer United_States Sacramento Originator: car1.Sacramento1 3701 3582 AS-path translation: { OREGONUNIV UONET } car1.Sacramento1 (metric 58341) Origin IGP, metric 0, localpref 100, valid, internal Community: North_America Lclprf_100 Level3_Customer United_States Sacramento Originator: car1.Sacramento1 - Route results for 128.223.6.81/16 from Seattle, WA BGP routing table entry for 128.223.0.0/16 Paths: (4 available, best #3) 3701 3582 AS-path translation: { OREGONUNIV UONET } 4.53.150.46 from 4.53.150.46 (ptck-core1-gw.nero.net) Origin IGP, localpref 90, valid, external Community: North_America Lclprf_90 Level3_Customer United_States Seattle Level3:11847 3701 3582, (received-only) AS-path translation: { OREGONUNIV UONET } 4.53.150.46 from 4.53.150.46 (ptck-core1-gw.nero.net) Origin IGP, localpref 100, valid, external Community: Level3:90 3701 3582 AS-path translation: { OREGONUNIV UONET } car1.Sacramento1 (metric 34363) Origin IGP, metric 0, localpref 100, valid, internal, best Community: North_America Lclprf_100 Level3_Customer United_States Sacramento Originator: car1.Sacramento1 3701 3582 AS-path translation: { OREGONUNIV UONET } car1.Sacramento1 (metric 34363) Origin IGP, metric 0, localpref 100, valid, internal Community: North_America Lclprf_100 Level3_Customer United_States Sacramento Originator: car1.Sacramento1 Best Regards Reza Motamedi (R.M) Graduate Research Fellow Computer and Information Science University of Oregon
Re: What can I infer from show ip route and similar BGP commands?
Thanks Joel for your detailed explanation. It was very informative. I have been using routeviews for sometime, but given that I could get this amount of information from other sources, I decided to give this a try. On another note, do you think there is any value in checking the next hop IP? I have been checking and it looks as if when the IP is in the AS at the head of the AS path, the entry is associated with an iBGP record, right? I just used the ripe stat to map IPs to AS and it always holds when there is an AS for the next hop IP. Thanks again for your input.