A quick copy-and-paste summary on BGP attribute categorization.
WELL-KNOWN, MANDATORY
AS-path: A list of the Autonomous Systems (AS) numbers that a route passes through to reach the destination. As the update passes through an AS the AS number is inserted at the beginning of the list. The AS-path attribute has a reverse-order list of AS passed through to get to the destination.
Next-hop: The next-hop address that is used to reach the destination.
Origin: Indicates how BGP learned a particular route. There are three possible types -- IGP (route is internal to the AS), EGP (learned via EBGP), or Incomplete (origin unknown or learned in a different way).
WELL-KNOWN, DISCRETIONARY
Local Preference: Defines the preferred exit point from the local AS for a specific route.
Atomic Aggregate: Set if a router advertises an aggregate causes path attribute information to be lost.
OPTIONAL, TRANSITIVE
Aggregator: Specifies the router ID and AS of the router that originated an aggregate prefix. Used in conjunction with the atomic aggregate attribute.
Community: Used to group routes that share common properties so that policies can be applied at the group level.
OPTIONAL, NON-TRANSITIVE
Multi-exit-discriminator (MED): Indicates the preferred path into an AS to external neighbors when multiple paths exist.
A list of path attributes is contained in BGP update messages. The attribute is variable length and consists of three fields: Attribute type consisting of a 1-byte attribute flags field and a 1-byte attribute code field, Attribute length field that is 1 or 2 bytes, and a variable length attribute value field. The attribute type codes used by Cisco are: 1-origin, 2-AS-path, 3-Next-hop, 4-MED, 5-Local preference, 6-Atomic aggregate, 7-aggregator, 8-community, 9-originator-ID, and 10-cluster list.
Showing posts with label BGP. Show all posts
Showing posts with label BGP. Show all posts
BGP MED
BGP MED is an optional non-transitive attribute meaning its not propagated throughout the whole internet but just to adjacent AS. The word "optional" means that this is not necessarily by default sent with the BGP updates. The purpose of MED is to influence how other autonomous systems enter your AS to reach a certain prefix. If the other attributes are set to default, MED will be the attribute used for path selection however, if Weight or Local preference is configured on the adjacent AS router, then MED will not be selected. The lower the MED the more preferred the path will be.
To start lets configure 2 route maps and set the MED as required.
Access-list matches all routes. Now, lets apply the route map to the neighbors.
Its in the "out" direction because R4 is the one advertising the routes. Let's check what R2 and R3 see in their BGP table.
Ok, its clear that the Metric now is changed to 20 and 30 for R2 and R3 respectively. Let's see how R1 sees the routes.
R1 sees two paths, but notice that the paths with ">" are with those with lower MED. Therefore it is going to take those paths. Now, lets configure R4 so that the path R1 will take to 144.144.144.144/32 in R4 will be through R3 then clear the BGP session after.
Now, lets see the outputs.
We can see a change in R3 that shows a MED of 10 for 144.144.144.144/32, while R1 shows the same and will now take R3 to reach the subnet.
Acronym for Multi Exit Discriminator and otherwise known as "Metric" in the BGP table.
The lower the MED the more preferred.
It is an optional non-transitive attribute.
Can dictate how other AS enter your AS.
Configure R4 so that it will advertise a MED value of 30 to R3 and 20 to R2. Afterwards,
tweak the route map to set a MED of 10 for network 144.144.144.144/32 in R4 towards R3. The end
result should have traffic from AS123 to 4.4.4.4/32 and 44.44.44.44/32 take R2 but traffic for
144.144.144.144/32 should take R3. At the start BGP has been established on all routers.
To start lets configure 2 route maps and set the MED as required.
R4(config)#access-list 20 permit any
R4(config)#access-list 30 permit any
R4(config)#route-map R2SETMED20 permit 10
R4(config-route-map)#match ip address 20
R4(config-route-map)#set metric 20
R4(config-route-map)#route-map R3SETMED30 permit 10
R4(config-route-map)#match ip address 30
R4(config-route-map)#set metric 30
Access-list matches all routes. Now, lets apply the route map to the neighbors.
R4(config-router)#neighbor 24.24.24.2 route-map R2SETMED20 out
R4(config-router)#neighbor 34.34.34.3 route-map R3SETMED30 out
Its in the "out" direction because R4 is the one advertising the routes. Let's check what R2 and R3 see in their BGP table.
R2#sh ip bgp
BGP table version is 31, local router ID is 24.24.24.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
*> 4.4.4.4/32 24.24.24.4 20 0 4 i
*> 44.44.44.44/32 24.24.24.4 20 0 4 i
*> 144.144.144.144/32
24.24.24.4 20 0 4 i
R3#sh ip bgp
BGP table version is 10, local router ID is 34.34.34.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
*> 4.4.4.4/32 34.34.34.4 30 0 4 i
*> 44.44.44.44/32 34.34.34.4 30 0 4 i
*> 144.144.144.144/32
34.34.34.4 30 0 4 i
Ok, its clear that the Metric now is changed to 20 and 30 for R2 and R3 respectively. Let's see how R1 sees the routes.
R1#sh ip bgp
BGP table version is 34, local router ID is 13.13.13.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
*>i4.4.4.4/32 24.24.24.4 20 100 0 4 i
* i 34.34.34.4 30 100 0 4 i
*>i44.44.44.44/32 24.24.24.4 20 100 0 4 i
* i 34.34.34.4 30 100 0 4 i
*>i144.144.144.144/32
24.24.24.4 20 100 0 4 i
* i 34.34.34.4 30 100 0 4 i
R1 sees two paths, but notice that the paths with ">" are with those with lower MED. Therefore it is going to take those paths. Now, lets configure R4 so that the path R1 will take to 144.144.144.144/32 in R4 will be through R3 then clear the BGP session after.
R4(config)#access-list 33 permit 144.144.144.144 0.0.0.0
R4(config)#route-map R3SETMED30 permit 10
R4(config-route-map)#match ip address 33
R4(config-route-map)#set metric 10
R4(config-route-map)#route-map R3SETMED30 permit 20
R4(config-route-map)#match ip address 30
R4(config-route-map)#set metric 30
R4#clear ip bgp *
Now, lets see the outputs.
R2#sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
*> 4.4.4.4/32 24.24.24.4 20 0 4 i
*> 44.44.44.44/32 24.24.24.4 20 0 4 i
*> 144.144.144.144/32
24.24.24.4 20 0 4 i
R3#sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
*> 4.4.4.4/32 34.34.34.4 30 0 4 i
*> 44.44.44.44/32 34.34.34.4 30 0 4 i
*> 144.144.144.144/32
34.34.34.4 10 0 4 i
R1#sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
* i4.4.4.4/32 34.34.34.4 30 100 0 4 i
*>i 24.24.24.4 20 100 0 4 i
* i44.44.44.44/32 34.34.34.4 30 100 0 4 i
*>i 24.24.24.4 20 100 0 4 i
*>i144.144.144.144/32
34.34.34.4 10 100 0 4 i
* i 24.24.24.4 20 100 0 4 i
We can see a change in R3 that shows a MED of 10 for 144.144.144.144/32, while R1 shows the same and will now take R3 to reach the subnet.
BGP Local Preference
Local Preference is one of the ways to alter the path taken by one AS to reach another AS. The difference between Local Preference and Weight is that Weight is just locally signifant in the router while Local Preference is what I call "Local AS significant". What I mean by that is that Local Preference is being propagated Intra AS but not outside the AS.
In this lab, local preference will be configured and will be using route map for more flexibility. Check the diagram below for details.
Here are the initial BGP configurations on the routers.
Let's see what is the best path taken by R1 to reach the networks advertised by R4.
It's clear that it prefers to take R2 to reach the networks in R4. Let's configure R3 so that all routes received by R3 will have a Local preference of 300
Immediately, even without clearing the BGP process, R3 now became the more preferred path to reach R4. Remember that in Local Preference, the higher the value, the more preferred.
Let's configure in R2 a route-map so the network 144.144.144.144/32 will have a local preference of 500. This will make R2 the best path to reach the mentioned network.
Firstly, why is that the route-map has an "in" direction. It's because we are receiving the route from another router, R2 is not the one advertising. You can see now that path to 144.144.144.144/32 will have R2 as the next hop. If you noticed also, why is that for 4.4.4.4/32 and 44.44.44.44/32, there is no other path except through 13.13.13.3. Check the route-map above and you'll find the answer. There is no succedding line after line 10, which means, it will block out the subnets and not advertised it to R1.
Let's configure the 20th sequence of the route-map.
Let's see now if there are changes.
That's it for local preference. Hopefully I can finish the BGP topics soon. :)
Local preference is to influence your own AS how to get or exit to another AS.
MED is to influence other AS how to enter your AS.
The higher the local preference, the more preferred.
In this lab, local preference will be configured and will be using route map for more flexibility. Check the diagram below for details.
R1, R2 and R3 belongs to AS 123. R4 is in AS4 and is advertising 4.4.4.4/32, 44.44.44.44/32 and 144.144.144.144/32
subnets.We need to set all routes learned from R3 to have local preference value of 300. After which, configure a
route-map that will assign a local preference of 500 in R2 for the network 144.144.144.144/32.
Here are the initial BGP configurations on the routers.
R1#
!
router bgp 123
no synchronization
bgp log-neighbor-changes
neighbor 12.12.12.2 remote-as 123
neighbor 13.13.13.3 remote-as 123
no auto-summary
R2#
!
router bgp 123
no synchronization
bgp log-neighbor-changes
neighbor 12.12.12.1 remote-as 123
neighbor 12.12.12.1 next-hop-self
neighbor 24.24.24.4 remote-as 4
no auto-summary
R3#
!
router bgp 123
no synchronization
bgp log-neighbor-changes
neighbor 13.13.13.1 remote-as 123
neighbor 13.13.13.1 next-hop-self
neighbor 34.34.34.4 remote-as 4
no auto-summary
R4#
!
router bgp 4
no synchronization
bgp log-neighbor-changes
network 4.4.4.4 mask 255.255.255.255
network 44.44.44.44 mask 255.255.255.255
network 144.144.144.144 mask 255.255.255.255
neighbor 24.24.24.2 remote-as 123
neighbor 34.34.34.3 remote-as 123
no auto-summary
Let's see what is the best path taken by R1 to reach the networks advertised by R4.
R1#sh ip bgp
BGP table version is 10, local router ID is 1.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
*>i4.4.4.4/32 12.12.12.2 0 100 0 4 i
* i 13.13.13.3 0 100 0 4 i
*>i44.44.44.44/32 12.12.12.2 0 100 0 4 i
* i 13.13.13.3 0 100 0 4 i
*>i144.144.144.144/32
12.12.12.2 0 100 0 4 i
* i 13.13.13.3 0 100 0 4 i
R1#sh ip route | beg Gateway
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
4.0.0.0/32 is subnetted, 1 subnets
B 4.4.4.4 [200/0] via 12.12.12.2, 00:04:00
144.144.0.0/32 is subnetted, 1 subnets
B 144.144.144.144 [200/0] via 12.12.12.2, 00:04:00
12.0.0.0/24 is subnetted, 1 subnets
C 12.12.12.0 is directly connected, Serial1/2
13.0.0.0/24 is subnetted, 1 subnets
C 13.13.13.0 is directly connected, Serial1/3
44.0.0.0/32 is subnetted, 1 subnets
B 44.44.44.44 [200/0] via 12.12.12.2, 00:04:00
It's clear that it prefers to take R2 to reach the networks in R4. Let's configure R3 so that all routes received by R3 will have a Local preference of 300
R3#config t
R3(config)#router bgp 123
R3(config-router)#bgp default local-preference 300
R1#sh ip bgp
BGP table version is 13, local router ID is 1.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
* i4.4.4.4/32 12.12.12.2 0 100 0 4 i
*>i 13.13.13.3 0 300 0 4 i
* i44.44.44.44/32 12.12.12.2 0 100 0 4 i
*>i 13.13.13.3 0 300 0 4 i
* i144.144.144.144/32
12.12.12.2 0 100 0 4 i
*>i 13.13.13.3 0 300 0 4 i
Immediately, even without clearing the BGP process, R3 now became the more preferred path to reach R4. Remember that in Local Preference, the higher the value, the more preferred.
Let's configure in R2 a route-map so the network 144.144.144.144/32 will have a local preference of 500. This will make R2 the best path to reach the mentioned network.
R2(config)#access-list 1 permit host 144.144.144.144
R2(config)#route-map LOCALPREF500 permit 10
R2(config-route-map)#match ip address 1
R2(config-route-map)#set local-preference 500
R2#(config)# router bgp 123
R2(config-router)#neighbor 24.24.24.4 route-map LOCALPREF500 in
R2# clear ip bgp *
R1#sh ip bgp
BGP table version is 14, local router ID is 1.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
*>i4.4.4.4/32 13.13.13.3 0 300 0 4 i
*>i44.44.44.44/32 13.13.13.3 0 300 0 4 i
*>i144.144.144.144/32
12.12.12.2 0 500 0 4 i
* i 13.13.13.3 0 300 0 4 i
Firstly, why is that the route-map has an "in" direction. It's because we are receiving the route from another router, R2 is not the one advertising. You can see now that path to 144.144.144.144/32 will have R2 as the next hop. If you noticed also, why is that for 4.4.4.4/32 and 44.44.44.44/32, there is no other path except through 13.13.13.3. Check the route-map above and you'll find the answer. There is no succedding line after line 10, which means, it will block out the subnets and not advertised it to R1.
Let's configure the 20th sequence of the route-map.
R2(config)#route-map LOCALPREF500 permit 20
Let's see now if there are changes.
R1#sh ip bgp
BGP table version is 16, local router ID is 1.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
* i4.4.4.4/32 12.12.12.2 0 100 0 4 i
*>i 13.13.13.3 0 300 0 4 i
* i44.44.44.44/32 12.12.12.2 0 100 0 4 i
*>i 13.13.13.3 0 300 0 4 i
*>i144.144.144.144/32
12.12.12.2 0 500 0 4 i
* i 13.13.13.3 0 300 0 4 i
That's it for local preference. Hopefully I can finish the BGP topics soon. :)
BGP Weight Attribute
The BGP Weight attribute is a Cisco Proprietary attribute that influences a router how to reach a certain prefix. The difference between Local Preference and Weight is that the former is propagated within an AS and the latter is router locally significant. Weight can be used if there is one router connected to two or more AS's or just to just one with two or more eBGP peers. Now, lets configure weight and later use a route-map for more complex use of weight.
Lets see how R1 reaches the prefixes announced by R4.
Ok, it takes AS3 to reach the prefixes. Now, lets configure Weight to make AS2 the more preferred path to reach the prefixes.
Now let's see if that changes after clearing the BGP session "softly".
It's now taking AS 2. Let's configure a route-map so R1 will take AS3 to reach 144.144.144.144/32. The weight should be 200. We will apply the route-map towards neighbor 13.13.13.3.
The ACL is to filter which routes be given a weight of 200. The reason the route-map was configured inbound direction because we are receiving the routes from that neighbor. Let's see what happens to the BGP table.
Now, R1 will take AS3 to reach 144.144.144.144/32. Notice that the weight now is 200, and its more prefered.
Weight is a Cisco Proprietary attribute for BGP that is "locally significant."
Local Preference is a Well-known Discretionary attribute, Weight doesn't belong to any category.
Default Weight for locally originated routes is 32768.Zero is the default for other routes.
Weight is not propagated to other routers within the AS.
All routers have BGP established and within its own AS.R4 is announcing 4 prefixes and the condition is
for R1 to reach routes 4.4.4.4/32, 44.44.4.44/32 and 144.144.144.144/32, it must take AS2. Then later
configure a route-map to so that R1 with take AS 3 to reach 144.144.144.144/32.
Lets see how R1 reaches the prefixes announced by R4.
R1#sh ip bgp
BGP table version is 12, local router ID is 13.13.13.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
* 4.4.4.4/32 12.12.12.2 0 2 4 i
*> 13.13.13.3 0 3 4 i
* 44.44.44.44/32 12.12.12.2 0 2 4 i
*> 13.13.13.3 0 3 4 i
* 144.144.144.144/32
12.12.12.2 0 2 4 i
*> 13.13.13.3 0 3 4 i
Ok, it takes AS3 to reach the prefixes. Now, lets configure Weight to make AS2 the more preferred path to reach the prefixes.
R1(config)#router bgp 1
R1(config-router)#neighbor 12.12.12.2 weight 100
R1(config-router)#do clear ip bgp * soft
Now let's see if that changes after clearing the BGP session "softly".
R1#sh ip bgp
BGP table version is 15, local router ID is 13.13.13.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
*> 4.4.4.4/32 12.12.12.2 100 2 4 i
* 13.13.13.3 0 3 4 i
*> 44.44.44.44/32 12.12.12.2 100 2 4 i
* 13.13.13.3 0 3 4 i
*> 144.144.144.144/32
12.12.12.2 100 2 4 i
* 13.13.13.3 0 3 4 i
It's now taking AS 2. Let's configure a route-map so R1 will take AS3 to reach 144.144.144.144/32. The weight should be 200. We will apply the route-map towards neighbor 13.13.13.3.
R1(config)#access-list 1 permit host 144.144.144.144
R1(config)#route-map TAKE_AS3 permit 10
R1(config-route-map)#match address 1
R1(config-route-map)#set weight 200
R1(config-router)#neighbor 13.13.13.3 route-map TAKE_AS3 in
R1(config-router)# do clear ip bgp * soft
The ACL is to filter which routes be given a weight of 200. The reason the route-map was configured inbound direction because we are receiving the routes from that neighbor. Let's see what happens to the BGP table.
R1#sh ip bgp
BGP table version is 16, local router ID is 13.13.13.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
*> 4.4.4.4/32 12.12.12.2 100 2 4 i
*> 44.44.44.44/32 12.12.12.2 100 2 4 i
* 144.144.144.144/32
12.12.12.2 100 2 4 i
*> 13.13.13.3 200 3 4 i
Now, R1 will take AS3 to reach 144.144.144.144/32. Notice that the weight now is 200, and its more prefered.
EBGP Multihop
Configuring iBGP doesn't require the neighbor address to be directly connected. The best practice for iBGP is to use the loopback address as the ip address configured on the BGP neighbor statement. Loopback interfaces never go down so provided that there is an alternate route to the loopback ip address through an IGP, BGP session will not be torn down.
Using loopback addresses for eBGP is also a good practice if there are multiple links between two routers on different autonomous system as shown on the example diagram below. This will also achieve load balancing.
The initial configuration for this lab is shown below.
Notice that in both routers we put 2 static routes to achieve load balancing. Currently the BGP session is not established eventhough both loopbacks are reachable. Now, lets configure "ebgp-multihop" on both routers and see if this will make the BGP session establish.
Now let's configure the routers.
The BGP session is not established even though we configured the "ebgp-multihop" command. Before we find out why, lets first discuss the "ebgp-multihop" command. The default value of this command if we don't put anything will be 255. We put a value of 2 because it will take 2 hops to reach 2.2.2.2 from 1.1.1.1 as they are not directly connected. Provided all the requirements are met except the hop count value, if the hop count value is lesser than what it should be, the eBGP neighborship will not be established.
Going back to why its not established, its because by default for BGP to establish the TCP session it will use the outgoing interface ip address as the source. The other router will reject the incoming TCP SYN packets because it doesn't recognize the source IP address as a configured neighbor. In our case, it will source the TCP session using the two physical interfaces ip addresses.
Now lets configure, the update-source command sourcing all BGP negiotiations and updates from Loopback0 which are the ip addresses configured on our neighbor statements.
BGP session now established. We can see in CEF that this is load balanced.
Now, BGP session is established. Let's try shutting down one link and see if the session is still established.
BGP session still established. Thats all about EBGP Multihop feature.:)
Using loopback addresses for eBGP is also a good practice if there are multiple links between two routers on different autonomous system as shown on the example diagram below. This will also achieve load balancing.
The initial configuration for this lab is shown below.
R1#
!
interface Serial1/0
ip address 10.10.10.1 255.255.255.0
serial restart-delay 0
end
!
interface Serial1/1
ip address 10.10.20.1 255.255.255.0
serial restart-delay 0
end
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
router bgp 1
no synchronization
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 2
no auto-summary
!
ip route 2.2.2.2 255.255.255.255 10.10.10.2
ip route 2.2.2.2 255.255.255.255 10.10.20.2
R2#
!
interface Serial1/0
ip address 10.10.10.2 255.255.255.0
serial restart-delay 0
end
!
interface Serial1/1
ip address 10.10.20.2 255.255.255.0
serial restart-delay 0
end
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
router bgp 2
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 1
no auto-summary
!
ip route 1.1.1.1 255.255.255.255 10.10.10.1
ip route 1.1.1.1 255.255.255.255 10.10.20.1
Notice that in both routers we put 2 static routes to achieve load balancing. Currently the BGP session is not established eventhough both loopbacks are reachable. Now, lets configure "ebgp-multihop" on both routers and see if this will make the BGP session establish.
The purpose of "ebgp-multihop" is to connect to eBGP neighbors that are not directly connected.
As we know, BGP expects eBGP peers to be directly connected but this command will make
neighborship possible even though they are not directly connected.
Now let's configure the routers.
R1(config)#router bgp 1
R1(config-router)#neighbor 2.2.2.2 ebgp-multihop 2
R2(config)#router bgp 2
R2(config-router)#neighbor 1.1.1.1 ebgp-multihop 2
R1#sh ip bgp sum
BGP router identifier 1.1.1.1, local AS number 1
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 2 0 0 0 0 0 never ActiveThe BGP session is not established even though we configured the "ebgp-multihop" command. Before we find out why, lets first discuss the "ebgp-multihop" command. The default value of this command if we don't put anything will be 255. We put a value of 2 because it will take 2 hops to reach 2.2.2.2 from 1.1.1.1 as they are not directly connected. Provided all the requirements are met except the hop count value, if the hop count value is lesser than what it should be, the eBGP neighborship will not be established.
Going back to why its not established, its because by default for BGP to establish the TCP session it will use the outgoing interface ip address as the source. The other router will reject the incoming TCP SYN packets because it doesn't recognize the source IP address as a configured neighbor. In our case, it will source the TCP session using the two physical interfaces ip addresses.
The BGP session updates should be sourced from the IP address that the the neighbor
configured for eBGP Multihop to work. The command "neighbor ip_address update-source
Loopback0" in our example is needed.
Now lets configure, the update-source command sourcing all BGP negiotiations and updates from Loopback0 which are the ip addresses configured on our neighbor statements.
R1(config)#router bgp 1
R1(config-router)#neighbor 2.2.2.2 update-source Loopback0
R2(config)#router bgp 2
R2(config-router)#neighbor 1.1.1.1 update-source Loopback0
R1#sh ip bgp su
*Aug 13 14:41:43.175: %SYS-5-CONFIG_I: Configured from console by consolem
BGP router identifier 1.1.1.1, local AS number 1
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 2 11 11 1 0 0 00:00:47 0
R2#sh ip bgp sum
*Aug 13 14:41:38.099: %SYS-5-CONFIG_I: Configured from console by console
BGP router identifier 2.2.2.2, local AS number 2
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 1 11 11 1 0 0 00:00:42 0
BGP session now established. We can see in CEF that this is load balanced.
R1#sh ip cef 2.2.2.2
2.2.2.2/32, version 27, epoch 0, per-destination sharing
0 packets, 0 bytes
via 10.10.20.2, 0 dependencies, recursive
traffic share 1
next hop 10.10.20.2, Serial1/1 via 10.10.20.0/24
valid adjacency
via 10.10.10.2, 0 dependencies, recursive
traffic share 1
next hop 10.10.10.2, Serial1/0 via 10.10.10.0/24
valid adjacency
0 packets, 0 bytes switched through the prefix
tmstats: external 0 packets, 0 bytes
internal 0 packets, 0 bytes
Now, BGP session is established. Let's try shutting down one link and see if the session is still established.
R2(config)#int se1/0
R2(config-if)#shut
R2(config-if)#^Z
R2#sh ihp b
*Aug 13 14:42:38.871: %SYS-5-CONFIG_I: Configured from console by console
*Aug 13 14:42:39.095: %LINK-5-CHANGED: Interface Serial1/0, changed state to administrativ
*Aug 13 14:42:39.095: %ENTITY_ALARM-6-INFO: ASSERT INFO Se1/0 Physical Port Administrative State Down
*Aug 13 14:42:40.095: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to down
R2#sh ip bgp sum
BGP router identifier 2.2.2.2, local AS number 2
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.1.1 4 1 12 12 1 0 0 00:01:45 0
BGP session still established. Thats all about EBGP Multihop feature.:)
BGP Confederation
This is feature is used to split an autonomous system into smaller autonomous systems or the reverse which is to combine several autonomous systems into one. Reasons of splitting might be IGP's like OSPF might not be able to handle the routes of a really big enterprise so splitting the AS into smaller will help OSPF scale better, or perhaps the enterprise wants to have separate administrative control per region and wants to control the routing policies on their specific regions. This could also be used if there are company mergers and they want to appear as one AS to other EBGP peers. One thing that intrigues me though is that one of the materials I was using mentioned that this could also be a work around for the BGP Split Horizon Rule. I really doubt that Confederations can be a work around for that. I'll find out for sure in this lab.
The diagram below shows 5 Routers with each its own AS number. The goal here to group these routers into one confederation and make them appear as AS1234 to R5 in AS5.
Below are the configurations I have placed on the routers.
I have configured static routes for reachability. Notice as well that I am using EBGP-multihop feature for EBGP neighbors. I have configured Loopback10 11.11.11.11/32 in R1 and lets see how R2,R3,R4 and R5 see this prefix.
All of them is seeing this prefix sourcing from an EBGP. Now let's configure R1, R2, R3 and R4 as one confederation and let's see how the BGP table looks like after that. To configure BGP confederations, what are needed is the confederation ID and the peer ASes belonging to that confederation.
As you noticed, you are not allowed to configure your own AS on the "bgp confederation peer command". Ok now let's check how R2,R3,R4 and R5 sees this prefix.
It's clear that its now behaving like they are in one AS. In R4, you can see that it enclosed the AS path in parenthesis, which means AS is using BGP confederation. I have not configured any route reflector here but R4 is still learning the prefix as advertised by R2 and R3. Therefore in some way it circumvents the BGP Split Horizon rule. In a confederation, it may appear like its one AS but it functions how the peering is configured whether its IBGP or EBGP. Going back, R5 is not seeing anything. You know why? It's because R4 doesn't know how to get to 1.1.1.1 inorder to reach 11.11.11.11/32. It won't advertise anything to R5 until it knows how to get to the destination. Let's configure a static route.
Then let's see if R4 now sees the best path to 11.11.11.11 in its BGP table.
EBGP peering between R4 and R5 is still there but R5 is still using 4 as the remote-as of R4. It may learn the prefix even though the remote-as number for 4.4.4.4 hasn't been changed, however if the link goes down or the BGP session is cleared, BGP will generate now an error that neighbor in wrong AS. Let's change that config to 1234 and check if R5 now sees 11.11.11.11/32.
The AS path to get to 11.11.11.11/32 is now only 1234 and R5 is now seeing the groups of AS as one AS. Well that's all about it regarding Confederations.
The diagram below shows 5 Routers with each its own AS number. The goal here to group these routers into one confederation and make them appear as AS1234 to R5 in AS5.
Below are the configurations I have placed on the routers.
R1#sh run | section router bgp
router bgp 1
no synchronization
bgp log-neighbor-changes
network 1.1.1.1 mask 255.255.255.255
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 ebgp-multihop 2
neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 3
neighbor 3.3.3.3 ebgp-multihop 2
neighbor 3.3.3.3 update-source Loopback0
no auto-summary
R2#sh run | section router bgp
router bgp 2
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 ebgp-multihop 2
neighbor 1.1.1.1 update-source Loopback0
neighbor 4.4.4.4 remote-as 4
neighbor 4.4.4.4 ebgp-multihop 2
neighbor 4.4.4.4 update-source Loopback0
no auto-summary
R3#sh run | section router bgp
router bgp 3
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 ebgp-multihop 2
neighbor 1.1.1.1 update-source Loopback0
neighbor 4.4.4.4 remote-as 4
neighbor 4.4.4.4 ebgp-multihop 2
neighbor 4.4.4.4 update-source Loopback0
no auto-summary
R4#sh run | section router bgp
router bgp 4
no synchronization
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 ebgp-multihop 2
neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 3
neighbor 3.3.3.3 ebgp-multihop 2
neighbor 3.3.3.3 update-source Loopback0
neighbor 5.5.5.5 remote-as 5
neighbor 5.5.5.5 ebgp-multihop 2
neighbor 5.5.5.5 update-source Loopback0
no auto-summary
R5#sh run | section router bgp
router bgp 5
no synchronization
bgp log-neighbor-changes
neighbor 4.4.4.4 remote-as 4
neighbor 4.4.4.4 ebgp-multihop 2
neighbor 4.4.4.4 update-source Loopback0
no auto-summaryI have configured static routes for reachability. Notice as well that I am using EBGP-multihop feature for EBGP neighbors. I have configured Loopback10 11.11.11.11/32 in R1 and lets see how R2,R3,R4 and R5 see this prefix.
R2# sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
*> 11.11.11.11/32 1.1.1.1 0 0 1 i
R3#sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
* 11.11.11.11/32 4.4.4.4 0 4 2 1 i
*> 1.1.1.1 0 0 1 i
R4#sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
* 11.11.11.11/32 3.3.3.3 0 3 1 i
*> 2.2.2.2 0 2 1 i
R5#sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
*> 11.11.11.11/32 4.4.4.4 0 4 2 1 i
All of them is seeing this prefix sourcing from an EBGP. Now let's configure R1, R2, R3 and R4 as one confederation and let's see how the BGP table looks like after that. To configure BGP confederations, what are needed is the confederation ID and the peer ASes belonging to that confederation.
R1(config)#router bgp 1
R1(config-router)#bgp confederation identifier 1234
R1(config-router)#bgp confederation peers 2 3 4
R2(config)#router bgp 2
R2(config-router)#bgp confederation identifier 1234
R2(config-router)#bgp confederation peers 1 3 4
R3(config)#router bgp 3
R3(config-router)#bgp confederation identifier 1234
R3(config-router)#bgp confederation peers 1 2 4
R4(config)#router bgp 4
R4(config-router)#bgp confederation identifier 1234
R4(config-router)#bgp confederation peers 1 2 3
R4(config-router)#bgp confederation peers 4
4 Local member-AS not allowed in confed peer list
4 Local member-AS not allowed in confed peer list
As you noticed, you are not allowed to configure your own AS on the "bgp confederation peer command". Ok now let's check how R2,R3,R4 and R5 sees this prefix.
R2#sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
*> 11.11.11.11/32 1.1.1.1 0 100 0 (1) i
R3#sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
*> 11.11.11.11/32 1.1.1.1 0 100 0 (1) i
R4#sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
* 11.11.11.11/32 1.1.1.1 0 100 0 (3 1) i
* 1.1.1.1 0 100 0 (2 1) i
R5#sh ip bgp
It's clear that its now behaving like they are in one AS. In R4, you can see that it enclosed the AS path in parenthesis, which means AS is using BGP confederation. I have not configured any route reflector here but R4 is still learning the prefix as advertised by R2 and R3. Therefore in some way it circumvents the BGP Split Horizon rule. In a confederation, it may appear like its one AS but it functions how the peering is configured whether its IBGP or EBGP. Going back, R5 is not seeing anything. You know why? It's because R4 doesn't know how to get to 1.1.1.1 inorder to reach 11.11.11.11/32. It won't advertise anything to R5 until it knows how to get to the destination. Let's configure a static route.
R4(config)#ip route 1.1.1.1 255.255.255.255 24.24.24.2
R4(config)#ip route 1.1.1.1 255.255.255.255 34.34.34.3
Then let's see if R4 now sees the best path to 11.11.11.11 in its BGP table.
R4#sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
*> 11.11.11.11/32 1.1.1.1 0 100 0 (2 1) i
EBGP peering between R4 and R5 is still there but R5 is still using 4 as the remote-as of R4. It may learn the prefix even though the remote-as number for 4.4.4.4 hasn't been changed, however if the link goes down or the BGP session is cleared, BGP will generate now an error that neighbor in wrong AS. Let's change that config to 1234 and check if R5 now sees 11.11.11.11/32.
R5(config)#router bgp 5
R5(config-router)#neighbor 4.4.4.4 remote 1234
R5(config-router)#neighbor 4.4.4.4 update-source Lo0
*Aug 6 16:09:00.259: %BGP-5-ADJCHANGE: neighbor 4.4.4.4 Down Remote AS changed.4.4.4
*Aug 6 16:09:02.567: %BGP-5-ADJCHANGE: neighbor 4.4.4.4 Up update lo0
R5(config-router)#neighbor 4.4.4.4 ebgp 2
R5#sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
*> 11.11.11.11/32 4.4.4.4 0 1234 i
The AS path to get to 11.11.11.11/32 is now only 1234 and R5 is now seeing the groups of AS as one AS. Well that's all about it regarding Confederations.
BGP Maximum-Prefix
BGP handles over 100,000 routes in the internet and it is doing a very good job in doing so. I tried doing the "show ip bgp" command on our internet router with a Public AS and takes quite a long time to show all the prefixes. I have to hit the space bar a lot of times. You can imagine how much CPU this number of routes will take on the router.
I have read an article that a few months ago, there was one ISP that advertised the whole internet routing table and originated all the routes. A mistake will most likely affect the routers in the internet, or could take the internet down if there are no counter measures done. One more possible thing I can imagine that might happen is that private ip addresses from a customer might be advertised out to the internet if the ISP failed to filter the private address. ( I dunno if this happened before)
Limiting the number of prefixes received from a BGP neighbor is one of the best ways to make sure these mistakes never affect the whole internet. The best practice is to check the number of prefixes received from a neighbor and then give a little allowance on the number of prefixes allowed. R1 on the diagram below is announcing prefixes to R2, let's see what happens if these prefixes reach the limit and what happens if it exceeds the limit.
Let's see how many prefixes R2 learns from R1.
It's learning 100 prefixes from R1. Now lets configure BGP so that R2 will only allow 101 routes from R1. The command we will use is "neighbor neighboraddress
Let's advertise one route to BGP in R1. I will configure as well a static route pointing to Null0, to make sure the new route will be advertised. I didn't configure any loopback addresses on R1.
Let's see how R2 reacted to this configuration.
Oh, it reacted by generating a log message that the number of prefixes learned from R1 has reached its maximum. Lets add one more route in R1 and see what happens.
Let's check R1 and R2 syslog messages.
This time it gave also a notification in R2 and also generated a hexadecimal code. ( I have yet to review what this means :)) Right then and there, when it exceeded the limit R2 dropped the peering to R1. Let's see what the BGP table summary looks like after the violation.
The state is in Idle and included a description (PfxCt) which means the neighbor exceeded the prefix limit set. The peering will only be established once the prefixes goes below the threshold set and "clear ip bgp *" needs to be issued to renegotiate the connection. Again, this command is very useful to protect your own AS from over flooding of prefixes and protect other ASes as well.
I have read an article that a few months ago, there was one ISP that advertised the whole internet routing table and originated all the routes. A mistake will most likely affect the routers in the internet, or could take the internet down if there are no counter measures done. One more possible thing I can imagine that might happen is that private ip addresses from a customer might be advertised out to the internet if the ISP failed to filter the private address. ( I dunno if this happened before)
Limiting the number of prefixes received from a BGP neighbor is one of the best ways to make sure these mistakes never affect the whole internet. The best practice is to check the number of prefixes received from a neighbor and then give a little allowance on the number of prefixes allowed. R1 on the diagram below is announcing prefixes to R2, let's see what happens if these prefixes reach the limit and what happens if it exceeds the limit.
Let's see how many prefixes R2 learns from R1.
R2#sh ip bgp summary
BGP router identifier 10.10.10.2, local AS number 234
BGP table version is 101, main routing table version 101
100 network entries using 11700 bytes of memory
100 path entries using 5200 bytes of memory
2/1 BGP path/bestpath attribute entries using 248 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 17172 total bytes of memory
BGP activity 100/0 prefixes, 100/0 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.10.10.1 4 123 13 12 101 0 0 00:06:03 100It's learning 100 prefixes from R1. Now lets configure BGP so that R2 will only allow 101 routes from R1. The command we will use is "neighbor neighboraddress
R2(config)#router bgp 234
R2(config-router)#neighbor 10.10.10.1 remote-as 123
R2(config-router)#neighbor 10.10.10.1 maximum-prefix 101
Let's advertise one route to BGP in R1. I will configure as well a static route pointing to Null0, to make sure the new route will be advertised. I didn't configure any loopback addresses on R1.
R1(config)#router bgp 123
R1(config-router)#network 1.1.1.101 mask 255.255.255.255
R1(config-router)#ip route 1.1.1.101 255.255.255.255 Null0
Let's see how R2 reacted to this configuration.
R2#
*Aug 5 13:08:58.959: %BGP-4-MAXPFX: No. of prefix received from 10.10.10.1 (afi 0) reaches 101, max 101
Oh, it reacted by generating a log message that the number of prefixes learned from R1 has reached its maximum. Lets add one more route in R1 and see what happens.
R1(config)#router bgp 123
R1(config-router)#network 1.1.1.102 mask 255.255.255.255
R1(config-router)#ip route 1.1.1.102 255.255.255.255 Null0Let's check R1 and R2 syslog messages.
R1#
*Aug 5 13:11:16.415: %BGP-3-NOTIFICATION: received from neighbor 10.10.10.2 3/1 (update malformed) 0 bytes
*Aug 5 13:11:16.415: %BGP-5-ADJCHANGE: neighbor 10.10.10.2 Down BGP Notification received
R2#
*Aug 5 13:11:20.199: %BGP-3-MAXPFXEXCEED: No. of prefix received from 10.10.10.1 (afi 0): 102 exceed limit 101
*Aug 5 13:11:20.199: %BGP-5-ADJCHANGE: neighbor 10.10.10.1 Down BGP Notification sent
*Aug 5 13:11:20.199: %BGP-3-NOTIFICATION: sent to neighbor 10.10.10.1 3/1 (update malformed) 0 bytes FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0035 0200 0000 1940 0101 0040 0204 0201 007B 4003 040A 0A0A 0180 0404 0000 0000 2001 0101 66
This time it gave also a notification in R2 and also generated a hexadecimal code. ( I have yet to review what this means :)) Right then and there, when it exceeded the limit R2 dropped the peering to R1. Let's see what the BGP table summary looks like after the violation.
R2#sh ip bgp sum
BGP router identifier 10.10.10.2, local AS number 234
BGP table version is 203, main routing table version 203
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.10.10.1 4 123 21 19 0 0 0 00:04:26 Idle (PfxCt)
The state is in Idle and included a description (PfxCt) which means the neighbor exceeded the prefix limit set. The peering will only be established once the prefixes goes below the threshold set and "clear ip bgp *" needs to be issued to renegotiate the connection. Again, this command is very useful to protect your own AS from over flooding of prefixes and protect other ASes as well.
VRF Route Target
MPLS VPN implementation requires VRF and also exporting and importing routes for that VRF. I mentioned on my previous posts about VRF that the VRF name is locally significant and even the RD number. What counts is what you import and export. Importing and exporting route targets use the same syntax as the RD and it is ASN:NN as shown by the example below.
By definition the routes that you "export" are only the routes you advertise on the vrf address family in BGP. The routes that you import are the cummulative routes with the same label that were exported from the other routers participating in the MPLS VPN. Remember that you don't export what you have learned through importation. Check the diagram below and the scenario we need to accomplish in this lab.
Scenario Conditions:
1. EMEA should have full ip reachability to APAC and AMERICAS but APAC and AMERICAS should not see each other.
2. RR should only see the all the routes but will not be seen by the routers.
I have setup everything and configured MPLS as well. I have configured the clients on the RR on both ipv4 and vpnv4 address-families. The command "show ip bgp vpnv4 all sum" on the RR should show that its learning prefixes from the clients.
We can clearly see that its learning prefixes in the vpnv4 but will not put those routes in the routing table until it has been imported in one of the VRF's. In our case, I have configured vrf ALL-VRF in RR and imported all the route-targets 123:1, 123:2 and 123:4. In a VRF you can export and import as many route-targets as needed. Lets see if RR can see the routes now
Ok, we have meet the first condition. RR is now able to see the routes exported by the RR clients. They won't see the route advertised in RR because the clients are not even importing that route. Full reachability in MPLS VPN requires that one router's exported route-target should be imported by another and vice-versa, otherwise you can only see the route but you won't be able to reach it. The networks should be in the corresponding VRF routing table of the routers.
To illustrate this point, let's configure the second scenario. Below are the VRF configurations on the 3 clients.
APAC is exporting route-target 123:1 and its importing 123:3 which is exported by EMEA. EMEA on the other hand is importing 123:1 and exporting 123:3. There should be full ip reachability between the two. By the way the route-target ID doesn't necessarily match with the RD. Normally for networks that should see each other in MPLS VPN both the export and import route target ID's are the same. It will get rid of any unnecessary confusion created by using different RT ID's. Take into consideration AMERICAS and EMEA routers. As you can see on the config above, AMERICAS is importing and exporting 123:2. One command can generate the both export and import and that is "route-target both 123:2". EMEA is importing and exporting also 123:2 which means they will reach each other. Let's test if we have accomplished the condition, we will show the routing table in APAC and AMERICAS and let's ping the networks in EMEA. The ping should be sourced on the loopback interfaces where we configured the VRF's.
It will take a while to get used to VRF Route-target if you are just learning it but this should be pretty easy. Remember, you can't reach a network that you have imported unless it exported your network. In MPLS VRF, entries in your VRF routing table doesn't assure reachability, the router in the destination network should also have your network in its VRF routing table. Ok, we are done! :)
!
ip vrf ALL-VRF
rd 123:4
route-target export 123:4
route-target import 123:1
route-target import 123:2
route-target import 123:3By definition the routes that you "export" are only the routes you advertise on the vrf address family in BGP. The routes that you import are the cummulative routes with the same label that were exported from the other routers participating in the MPLS VPN. Remember that you don't export what you have learned through importation. Check the diagram below and the scenario we need to accomplish in this lab.
Scenario Conditions:
1. EMEA should have full ip reachability to APAC and AMERICAS but APAC and AMERICAS should not see each other.
2. RR should only see the all the routes but will not be seen by the routers.
I have setup everything and configured MPLS as well. I have configured the clients on the RR on both ipv4 and vpnv4 address-families. The command "show ip bgp vpnv4 all sum" on the RR should show that its learning prefixes from the clients.
RR#sh ip bgp vpnv4 all sum
BGP router identifier 123.123.123.4, local AS number 123
BGP table version is 13, main routing table version 13
12 network entries using 1644 bytes of memory
12 path entries using 816 bytes of memory
4/3 BGP path/bestpath attribute entries using 496 bytes of memory
3 BGP extended community entries using 72 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 3028 total bytes of memory
BGP activity 12/0 prefixes, 12/0 paths, scan interval 15 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
123.123.123.1 4 123 52 57 13 0 0 00:40:41 2
123.123.123.2 4 123 53 61 13 0 0 00:41:26 2
123.123.123.3 4 123 43 44 13 0 0 00:36:44 2We can clearly see that its learning prefixes in the vpnv4 but will not put those routes in the routing table until it has been imported in one of the VRF's. In our case, I have configured vrf ALL-VRF in RR and imported all the route-targets 123:1, 123:2 and 123:4. In a VRF you can export and import as many route-targets as needed. Lets see if RR can see the routes now
RR
!
ip vrf ALL-VRF
rd 123:4
route-target export 123:4
route-target import 123:1
route-target import 123:2
route-target import 123:3
RR#sh ip route vrf ALL-VRF
Routing Table: ALL-VRF
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
B 1.1.1.1 [200/0] via 123.123.123.1, 00:46:26
2.0.0.0/32 is subnetted, 1 subnets
B 2.2.2.2 [200/0] via 123.123.123.2, 00:46:26
33.0.0.0/32 is subnetted, 1 subnets
B 33.33.33.33 [200/0] via 123.123.123.3, 00:46:26
3.0.0.0/32 is subnetted, 1 subnets
B 3.3.3.3 [200/0] via 123.123.123.3, 00:46:26
22.0.0.0/32 is subnetted, 1 subnets
B 22.22.22.22 [200/0] via 123.123.123.2, 00:46:26
11.0.0.0/32 is subnetted, 1 subnets
B 11.11.11.11 [200/0] via 123.123.123.1, 00:46:28
123.0.0.0/32 is subnetted, 1 subnets
C 123.123.123.14 is directly connected, Loopback40Ok, we have meet the first condition. RR is now able to see the routes exported by the RR clients. They won't see the route advertised in RR because the clients are not even importing that route. Full reachability in MPLS VPN requires that one router's exported route-target should be imported by another and vice-versa, otherwise you can only see the route but you won't be able to reach it. The networks should be in the corresponding VRF routing table of the routers.
To illustrate this point, let's configure the second scenario. Below are the VRF configurations on the 3 clients.
APAC#
!
ip vrf APAC
rd 123:1
route-target export 123:1
route-target import 123:3
AMERICAS#
!
ip vrf AMERICAS
rd 123:2
route-target export 123:2
route-target import 123:2
EMEA#
!
ip vrf EMEA
rd 123:3
route-target export 123:3
route-target export 123:2
route-target import 123:1
route-target import 123:2APAC is exporting route-target 123:1 and its importing 123:3 which is exported by EMEA. EMEA on the other hand is importing 123:1 and exporting 123:3. There should be full ip reachability between the two. By the way the route-target ID doesn't necessarily match with the RD. Normally for networks that should see each other in MPLS VPN both the export and import route target ID's are the same. It will get rid of any unnecessary confusion created by using different RT ID's. Take into consideration AMERICAS and EMEA routers. As you can see on the config above, AMERICAS is importing and exporting 123:2. One command can generate the both export and import and that is "route-target both 123:2". EMEA is importing and exporting also 123:2 which means they will reach each other. Let's test if we have accomplished the condition, we will show the routing table in APAC and AMERICAS and let's ping the networks in EMEA. The ping should be sourced on the loopback interfaces where we configured the VRF's.
APAC#sh ip route vrf APAC
Routing Table: APAC
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
33.0.0.0/32 is subnetted, 1 subnets
B 33.33.33.33 [200/0] via 123.123.123.3, 01:04:51
3.0.0.0/32 is subnetted, 1 subnets
B 3.3.3.3 [200/0] via 123.123.123.3, 01:04:51
11.0.0.0/32 is subnetted, 1 subnets
C 11.11.11.11 is directly connected, Loopback10
APAC#ping vrf APAC 3.3.3.3 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 248/346/436 ms
AMERICAS#sh ip route vrf AMERICAS
Routing Table: AMERICAS
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Loopback0
33.0.0.0/32 is subnetted, 1 subnets
B 33.33.33.33 [200/0] via 123.123.123.3, 00:56:20
3.0.0.0/32 is subnetted, 1 subnets
B 3.3.3.3 [200/0] via 123.123.123.3, 00:56:20
22.0.0.0/32 is subnetted, 1 subnets
C 22.22.22.22 is directly connected, Loopback10
AMERICAS#ping vrf AMERICAS 3.3.3.3 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 184/593/1020 ms
EMEA#sh ip route vrf EMEA
Routing Table: EMEA
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
B 1.1.1.1 [200/0] via 123.123.123.1, 00:00:00
2.0.0.0/32 is subnetted, 1 subnets
B 2.2.2.2 [200/0] via 123.123.123.2, 01:07:06
33.0.0.0/32 is subnetted, 1 subnets
C 33.33.33.33 is directly connected, Loopback10
3.0.0.0/32 is subnetted, 1 subnets
C 3.3.3.3 is directly connected, Loopback0
22.0.0.0/32 is subnetted, 1 subnets
B 22.22.22.22 [200/0] via 123.123.123.2, 01:07:06
11.0.0.0/32 is subnetted, 1 subnets
B 11.11.11.11 [200/0] via 123.123.123.1, 00:00:03It will take a while to get used to VRF Route-target if you are just learning it but this should be pretty easy. Remember, you can't reach a network that you have imported unless it exported your network. In MPLS VRF, entries in your VRF routing table doesn't assure reachability, the router in the destination network should also have your network in its VRF routing table. Ok, we are done! :)
BGP Remove-Private-AS
Most companies have acquired their own AS number and also some have implemented Private AS numbers connected to their Public AS network. They might have created a private AS number per region. There are others also who run BGP and are using private AS connected to their ISP using PA (Provider Allocated) Public IP addresses. No matter, how its implemented, announcing the private AS number you are using to the internet is a big NO, NO. ISP's should filter these private AS and not advertise them out to the internet.
Consider the diagram below. Let's say R1 is in Company A and is connected to its ISP using a private AS number 65535. The task we need to complete here is to filter any private AS to be announced to R2 so that R2 will only see the AS number of the ISP.
Firstly, I have done configuring the IP addresses indicated in the diagram. Created Loopback0 and Loopback10 in R1 and ISP and advertised them in BGP. Of course, all routers have BGP established. I have also announced networks 123.123.123.123/32 and 12.12.12.12/32 in the ISP router.
Now, lets check what R2 sees in the BGP table.
We see that the AS path to get to 1.1.1.1/32 and 11.11.11.11/32 is through AS 100 then AS65535. Lets do a filtering in ISP router not to advertise this private AS but instead make the ISP's AS the originating AS.
The "remove-private-as" appended to the neighbor statement ensures that any private AS connected to the ISP will not appear in the AS path. Lets clear the BGP process by doing "clear ip bgp * soft" on ISP router and see what R2 BGP table.
The networks from R1 now is seen originated from AS 100. The private AS number was removed by the command we issued. Note that this command works in the outbound direction and should be placed on the networks with public AS number but have private AS connected to them. I tried this command on R2 before I added in ISP but I didn't work because like what I mentioned, this works in the outbound direction. Lab is done, proceeding to the next one or perhaps I might reading some cool mangas like my favorite One Piece! :)
Consider the diagram below. Let's say R1 is in Company A and is connected to its ISP using a private AS number 65535. The task we need to complete here is to filter any private AS to be announced to R2 so that R2 will only see the AS number of the ISP.
Firstly, I have done configuring the IP addresses indicated in the diagram. Created Loopback0 and Loopback10 in R1 and ISP and advertised them in BGP. Of course, all routers have BGP established. I have also announced networks 123.123.123.123/32 and 12.12.12.12/32 in the ISP router.
Now, lets check what R2 sees in the BGP table.
R2#sh ip bgp
BGP table version is 5, local router ID is 192.168.20.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
*> 1.1.1.1/32 192.168.20.20 0 100 65535 i
*> 11.11.11.11/32 192.168.20.20 0 100 65535 i
*> 12.12.12.12/32 192.168.20.20 0 0 100 i
*> 123.123.123.123/32
192.168.20.20 0 0 100 i
We see that the AS path to get to 1.1.1.1/32 and 11.11.11.11/32 is through AS 100 then AS65535. Lets do a filtering in ISP router not to advertise this private AS but instead make the ISP's AS the originating AS.
ISP(config)#router bgp 100
ISP(config-router)#neighbor 192.168.20.1 remove-private-as
The "remove-private-as" appended to the neighbor statement ensures that any private AS connected to the ISP will not appear in the AS path. Lets clear the BGP process by doing "clear ip bgp * soft" on ISP router and see what R2 BGP table.
R2#sh ip bgp
BGP table version is 7, local router ID is 192.168.20.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
*> 1.1.1.1/32 192.168.20.20 0 100 i
*> 11.11.11.11/32 192.168.20.20 0 100 i
*> 12.12.12.12/32 192.168.20.20 0 0 100 i
*> 123.123.123.123/32
192.168.20.20 0 0 100 i
The networks from R1 now is seen originated from AS 100. The private AS number was removed by the command we issued. Note that this command works in the outbound direction and should be placed on the networks with public AS number but have private AS connected to them. I tried this command on R2 before I added in ISP but I didn't work because like what I mentioned, this works in the outbound direction. Lab is done, proceeding to the next one or perhaps I might reading some cool mangas like my favorite One Piece! :)
VRF and VRF-lite
I remembered that several months ago, I had an implementation regarding VRF-lite. In my previous posts VRF Basics and MPLS VPN VRF Select I haven't actually mentioned about VRF-lite. What exactly is this and how does this differ with VRF used in MPLS VPN?
First, ask the question, what is required to run VRF in the MPLS VPN implementation? Of course VRF, MP-BGP and MPLS should be running on the Provider's routers. It would need BGP VPNv4 neighborship to make MPLS VPN run.
VRF-lite is normally VRF without MPLS. This is Cisco's way, of what is so called virtualization. This can be useful of course if the enterprise has networks of overlapping IP addresses or some segments they don't want to be reached by other segments. Its kinda like VLAN in the sense that its in WAN. In this sense, VRF-lite configuration doesn't need the route-target part. For every VRF is a separate routing table. Routing VRF-lite can be done by static or dynamic under its vrf instance. I think I'll create a lab for this to show how it can be configured using IGP's. By the way, these days, I wonder why I am posting more on MPLS than any other topic? Does it mean I want to pursue CCIE SP than gettting the R&S? Good day! :)
First, ask the question, what is required to run VRF in the MPLS VPN implementation? Of course VRF, MP-BGP and MPLS should be running on the Provider's routers. It would need BGP VPNv4 neighborship to make MPLS VPN run.
VRF-lite is normally VRF without MPLS. This is Cisco's way, of what is so called virtualization. This can be useful of course if the enterprise has networks of overlapping IP addresses or some segments they don't want to be reached by other segments. Its kinda like VLAN in the sense that its in WAN. In this sense, VRF-lite configuration doesn't need the route-target part. For every VRF is a separate routing table. Routing VRF-lite can be done by static or dynamic under its vrf instance. I think I'll create a lab for this to show how it can be configured using IGP's. By the way, these days, I wonder why I am posting more on MPLS than any other topic? Does it mean I want to pursue CCIE SP than gettting the R&S? Good day! :)
MPLS VPN VRF Source Selection
It's been a while since I did some labs. Recently I received a comment from someone in the VRF Basics entry regarding importing the loopbacks from the CE routers to a VRF for management purposes. I'm in the middle of my BGP review but I'm curious anyway. I created a lab and tried a way and it seems I found a way how to. The feature is called VRF source selection, in which you can have multiple VRF's in an interface and VRF mapping is based on the source ip address. As we all know, CE routers usually don't have VRF's configured on them and usually for MPLS VPN setup one customer is assigned to one VRF. For MPLS Basics check my previous entry.
The diagram below shows 2 PE's and 3 CE's. I have preconfigured the PE's with BGP peering on both ipv4 and vpnv4 address-families and the necessary IP configuration with the CE's having a default route toward the directly connected PE. VPNv4 address-family on BGP by the way, is used for MPLS VPN. Configured MPLS on the link between PE1 and PE2.
Scenario:
We have 2 Customers, Customer1 and Customer2. The branch offices needs to connect to the other branches in PE2(I have created Loopback addresses for these). They need to have their own VRF's configured. Customer1 and Customer2 should have loopback0 ip addresses configured on the CE's for the NOC to use as management ip to access from their hopping server which is in ISP NOC router. VRF named "Management" should be used on the CE's. Customer's LAN networks are represented as Loopback10. The RD's of the Customers should be Customer1 - 1234:1, Customer2 - 1234:2 and Management - 1234:100. Click the image below for a bigger view.
The scenario requires 2 VRF's from every Customer CE. The Command "ip vrf forwarding" only uses one VRF per interface. We only have 1 interface and this command is not a feasible solution. We need to use VRF source selection in order to use multiple VRF's in an interface.
Provided that we already created the VRF's, first we would need to map a source IP address to a VRF. The PE will know which VRF a packet will be through the source IP.
After that, we would need to configure the interfaces in the PE's to use source selection. As mentioned, a while ago, "ip vrf forwarding" command is used if there is only one VRF used so in this scenario there is no need for the command.
The commands mean that on the corresponding interfaces the VRF are activated based on the "vrf selection source" commands. It's the equivalent of "ip Vrf forwarding" command but in the sense that its for multiple vrfs.
Well now the question is, how will the VRF's know which subnets will come from what interface. Simple, through routing.:) In our case since we are not configuring dynamic routing, we will configure static vrf routes.
It's obvious that the "vrf" keyword there points to what VRF this route belongs to.:) MPLS VPN requires that the routes be learned by Multiprotocol BGP. Since these are static routes we need to redistribute them into BGP on the ipv4 VRF address-family. Output pasted below from the running config.
If you notice, we didn't redistribute it on the "ipv4" global address-family but instead we did it on their corresponding VRF address-families. We learned that VRF's are like separate routing tables in a single router, and that exactly is the reason why we advertise this in different address-families.
We are not done yet, remember we have 2 loopback's in PE2 representing the other sites of Customer1 and Customer2. Lets configure those.
Let's check the VRF routing tables on R1.
We can see the routes that should be there. Now let's test the Customer1 VRF first if we achieved our objective. It should be able to reach the network 111.111.111.111/32 in PE2.
Cool its working! We need to specify the source ip so that it will be in the correct VRF. Network 111.111.111.111/32 is in vrf Customer1, if we don't use a source ip, by default it will use the exit interface's ip address as the source and will not be using any vrf since we don't have a source selection mapping for that. Instead it will use the "global routing table" which doesn't have entries for 111.111.111.111/32. Let's see what happens.
As expected! Let's do a test for Customer2.
And for our final objective, the Loopback0 should be reachable through vrf "Management" from ISP NOC router. By the way, since we are only using one VRF for this, it was not necessary to use source selection. It's only for example sake!:) Now for the testing.
Success!!! Whew, I don't like long blog entries but sure this will be helpful for myself in case I forget this feature. More on route-target import and export next time. Cheers!
The diagram below shows 2 PE's and 3 CE's. I have preconfigured the PE's with BGP peering on both ipv4 and vpnv4 address-families and the necessary IP configuration with the CE's having a default route toward the directly connected PE. VPNv4 address-family on BGP by the way, is used for MPLS VPN. Configured MPLS on the link between PE1 and PE2.
Scenario:
We have 2 Customers, Customer1 and Customer2. The branch offices needs to connect to the other branches in PE2(I have created Loopback addresses for these). They need to have their own VRF's configured. Customer1 and Customer2 should have loopback0 ip addresses configured on the CE's for the NOC to use as management ip to access from their hopping server which is in ISP NOC router. VRF named "Management" should be used on the CE's. Customer's LAN networks are represented as Loopback10. The RD's of the Customers should be Customer1 - 1234:1, Customer2 - 1234:2 and Management - 1234:100. Click the image below for a bigger view.
The scenario requires 2 VRF's from every Customer CE. The Command "ip vrf forwarding" only uses one VRF per interface. We only have 1 interface and this command is not a feasible solution. We need to use VRF source selection in order to use multiple VRF's in an interface.
Provided that we already created the VRF's, first we would need to map a source IP address to a VRF. The PE will know which VRF a packet will be through the source IP.
PE1(config)#vrf selection source 1.1.1.1 255.255.255.255 vrf Management
PE1(config)#vrf selection source 2.2.2.2 255.255.255.255 vrf Management
PE1(config)#vrf selection source 11.11.11.11 255.255.255.255 vrf Customer1
PE1(config)#vrf selection source 22.22.22.22 255.255.255.255 vrf Customer2
PE2(config)#vrf selection source 3.3.3.3 255.255.255.255 vrf Management
After that, we would need to configure the interfaces in the PE's to use source selection. As mentioned, a while ago, "ip vrf forwarding" command is used if there is only one VRF used so in this scenario there is no need for the command.
PE1(config)#interface Serial1/1
PE1(config-if)#ip vrf select source
PE1(config-if)#ip vrf receive Customer1
PE1(config-if)#ip vrf receive Management
PE1(config)#interface Serial1/2
PE1(config-if)#ip vrf select source
PE1(config-if)#ip vrf receive Customer2
PE1(config-if)#ip vrf receive Management
PE2(config)#interface Se1/3
PE2(config)#ip vrf select source
PE2(config)#ip vrf receive Management
The commands mean that on the corresponding interfaces the VRF are activated based on the "vrf selection source" commands. It's the equivalent of "ip Vrf forwarding" command but in the sense that its for multiple vrfs.
Well now the question is, how will the VRF's know which subnets will come from what interface. Simple, through routing.:) In our case since we are not configuring dynamic routing, we will configure static vrf routes.
PE1(config)#ip route vrf Customer1 11.11.11.11 255.255.255.255 192.168.10.1
PE1(config)#ip route vrf Customer2 22.22.22.22 255.255.255.255 192.168.20.2
PE1(config)#ip route vrf Management 1.1.1.1 255.255.255.255 192.168.10.1
PE1(config)#ip route vrf Management 2.2.2.2 255.255.255.255 192.168.20.2
PE2(config)#ip route vrf Management 3.3.3.3 255.255.255.255 192.168.30.3
It's obvious that the "vrf
PE1
!
address-family ipv4
neighbor 10.10.10.2 activate
no auto-summary
no synchronization
exit-address-family
!
address-family vpnv4
neighbor 10.10.10.2 activate
neighbor 10.10.10.2 send-community extended
exit-address-family
!
address-family ipv4 vrf Management
redistribute static metric 1
no auto-summary no synchronization
exit-address-family
!
address-family ipv4 vrf Customer2
redistribute static metric 1
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf Customer1
redistribute static metric 1 no auto-summary no synchronization exit-address-family
PE2
!
address-family ipv4 vrf Management
redistribute static metric 1
no auto-summary
no synchronization
exit-address-family
If you notice, we didn't redistribute it on the "ipv4" global address-family but instead we did it on their corresponding VRF address-families. We learned that VRF's are like separate routing tables in a single router, and that exactly is the reason why we advertise this in different address-families.
We are not done yet, remember we have 2 loopback's in PE2 representing the other sites of Customer1 and Customer2. Lets configure those.
Ok, now lets check BGP peering on the VPNv4 address family. The "show ip bgp vpnv4 all summary" command will display the summary of the prefixes learned through all the VRF's.
PE2
!
interface Loopback1
ip vrf forwarding Customer1
ip address 111.111.111.111 255.255.255.255
!
interface Loopback2
ip vrf forwarding Customer2
ip address 222.222.222.222 255.255.255.255
Now let's advertise this in BGP.
!
address-family ipv4 vrf Customer2
no auto-summary
no synchronization
network 222.222.222.222 mask 255.255.255.255
exit-address-family
!
address-family ipv4 vrf Customer1
no auto-summary
no synchronization
network 111.111.111.111 mask 255.255.255.255
exit-address-family
PE1#sh ip bgp vpnv4 all sum | beg Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.10.10.2 4 1234 93 106 15 0 0 01:14:47 3
PE2#sh ip bgp vpnv4 all sum | beg Neighbor
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.10.10.1 4 1234 106 93 20 0 0 01:14:56 4
Let's check the VRF routing tables on R1.
PE1#sh ip route vrf Customer1 | beg Gateway
Gateway of last resort is not set
C 192.168.10.0/24 is directly connected, Serial1/1
111.0.0.0/32 is subnetted, 1 subnets
B 111.111.111.111 [200/0] via 10.10.10.2, 00:23:02
11.0.0.0/32 is subnetted, 1 subnets
S 11.11.11.11 [1/0] via 192.168.10.1
PE1#sh ip route vrf Customer2 | beg Gateway
Gateway of last resort is not set
222.222.222.0/32 is subnetted, 1 subnets
B 222.222.222.222 [200/0] via 10.10.10.2, 00:24:04
22.0.0.0/32 is subnetted, 1 subnets
S 22.22.22.22 [1/0] via 192.168.20.2
C 192.168.20.0/24 is directly connected, Serial1/2
PE1#sh ip route vrf Management | beg Gateway
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
S 1.1.1.1 [1/0] via 192.168.10.1
2.0.0.0/32 is subnetted, 1 subnets
S 2.2.2.2 [1/0] via 192.168.20.2
3.0.0.0/32 is subnetted, 1 subnets
B 3.3.3.3 [200/1] via 10.10.10.2, 01:02:10
C 192.168.10.0/24 is directly connected, Serial1/1
C 192.168.20.0/24 is directly connected, Serial1/2
We can see the routes that should be there. Now let's test the Customer1 VRF first if we achieved our objective. It should be able to reach the network 111.111.111.111/32 in PE2.
Customer1#ping 111.111.111.111 source 11.11.11.11
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 111.111.111.111, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 144/168/192 ms
Cool its working! We need to specify the source ip so that it will be in the correct VRF. Network 111.111.111.111/32 is in vrf Customer1, if we don't use a source ip, by default it will use the exit interface's ip address as the source and will not be using any vrf since we don't have a source selection mapping for that. Instead it will use the "global routing table" which doesn't have entries for 111.111.111.111/32. Let's see what happens.
Customer1#ping 111.111.111.111
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 111.111.111.111, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
As expected! Let's do a test for Customer2.
Customer2#ping 222.222.222.222 source 22.22.22.22
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 222.222.222.222, timeout is 2 seconds:
Packet sent with a source address of 22.22.22.22
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 144/173/192 ms
And for our final objective, the Loopback0 should be reachable through vrf "Management" from ISP NOC router. By the way, since we are only using one VRF for this, it was not necessary to use source selection. It's only for example sake!:) Now for the testing.
ISPNOC#ping 1.1.1.1 source 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 172/216/264 ms
ISPNOC#ping 2.2.2.2 source 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 168/231/292 ms
Success!!! Whew, I don't like long blog entries but sure this will be helpful for myself in case I forget this feature. More on route-target import and export next time. Cheers!
BGP AS-Path Prepending
BGP is rich in features that you can have more control than on what IGP's offer however, you can only have control on how the traffic leaves your autonomous system and can't really control how other autonomous systems reach you. Other AS'es might have BGP policies that route the traffic in a way you don't intend it to go. You don't have control over those because, its their autonomous systems after all. However, there are work arounds which allow, an autonomous system affect the other autonomous systems, one of this is called BGP AS-path prepending. It is basically adding additional AS-paths by repeating your own AS number. Consider the diagram below. (Click image for a bigger view) By looking at the diagram, if you are familiar with BGP, the AS-path the networks from R4 will take towards R1 will be AS4, AS3 and then AS1. If all the attributes are set to the default values, most likely the AS-path attribute will determine which path to take. The more desirable path in this scenario is AS4, AS3, AS2 and then AS1 for the reason that there is a 100mbps link connecting AS1 and AS2 which makes traffic forwarding more efficient. But remember, unlike IGP's, BGP doesn't take to account the bandwidth.
In this scenario we are in AS1 and we make AS2 the more desirable path for AS4 to reach us using AS-path prepending.
Checking on R4 we will see how it gets to R1.
Just as we guessed, it would take AS3 then AS1 which is the shortest path based on BGP attributes. Now we will configure AS-prepending on R1 for R4 to take the AS3, AS2 then AS1 path.
We made it 1 1 1 cause it would only 2 AS paths to reach R1 from R4 through R3. We will make that AS-path longer and less desirable. We will apply this route map we created to the neighborship peering between R1 and R3.
The reason its in the outbound direction because R1 is advertising the subnets. Let's clear the bgp process in R1 to make the changes. Then lets see what happened to the AS-path in R4.
Ok, you can see the difference now, its now taking 3-2-1. This is because it received an advertisement from R3 about the best path. BGP only advertises the best path to a network to its neighbor. Since R3 is seeing the AS_Path going to R1 is longer, it now takes AS2 to get to R1. Lets see what happened to the BGP table after applying the route map.
Three 1's were added to the AS_Path based on what we put on the route-map, so from the AS-path values, R3 will not go directly to R1 but will take R2 now instead.
Now what if we want traffic to 11.11.11.11 to take A3 directly and traffic to 1.1.1.1 take AS3 then AS2 from R4. We will create an access-list TAKER2 and modify the route-map to match the condition.
Let's check what happened to R3
Cool, you can see the difference with the ACL. Now 1.1.1.1 in R3 has prepend but 11.11.11.11 has no prepend. Finally, lets check R4.
From R4 traffic to 1.1.1.1 will pass through AS2 but to 11.11.11.11 it will go directly to R3 then R1. Whew, kinda hard to explain. Enough is enough! Cheers! :)
In this scenario we are in AS1 and we make AS2 the more desirable path for AS4 to reach us using AS-path prepending.
Checking on R4 we will see how it gets to R1.
R4#
*Jul 16 13:25:54.039: %SYS-5-CONFIG_I: Configured from console by console
R4#sh ip bgp
BGP table version is 11, local router ID is 34.34.34.4
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
*> 1.1.1.1/32 34.34.34.3 0 3 1 i
*> 4.4.4.4/32 0.0.0.0 0 32768 i
*> 11.11.11.11/32 34.34.34.3 0 3 1 i
*> 44.44.44.44/32 0.0.0.0 0 32768 i
Just as we guessed, it would take AS3 then AS1 which is the shortest path based on BGP attributes. Now we will configure AS-prepending on R1 for R4 to take the AS3, AS2 then AS1 path.
R1(config)#route-map ASPREPEND permit 10
R1(config-route-map)#set as-path prepend 1 1 1
R1(config)#route-map ASPREPEND permit 20
We made it 1 1 1 cause it would only 2 AS paths to reach R1 from R4 through R3. We will make that AS-path longer and less desirable. We will apply this route map we created to the neighborship peering between R1 and R3.
R1(config)#router bgp 1
R1(config-router)#neighbor 13.13.13.3 route-map ASPREPEND out
The reason its in the outbound direction because R1 is advertising the subnets. Let's clear the bgp process in R1 to make the changes. Then lets see what happened to the AS-path in R4.
R4#sh ip bgp
BGP table version is 13, local router ID is 34.34.34.4
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
*> 1.1.1.1/32 34.34.34.3 0 3 2 1 i
*> 4.4.4.4/32 0.0.0.0 0 32768 i
*> 11.11.11.11/32 34.34.34.3 0 3 2 1 i
*> 44.44.44.44/32 0.0.0.0 0 32768 i
Ok, you can see the difference now, its now taking 3-2-1. This is because it received an advertisement from R3 about the best path. BGP only advertises the best path to a network to its neighbor. Since R3 is seeing the AS_Path going to R1 is longer, it now takes AS2 to get to R1. Lets see what happened to the BGP table after applying the route map.
R3#sh ip bgp
BGP table version is 13, local router ID is 23.23.23.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
*> 1.1.1.1/32 23.23.23.2 0 2 1 i
* 13.13.13.1 0 0 1 1 1 1 i
*> 4.4.4.4/32 34.34.34.4 0 0 4 i
*> 11.11.11.11/32 23.23.23.2 0 2 1 i
* 13.13.13.1 0 0 1 1 1 1 i
*> 44.44.44.44/32 34.34.34.4 0 0 4 i
Three 1's were added to the AS_Path based on what we put on the route-map, so from the AS-path values, R3 will not go directly to R1 but will take R2 now instead.
Now what if we want traffic to 11.11.11.11 to take A3 directly and traffic to 1.1.1.1 take AS3 then AS2 from R4. We will create an access-list TAKER2 and modify the route-map to match the condition.
R1(config)#ip access-list extended TAKER2
R1(config-ext-nacl)#permit ip host 1.1.1.1 any
R1(config)#route-map ASPREPEND permit 10
R1(config-route-map)#match ip address TAKER2
R1(config-route-map)#set as-path prepend 1 1 1
Let's check what happened to R3
R3#sh ip bgp
BGP table version is 28, local router ID is 23.23.23.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
*> 1.1.1.1/32 23.23.23.2 0 2 1 i
* 13.13.13.1 0 0 1 1 1 1 i
*> 4.4.4.4/32 34.34.34.4 0 0 4 i
* 11.11.11.11/32 23.23.23.2 0 2 1 i
*> 13.13.13.1 0 0 1 i
*> 44.44.44.44/32 34.34.34.4 0 0 4 i
Cool, you can see the difference with the ACL. Now 1.1.1.1 in R3 has prepend but 11.11.11.11 has no prepend. Finally, lets check R4.
R4#sh ip bgp
BGP table version is 27, local router ID is 34.34.34.4
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
*> 1.1.1.1/32 34.34.34.3 0 3 2 1 i
*> 4.4.4.4/32 0.0.0.0 0 32768 i
*> 11.11.11.11/32 34.34.34.3 0 3 1 i
*> 44.44.44.44/32 0.0.0.0 0 32768 i
From R4 traffic to 1.1.1.1 will pass through AS2 but to 11.11.11.11 it will go directly to R3 then R1. Whew, kinda hard to explain. Enough is enough! Cheers! :)
Certifications
Blogs that I Read
-
-
-
-
IPv6 radius accounting is still a mess - Since the beginning of putting IPv6 into production BRAS/BNG (almost 3 years ago), we were facing the following issue: radius accounting records were missi...12 years ago
-
Internetwork Expert Volume IV (Troubleshooting) Workbook Review: Part 3 - Once you get the initial configurations loaded you’re ready to begin the lab. This is when the “fun” begins. Those of us who are used to starting labs wi...16 years ago
-
-
Cavani Authorize Central Approached Atletico Madrid Squad - Atletico Madrid Squad – PSG striker Edinson Cavani, incredulously, if he is a similar player Luis Suarez, though they are both from Uruguay. CAVANI will be...9 years ago
-
Network Engineer Jobs - So you want to work for Google as Network Engineer? Check out one of the job ads here. I pasted the screenshot below just in case the ad is removed once...8 years ago
-
Interested in Microsoft Azure? Tune into James Rudley’s Newest Course - Get ready to explore the different methods of automating technical and business challenges with Azure in James Rudley’s new course; Automation With Microso...7 years ago
-
On the Futility of Opening Ansible Issues - Remember the anonymous troll who chided me for writing a rant instead of opening a GitHub issue in the relevant Ansible repository? Well, I decided to be...1 week ago
-
Clearing the fog around open switching terminology - The networking industry is making a decisive move toward open switches. Much of the media's attention is on mega-scale operators' do-it-yourself switche...11 years ago
-
-
A Short Summary of Planes - A Short Summary of Planes (the network kind) When the CCDE program was first developed, Cisco conveniently broke down the included technologies into five...7 years ago
-
Book Review: Model-Driven DevOps - Earlier this month at Cisco Live in Las Vegas, I attended a presentation by Steven Carter and Jason King titled *Model-Driven DevOps: The Enterprise Auto...3 years ago
-
Data Center Study - Notes 01 - - reverse proxy caching - the user of loadbalancers for server health monitoring - the need for jumbo frames - the need for NIC features such as interrupt co...12 years ago
-
-
I’m Back - Well hello blog world. Yes it’s been a while since I last posted an update. I meant to update sooner but because I haven’t logged on to WordPress in such a...13 years ago
-
Integrating the Nexus 1000v VSM with vCenter - This is a follow-up to my previous post regarding the Nexus 1000v. Now that I help set the stage for what the Nexus 1000v really is, we can start looking a...16 years ago
-
Subscribe
Posts
All Comments
