Arien,
Arien Vijn wrote: This is how I understand your proposed setup: - Connect this DNS server directly to the L2 IXP infrastructure via an 802.1q NIC. - Configure n VLANs on it - one for each peer. - In each VLAN, the server answers DNS queries on a different /64 address. - Each of these /64 belongs to the aggregate of the respective peers. Is this an accurate description?
You got it. I think that behind a router or firewall instead of directly on the L2 fabric would be better, though.
Where is your problem?
Well, *if* my understanding is correct. Then I do see a number of issues.
A number of them, indeed. And half of them, to be resolved, might require major annoyances including but not limited to: extra hardware, tedious or dirty configuration, hacks, and longs evenings swearing at debugging the darn thing. But none that can't be solved, AFAIK; can you be more specific please? I am not saying this a good configuration as there is none today. I'm not even saying this is the best (or the less worst) that would solve your problem short term. The points I am trying to make are: 1. You want to do multihoming without a multihoming protocol. - It can't be a free lunch. - If you want to do it today anyway, what you have is described above and some other methods equally un-satisfactory. 2. Whatever you do over PA is unlikely to be mergeable with any future multihoming solution including short-term ones. Do not build a multihomed infrastructure on PA, it is not going anywhere. In other words: I'm afraid that whatever you can do today is quick and dirty. Try to make it easier on the community and yourself to clean up later. Local messes are easier to clean than global messes. There is no way nobody has found yet that you will get the multihoming solution both RIPE-NCC and AMS-IX need without an allocation. A PA allocation is not a long-term solution. Every multihoming solution that I have seen requires a clean PA space. Every shot someone takes at PA aggregation diminishes the viability of a good multihoming solution. Don't play with that too much or the only multihoming solution you might ever get is a PI swamp. I short: PA is not what you need in the long run. If you don't want to end up in the PI swamp, don't make my job impossible in delivering the local /48 allocation you need. Michel.
Michel and all, Sorry for the late reply. Layer 2/switch software issues kept my attention all week. On 05-05-2002 22:39PM, "Michel Py" <michel@arneill-py.sacramento.ca.us> wrote:
Arien Vijn wrote: This is how I understand your proposed setup: - Connect this DNS server directly to the L2 IXP infrastructure via an 802.1q NIC. - Configure n VLANs on it - one for each peer. - In each VLAN, the server answers DNS queries on a different /64 address. - Each of these /64 belongs to the aggregate of the respective peers. Is this an accurate description?
You got it. I think that behind a router or firewall instead of directly on the L2 fabric would be better, though.
All right. But what about these VLANs then? Do you mean that VLANs have to be defined on both sites of this router/firewall? Why do you think we need VLANs anyway? Why not just configure n addresses in the same VLAN?
Where is your problem?
Well, *if* my understanding is correct. Then I do see a number of issues.
A number of them, indeed. And half of them, to be resolved, might require major annoyances including but not limited to: extra hardware, tedious or dirty configuration, hacks, and longs evenings swearing at debugging the darn thing. But none that can't be solved, AFAIK; can you be more specific please?
Several inter-depending parameters over multiple parties. This is a night mare. Apart from the enormous extra administrative burden which is required. - VLANs must be defined an must not conflict with those of other members. Many members do have switches them selves in-between the IX infrastructure and their border routers. - VLANs must be configured correctly in multiple places by multiple parties. - Internet companies join, spit-up, disappear and reappear all the time. Their policies might change accordingly. - Administer all these subnets and then hoping peers will route it correctly. Suppose we can deal with this. Then it *might* work for UDP but what about TCP sessions? Failover is a MH requirement too. Is this worth the manpower? In other words it is too much of a hassle for a solution which, might be working (but not all the time).
I am not saying this a good configuration as there is none today. I'm not even saying this is the best (or the less worst) that would solve your problem short term.
Ack
The points I am trying to make are:
1. You want to do multihoming without a multihoming protocol. - It can't be a free lunch. - If you want to do it today anyway, what you have is described above and some other methods equally un-satisfactory.
You are right, there is no solution that does not hurt somehow. But as long as there is no pressure (no market and no exploding IPv6 routing tables) router vendors are at least reluctant to implement multi homing protocols. Some already seem to have a hard time getting the current code stable. Others lack filters. Advertising /48 is unsatisfactory from a aggregation point of view. But it is the only working MH "solution" at the moment.
2. Whatever you do over PA is unlikely to be mergeable with any future multihoming solution including short-term ones. Do not build a multihomed infrastructure on PA, it is not going anywhere.
An Internet Exchange is by definition a multi homed environment. The fact that the IPV6 policies state that it is not desirable/needed to announce peering address space is at least not compliant with current IPv4 routing practices.
In other words: I'm afraid that whatever you can do today is quick and dirty. Try to make it easier on the community and yourself to clean up later. Local messes are easier to clean than global messes.
Ack
There is no way nobody has found yet that you will get the multihoming solution both RIPE-NCC and AMS-IX need without an allocation. A PA allocation is not a long-term solution. Every multihoming solution that I have seen requires a clean PA space. Every shot someone takes at PA aggregation diminishes the viability of a good multihoming solution. Don't play with that too much or the only multihoming solution you might ever get is a PI swamp.
I short: PA is not what you need in the long run. If you don't want to end up in the PI swamp, don't make my job impossible in delivering the local /48 allocation you need.
Our neutrality at least makes us reluctant to use provider space anyway. I would very much like to see a working and scalable solution. It would solve one of the main IPv6 issues for neutral, in-depended entities, which just do not fit the customer-ISP-upstream model. Arien
participants (2)
-
Arien Vijn -
Michel Py