3.7.d Implement, Optimize and Troubleshoot Routing Policies
3.7.d (ii) Conditional Advertisement
It is practically impossible to affect incoming traffic flows with 100% accuracy using BGP path attributes. There are methods to influence inbound routing like AS prepending or MED but traffic might still enter the AS over either link. BGP Conditional Advertisement allows the router to advertise a route only when certain conditions are met.
Conditional advertisement has two forms: advertisement of some prefixes when some other prefixes do not exist and advertisement of some prefixes when they do exist. The prefixes to be advertised are defined by a special route map called advertise-map. The condition is defined by a route map called non-exist-map for conditions that do not exist or by a route map called exist-map for conditions that do exist.
A common application for conditional advertisement is to force inbound and outbound traffic over one link and failover to the backup route only when the primary link fails.
+--------+
| |
| AS 200 |
| |
+--------+ +--------+
| | /
| AS 100 | --<
| | \
+--------+ +--------+
| |
| AS 300 |
| |
+--------+
Let's say R1 in AS 100 uses its connection to R3 in AS 300 (directly connected network 198.51.100.0/24) as its primary link. R1's connection to R2 in AS 200 (directly connected network 192.0.2.0/24) is strictly a backup connection. R1 has a local route 203.0.113.0/24 that should be advertised to R2 only if R3 is down. This can be accomplished with BGP conditional advertisement.
In other words:
- If 198.51.100.0/24 exists in R1's BGP table, then do not advertise 203.0.113.0/24 to R2.
- If 198.51.100.0/24 does not exist in R1's BGP table, then advertise the 203.0.113.0/24 to R2.
Configuration.
R1#
interface Loopback0
ip address 203.0.113.0 255.255.255.0
!
interface FastEthernet0/0
ip address 198.51.100.1 255.255.255.0
!
interface FastEthernet0/1
ip address 192.0.2.1 255.255.255.0
!
ip prefix-list R1-LOCAL seq 10 permit 203.0.113.0/24
!
ip prefix-list R1-R3-NET seq 10 permit 198.51.100.0/24
!
route-map ADV-ROUTE permit 10
match ip address prefix-list R1-LOCAL
!
route-map NON-EXIST-R1-R3 permit 10
match ip address prefix-list R1-R3-NET
!
router bgp 100
network 203.0.113.0 mask 255.255.255.0
network 198.51.100.0 mask 255.255.255.0
neighbor 192.0.2.2 remote-as 200
neighbor 192.0.2.2 advertise-map ADV-ROUTE non-exist-map NON-EXIST-R1-R3
neighbor 198.51.100.3 remote-as 300
R2#
interface FastEthernet0/0
ip address 192.0.2.2 255.255.255.0
!
router bgp 200
neighbor 192.0.2.1 remote-as 100
R3#
interface FastEthernet0/0
ip address 198.51.100.3 255.255.255.0
!
router bgp 300
neighbor 198.51.100.1 remote-as 100
Using the primary link under normal conditions.
R1#show ip bgp neigh 198.51.100.3 advertised-routes
BGP table version is 5, local router ID is 203.0.113.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 198.51.100.0 0.0.0.0 0 32768 i
*> 203.0.113.0 0.0.0.0 0 32768 i
Total number of prefixes 2
Note that 203.0.113.0/24 is not advertised to R2.
R1#show ip bgp neigh 192.0.2.2 advertised-routes
BGP table version is 5, local router ID is 203.0.113.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 198.51.100.0 0.0.0.0 0 32768 i
Total number of prefixes 1
After the link between R1 and R3 is shutdown, 203.0.113.0/24 is advertised to R2.
R1#show ip bgp neighbors 192.0.2.2 advertised-routes
BGP table version is 7, local router ID is 203.0.113.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 203.0.113.0 0.0.0.0 0 32768 i
Total number of prefixes 1
Naturally, 198.51.100.0/24 is no longer advertised because it does not exist in R1's BGP table.
3.7.d(iii) Outbound Route Filtering (ORF)
The BGP ORF feature is a routing policy optimization to filter out unwanted updates at the source. ORF is enabled through the advertisement of ORF capabilities. This indicates that the BGP speaker will accept an inbound prefix-list from a neighbor and apply it locally as an outbound filter.
ORF can be configured with send and/or receive ORF capabilities. The local peer advertises the ORF capability in send mode. The remote peer receives the ORF capability in receive mode and applies the filter as an outbound policy.
R1 is advertising the following networks to R3.
R1#show ip bgp neighbors 150.1.3.3 advertised-routes
BGP table version is 8, local router ID is 150.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 192.0.2.0 0.0.0.0 0 32768 i
*> 198.51.100.0 0.0.0.0 0 32768 i
*> 203.0.113.0 0.0.0.0 0 32768 i
Total number of prefixes 3
R3 has the following inbound filters applied.
ip prefix-list ORF-DENY seq 5 deny 203.0.113.0/24
ip prefix-list ORF-DENY seq 10 permit 0.0.0.0/0 le 32
!
router bgp 200
no synchronization
neighbor 150.1.1.1 remote-as 100
neighbor 150.1.1.1 ebgp-multihop 2
neighbor 150.1.1.1 update-source Loopback0
neighbor 150.1.1.1 prefix-list ORF-DENY in
no auto-summary
It is unnecessary to send 203.0.113.0/24 to R3 because the route is denied as soon as it is received.
*BGP(0): 150.1.1.1 rcvd 203.0.113.0/24 -- DENIED due to: distribute/prefix-list;
R3's BGP table (excluding locally originated routes).
R3#show ip bgp | exclude 0.0.0.0
BGP table version is 19, local router ID is 150.1.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 192.0.2.0 150.1.1.1 0 0 100 i
*> 198.51.100.0 150.1.1.1 0 0 100 i
To enable the ORF feature, R1 must be configured with the ORF receive capability and R3 with the ORF send capability.
R1#
router bgp 100
neighbor 150.1.3.3 capability orf prefix-list receive
R3#
router bgp 200
neighbor 150.1.1.1 prefix-list ORF-DENY in
neighbor 150.1.1.1 capability orf prefix-list send
R3's inbound routing policy is now applied outbound on R1.
R1#show ip bgp neighbors 150.1.3.3 advertised-routes
BGP table version is 20, local router ID is 150.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 192.0.2.0 0.0.0.0 0 32768 i
*> 198.51.100.0 0.0.0.0 0 32768 i
Total number of prefixes 2
With the full Internet routing table consisting of hundreds of thousands of routes, the benefit of minimized resource utilization due to ORF is clear. Although the same end result is achieved, ORF is much more efficient as compared to traditional inbound route filtering.
3.7.d (iv) Communities, extended communities
A community is a group of prefixes that share some common property and can be assigned the BGP community attribute. The BGP Community attribute is an optional transitive attribute of variable length. The attribute is a four-octect value, with the AS number typically encoded in the first two octects followed by a unique two-byte value.
BGP communities themselves do not affect the BGP best path selection but they can be used as flags to mark a set of routes. The community and extended communities attributes can trigger routing decisions, such as acceptance, rejection, preference, or redistribution. A prefix can have more than one community attributes. A BGP speaker can act on one, some or all the attributes. A router can also add or modify the community attributes before advertising to other peers.
BGP Community Attribute
++++++++++++++++++++++++++++++++++++++++
| Autonomous System Number (2 octects) |
++++++++++++++++++++++++++++++++++++++++
| Value (2 octets) |
++++++++++++++++++++++++++++++++++++++++
Communities can be defined in decimal or hexadecimal. Some community ranges are reserved and some values are used for specific purposes. For example, 0 to 65,535 (0x00000000 to 0x0000FFFF) and 4,294,967,041 to 4,294,967,295 (0xFFFF0000 to 0xFFFFFFFF) has been reserved by IANA.
Specific-purpose community attributes include:
- INTERNET (0): The default community. By default, all routes belong to this community and all routes in this category are advertised freely.
- NO_EXPORT (4,294,967,041 or 0xFFFFFF01): Routes with this COMMUNITY attribute must not be advertised outside of the local AS or confederation.
- NO_ADVERTISE (4,294,967,042 or 0xFFFFFF02): Routes with this COMMUNITY attribute must not be advertised to any peer.
- LOCAL_AS (4,294,967,043 or 0xFFFFFF03): Routes with this COMMUNITY attribute must not be advertised to any eBGP or external confederation peer (referred to as NO_EXPORT-SUBCONFED in RFC 1997).
The 4-octet community value does not provide enough expansion and flexibility to accommodate VPN requirements. This lead to the creation of extended communities. An extended community is an 8-octet value that is also divided into two main sections. The first 2 octets of the community encode a type field while the last 6 octets carry a unique set of data in a format defined by the type field. Extended communities provide a larger range for grouping or categorizing communities.
BGP Extended Community Attribute
++++++++++++++++++++++++++++++++++++++++++++++++++
| I | T | Type High (4 bits) | Type Low (8 bits) |
++++++++++++++++++++++++++++++++++++++++++++++++++
| |
| |
| Value (6 octets) |
| |
| |
++++++++++++++++++++++++++++++++++++++++++++++++++
I = IANA or IETF
T = transitive or non-transitive
The Route Target extended community is in popular use wihin MPLS VPNs.The Route Target Community identifies one or more routers that may receive a set of routes (that carry this Community) carried by BGP.
BGP communities are not propagated by default. The neighbor x.x.x.x send-community [standard | extended | both] is required.
Let's look at an example. R1 in AS 100 has the following routes: 192.168.10.0/24, 192.168.11.0/24, 172.16.16.0/24, and 172.16.17.0/24. R1 is going to advertise the 172.16.16.0/24 and 172.16.17.0/24 networks with a community attribute NO_EXPORT to prevent AS 200 from propagating those routes further to AS 300.
+--------+ +--------+ +--------+
| | | | | |
| AS 100 | --- | AS 200 | --- | AS 300 |
| | | | | |
+--------+ +--------+ +--------+
The configuration.
ip prefix-list 172-NETS seq 5 permit 172.16.16.0/24
ip prefix-list 172-NETS seq 10 permit 172.16.17.0/24
!
!
!
route-map NO-EXPORT permit 10
match ip address prefix-list 172-NETS
set community no-export
!
route-map NO-EXPORT permit 20
!
router bgp 100
no synchronization
bgp log-neighbor-changes
network 172.16.16.0 mask 255.255.255.0
network 172.16.17.0 mask 255.255.255.0
network 192.168.10.0
network 192.168.11.0
neighbor 10.1.12.2 remote-as 200
neighbor 10.1.12.2 send-community both
neighbor 10.1.12.2 route-map NO-EXPORT out
no auto-summary
R2 and R3 have only basic BGP configuration for peering.
Packet capture of the BGP UPDATE as sent from R1 to R2.
Border Gateway Protocol - UPDATE message
Path Attributes
Path Attribute - COMMUNITIES: NO_EXPORT
Flags: 0xc0: Optional, Transitive, Complete
Type Code: COMMUNITIES (8)
Length: 4
Communities: NO_EXPORT
Community Well-known: NO_EXPORT (0xffffff01)
Network Layer Reachability Information (NLRI)
172.16.16.0/24
NLRI prefix length: 24
NLRI prefix: 172.16.16.0 (172.16.16.0)
172.16.17.0/24
NLRI prefix length: 24
NLRI prefix: 172.16.17.0 (172.16.17.0)
R2 receives all the advertised routes.
R2#show ip bgp
BGP table version is 7, local router ID is 150.1.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 172.16.16.0/24 10.1.12.1 0 0 100 i
*> 172.16.17.0/24 10.1.12.1 0 0 100 i
*> 192.168.10.0 10.1.12.1 0 0 100 i
*> 192.168.11.0 10.1.12.1 0 0 100 i
However, R2 does not advertise the NO_EXPORT routes to R3.
R2#show ip bgp 172.16.16.0 255.255.255.0
BGP routing table entry for 172.16.16.0/24, version 6
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)
Not advertised to any peer
100
10.1.12.1 from 10.1.12.1 (192.168.11.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: no-export
R2#show ip bgp neighbor 10.1.23.3 advertised-routes
BGP table version is 7, local router ID is 150.1.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 192.168.10.0 10.1.12.1 0 0 100 i
*> 192.168.11.0 10.1.12.1 0 0 100 i
Total number of prefixes 2
3.7.d(v) Multi-homing
Multihoming is connecting your network to two different ISPs. Multihoming provides redundancy by offering a backup route in case of a link failure and network optimization by selecting the ISP which offers the best path to a resource.
When running BGP with multiple ISPs, there is a risk that the local AS becomes a transit AS. Internet traffic could then pass through the AS and potentially consume all bandwidth and CPU resources. One method to guarantee that the local AS will not become a transit AS is to allow only locally generated routes to be advertised to both ISP - filtering the Internet routes going from one ISP to the other. This can be done with an outbound policy that permits only routes from the local AS.
Regular expressions use character definitions to match patterns. For example, ^ = start of string and $=end of string. Together with numbers, these characters can be used to match locally originated BGP routes or routes that were advertised through a particular AS (included in the AS_PATH). This is accomplished by ^$ (locally originated route; empty AS_PATH) and ^100$ (only AS 100 in the AS_PATH), respectively.
ip as-path access-list 10 permit ^$
!
route-map LOCAL-ONLY permit 10
match as-path 10
!
router bgp 300
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 route-map LOCAL-ONLY out
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 route-map LOCAL-ONLY out
Further, the configuration can be narrowed down to receive only directly connected routes from each ISP.
ip as-path access-list 20 permit ^100$
!
route-map AS-100-ONLY permit 10
match as-path 20
!
ip as-path access-list 30 permit ^200$
!
route-map AS-200-ONLY permit 10
match as-path 30
!
router bgp 300
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 route-map LOCAL-ONLY out
neighbor 1.1.1.1 route-map AS-100-ONLY in
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 route-map LOCAL-ONLY out
neighbor 2.2.2.2 route-map AS-200-ONLY in
In addition to the BGP configuration, a default route is required. There are three main methods to advertise the default route:
- Allowing the default route in the inbound policy.
- Using an IGP.
- Installing a static default route.
ip as-path access-list 20 permit ^100$
!
ip as-path access-list 30 permit ^200$
!
ip prefix-list DEFAULT-ROUTE seq 10 permit 0.0.0.0/0
!
route-map AS-100-ONLY permit 10
match as-path 20
route-map AS-100-ONLY permit 20
match ip address prefix-list DEFAULT-ROUTE
!
route-map AS-200-ONLY permit 10
match as-path 30
route-map AS-200-ONLY permit 20
match ip address prefix-list DEFAULT-ROUTE
!
router bgp 300
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 route-map LOCAL-ONLY out
neighbor 1.1.1.1 route-map AS-100-ONLY in
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 route-map LOCAL-ONLY out
neighbor 2.2.2.2 route-map AS-200-ONLY in
No comments:
Post a Comment