nested prefixes in Internet

Mailman List Mirror (Read Only)
1

Hi,

let's assume that there is an ISP "A" operating in Europe region who
has /19 IPv4 allocation from RIPE. From this /19 they have leased /24
to ISP "B" who is multi-homed. This means that ISP "B" would like to
announce this /24 prefix to ISP "A" and also to ISP "C". AFAIK this
gives two possibilities:

1) Deaggregate /19 in ISP "A" network and create "inetnum" and "route"
objects for all those networks to RIPE database. This means that ISP
"A" announces around dozen IPv4 prefixes to Internet except this /24
and ISP "B" announces this specific /24 to Internet.

2) ISP "A" continues to announce this /19 to Internet and at the same
time ISP "B" starts to announce /24 to Internet. As this /24 is
more-specific than /19, then traffic to hosts in this /24 will end up
in ISP "B" network.

Which approach is better? To me the second one seems to be better
because it keeps the IPv4 routing-table smaller and requires ISP "A"
to make no deaggregation related configuration changes. Only bit weird
behavior I can see with the second option is that if ISP "B" stops for
some reason announcing this /24 network to Internet, then traffic to
hosts in this /24 gets to ISP "A" network and is blackholed there.

thanks,
Martin

2

* Martin T.:

let's assume that there is an ISP "A" operating in Europe region who
has /19 IPv4 allocation from RIPE. From this /19 they have leased /24
to ISP "B" who is multi-homed. This means that ISP "B" would like to
announce this /24 prefix to ISP "A" and also to ISP "C". AFAIK this
gives two possibilities:

1) Deaggregate /19 in ISP "A" network and create "inetnum" and "route"
objects for all those networks to RIPE database. This means that ISP
"A" announces around dozen IPv4 prefixes to Internet except this /24
and ISP "B" announces this specific /24 to Internet.

2) ISP "A" continues to announce this /19 to Internet and at the same
time ISP "B" starts to announce /24 to Internet. As this /24 is
more-specific than /19, then traffic to hosts in this /24 will end up
in ISP "B" network.

Which approach is better?

Are the autonomous systems for the /19 and /24 connected directly? If
they are, (2) is better from a global view (because it needs fewer
routing table entries). (1) can be better from B's perspective
because it prevents certain routing table optimizations (due to the
lack of the covering prefix). But (1) can also be worse for B and A's
other customers if /24s (and slightly shorter prefixes) in this part
of the IPv4 address space are commonly filtered.

3

Option 3?

ISP A announces the /19 and the /24 while ISP B does just the /24

4

Precisely. This is how it's done by providers I've worked with.

-mel beckman

5

Hi Martin,

What do you want to do? Move from A to B or add A to B?

Cheers,
mh

6

Florian:

Are the autonomous systems for the /19 and /24 connected directly?

Yes they are.

(1) can be better from B's perspective because it prevents certain routing table optimizations (due to the lack of the covering prefix)

What kind of routing table optimizations are possible if covering /19
prefix is also present in global routing table?

But (1) can also be worse for B and A's other customers if /24s (and slightly shorter prefixes) in this part of the IPv4 address space are commonly filtered.

Based on my experience /24 is allowed in prefix-filters.. Longer IPv4
prefixes are not.

Roy, Mel:

Could you please elaborate on that option. What kind of advantages
does this have compared to option 2?

thanks,
Martin

7

* Martin T.:

Florian:

Are the autonomous systems for the /19 and /24 connected directly?

Yes they are.

Then deaggregation really isn't necessary at all.

(1) can be better from B's perspective because it prevents certain
routing table optimizations (due to the lack of the covering prefix)

What kind of routing table optimizations are possible if covering /19
prefix is also present in global routing table?

The /24 prefix could arguably be dropped and ignored for routing
decisions.

8

Florian:

as I told in my initial e-mail, ISP-B is multi-homed, i.e connected to
ISP-A(who leases the /24 to ISP-B from their /19 block) and also to
ISP-C. ISP-B wants to announce this /24 both to ISP-A and ISP-C.
That's the reason why either solution 1 or 2 in my initial e-mail is
needed.

However, I would like to hear from Roy and Mel why do they prefer a
third option where ISP A announces the /19 and the /24 while ISP B
does just the /24.

thanks,
Martin

9

