Splitting a block of Class C's

One of my ISP clients is leaving, and the person who was assigning IP's when they became our client chose to give them class C's scattered throughout our block. These are Sprint IP's which are assigned to us with our Sprint circuit. Our former client is getting a Sprint T1 and asking Sprint to route these class C's to them rather than us, and they tell me that Sprint appears willing. They don't have an AS, but they're getting another local ISP to advertise the IP's for them. I normally wouldn't agree to participate in such a mess, but we're shutting off the Sprint circuit in a couple of months, and I can't see making them re-IP hundreds of domains under the circumstances. Has anyone done something like this? I'm wondering how much it will increase the CPU load on my router. I'm already running at 20% average, and if it gets much over that I start dropping ICMP packets. I know enough BGP to stop advertising the appropriate class C's, but I'm not sure that this won't cause problems that I haven't considered. Will anyone refuse to accept advertisements which send adjacent /24's to different places? Is this an officially "broken" setup, or is it just ugly?

It really depends on what you *want* to do. If the /24's you have assigned
to them are non-contiguous then they will want to renumber anyway so they
can advertise an aggregate. If you want to help them out, tell them to go
ahead and advertise the /24's out of your aggregate. Some providers have
stricter filtering, but generally will be reachable through other
providers, so connectivity isn't a big deal. Sprint should be advertising
an aggregate of your IP space which will bring all traffic to their
network. Once it reaches Sprint's network, the more specific routes your
customer is advertising will go to them and the rest will come to you. I
can't see that this would add any additional load to your router.

andy

It may not be that simple. I guess I should have mentioned that I don't route anything through Sprint. The only reason I've kept the Sprint circuit is to avoid re-IP-ing. Sprint isn't reliable enough to carry customer traffic. I do advertise the Sprint route, but I add a couple of hops to make sure the traffic goes through my "real" circuit.

>It really depends on what you *want* to do. If the /24's you have assigned
>to them are non-contiguous then they will want to renumber anyway so they
>can advertise an aggregate. If you want to help them out, tell them to go
>ahead and advertise the /24's out of your aggregate. Some providers have
>stricter filtering, but generally will be reachable through other
>providers, so connectivity isn't a big deal. Sprint should be advertising
>an aggregate of your IP space which will bring all traffic to their
>network. Once it reaches Sprint's network, the more specific routes your
>customer is advertising will go to them and the rest will come to you. I
>can't see that this would add any additional load to your router.
>
>andy

It may not be that simple.

It never is.

I guess I should have mentioned that I don't
route anything through Sprint. The only reason I've kept the Sprint circuit
is to avoid re-IP-ing. Sprint isn't reliable enough to carry customer
traffic. I do advertise the Sprint route, but I add a couple of hops to
make sure the traffic goes through my "real" circuit.

I don't think the above details should affect your situation. Your traffic
will get to you the way it usually does while the more specifics will be
routed through Sprint's network to your customer. Just because you pad
your ascount doesn't change my response.

andy

Just ugly, and as others here will no doubt point out, unfriendly to the
size of Internet routing tables everywhere.

If you really want to do this, you should keep anouncing your whole IP
address block, since the /24s will get filtered in some other places.
Your former customer (if they really want to do this) should be anouncing
the /24s, which will be more specific and will thus send traffic bound for
their space to them. You will need to open your filters to let those
announcements in, or else you won't be able to communicate with your
former customer.

This will work reliably only because you share an upstream provider, who
will presumably be passing on your announcement of your shorter prefix to
the rest of the Net, and who can presumably be paid to listen to the /24
anouncements. A further complication may arise if you have another
upstream, who either isn't listening to the /24 announcements or has peers
who aren't listening to them. Traffic to your fomer customer could end up
taking a rather roundabout route, either through your other upstream or
through your network.

