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 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
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.
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
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:
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?
I I were you, I will advertise as following.
/21 Original ARIN allocation
/22 First half of ARIN allocation
/22 second half of ARIN allocationIn 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:
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.
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
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
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