Hey all, I'm looking for an opinion from the group. I have an ARIN /21 assignment and a new requirement for a second data center. Rather than ask for another assignment, I would like to advertise one /22 from one location and the other /22 from the second location both with the same asn. My apps will work that way, so I don't have an issue internally, but I'm looking for a broader base opinion on that. Thanks a lot! -James
On Thu, 22 May 2008, James Kelty wrote:
I'm looking for an opinion from the group. I have an ARIN /21 assignment and a new requirement for a second data center. Rather than ask for another assignment, I would like to advertise one /22 from one location and the other /22 from the second location both with the same asn. My apps will work that way, so I don't have an issue internally, but I'm looking for a broader base opinion on that.
You can do this and it shouldn't be much of an issue. Note tht if you change your routing policy in the future and opt to announce the full /21 from both data centers, you will need to make provisions for connectivity between the two sites since both sites would be advertising reachability for the full block. jms
As long as your upstreams/partners are cool with that, there is no related designation between how addresses are allocated versus how they are announced. In other words, TECHNICALLY you could advertise a whole bunch of /30's.... You just run the risk of being filtered and/or ridiculed along the way. :) But splitting the /22's from the same announcing AS shouldn't cause any problems as long as you design your connectivity ok. Scott -----Original Message----- From: James Kelty [mailto:jkelty@pandora.com] Sent: Thursday, May 22, 2008 12:39 PM To: nanog@nanog.org Subject: Splitting ARIN assignment Hey all, I'm looking for an opinion from the group. I have an ARIN /21 assignment and a new requirement for a second data center. Rather than ask for another assignment, I would like to advertise one /22 from one location and the other /22 from the second location both with the same asn. My apps will work that way, so I don't have an issue internally, but I'm looking for a broader base opinion on that. Thanks a lot! -James
Hi, I do appreciate real life is often more complex than high flying ideals. But aggregation and general good practice would mean in an ideal world you would invest in the internal infrastructure to connect your data centres together with a network and run an IGP+iBGP plus advertise the /21 eBGP at both sites to upstreams. It could be argued that the cost of building the network to run your AS is part and parcel of the expense of opening new datacenter - rather than this ever increasing route table growth. Plus if you de-aggregate as intended you can not announce a covering route for the /21 due to no internal connectivity and if this puts the /22 under the minimum allocation size for the RIR block your IP space comes from then don't be surprised when it gets filtered out and people end up having to accept no routing to your network at all or, sum optimal via a default. But life is rarely as simple as ideals. My 2e Ben -----Original Message----- From: Scott Morris [mailto:swm@emanon.com] Sent: 22 May 2008 17:49 To: 'James Kelty'; nanog@nanog.org Subject: RE: Splitting ARIN assignment As long as your upstreams/partners are cool with that, there is no related designation between how addresses are allocated versus how they are announced. In other words, TECHNICALLY you could advertise a whole bunch of /30's.... You just run the risk of being filtered and/or ridiculed along the way. :) But splitting the /22's from the same announcing AS shouldn't cause any problems as long as you design your connectivity ok. Scott -----Original Message----- From: James Kelty [mailto:jkelty@pandora.com] Sent: Thursday, May 22, 2008 12:39 PM To: nanog@nanog.org Subject: Splitting ARIN assignment Hey all, I'm looking for an opinion from the group. I have an ARIN /21 assignment and a new requirement for a second data center. Rather than ask for another assignment, I would like to advertise one /22 from one location and the other /22 from the second location both with the same asn. My apps will work that way, so I don't have an issue internally, but I'm looking for a broader base opinion on that. Thanks a lot! -James
James Kelty wrote:
Hey all,
I'm looking for an opinion from the group. I have an ARIN /21 assignment and a new requirement for a second data center. Rather than ask for another assignment, I would like to advertise one /22 from one location and the other /22 from the second location both with the same asn. My apps will work that way, so I don't have an issue internally, but I'm looking for a broader base opinion on that.
Thanks a lot!
-James
You should attempt to advertise the /21 at each site along with the site's /22 If you dont have dedicated interconnectivity between the sites, tunneling *carefully* should do the trick. This will ensure that if/when those who filter on strict allocation boundaries dont hear your /22, there will still be reachability, even if suboptimal, to your sites.
On May 22, 2008, at 7:02 PM, Joe Maimon wrote:
James Kelty wrote:
Hey all, I'm looking for an opinion from the group. I have an ARIN /21 assignment and a new requirement for a second data center. Rather than ask for another assignment, I would like to advertise one /22 from one location and the other /22 from the second location both with the same asn. My apps will work that way, so I don't have an issue internally, but I'm looking for a broader base opinion on that. Thanks a lot! -James
You should attempt to advertise the /21 at each site along with the site's /22
If you dont have dedicated interconnectivity between the sites, tunneling *carefully* should do the trick.
This will ensure that if/when those who filter on strict allocation boundaries dont hear your /22, there will still be reachability, even if suboptimal, to your sites.
I have an equivalent dilemma: I'm of course well educated about not de- aggregating and would like, as much as possible, to avoid it. I'm trying to build a small-bandwidth core across an MPLS VPN, and I haven't been able to get an answer from the suppliers I'm auditing (even big ones...) although I'm pretty sure I can do it. Basically, the way I see it is that it would only be equivalent to a situation where hosts on my local LANs had tcp179 sessions across the VPN - but yet some (quite big players, not mentioning them though) are saying it would conflict with their instance of MP-BGP used for the VPN-v4. I seriously doubt it, but don't want to try it if there is a slightest risk. Also, I'm technically convinced that the supplier can maintain my loopback's connectivity and replace my IGP to bear my infrastructure's addressing (well I'd first have to get them to accept whatever OSPF between my router and their CPE, so their CPEs redistribute my subnets into the VPN's vrf on their PEs). I also don't want to add operational complexity by setting tunnels (one of the suppliers advised me to...) to bear the sessions - which I know would work, but I need to be sure my designed can be maintained easily, with least possible training. The only B-Plan that I eventually have, is voluntarily bypass best- practice (should my self esteem suffer from that :) split my announces on different geographical zones, to not have to maintain iBGP sync. Any one of you folks have any such experience ? I'd hate to upset the community and get NOs to peering enquiries just because of that, which basically would make running an AS pointless... Any pointers warmly welcome. Greg VILLAIN Independent internet architect
On Sat, May 31, 2008 at 5:34 PM, Greg VILLAIN <nanog@grrrrreg.net> wrote:
I have an equivalent dilemma: I'm of course well educated about not de-aggregating and would like, as much as possible, to avoid it. I'm trying to build a small-bandwidth core across an MPLS VPN, and I haven't been able to get an answer from the suppliers I'm auditing (even big ones...) although I'm pretty sure I can do it.
Basically, the way I see it is that it would only be equivalent to a situation where hosts on my local LANs had tcp179 sessions across the VPN - but yet some (quite big players, not mentioning them though) are saying it would conflict with their instance of MP-BGP used for the VPN-v4. I
nonsense... traffic from CE to CE isn't visible to the PE nor P routers aside from labelled packets... How else would people be able to sell CCC circuits across MPLS networks that are used for Internet Connectivity and have BGP from CE to PE (where the ce/pe link is the CCC link) I think the folks you are chatting with at the providers are not understanding your question(s) or their network(s). -Chris
I I were you, I will advertise as following. /21 Original ARIN allocation /22 First half of ARIN allocation /22 second half of ARIN allocation In this case, you will have backup /21 route just in case of filtering or something like that. But in normal case, traffic will be routed based on more specific routes, which are /22s. In some case, upstream ISPs may filter based on strict filtering, which means all BGP prefix announcement should be matched with registered CIDR info including subnet size. In most case, upstream ISP will accept any subnet size between registered size (/21) and /24 size. Because of load sharing and traffic engineering requirement, it is easy to handle those situation with /22 size. Make sure that your two location is inter-connected directly, and have enough capacity when each of location upstream connection goes down. Hyun ames Kelty wrote:
Hey all,
I'm looking for an opinion from the group. I have an ARIN /21 assignment and a new requirement for a second data center. Rather than ask for another assignment, I would like to advertise one /22 from one location and the other /22 from the second location both with the same asn. My apps will work that way, so I don't have an issue internally, but I'm looking for a broader base opinion on that.
Thanks a lot!
-James
Make sure that your two location is inter-connected directly,
Why is this required? If you put static routes to point the remote /21 to the upstream provider on each side wouldn't that take care of the origin AS loop? On 5/22/08 10:45 AM, "Hyunseog Ryu" <r.hyunseog@ieee.org> wrote:
I I were you, I will advertise as following.
/21 Original ARIN allocation /22 First half of ARIN allocation /22 second half of ARIN allocation
In this case, you will have backup /21 route just in case of filtering or something like that. But in normal case, traffic will be routed based on more specific routes, which are /22s.
In some case, upstream ISPs may filter based on strict filtering, which means all BGP prefix announcement should be matched with registered CIDR info including subnet size. In most case, upstream ISP will accept any subnet size between registered size (/21) and /24 size.
Because of load sharing and traffic engineering requirement, it is easy to handle those situation with /22 size.
Make sure that your two location is inter-connected directly, and have enough capacity when each of location upstream connection goes down.
Hyun
ames Kelty wrote:
Hey all,
I'm looking for an opinion from the group. I have an ARIN /21 assignment and a new requirement for a second data center. Rather than ask for another assignment, I would like to advertise one /22 from one location and the other /22 from the second location both with the same asn. My apps will work that way, so I don't have an issue internally, but I'm looking for a broader base opinion on that.
Thanks a lot!
-James
Charles Yamasaki Manager Network Engineering Move Inc. 30700 Russell Ranch Rd Westlake Village, CA 91362 O: 805.557.3829 M: 805.603.6492 F: 805.557.3870
What if upstream connection - Internet - goes down? If you have fully redundant system implemented from both locations, so you don't need another site for operation, that will be fine. But in normal situation, there is some dependency. Also, if you have massive backup and/or data transaction between two location, it may good to have inter-connection - private link - between both location. Origin AS loop can be resolved by BGP configuration feature, or putting default route back to upstream connection. So probably that's not an issue at all. Real issue will be data/operation dependency between two locations such as DNS server IP address and things like that. If you are 100% sure about that there is no dependency between two locations, you may omit the requirement for inter-connection between two locations. Hyun Yamasaki, Charles wrote:
Make sure that your two location is inter-connected directly,
Why is this required? If you put static routes to point the remote /21 to the upstream provider on each side wouldn't that take care of the origin AS loop?
On 5/22/08 10:45 AM, "Hyunseog Ryu" <r.hyunseog@ieee.org> wrote:
I I were you, I will advertise as following.
/21 Original ARIN allocation /22 First half of ARIN allocation /22 second half of ARIN allocation
In this case, you will have backup /21 route just in case of filtering or something like that. But in normal case, traffic will be routed based on more specific routes, which are /22s.
In some case, upstream ISPs may filter based on strict filtering, which means all BGP prefix announcement should be matched with registered CIDR info including subnet size. In most case, upstream ISP will accept any subnet size between registered size (/21) and /24 size.
Because of load sharing and traffic engineering requirement, it is easy to handle those situation with /22 size.
Make sure that your two location is inter-connected directly, and have enough capacity when each of location upstream connection goes down.
Hyun
ames Kelty wrote:
Hey all,
I'm looking for an opinion from the group. I have an ARIN /21 assignment and a new requirement for a second data center. Rather than ask for another assignment, I would like to advertise one /22 from one location and the other /22 from the second location both with the same asn. My apps will work that way, so I don't have an issue internally, but I'm looking for a broader base opinion on that.
Thanks a lot!
-James
Charles Yamasaki Manager Network Engineering Move Inc. 30700 Russell Ranch Rd Westlake Village, CA 91362 O: 805.557.3829 M: 805.603.6492 F: 805.557.3870
Yamasaki, Charles wrote:
Make sure that your two location is inter-connected directly,
Why is this required? If you put static routes to point the remote /21 to the upstream provider on each side wouldn't that take care of the origin AS loop?
Origin AS is easily handled by the allow-as-in neighbor command and better replaced with more flexible as-path and prefix-lists in route-maps. The interconnection is required to be able to advertise the entire space as a "covering" prefix at both sites. Doing that without interconnectivity and using your static route idea would generate routing loops.
Sorry, typo'd the /21. He wants to carve into /22. On 5/22/08 11:45 AM, "Joe Maimon" <jmaimon@ttec.com> wrote:
Yamasaki, Charles wrote:
Make sure that your two location is inter-connected directly,
Why is this required? If you put static routes to point the remote /21 to the upstream provider on each side wouldn't that take care of the origin AS loop?
Origin AS is easily handled by the allow-as-in neighbor command and better replaced with more flexible as-path and prefix-lists in route-maps.
The interconnection is required to be able to advertise the entire space as a "covering" prefix at both sites.
Doing that without interconnectivity and using your static route idea would generate routing loops.
Charles Yamasaki Manager Network Engineering Move Inc. 30700 Russell Ranch Rd Westlake Village, CA 91362 O: 805.557.3829 M: 805.603.6492 F: 805.557.3870
participants (9)
-
Ben Butler -
Christopher Morrow -
Greg VILLAIN -
Hyunseog Ryu -
James Kelty -
Joe Maimon -
Justin M. Streiner -
Scott Morris -
Yamasaki, Charles