《
BGP routing policies in ISP Networks
"
IEEE Network magazine 2005
1 Ways to configure local policythere are three classes of "knobs" that can be used to controlimport and export policies: 1) preference (demo-process) 2) filter (eliminate certain route) 3) tag (community) 2 BGP policy common practice and design pattern1) business relationship (1) inbound: Assign local-preference to influence the BGP demo-process. often an ISP will achieve this byassigning a non-ove Rlapping range of localpref values to eachtype of peering relationship; for example localpref values inthe range 90-99 might be used for MERs, 80-89 for peers, 70-79 for providers, and 60-69 for backup links. localpref canthen be varied within each range to do traffic engineering withoutviolating the constraints associated with the business relationship. so if I stand in the perspective of an autonomous system or ISP, we can use SNMP or other methods to obtain The route table of the VBR can be used to predict the business relationship with the neighbor autonomous system based on the Local-preference value of multiple routes with the same prefix. (2) outbound:
Controlling route ExportIt seems that it is difficult to deduce an export policy by means of a single autonomous system, but it does not mean that it should be verified and matched one by one with the method of policy configuration, in fact, we only need to be able to deduce the commercial relationship correctly. 2) Traffic Engineering (1) outbound traffic control (by changing local-preference and IGP costs) outbound traffic control is actually the control of inbound policies, I think this can be done from the perspective of a single autonomous system. For example, if you find that the local-preferce with the same prefix is different from the routing table of different vbrs, load Balancing may be performed. Different metric methods are used to find different hot-potato regions and different as-path lengths. (2)
Inbound traffic control (by as prepending and MED ):The control of inbound traffic is actually the outbound policy, that is, how to reach the prefix of the autonomous system. It mainly includes the MED values used by neighboring Autonomous Systems in multiple link and the Autonomous System Numbers controlled by remote. However, I think it is more straightforward to collect data from the neighbor autonomous system for analysis.
(3) remote control (by changing community attributes ):Remote controlprovides more flexibility than med because it allows controlof inputs to earlier steps of the demo-process like local-pref, as shown in the example above. moreover, Med can onlychange the relative preference of routes, while remote controlcan be configured to filter routes, or perform as prepending. however, ISP's neighbors mustagree in advance to accept Community attributes from the otherpeer. also, the highly expressive nature of Community attributesintroduces potential for misconfiguration. 3) scalability
Limiting routing table size (by filtering and using the Community attribute):
Limit the number of routing changes (by suppressing routes that flap)4) Security
Discarding invalid routes (by import filtering)
Protect integrity of routing policies (by rewriting attributes)
Securing the network infrastructure (by export filtering)
Blocking denial-of-service attacks (by filtering and damping)《
Practical Verification Techniques for wide-area RoutingSigcomm Cr 20041 verify five aspect of correcteness:
Validity(The existence of a route impliesthe existence of a corresponding path ),
Visibility(The existence ofa path implies the existence of a corresponding route ),
Safety(Theexistence of a stable, unique path assignment ),
Determinism(Bestroute selection is independent of message ordering and the presenceof sub-optimal routes), and
Information-Flow Control(The protocolconforms to a specified information flow policy; that is, it does not "leak" information ). 2 Verification Methodology: static analysisparses configuration statements to detect errors that are evidentfrom the configuration commands themselves. A Sandbox can determinewhether (and under what circumstances) a seemingly correct
Configuration can produce incorrect behavior
