1. Best Practices for ISPs
By Ahmer Ghazi, Sysnet

2. Introduction POP Hierarchy Scaling IGP Scaling BGP
Not running IGP with the customer
No customer routes in IGP
No Redistribution from BGP to IGP
IGP Summarization
Partitioning into areas
Scaling BGP
Aggregation
Filtering Policy
Route Reflector Design

3. POP Hierarchy Primary POP Secondary POP Other POPs Core Peering ISPs
Distribution
Access
Primary POP
Secondary POP
Customers

4. Scaling IGP Never run IGP with the customer
Increases the database size and difficult to control
Routing instability within the customers’ network will be propagated to the ISP.
If non-BGP customer, ISP should put static routes for customers address blocks.
Customer static routes should not be redistributed into IGP.
Redistribute customer static routes directly into BGP; send towards core using iBGP.

5. Scaling IGP (Managing Edge links)
Edge links, if required should be summarized at the AS Boundary router
Edge link IP addresses should be assigned from contiguous address block
Externals create Type-5 LSA in OSPF and flooded everywhere
If not summarized at ASBR, externals cannot be summarized at ABR

6. Scaling IGP (No Redistribution from BGP to IGP)
Goal of the IGP design should be to minimize the number of prefixes and only carry the BGP Next-Hops.
Never redistribute BGP into IGP
Try to bring customers in stub area; that way redistribution (even if configured) won’t work.

7. Scaling IGP (Summarization)
IGP Summarization at POP boundary
Manageable address allocation
Edge Links
Customer addresses
Internal (to the POP) addresses
No backhaul connections by-passing the core
Not summarizing Loopbacks

8. Scaling IGP (Area Partitioning)
Scalable but complex
Less Load on routers
Instability is hidden

9. BGP Prefix Aggregation
Aggregation at Multiple points
Following is captured from a router server. ? i
AS owns /19
Engineer traffic by advertising different MEDs.
Advertise more specifics with “no-export” community, in addition to the aggregate.

10. Filtering Policy
Filter to prevent the injection of invalid routes into global tables.
Prefixes should not be accepted as smaller blocks.
ISP should only accept prefixes originated from the customers’ AS and those for which the customer is offering transit services.
Avoid becoming an unintended transit.

11. Route Reflectors Route reflector Client Non-client Cluster Cluster ID
Cluster List
Originator-ID
Hierarchical RRs
Normal BGP peer RR RR RR
RRC
RRC

12. Route Reflector
RR advertises iBGP learned routes from its clients to other iBGP routers.
A Cluster consists of RR + Clients; Cluster, Cluster-ID, Cluster List
RR does not modify any of the BGP attributes.
Route Reflector might not come in the actual traffic path.
The RR discards the route if it sees its own cluster-id in the cluster list

13. Multiple RR
Two RRs per POP
RR1
RR2
RRC

14. RR Designs Follow physical topology
Larger POPs can have two levels of route reflection.
Core (RR), Distribution (RR & Client), Edge routers (Client)
RR of smaller POPs will be clients of the top level RR of the larger POPs.
All the RR should either be iBGP fully meshed or connected to another layer of RR.

15. Hierarchical RR Primary POP Secondary POP Other POPs Core RR RR
Peering ISPs
Distribution RR RR
RR/RRC
RR/RRC
Access
RRC
RRC
RRC
RRC
RRC
RRC
RRC
Primary POP
Secondary POP
Customers

16. Summary Scaling IGP Scaling BGP Not running IGP with the customer
No customer routes in IGP
No Redistribution from BGP to IGP
IGP Summarization
Partitioning into areas
Scaling BGP
Prefix Aggregation
Filtering Policy
Route Reflector Design