Hi Martin, What do you want to do? Move from A to B or add A to B? Cheers, mh Le 27 sept. 2016 17:52, à 17:52, Mel Beckman <mel@beckman.org> a écrit:

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

-mel beckman

...

On Sep 27, 2016, at 7:06 AM, Roy <r.engehausen@gmail.com> wrote:

Option 3?

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

...

On 9/27/2016 4:20 AM, Martin T wrote: 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

* 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.

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:

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

On Wed, Oct 5, 2016 at 11:50 PM, Florian Weimer <fw@deneb.enyo.de> wrote:

...

* 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.

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. On 10/10/2016 9:16 AM, joel jaeggli wrote:

On 10/10/16 9:04 AM, Roy wrote:

...

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.

Den 10/10/2016 kl. 19.24 skrev Niels Bakker:

* 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. Regards, Baldur

Den 10/10/2016 kl. 22.27 skrev Owen DeLong:

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. 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

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 On Wed, Oct 12, 2016 at 1:58 AM, Owen DeLong <owen@delong.com> wrote:

...

On Oct 10, 2016, at 14:59 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:

Den 10/10/2016 kl. 22.27 skrev Owen DeLong:

...

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

Hi Solution B is what happens by default and requires no changes by any party. A, B and C just do what they would do in any transit relation. The default BGP shortest AS path length first algorithm will make sure that traffic is delivered correctly. Solution A requires that ISP A actively filter the /24 announcement and that would have severe negative impact. It would mean that you would not receive any traffic at all through that link unless the link to ISP B is down. Not even traffic from A to B (that would go A -> C -> B because of the more specific). Maybe you meant that they would only filter the /24 announcement on the peering link between A and C, but that would have no effect and therefore makes no sense. Remember that ISP A is only originating their own /19. The /24 route announcement is received from ISP B and merely propagated (not originated) to ISP As uplink and peers. The moment that the link between A and B is down, the /24 route announcement will gone as well - instead A will be receiving the /24 route announcement via C. Regards, Baldur Den 19/10/2016 kl. 18.27 skrev Martin T:

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

On Wed, Oct 12, 2016 at 1:58 AM, Owen DeLong <owen@delong.com> wrote:

...

...

On Oct 10, 2016, at 14:59 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:

Den 10/10/2016 kl. 22.27 skrev Owen DeLong:

...

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

On Mon, Oct 10, 2016 at 2:44 PM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:

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

Here's a real-world issue I ran into with this. In this case, it isn't that someone filtered /24s, but that they didn't have a full table (peering routes only plus a default). This resulted in them following the less specific route for traffic destined for the /24. A customer of mine was advertising only a /20 to me and then only a more specific /24 was advertised from a remote site of theirs to a different ISP. The customer did have a connection between their two sites, so in theory it was OK if the traffic arrived on their "wrong" link, except that the customer strongly didn't want this to happen, thus the inconsistent routes. This customer found that the remote /24 was unable to access a large CDN provider. This CDN told them that a traceroute to the /24 went to my network (we peered at an exchange) and was then dropped. This seemed odd at first, as I confirmed I was not advertising the /24 to them so why were they routing it to me? It turned out that the CDN provider was running a peer-routes-only network with a default to their transit. This meant that they saw the /20 from their peer (me) but never saw the /24, since they carried no transit routes. This resulted in them routing the entire /20 to me. My peering router was not willing to route traffic from a peering exchange towards transit I had to pay for, so it was dropped. The customer's split advertisements didn't seem particularly unreasonable or invalid, though perhaps they were not the preferred setup. It wasn't unreasonable for me to not route from a peering exchange to transit. It wasn't unreasonable of the CDN to have a peering-and-default routing table. But, those three things together were not compatible. I called the customer and presented them with my findings and some potential options to consider, and consistent advertisements was one of those options. The customer strongly wanted incoming traffic to arrive directly to the correct location so he didn't want to do that. I suggested a possible compromise was for him to advertise both the /24 and /20 to me, but use communities so that I never advertised his /24 to any upstreams or peering exchanges. That way, if traffic for the /24 accidentally hit my network like we were running into, I would route it to him and he could pass it to the correct site. It meant that a little traffic would arrive at the wrong site in his network and have to pass over his back-end link, but at least it would be fairly limited. He didn't like this either. He didn't want to split the /20 advertisement up to no longer cover the /24 either, I think just because "I shouldn't have to do that!" The option the customer chose in the end was to use a community on his advertisement to instruct my routers to no longer advertise his /20 to any peering exchanges at all. That ensured the CDN didn't directly send me anything for him (not the /24 or the /20), and the transit networks in-between took care of making sure traffic to the /24 didn't accidentally end up on my network. While I didn't find it very elegant to be shifting traffic from peering exchanges to transit, it wasn't a significant amount of traffic and it got him off my back.

