[NANOG] peering between ASes
Hi, here is a quick question. 1. Beside public peering in IXP and private peering between two dedicated ASes, are there any other interconnection models in the current Internet? 2. How does private peering implement, just a router from each AS and a link inbetween? Do they have multi-access in one peering location? I mean one router from an AS peer with two/more routers from another AS? Cheers,
Kai Chen wrote:
Hi, here is a quick question. 1. Beside public peering in IXP and private peering between two dedicated ASes, are there any other interconnection models in the current Internet?
There is the model where all partcipants peer through agency of 3rd party. That tends to be looked on as an extremely bad idea, but some regulatory environments encourage or enforce that sort of behavior particularly around the monopoly PTT.
2. How does private peering implement, just a router from each AS and a link inbetween? Do they have multi-access in one peering location? I mean one router from an AS peer with two/more routers from another AS?
you'll find that the details vary between entities. some bi-lateral relationships are going to require peering in more than one location, require a minimum ammount of redundancy etc. depends on how business critical the relationship is, how much traffic is being exchanged, the sized of the networks involved etc.
Cheers, _______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
2008/5/16 Joel Jaeggli <joelja@bogus.com>:
Kai Chen wrote:
Hi, here is a quick question. 1. Beside public peering in IXP and private peering between two dedicated ASes, are there any other interconnection models in the current Internet?
There is the model where all partcipants peer through agency of 3rd party. That tends to be looked on as an extremely bad idea, but some regulatory environments encourage or enforce that sort of behavior particularly around the monopoly PTT.
I don't know if the 3rd party you mentioned is the IXP?
2. How does private peering implement, just a router from each AS and a
link inbetween? Do they have multi-access in one peering location? I mean one router from an AS peer with two/more routers from another AS?
you'll find that the details vary between entities. some bi-lateral relationships are going to require peering in more than one location, require a minimum ammount of redundancy etc. depends on how business critical the relationship is, how much traffic is being exchanged, the sized of the networks involved etc.
Sure, two ASs may peer with each other at multiple locations, I do want to know in each of these peering location, if there exist multi-access between these two ASes.
Cheers,
_______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
On 17/05/2008, at 3:52 AM, Kai Chen wrote:
Sure, two ASs may peer with each other at multiple locations, I do want to know in each of these peering location, if there exist multi-access between these two ASes.
If you're looking for some rules about how this must work, you won't find them - all these things are optional and dynamic. Multiple accesses between two ASes at a single physical location is possible, yes. It's probably a good idea in most cases - whether it happens or not is usually a matter of whether the cost (both capital and opex) is worth it, I imagine. RE. your original question (2) - yes a single router in each AS and a link between them is the simplest. Add more routers and more links as required to meet capacity and resiliency requirements, where cost permits. -- Nathan Ward
Kai Chen wrote:
There is the model where all partcipants peer through agency of 3rd party. That tends to be looked on as an extremely bad idea, but some regulatory environments encourage or enforce that sort of behavior particularly around the monopoly PTT.
I don't know if the 3rd party you mentioned is the IXP?
Some IXPs have MLPA (MultiLateral Peering Agreements) where some or all of the participants agree to connect to a route server (usually with it's own AS) and exchange routes this way. It's reasonably common around AsiaPac - all the peering fabrics in Australia are MLPA for example, but I can think of optional examples in the USA (eg. Any2) that have it as an option or places like HKIX which have an MPLA which is mandatory for Hong Kong prefixes. This doesn't stop you doing bilateral as well across the same fabrics. MLPA works well in certain environments, especially where the major IP transit providers in a country won't peer, but rivalries tend to mean that a neutral (or fairly neutral) 3rd party can provide the routing part (this is pretty much what happened in Australia). It's convienient for content providers - they can "hook up" to one route server and often pickup half of the people on the exchange without having to spend ages negotiating with small networks who often don't have the technical know how or don't have the BGP experience, or indeed the smaller networks themselves as they can connect to an exchange and at least guarantee enough data to justify doing so. It gets more complex as some networks then become bigger and become transit providers and don't like customers sending routes to them via a peering fabric etc. Which is why, with a much more diverse range of networks and no one player dominating people the transit game (eg. in the USA, Western Europe) that MLPA isn't common. Some MLPAs give you some control over routing (eg. don't send my prefixes to ASxxxx), but a lot don't. Regards, Matthew
On 17/05/2008, at 5:05 PM, Matthew Moyle-Croft wrote:
Some MLPAs give you some control over routing (eg. don't send my prefixes to ASxxxx), but a lot don't.
If you really need to, you can get a similar effect by using ASPATH poisoning; just prepend your AS paths with the ASes you don't want those prefixes hitting. Similar, not identical, so may not work for you how you want. Googling around finds some explanation of it here: http://ispcolumn.isoc.org/2005-08/as1.html Nothing really about how it works in a MLPA IXP though. -- Nathan Ward
If you really need to, you can get a similar effect by using ASPATH poisoning; just prepend your AS paths with the ASes you don't want those prefixes hitting.
..
Nothing really about how it works in a MLPA IXP though.
It'd work, but it's a pretty evil thing to do and it's a fairly easy to get around surely (neighbor 1.1.1.1 allowas-in on IOS). MMC
On 17/05/2008, at 5:30 PM, Matthew Moyle-Croft wrote:
If you really need to, you can get a similar effect by using ASPATH poisoning; just prepend your AS paths with the ASes you don't want those prefixes hitting.
.. Nothing really about how it works in a MLPA IXP though.
It'd work, but it's a pretty evil thing to do and it's a fairly easy to get around surely (neighbor 1.1.1.1 allowas-in on IOS).
"If you really need to". Geoff's thing also says "controversial". If the foreign AS really wants to send you routes that way, they can do it regardless of how you stop your advertisements being accepted by/ reaching them. We're hardly talking high security here. ip route <prefix> <netmask> 1.1.1.1 works a treat. -- Nathan Ward
Nathan Ward wrote:
If the foreign AS really wants to send you routes that way, they can do it regardless of how you stop your advertisements being accepted by/ reaching them. We're hardly talking high security here.
ip route <prefix> <netmask> 1.1.1.1 works a treat.
I'm not quite sure of your point Nathan. That'd stop connectivity which isn't usually the point - especially if the issue is point (2) below. MLPAs are disliked for two main reasons that I've been able to discern. (1) Lack of control Because of the lack of direct relationships with the other networks you can get some fairly odd routing behaviours which gives suboptimal performance when you meet at multiple MLPAs in a theatre - leading to difficulty in doing traffic engineering. From traffic flows, to wierdness caused by people advertising prefixes inconsistently to transit and peering and blaming IOS bugs for it <sigh>. (2) Transit customers using an MLPA to "not pay" for traffic to your network A fair point - but, if they weren't a customer then you might be paying to get their traffic or they would be sending it that way anyway. MMC
On 17/05/2008, at 5:53 PM, Matthew Moyle-Croft wrote:
Nathan Ward wrote:
If the foreign AS really wants to send you routes that way, they can do it regardless of how you stop your advertisements being accepted by/ reaching them. We're hardly talking high security here.
ip route <prefix> <netmask> 1.1.1.1 works a treat.
I'm not quite sure of your point Nathan. That'd stop connectivity which isn't usually the point - especially if the issue is point (2) below.
If a foreign AS wants to work around things put in place by you/others so they don't get your prefixes (be it ASPATH poisoning, route filtering by the MLPA route-server operator, etc.) they can do so easily by putting a static route in to their equipment. My point is that none of these techniques are bulletproof. I think I meant to say "packets" where I said "routes" where you quoted me above, also, that ip route blah was something that the foreign AS would stuff in to their router. I hope that's a bit more clear.
MLPAs are disliked for two main reasons that I've been able to discern.
I'm not debating for/against MLPAs, that doesn't really go anywhere productive. I'm giving info that some people might find useful if they've got a network condition they need to work around with a dirty hack. -- Nathan Ward
participants (4)
-
Joel Jaeggli -
Kai Chen -
Matthew Moyle-Croft -
Nathan Ward