The solution proposed allows ISP-B to use both paths at the same time, needs ISP-C to minimal changes, and has low impact on the global routing tables.. I have successfully used it in the past and my old company is still using it today.

.On 10/9/2016 11:50 PM, Martin T wrote:

10

The solution proposed allows ISP-B to use both paths at the same time,
needs ISP-C to minimal changes, and has low impact on the global
routing tables.. I have successfully used it in the past and my old
company is still using it today.

Having two parties in control of a prefix announcement is a bit of a
disaster. ISP A becomes partitioned from isp B isp B does not withdraw
the covering aggregate and black-holes the of ISP A that lands on it's
edge. bummer.

11

I don't think I ever said that ISP-B would announce the /19. That would only be announced by ISP-A. ISP-B would only announce the /24 that has been delegated to it.

If the ISP-A/ISP-B link goes down then the /24 would be seen only via ISP-C which is the desired result.

12

* r.engehausen@gmail.com (Roy) [Mon 10 Oct 2016, 19:19 CEST]:

I don't think I ever said that ISP-B would announce the /19. That would only be announced by ISP-A. ISP-B would only announce the /24 that has been delegated to it.

If the ISP-A/ISP-B link goes down then the /24 would be seen only via ISP-C which is the desired result.

What if ISP-A then receives traffic inside its /19 destined for ISP-B's /24? It will have to send it over transit and won't bill ISP-B for that traffic. You cannot expect 100% of the rest of the Internet to honour the more specific all the time.

  -- Niels.

13

Is that a real problem? In my experience a /24 is honoured almost universially.

If we assume the big tier 1 transit providers honour the /24 announcement, the only possible way for ISP-A to receive traffic via the /19 is if ISP-A is directly peered with someone that ignores the /24.

Even if some small amount of traffic does go that route, it might not be viewed as a problem as the volume is likely to be very low.

Regards,

Baldur

14

* r.engehausen@gmail.com (Roy) [Mon 10 Oct 2016, 19:19 CEST]:

I don't think I ever said that ISP-B would announce the /19. That would only be announced by ISP-A. ISP-B would only announce the /24 that has been delegated to it.

If the ISP-A/ISP-B link goes down then the /24 would be seen only via ISP-C which is the desired result.

What if ISP-A then receives traffic inside its /19 destined for ISP-B's /24? It will have to send it over transit and won't bill ISP-B for that traffic. You cannot expect 100% of the rest of the Internet to honour the more specific all the time.

Is that a real problem? In my experience a /24 is honoured almost universally.

In my experience, with notable exceptions, ISPs don’t like to provide transit to people who aren’t paying them, so if it becomes enough traffic to get noticed, it’s not at all unlikely that ISP-A would start dropping it, even if they didn’t ignore the prefix.

If we assume the big tier 1 transit providers honour the /24 announcement, the only possible way for ISP-A to receive traffic via the /19 is if ISP-A is directly peered with someone that ignores the /24.

Not true… There are myriad reasons that the /24 might not reach a network peered with ISP-A, including the possibility of being a downstream customer of a network peered with or buying transit from ISP-A. In the latter case, not an issue, since it’s paid transit, but in the former (peered, not transit), again, ISP-A is probably not super excited to carry traffic that someone isn’t paying them to carry.

Even if some small amount of traffic does go that route, it might not be viewed as a problem as the volume is likely to be very low.

Until some clever miscreant notices the situation and decides to exploit it for a dDOS.

Owen

15

* baldur.norddahl@gmail.com (Baldur Norddahl) [Mon 10 Oct 2016, 21:45 CEST]:

* r.engehausen@gmail.com (Roy) [Mon 10 Oct 2016, 19:19 CEST]:

I don't think I ever said that ISP-B would announce the /19. That would only be announced by ISP-A. ISP-B would only announce the /24 that has been delegated to it.

If the ISP-A/ISP-B link goes down then the /24 would be seen only via ISP-C which is the desired result.

What if ISP-A then receives traffic inside its /19 destined for ISP-B's /24? It will have to send it over transit and won't bill ISP-B for that traffic. You cannot expect 100% of the rest of the Internet to honour the more specific all the time.

Is that a real problem? In my experience a /24 is honoured almost universially.

If we assume the big tier 1 transit providers honour the /24 announcement, the only possible way for ISP-A to receive traffic via the /19 is if ISP-A is directly peered with someone that ignores the /24.