That only works if the /24 isn't coming from the middle of the /20 block and is on the front end or back end. Luke Guillory Network Operations Manager Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory@reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Martin T Sent: Monday, October 24, 2016 7:06 AM To: Matt Buford; Baldur Norddahl Cc: nanog Subject: Re: nested prefixes in Internet Thank you all for the replies! I'll go with the solution where "ISP A" announces both /19 prefix and /24 prefix. Martin On Thu, Oct 20, 2016 at 1:16 AM, Matt Buford <matt@overloaded.net> wrote:

On Mon, Oct 10, 2016 at 2:44 PM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:

...

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

Here's a real-world issue I ran into with this. In this case, it isn't that someone filtered /24s, but that they didn't have a full table (peering routes only plus a default). This resulted in them following the less specific route for traffic destined for the /24.

A customer of mine was advertising only a /20 to me and then only a more specific /24 was advertised from a remote site of theirs to a different ISP. The customer did have a connection between their two sites, so in theory it was OK if the traffic arrived on their "wrong" link, except that the customer strongly didn't want this to happen, thus the inconsistent routes.

This customer found that the remote /24 was unable to access a large CDN provider. This CDN told them that a traceroute to the /24 went to my network (we peered at an exchange) and was then dropped.

This seemed odd at first, as I confirmed I was not advertising the /24 to them so why were they routing it to me? It turned out that the CDN provider was running a peer-routes-only network with a default to their transit. This meant that they saw the /20 from their peer (me) but never saw the /24, since they carried no transit routes. This resulted in them routing the entire /20 to me.

My peering router was not willing to route traffic from a peering exchange towards transit I had to pay for, so it was dropped.

The customer's split advertisements didn't seem particularly unreasonable or invalid, though perhaps they were not the preferred setup. It wasn't unreasonable for me to not route from a peering exchange to transit. It wasn't unreasonable of the CDN to have a peering-and-default routing table. But, those three things together were not compatible.

I called the customer and presented them with my findings and some potential options to consider, and consistent advertisements was one of those options. The customer strongly wanted incoming traffic to arrive directly to the correct location so he didn't want to do that. I suggested a possible compromise was for him to advertise both the /24 and /20 to me, but use communities so that I never advertised his /24 to any upstreams or peering exchanges. That way, if traffic for the /24 accidentally hit my network like we were running into, I would route it to him and he could pass it to the correct site. It meant that a little traffic would arrive at the wrong site in his network and have to pass over his back-end link, but at least it would be fairly limited. He didn't like this either. He didn't want to split the /20 advertisement up to no longer cover the /24 either, I think just because "I shouldn't have to do that!"

The option the customer chose in the end was to use a community on his advertisement to instruct my routers to no longer advertise his /20 to any peering exchanges at all. That ensured the CDN didn't directly send me anything for him (not the /24 or the /20), and the transit networks in-between took care of making sure traffic to the /24 didn't accidentally end up on my network. While I didn't find it very elegant to be shifting traffic from peering exchanges to transit, it wasn't a significant amount of traffic and it got him off my back.

Misread the email. Ignore my ignorance. Sent from my iPad

On Oct 24, 2016, at 9:48 PM, Owen DeLong <owen@delong.com> wrote:

How do you figure that?

Owen

...

On Oct 24, 2016, at 06:22 , Luke Guillory <lguillory@reservetele.com> wrote:

That only works if the /24 isn't coming from the middle of the /20 block and is on the front end or back end.

Luke Guillory Network Operations Manager

Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory@reservetele.com

Reserve Telecommunications 100 RTC Dr Reserve, LA 70084

_________________________________________________________________________________________________

Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. .

-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Martin T Sent: Monday, October 24, 2016 7:06 AM To: Matt Buford; Baldur Norddahl Cc: nanog Subject: Re: nested prefixes in Internet

Thank you all for the replies! I'll go with the solution where "ISP A" announces both /19 prefix and /24 prefix.

