I didn't mean confederations. May be a diagram would be better.
Current design: (ASN: 1234) (Customer-A) --(ebgp) --[[ (Area 10) --- (Area 0) --- (Area 20) ]]-- (ebgp)-- (Customer-B) IGP is running in Area 0 for P2P and loopbacks. Area10, Area0 and Area20 are part of one Administravie domain representing ASN: 1234. Area10, Area20 has its own customers. New Proposed design: Remove Area10 and Area20 and instead use E-BGP. Area10 would become ASN65010, Area20 would become ASN65020 and run their own IGP. ASN65010 would be a customer of ASN1234. Problem: If Area10 becomes ASN65010, what happens to the customer who peers with ASN1234? I still want the customer to peer with ASN1234 and customer should not be aware of ASN65010. Sincerely, -Tim On Fri, Dec 28, 2012 at 10:33 PM, Christopher Morrow <[email protected]> wrote: > (Android mail sucks, sorry) > > I think the OP means confederation not 'private islands'.... And they'll have > to do some planning to move to confederations. > > More importantly, why get rid of your igp? Are you not already doing route > reflection and/or ibgp full mesh ? > > "Justin M. Streiner" <[email protected]> wrote: > >>On Fri, 28 Dec 2012, tim tiriche wrote: >> >>> We have multi area OSPF and would like to migrate the multi area to >>> private ASN BGP islands. >> >>How are you defining an 'island'? >> >>> Main ASN:1234 >>> >>> Problem: >>> >>> In the current OSPF areas there is an e-BGP Peering and Transit with >>> customer. >>> After migration, how can i ensure that customer peer using the Main >>> ASN:1234 and transport it over the core? >> >>"Peering" and "Transit" mean two different things to a number of people >>who read this mailing list. I'm guessing you mean one or the other (most >>likely transit)? >> >>If the customers speak eBGP with you today, and your end of the session is >>in AS1234, then the customer's traffic will transit AS1234, depending on >>what you do with the traffic while it's on your network. If I'm >>understanding your intentions correctly, what do you hope to gain, or what >>problem are you trying to solve by creating 'private ASN BGP islands'? >> >>If the issue is reducing the number of IBGP sessions on your backbone, >>have a look at route reflectors and BGP confederations. >> >>> How have others done it? >> >>In my past life, we spoke eBGP with our downstream customers. Either the >>customers had their own public ASN, or we used another public ASN that we >>had available at the time. Private ASNs were used in a few corner cases. >>The latter two approaches impose limitations that might not be acceptable >>for some customers. YMMV. >> >>jms >> >>> Loops, local-as? Would independent domain help? >>> >>> Looking for suggestions. >>> >>> Sincerely, >>> -Tim >>> _______________________________________________ >>> juniper-nsp mailing list [email protected] >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>> >>_______________________________________________ >>juniper-nsp mailing list [email protected] >>https://puck.nether.net/mailman/listinfo/juniper-nsp > > _______________________________________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
