RE: [address-policy-wg] Renumbering sites (Was: Just say *NO* to PI space -- or how to make it lessdestructive)
Wilfried Woeber wrote: Why does the laptop store the *addresses* instead of an (FQ)DN?
Mine is configured that way because I want to be able to get in remotely in case of a DNS failure so I can fix the DNS :-D Other reason: VPNs based on FQDNs have a tendency to timeout, especially at the first attempt from a remote location (because the FQDN is not cached and has to go up to the root). Also DNS requests go over UDP, which is unreliable. It happens all the time that Joe Blow traveling somewhere reports the next day that he could not check his email or download the sales report because the VPN was not working (because Joe either is not smart enough to retry or finds it a good excuse to go to the bar instead). Next time he goes out the VPN is configured with the hardcoded IP address of the VPN server. In the end, it does not matter why. It's out there, and has to be dealt with.
Jeroen Massar wrote: Renumbering is *NOT* simple and *CAN't* be automated (no remote company will allow you full automatic access to change things in their setup, think firewall rules for instance...)
Indeed. Even if they did, it would be logistically impossible. I'm currently configuring an IPSEC tunnel going to a very large corporation. There are thousands of tunnels, configured on every router brand and model man has ever made; each is unique. An automated tool to change this is not in the realm of possible. This leaves the large company with having to deal with thousands of different people with issues such as half of the techs that originally configured the thing are no longer there, nobody remembers the router's password, etc. Renumbering any sizeable organization is _always_ a very costly proposition. It requires allocating valuable resources for weeks to prepare and more to carry. Plus, in any renumbering I have done some issues popped out for weeks after the renumbering. Renumbering generates a steady flow of trouble tickets that require more resources to deal with _and_ make the network guys look like idiots. Only rookies that have never been in the trenches in the real world consider renumbering easy. Most of the more experienced network managers out there will tell you this: I don't want to go through this again. Michel.
Pardon me for saying, but all of this is bollocks. Renumbering is as easy as you want it to be. Make a proper policy and then create the tools for it. It is that easy. I am sure we can discuss poorly designed solutions any (other) time. I support proposal 2006-01. j -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Michel Py Sent: 25. april 2006 17:44 To: Jeroen Massar Cc: address-policy-wg@ripe.net Subject: RE: [address-policy-wg] Renumbering sites (Was: Just say *NO* to PI space -- or how to make it lessdestructive)
Wilfried Woeber wrote: Why does the laptop store the *addresses* instead of an (FQ)DN?
Mine is configured that way because I want to be able to get in remotely in case of a DNS failure so I can fix the DNS :-D Other reason: VPNs based on FQDNs have a tendency to timeout, especially at the first attempt from a remote location (because the FQDN is not cached and has to go up to the root). Also DNS requests go over UDP, which is unreliable. It happens all the time that Joe Blow traveling somewhere reports the next day that he could not check his email or download the sales report because the VPN was not working (because Joe either is not smart enough to retry or finds it a good excuse to go to the bar instead). Next time he goes out the VPN is configured with the hardcoded IP address of the VPN server. In the end, it does not matter why. It's out there, and has to be dealt with.
Jeroen Massar wrote: Renumbering is *NOT* simple and *CAN't* be automated (no remote company will allow you full automatic access to change things in their setup, think firewall rules for instance...)
Indeed. Even if they did, it would be logistically impossible. I'm currently configuring an IPSEC tunnel going to a very large corporation. There are thousands of tunnels, configured on every router brand and model man has ever made; each is unique. An automated tool to change this is not in the realm of possible. This leaves the large company with having to deal with thousands of different people with issues such as half of the techs that originally configured the thing are no longer there, nobody remembers the router's password, etc. Renumbering any sizeable organization is _always_ a very costly proposition. It requires allocating valuable resources for weeks to prepare and more to carry. Plus, in any renumbering I have done some issues popped out for weeks after the renumbering. Renumbering generates a steady flow of trouble tickets that require more resources to deal with _and_ make the network guys look like idiots. Only rookies that have never been in the trenches in the real world consider renumbering easy. Most of the more experienced network managers out there will tell you this: I don't want to go through this again. Michel.
On Tue, Apr 25, 2006 at 07:51:32PM +0200, Jørgen Hovland wrote:
Pardon me for saying, but all of this is bollocks. Renumbering is as easy as you want it to be. Make a proper policy and then create the tools for it. It is that easy. I am sure we can discuss poorly designed solutions any (other) time.
You seem to have a very easy Job, when you can make this proper policy for your customers. I can not, those (about) 100 connecting to my network all have different policies, different needs, different requirements. And we do our best, to fullfill their needs and make it as easy for them as possible. We call that "service". If you do not have to provide this, good for you. But please do not tell me, that my need to have paying customers is bad design. Nils, not in the ISP-Business -- Please let us know if your SunSolve visit saved you a call to Sun Support! Access Denied [komplette Auskunft zu einem Patch auf http://sunsolve.sun.com/]
(apologise for being slightly OT) -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Nils Ketelsen
You seem to have a very easy Job,
65% of my day goes to doing stuff a machine could have done. 20% goes to developing software/hardware so the machine can do it instead of us. The rest are coffee breaks and meetings.
when you can make this proper policy for your customers.
I can not, those (about) 100 connecting to my network all have different policies, different needs, different requirements. And we do our best, to fullfill their needs and make it as easy for them as
Some demand it, a few don't, but they all ask. possible. I didn't mention it would be in violation to your customers existing policies/needs. You automatically assumed so without even thinking/knowing how it can be implemented.
We call that "service". I surely would call that service, yes. Automatic renumbering service. I bet at least 5 people stole my idea just now.
If you do not have to provide this, good for you. What, service?
But please do not tell me, that my need to have paying customers is bad design. If your intentions are to get _any_ potential customer, then you obviously need to loosen up on policies as they all have special needs. In that case, I understand you completely. (I dropped a comment here on how not to get huge amount of customers when you adjust policies on demand per customer case)
Nils, not in the ISP-Business
j, in the ISP-business (with friends)
On Tue, Apr 25, 2006 at 09:10:19PM +0200, Nils Ketelsen wrote:
Pardon me for saying, but all of this is bollocks. Renumbering is as easy as you want it to be. Make a proper policy and then create the tools for it. It is that easy. I am sure we can discuss poorly designed solutions any (other) time.
You seem to have a very easy Job, when you can make this proper policy for your customers. I can not, those (about) 100 connecting to my network all have different policies, different needs, different requirements. And we do our best, to fullfill their needs and make it as easy for them as possible. We call that "service". If you do not have to provide this, good for you. But please do not tell me, that my need to have paying customers is bad design.
Nils, not in the ISP-Business
Opposite example - we serve about 60000 internet customers and have no problem to renumber almost all of them becouse we use DHCP. So, not any ISP/Telco will pain about renumbering. -- Dmitry Kiselev
Dmitry Kiselev wrote:
Opposite example - we serve about 60000 internet customers and have no problem to renumber almost all of them becouse we use DHCP. So, not any ISP/Telco will pain about renumbering.
Try to imagine you have 60000 _web_sites_ :) -- WBR, Maxim V. Tulyev (MT6561-RIPE, 2:463/253@FIDO)
On Wed, Apr 26, 2006 at 11:57:14AM +0400, Max Tulyev wrote:
Dmitry Kiselev wrote:
Opposite example - we serve about 60000 internet customers and have no problem to renumber almost all of them becouse we use DHCP. So, not any ISP/Telco will pain about renumbering.
Try to imagine you have 60000 _web_sites_ :)
I just show an example. There are some situations where renumbering become total nigthmare, but in some cases - no. In ISP market it is depend on operator's bussiness model. -- Dmitry Kiselev
I have a large multi-regional client, who's main base is in the USA. They are about to get a /19 from ARIN since they are multi-homed and have about 32 sites, but they also have about 5 sites in APNIC and the another 5 in the RIPE region. Do they have to become members in each RIR to get multi-homed allocations, or should one RIR handle it all? Would the answer to that above question change if the IP blocks used in APNIC and RIPE wouldn't be announced locally in those regions but would rather be MPLSed back to the USA and from there all Internet access would be allowed (thereby making the IP blocks pseudo-USA blocks)? References: http://www.ripe.net/info/resource-admin/rir-comp-matrix-rev.html This doc seems to imply with the 1.2 section statement of "Membership is globally open without condition" that ARIN can allocate IPs anywhere, as can RIPE, which sort of contradicts the section "Emergence of the RIRs" located at: http://www.ripe.net/info/resource-admin/rir-system.html So any official guidance is appreciated. Thanks, Hank
Hi Hank, On 4/25/06, Hank Nussbacher <hank@efes.iucc.ac.il> wrote:
I have a large multi-regional client, who's main base is in the USA. They are about to get a /19 from ARIN since they are multi-homed and have about 32 sites, but they also have about 5 sites in APNIC and the another 5 in the RIPE region. Do they have to become members in each RIR to get multi-homed allocations, or should one RIR handle it all?
IIRC this happens frequently. One RIR can satisfy their global needs.
Would the answer to that above question change if the IP blocks used in APNIC and RIPE wouldn't be announced locally in those regions but would rather be MPLSed back to the USA and from there all Internet access would be allowed (thereby making the IP blocks pseudo-USA blocks)?
No, same answer (obviously).
<snip>
So any official guidance is appreciated.
My answer above is just common sense, which may not be the same thing as "official guidance" ;-) -- Cheers, McTim $ whois -h whois.afrinic.net mctim
Hi, On Tue, Apr 25, 2006 at 08:43:52AM -0700, Michel Py wrote:
Most of the more experienced network managers out there will tell you this: I don't want to go through this again.
But at the same time, most of the more experienced network managers have been through it a couple of time, and will understand the necessity... :-) (We had to change the IP addresses for our recursive DNS servers 3 times by now, and making sure all customers update their configs *was* a nightmare - nevertheless, it was the correct thing to do) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
participants (8)
-
Dmitry Kiselev -
Gert Doering -
Hank Nussbacher -
Jørgen Hovland -
Max Tulyev -
McTim -
Michel Py -
Nils Ketelsen