nested prefixes in Internet

Tue Sep 27 17:52:54 UTC 2016

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