Thank you everyone. I will be going for confederations. Sincerely, -Tim
On Sun, Dec 30, 2012 at 1:19 PM, Chris Morrow <[email protected]> wrote: > > > On 12/30/2012 12:31 PM, tim tiriche wrote: >> I didn't mean confederations. >> > > yes you did, according to your diagram... > >> 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. > > this sort of sounds like the wrong hammer to be using... to me at least. > >> Area10 would become ASN65010, Area20 would become ASN65020 and run >> their own IGP. > > why? don't you want the edge device(s) in 20/10 to be able to benefit > from the whole IGP knowledge across your domain? breaking things up into > different igps seems more complicated than it needs to be, to me. > >> ASN65010 would be a customer of ASN1234. >> > > yea.. no. > I really think you mean that the confed-as is 1234 and > 65010/65020/65<core> are all parts of the confederation. If done this > way your customers continue to be peered with 1234 and you just migrate > things to a more stable/scalable solution over a few weeks work. > >> 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. > > right, that's what confederations are for (well, one purpose of them). > > The OTHER option is to use some of the whackitude that is 'peer-as' in > the juniper world and hide your ASN change from the customers... this > has longer term maintenance headache implications, and most uses of it > are for M&A situations: "We just bought AS12, let's make them part of > our AS: AS1, and slowly convert all customers we can talk to, meanwhile > 'peer-as' all customer sessions so they appear to still connect to AS4, > while the edge devices are re-homed into AS1" > > it's messy and will cause operations problems in the long term... > > -chris > > >> >> 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