That said, just because you can do something doesn't mean you should.
The weird routing scenario I described above (which depending on who your
other upstreams are may not happen) would not only cost you money for
bandwidth to carry traffic that you presumably aren't being paid for
anymore, but would also have performance issues and may run into
anti-spoofing filters, which would have to be modified. Growing the size
of the Internet routing table, or at least the routing table as seen by
those who don't filter out /24s, is a good thing to avoid when you can
easily do so. IP renumbering is a big pain, but it's unfortunately a
normal part of switching upstream providers for those without portable IP
space.

Are you big enough to get a portable IP address block from ARIN? Since
you say you're dropping your Sprint connection in a few months, you will
presumably have to renumber then. If you want to be really nice, you
could bite the bullet and do it now, turning over the old block to your
former customer. Alternatively, it's common practice to tell your
customer that they have to renumber out of your space when they stop
buying connectivity from you, and from your perspective that's probably
the easiest way to handle the situation.

-Steve

I wish the timing had worked out that way, but they have to be gone by June 1, and I can't give up the Sprint IP's until July or August. The alternative to the ugly solution is to make them re-IP all of their domains, and AFAIK there is no easy way to do that. Last time I checked, NetSol makes you do each one individually.

This will work reliably only because you share an upstream provider, who
will presumably be passing on your announcement of your shorter prefix to
the rest of the Net, and who can presumably be paid to listen to the /24
anouncements. A further complication may arise if you have another
upstream, who either isn't listening to the /24 announcements or has peers
who aren't listening to them. Traffic to your fomer customer could end up
taking a rather roundabout route, either through your other upstream or
through your network.

  If you are in the case where some of your former customer's traffic may
pass through your network, you are entirely justified in charging the
customer a fee for this 'service'. You may get some of his inbound traffic
unless all of your upstreams accept his /24s and meet with Sprint directly.

The weird routing scenario I described above (which depending on who your
other upstreams are may not happen) would not only cost you money for
bandwidth to carry traffic that you presumably aren't being paid for
anymore, but would also have performance issues and may run into
anti-spoofing filters, which would have to be modified.

  The problem is, if your Sprint connection isn't live, you will have no sure
way to get his traffic to him, and that's the problem. If you receive some
of his traffic from upstreams of yours that don't accept his /24
advertisements, you will have to get them to him in some way. You will
simply need to find one route to him that works, and push all his traffic
out that way. What will stop this from working are:

  1) If the upstream just hands the traffic back to you because it doesn't
see your customer's /24s.

  2) If the upstream or something on the path does see your customer's /24s
and decides that you shouldn't be originating the traffic and so blocks it.

  It's theoretically possible that all of your upstreams will have one or
both of these problems, and hence you will have no way to get traffic to
your former customer.

  Worst case, your former customer can always get a few IP address from
another provider (router interface addresses are fine) and set up a tunnel
to you. That will allow you to get him his traffic if it winds up on your
doorstep. Unfortunately, many tunnelling techniques aren't truly
transparent, and may not support a payload MTU of 1500. :frowning:

  Ugly, ugly, ugly.

  DS

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

NetSol? Presumably they don't have that many nameservers, when you
update a nameserver record, all domains automagically pick up the
change..shouldn't be that bad. IMHO, it's probably better for both
parties that you make them re-IP anyhow.

Regards,

Matt
- -----Original Message-----

Huh? You mean they're not running their own DNS servers? If they're not
running their own DNS servers but are doing hosting, they deserve what
they get. If they are, they need to simply update their host object in
whois for their DNS servers. (This may or may not work with "alternate
registries".) Then, they can write a simple script to go through the zone
files they have and change the first three octets to the new address
space.

I mentioned that, and it turns out they meant s/domains/servers/ but they really really don't want to re-IP, which I can understand. I had to re-IP 10 servers when my former employer moved offices, and it wasn't much fun. They have 50+ boxes in their space, and about half are client colos. In light of the advice I've heard here and elsewhere, I'm a bit nervous about what will happen, but I did tell them I would do it if Sprint agreed. I expected that Sprint would say no, but they claim that Sprint has agreed.