Even if some small amount of traffic does go that route, it might not be viewed as a problem as the volume is likely to be very low.

Sure, continue believing that, until you run into a customer who takes a /24 and then announces it no-export just to your upstream, and mysteriously has lots of outages on their link to you.

Aside from that, this does happen and apparently much more often than you think. Think CDN nodes with partial views. There are plenty networks that filter on or close to RIR boundaries due to hardware limitations as well.

  -- Niels.

16

But ISP-A is in fact being paid to carry the traffic. Supposedly ISP-B has a paid transit relation to ISP-A. In the case the transit link is down ISP-A might have to transport the traffic through a less profitable link however.

I know that if ISP-A was my network I would be making money even with the transit link down. Yes I might have to transport something out of my network through one of my transits, but outbound traffic is in fact free for us because we are heavy inbound loaded.

Regards,

Baldur

17

* r.engehausen@gmail.com (Roy) [Mon 10 Oct 2016, 19:19 CEST]: [snip]

If the ISP-A/ISP-B link goes down then the /24 would be seen only via
ISP-C which is the desired result.

What if ISP-A then receives traffic inside its /19 destined for ISP-B's /24?
It will have to send it over transit and won't bill ISP-B for that traffic.

This is still the favored approach over ISP-A de-aggregating their
address space to
support some multi-homed customers.

It's all something that ISP-A can put in their contract with ISP-B.
A can bill ISP-B per packet-byte routed with destination of B's
/24, if they wanted,
or reach other mutually agreeable conditions that make sure the /24 carve out
does not commit A to giving service to B involving more traffic than B pays for.

Or they can list Rate #1 for incoming traffic to B's /24 sent to a
peering link with ISP-B,
and apply pricing Rate #2 for packets destined for B's /24
between two transit providers.

...However, ISP-A and ISP-B should have a link; Either a physical connection
or a virtual one (such as a tunnel), with BGP peering between A and B,
for ISP-B to be
using a /24 from A's IP space with other providers.

You cannot expect 100% of the rest of the Internet to honour the more
specific all the time.

That is true, but not really notable / isn't really a significant problem.

Probably close enough to 100% of the internet to honor it 99% of the time,
and the 1% that don't probably will likely not be one of ISP A or
B's adjacent providers.
(If they are, then A or B will open a ticket, and the /24 will be
fixed to work as desired)

Heck.... on some occasion when ISP A has an outage, the /19 won't be there,
so less than 100% of the internet might 'honor' that one at times, as well.

18

Not true… There are myriad reasons that the /24 might not reach a network peered with ISP-A, including the possibility of being a downstream customer of a network peered with or buying transit from ISP-A. In the latter case, not an issue, since it’s paid transit, but in the former (peered, not transit), again, ISP-A is probably not super excited to carry traffic that someone isn’t paying them to carry.

But ISP-A is in fact being paid to carry the traffic. Supposedly ISP-B has a paid transit relation to ISP-A. In the case the transit link is down ISP-A might have to transport the traffic through a less profitable link however.

Which isn’t really in the agreement between ISP-B and ISP-A unless it was specifically (and unusually) negotiated.

Also, you’re assuming that the leased space came with a transit agreement. In many cases, address leases don’t, so consider the additional scenario where ISP-B leases addresses from ISP-A, but has transit contracts with ISP-C and ISP-D but no connection at all to ISP-A.

I know that if ISP-A was my network I would be making money even with the transit link down. Yes I might have to transport something out of my network through one of my transits, but outbound traffic is in fact free for us because we are heavy inbound loaded.

Yes, but it doesn’t help if it also came in on a transit link. Any traffic you both receive and transmit on transit costs you money pretty much no matter who you are.

Owen

19

Hi,

I made a drawing of those two best solutions: http://i.imgur.com/7NQVgUH.png

As much as I understand, both solutions require no special changes
from "ISP C". Only advantage of solution B over solution A, that I can
see, is that at the time when link between "ISP C" and "ISP B" is up,
the traffic from Internet towards "ISP B" prefers the "ISP C"
connection.

In case the link between "ISP A" and "ISP B" goes down, then traffic
from "ISP A" addressed to this /24 will use a private peering link
between "ISP A" and "ISP C" so the transit costs are not an issue.

thanks,
Martin

20

Assuming that there is a PNI A<->C assumes facts not in evidence.

Owen