Blog Feed

• Update filtering works on peer basis.
  • ‘neighbor <address> distribute-list [standard/extended acl]
  • ‘neighbor <address> filter-list [as-path-acl]
  • ‘neighbor <address> prefix-list [prefix-list name]
  • ‘neighbor <address> route-map
    • Using route maps avoids order of operations issues.

• Regular Expressions
  • Used for the following:
    • Show command outputs
    • TCL/EEM scripting
    • BGP AS-Path access-lists
    • BGP Expanded Community lists
  • Info can be found in
    • IOS Terminal Services Configuration Guide
      • Appendixes
        • Regular expressions

Regex AS-Path access-list example

In the image below R1 and R4 are in ASN 200, R3 and R2 in ASN 100.

R4 and R1 have two originating routes being advertised into BGP, 4.4.4.0/24 and 1.1.1.0/24. The regular expression ‘^$’ can be used with BGP to show only routes that are originating from the local ASN. This can be used with an access-list/filter list with BGP to only advertise into BGP the locally originated, instead of passing on routes from external ASNs onto additional ASNs.

In IOS the command ‘show ip bgp regex ^$’ can be used to show only the locally originated routes being advertised.

To create an ACL to filter down in BGP, the following can be completed.

The use of ‘filter-list’ on the neighbor statement then will only advertise out locally originated prefixes through the Regex ‘^$’.

BGP Max Prefix

• BGP defaults to full view from all peers
• Generally all prefixes should not get pushed upstream.
• Can filter on number of prefixes
  • ‘neighbor maximum-prefix’
  • Result can be log or shutdown peer.

BGP Outbound Route Filtering

• Traditionally what providers will advertise out.
  • Full Table
  • Default Only
  • Default plus local (partial)
• Outbound Route Filtering
  • Customer signals upstream what type of routes they want.
  • Results in control in customers hands vs. providers.
  • ‘neighbor ip-address capability orf prefix-list [send, receive, both]’

The ORF process can be configured with a prefix-list and then adding capability and prefix-list to a BGP neighbor statement. On R8 below we’re receiving all BGP routes from ASN 200 and 100 from R5. If we wanted to filter down to receiving one subnet from R5, 1.1.1.0/24, we specify that in the prefix list.

Now on R8’s BGP table, the local ASN prefixes and 1.1.1.0/24 are the only subnets available.

Soft Reconfiguration Inbound:

• Saves unfiltered BGP routes received from peer in Adj-RIBs-In.
  • Adj-RIBs-In–>Loc-RIB–>Adj-RIBs-Out
  • Allows router to run ‘show ip bgp neighbor <neighor> received-routes
• Takes up more memory because it’s saving another copy of inbound routes.
• ‘neighbor <address> soft-reconfiguration inbound’
• Makes troubleshooting easier.

Before:

Route Refresh Capability:

• Negotiated capability with OPEN message
• Can ask peer to send an update without having to hard clear session.
  • ‘clear bgp ipv4 unicast <neighbor> soft in’
  • ‘clear bgp ipv4 unicast <neighbor> in’
  • ‘clear bgp ipv4 unicast * in’
• Does not consume memory like Soft Reconfiguration Inbound

Communities:

• BGP’s way of using route tags.
• Used to group prefixes together.
  • Advertisement Policy
  • Filtering policy
  • Best Path Selection policy
• Optional Transitive
  • Not exchanged by default.
  • Needs the additional neighbor command ‘send-community’
• Standard
  • 4 byte value.
  • Can be decimal or AA:NN
    • AA:NN is enabled with:
      • ‘ip bgp new-format’
      • ‘ip bgp-community new-format‘

Well-Known:

• No-Export
  • Does not advertise to EBGP peers.
• No-Advertise
  • Does not advertise to ANY peer.
• Local-AS
  • Does not advertise to Confederation EBGP Peers
    • Sub domains.

Configuration:

