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 <m...@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.engehau...@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 >>
