Offers BGP prefix/route summary at Microsoft Enterprise Edge (MSEE) ExpressRoute routers
There is an urgent business need to summarize BGP prefix/route at MSEEs before being propagate to its peers at remote sites i.e. Cloud Gateway Access (CGA) routers in relation to Express Route service (as there is vary limit of allowable prefix entry set at remote CGA routers i.e. default 20 in some case).
This BGP prefix summarization helps reduce the need of large number of prefix entries to be broadcasted from Azure to CGA especially for business case that have large number of spoke VNETs (Hub and Spoke model) leveraging on granular address space of a large prefix.
For example, one of the spoke VNET prefix configuration as below.
192.168.0.0/25 (larger prefix for workload)
- 192.168.0.0/27 (subnet)
- 192.168.0.32/27 (subnet)
- 192.168.0.64/27 (subnet)
- 192.168.0.96/27 (subnet)
192.168.0.128/25 (larger prefix for backup and recovery)
- 192.168.0.128/27 (subnet)
- 192.168.0.160/27 (subnet)
- 192.168.0.192/27 (subnet)
- 192.168.0.224/27 (subnet)
From above example, spoke VNET alone potentially contribute a total number of 40 prefixes (2 address prefix/address space x 20 spoke VNETs) from Azure to CGA over BGP propagation for a 20 spoke VNETs deployment, not forgetting there is Hub and other direct expressroute connection from non hub-spoke deployment through Virtual Network Gateway.
This prefix entries would be reduced significantly to one prefix entry if BGP summarization can be performed at MSEEs leval, which end result is only 192.168.0.0/16 for this particular business case.
Thanks for the valid suggestion. Your feedback is now open for the user community to upvote which allows us to effectively prioritize your request against our existing feature list and also gives us insight into the potential impact of implementing the suggested feature
Herbert, John G commented
The lack of available summarization coupled with, as CataLin notes, the curiously low limit of 200 routes that can be sent from the VNet address space is a scalability and resiliency killer. Unless I am missing another feature which negates this need, this requirement seems to be pretty essential.
"Maximum number of routes advertised from Azure private peering from the VNet address space for an ExpressRoute connection" is 200.
!! This definetly has to be increased, or to have the possibility to summarize prefixes !!
Additionally the effect that "NOTHING WORKS" when exceeding the limit is not tolerable, it has to be a warning upfront or something - please work on this, Many thanks in advance - keep the good work up!!
It has been a quarter lapsed since this feedback was "triaged", would very much appreciate if ExpressRoute team may consider to pick this up as part of ER feature enhancement plan.