• Setup in route-maps.
• ‘set community {community-number [additive] [well-known-community] | none’
  • Not additive, needs additive keyword.
• Can delete community by setting as ‘none’
• Matching communities
  • List Creation
    • Standard list matches community name or number.
      • ‘ip community-list 1 standard permit no-export’
    • Expanded matches regular expression
      • ‘ip community-list expanded AS100 permit 100:[0-9]+‘
    • Reference from route-map
      • ‘match community AS100’

Extended Communities:

• Used for specific applications like MPLS L3/L2VPN, EIGRP Cost.

BGP Cost Community:

• Custom decision process.
• Only advertised within AS or confederations.
• Influences BGP path selection
  • Compares before even Weight.
• EIGRP PE/CE
  • Uses pre-bestpath cost community to encode composite metric into BGP.
• GSHUT Community
  • Used in conjunction with Graceful Restart
  • Takes restarting peer out of data-path by modifying local preference.
    • Similar to OSPF Max Metric LSA.

• Auto summarizes prefixes.
  • Requires subnet of network to be present.
  • No mask required on network/igp statement
  • Classful
• Disabled by Default.

• Summarization can occur anywhere, unlike OSPF and IS-IS (link state)
• Config
  • Under router bgp ASN process, ‘aggregate-address <network><mask>’
• config arguments
  • summary-only
    • suppress more specific routes
  • suppress-map
    • suppress subset of more specific routes
  • as-set
    • list of AS numbers and communities associated with the aggregate; inherited from more specific routes.
  • advertise-map
    • attributes of prefixes matched with advertised map are inherited in aggregate address
    • Used in conjunction with as-set
      • Prevents a specific AS from being included in AS_SET of the new aggregate.
      • Circumvents loop prevention
  • attribute-map | route-map
    • Used to modify attributes with aggregate address.
    • Used with as-set
      • Can set or remote attributes
      • E.g. remove “no-export” community, add MED.

Topology:

R8, R10 = ASN 810.1
R5, R2 and R3 = ASN 100
R1 and R4 = ASN 200

R10 is advertising subnets 172.16.10.0/24, 172.16.20.0/24, and 172.16.30.0/24 into BGP, which is seen in the route table of both ASN 200 routers.

summary-only config:
To summarize the subnets from R10 into ASN 200, we’ll have to add two commands to R2 and R3, which are the routers providing paths to ASN 200 for these IP ranges.

Now in the routing table on R1, we will only see the summary, and nothing else.

• RFC 1998
• Pre-stages inbound policy to
  • match on communities
  • set local pref
  • set other attributes
• Results in outbound path selection.

The below routers are running in the following ASNs:

R1, R4 = ASN 200
R3, R2 = ASN 100

R4 is advertising its Loopback subnet of 4.4.4.0/24 into BGP. We’re going to change the Local Pref of the route 4.4.4.0 on R2 by using a community.

Configuration:

On R2 the configuration needs to first have communities setup:

These communities then need to be referenced in a Route Map, this one called ‘BGP_IN’.

This then needs to be applied to a neighbor statement. In this case with R1.

Next, we’ll add a prefix-list for R4’s loopback subnet.

Then a route-map called ‘BGP_OUT’.

This route-map will reference the Loopback subnet on R4 and set the community string to 100:110, which makes sense to R2.

Then the route-map will get applied to the neighbor statement towards R2.

Now on R2 we’re seeing that the local preference has changed in accordance with the route-map that sets values on communities.

Continuing work on below image:

Autonomous Systems:
R1, R4 – ASN 200
R3, R2, R5 – ASN 100
R8, R10 – ASN 810.1

The next traffic engineering methods used will be MED and AS-Path. These are both methods to influence traffic coming inbound towards the Autonomous System. In the example below, R4 reaching R5 will have two paths via R2 and R3. The two paths can be seen to R5’s loopback with a ‘show ip bgp 5.5.5.5’. They’re both valid routes with equal attributes, but R2 is preferred probably because of a tie breaker that the neighbor has been there longest.

Currently both paths have the same AS length to reach R5, but to modify and prefer traffic to R5 through R3, we can set AS Prepend on R2.

Configuration:

On R2 a prefix list, route-map and set to out will need to be applied. The prefix-list will match the loopback subnet of 5.5.5.0/24

The Route-map will match ip address to this prefix list.

And the route-map will then be applied outbound towards the neighbor we want to have a longer AS Path, router R1.

So again, R1 has two paths to subnet 5.5.5.0/24, one through R2 and one through R3. Adding AS-Prepend to the neighbor statement, we’re essentially saying the AS Path is now 4 Autonomous systems away instead of 1. This can be seen within a ‘show ip bgp’.

If we remove the AS-Prepend route-map we’ll see things go back to normal. The BGP table for R1 will have two even attributable routes to 2.2.2.2, but will only prefer one.

To modify inbound traffic with MED, we’ll need to go through a similar process. We’ll create a prefix list, route-map and assign to neighbor statements on both R2 and R3 toward R1. On R2 we’ll set the MED (metric) to 100, and R3 will be set to 150. Configs below, R2:

Config below, on R3:

After this config is applied and the BGP clear ‘out’ has occurred, the route metrics will show differently in R1.

The route going through the next hop 10.40.1.1 is now the most preferred because Metric now shows 100, while 10.20.1.1 shows Metric of 150.

Note:

• Both sides advertising a MED value should have something set. By default BGP without any value will be best.
  • bgp bestpath med missing-as-worst can override the default behavior.

In the image below there are 7 routers all running BGP.

The routers are running the following ASNs:

• R1 and R4 – ASN 200
• R2, R3, R5 – ASN 100
• R8 and R10 – ASN 810.1.

R10 is advertising three Loopback networks into BGP and we’re seeing how BGP will by default choose R1’s path to R10. On R1 there are two different paths to R10s loopback IP 172.16.10.0/24.

In the bottom right the router shows the path through R2 (2.2.2.2) is the ‘best’ – ie. best path. This can be seen in the routing table:

Going down the list for path selection, the weight is set to 0 on both and the local preference are both default 100.

AS Path length and origin can be seen in the image above as well – 100, 810.1, both the same.

The routes are so evenly matched that BGP will go down to the tie breakers, ie.

• EBGP over iBGP
• IGP Metric to Next Hop
• Oldest
• Lowest RID
• Shortest cluster list
• Lowest Neighbor address

In this case BGP is selecting the neighbor going through R2 because it’s been exchanging routes for longer than R3.

To influence traffic outbound in BGP, we’ll need to send an advertisement inbound to R1. This will be accomplished typically with weight or local pref.

Configuration:

To modify by weight (Cisco proprietary) the first part of configuration will be a prefix-list and route map that can be applied inbound.

Next, the route-map needs to get applied inbound associated with the neighbor we want as more preferred – ie. R3 at 10.20.1.1.

The ‘clear ip bgp *’ refreshes inbound advertisements to the router. After the refresh, now we can see the route preference has changed to R3.

Weight can be seen as 12345.

Next is a Local Preference example. In the image below we have the same ASN list, but now we’re looking at R4 and R2. R4 is advertising it’s loopback subnet 4.4.4.0/24 over into ASN 100, and we want to change how traffic from R2 chooses it’s path to R4.

R2 currently has two routes to reach 4.4.4.4/24, one through it’s iBGP neighbor at R3, and one through R1 via EBGP.

R2 will install this route into it’s routing table via its eBGP neighbor because the administrative distance is shorter and EBGP will be preferred over iBGP. To modify the local preference inbound to prefer R3, we’ll need to create a prefix list, then route-map, saying change the local preference via R3. Local preference is AS specific/spread, not just locally significant.

Prefix-List:

Route-Map:

R3 is receiving this route from R1, so the route-map needs to be applied under that neighbor inbound via router bgp <asn>. R3 and R1 are connected over the transit 10.20.1.0/30.

Now in R2 we can see that the best path is through R3 because the local pref is higher. This same local pref can be seen within the Autonomous System.

Once the advertisement leaves the local AS, Local pref is set back to the default 100.

• Best Path Selection:
  • Default chooses single best path.
  • Best path installed in RIB/FIB
  • Advertised to other BGP peers.
  • Decision process
    • RFC 4271
• Prerequisites:
  • Next hop must be in routing table
    • prevents route recursion failure.
  • Synchronization rule must be met or disabled.
  • AS-Path must not contain local-AS
    • Standard EBGP Loop prevention
    • Can be disabled with ‘allow-as in’
  • First ASN in path must be neighbor’s ASN
    • ‘bgp enforce-first-as’ command.

• Path Selection Order
  • Weight
    • Cisco proprietary
    • Locally significant
    • Higher value is preferred
  • Local Preference
    • Higher value is preferred
    • Not advertised to EBGP peers.
    • Carried through confederation EBGP.
  • Locally Originated
    • Locally originated gets weight of 32768
  • AS-Path
    • Smaller length is preferred
  • Origin
    • IGP over EBGP over Incomplete
      • IGP origination is from network statement.
      • Incomplete is from redistribution.
        • Network statement preferred over redistribution.
  • MED
    • Smaller value preferred.
    • Only compared for peerings to same provider by default.
      • Typically only used for comparing the same route from the same provider over multiple links.

Tie Breakers:

• EBGP over iBGP
  • If learned from EBGP, it’s not your prefix.
  • EBGP always preferred.
• IGP Metric to Next-Hop
  • Can use multi-path if all equal after this step.
  • Hidden command to allow multipath if AS_Path is not the same (has to be same length)
    • ‘bgp bestpath as-path multipath-relax’

• Additional Tie Breakers:
  • Oldest
  • Lowest RID
  • Shortest cluster list
  • Lowest Neighbor Address
• Exceptions:
  • ‘bgp bestpath as-path ignore’
  • ‘bgp always-compare-med’
    • Compares MED for routes locally originated in Confederation.
  • ‘bgp bestpath med missing-as-worst’
    • Assign 4,294,967,294 to NULL MED
  • ‘bgp deterministic med’
    • Compare MED against all possible paths.
  • IGP Metric
    • ‘bgp bestpath igp-metric ignore’
      • IOS-XE 3.4S
  • Router-ID
    • ‘no bgp bestpath compare-router-id’

Manipulating Best Path Selection

• Outbound routing policy affects inbound traffic
• Inbound routing policy affects outbound traffic
• Longest match routing is above all
  • Affects both directions.

• Attributes for influencing outbound path selection:
  • Weight and Local Pref
    • Set inbound
    • Affects outbound traffic

• Attributes for influencing inbound path selection:
  • AS-Path and MED
    • Set outbound
    • Affects inbound traffic

• Multipath Load Balancing
  • MP load balancing for external links with unequal bandwidth
    • Enabled for IPv4, IPv6, VPNv4, VRF AF
    • For iBGP, eBGP, eiBGP
  • Still only one best path advertised to peers.

• Originates subnets from aggregate for purpose of traffic engineering.
  • Longest prefix.

Configuration:

• Inject Map
  • More specific subnet to advertise.
  • ‘set ip address prefix-list <list>‘
• Exist Map
  • Aggregate to be originated from.
  • ‘match ip address prefix-list <list>
  • ‘match ip route-source prefix-list <list>

In the image below R2, R3 and R5 are all in ASN 100, R8 and R10 in ASN 810.1. R5 R8 and R10 are running EBGP between the two ASNs.

R5 is going to summarize ASN 100 transit links 10.30.2.0 and 10.30.3.0 into ASN 810.1.

Both R8 and R10 are now showing 10.30.0.0/16 for the transit links within ASN 100. To advertise a more specific route that falls within the summary address, a conditional route injection needs to be performed. This is a valid method of traffic engineering. Currently if R10 is trying to reach the subnet 10.30.2.0/30, it will go over the EBGP path directly to R5. This is because AD for EBGP is much lower than AD of iBGP. Injecting a more specific route into BGP originating from R8 would steer traffic from R10 to R8 first because longest prefix is always going to be more preferred.

Configuration:

• Create Prefix Lists for Aggregate/Summary, Route neighbor/source, and more specific route.

Prefix-list AGGREGATE is the summarized route from R5.

Prefix-list ROUTE-SOURCE is the neighbor advertising the route inbound to ASN 810.1.

Prefix-list Transit_2 is the more specific prefix we want to advertise into BGP/down to R10.

• Create Route-Maps for ‘INJECT MAP’ and ‘EXIST MAP’.

‘INJECT_MAP’ defines the more specific route, ‘Transit_2’, to be sent into BGP domain.

‘EXIST_MAP’ specifies what’s there, ie. existing Aggregate (10.30.0.0/16) and the neighbor advertising the Aggregate via EBGP.

• BGP ASN statement

‘bgp inject-map INJECT_MAP exist-map EXIST_MAP’ defines in the global BGP process everything that’s just been discussed. Clearing BGP neighbors might be necessary in lab. The change takes a while to work.

• Network Layer Reachability Information.
  • In CCIE context, the routes passed between hosts via BGP.
• Uses UPDATE and WITHDRAW messages to exchange NLRI.

• BGP NLRI Origination.
  • ‘network’ statement.
    • Requires exact match in routing table.
  • ‘redistribute statement.
    • Won’t include OSPF External by default.
  • ‘aggregate-address’ statement.
    • Requires one subnet in BGP table.
  • ‘bgp inject-map’
    • Opposite of aggregation command.

Network Statement:

• Originates prefixes with ORIGIN of IGP (i)
• Requires exact match in RIB.
  • Does not need to be connected, can be learned via IGP.
• Assumes classful if mask keyword not used.
• Sets weight to 32768.

BGP Redistribute Statement:

• Originates prefixes with ‘ORIGIN INCOMPLETE (?).
• Originates classful summary if auto-summary enabled.
• Auto copies IGP metric to BGP MED.
• Won’t include OSPF External by default.
  • ‘redistribute ospf <process> match internal external’
    • Required to redistribute OSPF external.
• Sets weight to 32768.
• ‘bgp redistribute internal’
  • By default only external BGP routes are redistributed into IGP with redistribution.
  • Command allows for internal BgP routes to be redistributed into IGP.
  • Can result in routing loop.

BGP Conditional Advertisement:

• ‘neighbor advertise-map map 1 <non-exist or exist>’
• Advertise prefix matched in advertise-map
  • If prefix matched in non-exist map does not exist.

• Inject map
  • Subnet to be advertised.
  • set ip address prefix-list <list>
• Exist map
  • Aggregate to be originated from
  • match ip address prefix-list <list>
  • match ip route-source prefix-list <list>

The image below shows six routers all running BGP. R1, R2, R3 and R5 are all in ASN 100, while R8 and R10 are in ASN 810.1. R5 and R8 are EBGP peers.

Transit /30 subnets are setup for each link in ASN 100, 10.30.1.0, 10.30.2.0, and 10.30.3.0. These transits are being advertised in the local IGP and in BGP to ASN 810.1. This can be seen in R8’s routing table.

If we wanted to summarize these three subnets into one advertisement, the ‘aggregate-address’ command can be used under the BGP process on R5.

This results in one route showing under R8’s route table.

Similar to EIGRP, summarization in BGP can be performed nearly anywhere. The portion of the command ‘summary-only’ says that the summary will be the only route advertised, no more specific prefixes.

• Network Layer Reachability Information
  • Network Statement
    • MUST BE EXACT MATCH!
  • Redistribute Statement
    • Won’t include OSPF E1/2 by default.
  • Aggregate Address Statement
    • Requires one subnet in BGP Table first.
    • BGP inject-map
      • opposite of aggregation.

BGP Network Statement:

• Originates prefixes with ORIGIN of IGP (i)
• Requires exact match in the routing table
  • can be learned via IGP.
• No mask keyword assumes classful.
• Sets weight to 32768

BGP Redistribute Statement:

• Originates prefixes with ORIGIN INCOMPLETE (?)
• Originates classful summary if auto-summary is enabled.
• Auto copies IGP metric to BGP MED.
• Won’t include OSPF External by default.
  • redistribute ospf <id> match internal external
• Sets weight to 32768.

BGP Redistribute Internal:

• By default, only external BGP routes are redistributed into IGP with redistribution.
• ‘bgp redistribute internal’ lets internal BGP routes to be redistributed into IGP.
• Can result in a routing loop if not careful.

BGP Conditional Advertisement:

• Advertises prefix matched in advertise-map.
  • If prefix matched in non-exist map does not exist
  • If prefix matched in exist-map does exist.
• Typically used to track failure of a transit link.
  • Advertise to backup provider, only if primary provider is down.

BGP Conditional Route Injection:

• Originates subnets from aggregate for purpose of longest match traffic engineering.
• ‘bgp inject-map inject-map exist-map exist-map <copy attributes>
  • Inject map
    • subnet to be advertised
    • set ip address prefix-list<list>
  • Exist Map
    • Aggregate to be originated from
    • Match ip address prefix-list <list>
    • match ip route-source prefix-list <list>