Martin

...

On Thu, Oct 20, 2016 at 1:16 AM, Matt Buford <matt@overloaded.net> wrote: On Mon, Oct 10, 2016 at 2:44 PM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:

...

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

Here's a real-world issue I ran into with this. In this case, it isn't that someone filtered /24s, but that they didn't have a full table (peering routes only plus a default). This resulted in them following the less specific route for traffic destined for the /24.

A customer of mine was advertising only a /20 to me and then only a more specific /24 was advertised from a remote site of theirs to a different ISP. The customer did have a connection between their two sites, so in theory it was OK if the traffic arrived on their "wrong" link, except that the customer strongly didn't want this to happen, thus the inconsistent routes.

This customer found that the remote /24 was unable to access a large CDN provider. This CDN told them that a traceroute to the /24 went to my network (we peered at an exchange) and was then dropped.

This seemed odd at first, as I confirmed I was not advertising the /24 to them so why were they routing it to me? It turned out that the CDN provider was running a peer-routes-only network with a default to their transit. This meant that they saw the /20 from their peer (me) but never saw the /24, since they carried no transit routes. This resulted in them routing the entire /20 to me.

My peering router was not willing to route traffic from a peering exchange towards transit I had to pay for, so it was dropped.

The customer's split advertisements didn't seem particularly unreasonable or invalid, though perhaps they were not the preferred setup. It wasn't unreasonable for me to not route from a peering exchange to transit. It wasn't unreasonable of the CDN to have a peering-and-default routing table. But, those three things together were not compatible.

I called the customer and presented them with my findings and some potential options to consider, and consistent advertisements was one of those options. The customer strongly wanted incoming traffic to arrive directly to the correct location so he didn't want to do that. I suggested a possible compromise was for him to advertise both the /24 and /20 to me, but use communities so that I never advertised his /24 to any upstreams or peering exchanges. That way, if traffic for the /24 accidentally hit my network like we were running into, I would route it to him and he could pass it to the correct site. It meant that a little traffic would arrive at the wrong site in his network and have to pass over his back-end link, but at least it would be fairly limited. He didn't like this either. He didn't want to split the /20 advertisement up to no longer cover the /24 either, I think just because "I shouldn't have to do that!"

The option the customer chose in the end was to use a community on his advertisement to instruct my routers to no longer advertise his /20 to any peering exchanges at all. That ensured the CDN didn't directly send me anything for him (not the /24 or the /20), and the transit networks in-between took care of making sure traffic to the /24 didn't accidentally end up on my network. While I didn't find it very elegant to be shifting traffic from peering exchanges to transit, it wasn't a significant amount of traffic and it got him off my back.

Niels Bakker wrote:

...

I have reports that in case (2), some operators (e.g. Rostelecom) don't accept the /24 or even /23 prefix on the grounds that it is part of a larger /19 route already present in the routing table.

Could they have a reason not to accept these more specific prefixes other than a whim?

If you announce a prefix you must deliver traffic sent to addresses covered by it. You don't go announcing 0.0.0.0/0 to your peers either.

If a customer takes a /24 and announces it elsewhere, a transit provider runs the risk of accepting inbound traffic without having the possibility to bill their customer for it if it accepts more specifics from e.g. a peer.

That's all correct from the point of view of the provider annoncing the /19 route, and should be their risk. My question was however from a different perspective. If AS333 receives a /19 from AS111 and a /24 from AS222 (where AS222's /24 is nested within AS111's /19), what reason might AS333 have to ignore the /24? AS333 is not concerned with possible monetary relations between AS111 and AS222. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru

On Mon, 21 Nov 2016, Victor Sudakov wrote:

That's all correct from the point of view of the provider annoncing the /19 route, and should be their risk.

My question was however from a different perspective. If AS333 receives a /19 from AS111 and a /24 from AS222 (where AS222's /24 is nested within AS111's /19), what reason might AS333 have to ignore the /24? AS333 is not concerned with possible monetary relations between AS111 and AS222.

RIB/FIB bloat. They may figure the least specific route is good enough for getting packets to the destination and assume anything more specific is just the usual pointless deaggregation so commonly seen on the Internet. Maybe they're putting off hardware upgrades required by a current-day unfiltered full table. Maybe there are features that stop working properly on their routers if they load several unfiltered full tables into the RIB. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________