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
