bgp
BGP backdoor
30/01/11 11:32
BGP network backdoor allows to use a non-BGP backdoor link between two ASs.
Look at the topology:
If AS300 and AS500 are not BGP peers, the connection between the loopbacks on R3 and R5 goes through AS100:
R3#traceroute 5.5.5.5 so l0 probe 1 timeout 1 numeric
1 10.0.23.2 16 msec
2 10.0.12.1 24 msec
3 10.0.14.4 24 msec
4 10.0.45.5 [AS 100] 16 msec
Even if R3 and R5 are OSPF neighbors, OSPF routes have AD 110 while eBGP has AD 20 and wins:
R3#sir 5.5.5.5
Routing entry for 5.5.5.5/32
Known via "bgp 300", distance 20, metric 0
Tag 100, type external
Last update from 10.0.23.2 00:03:04 ago
Routing Descriptor Blocks:
* 10.0.23.2, from 10.0.23.2, 00:03:04 ago
Route metric is 0, traffic share count is 1
AS Hops 2
Route tag 100
How do we allow R3 and R5 do use backdoor link between S1/1 interfaces? Creating a backdoor:
R3(config)#router bgp 300
R3(config-router)#network 5.5.5.5 mask 255.255.255.255 backdoor
Verify:
R3#sir 5.5.5.5
Routing entry for 5.5.5.5/32
Known via "ospf 1", distance 110, metric 101, type intra area
Last update from 10.0.35.5 on Serial1/1, 00:00:19 ago
Routing Descriptor Blocks:
* 10.0.35.5, from 10.0.35.5, 00:00:19 ago, via Serial1/1
Route metric is 101, traffic share count is 1
What about the eBGP route?
R3#sh ip bgp 5.5.5.5
BGP routing table entry for 5.5.5.5/32, version 13
Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(17))
Not advertised to any peer
100 500
10.0.23.2 from 10.0.23.2 (2.2.2.2)
Origin IGP, localpref 100, valid, external, best
It's stil there but "RIB-failure" means a better IGP route was found, as we expected while creating the backdoor.
On R5 we still transit through AS100 to reach R3 L0.
R5#sir 3.3.3.3
Routing entry for 3.3.3.3/32
Known via "bgp 500", distance 20, metric 0
Tag 100, type external
Last update from 10.0.45.4 00:05:14 ago
Routing Descriptor Blocks:
* 10.0.45.4, from 10.0.45.4, 00:05:14 ago
Route metric is 0, traffic share count is 1
AS Hops 2
Route tag 100
We need the backdoor command on R5 too to keep traffic symmetric:
R5(config)#router bgp 500
R5(config-router)#network 3.3.3.3 mask 255.255.255.255 backdoor
Verify:
R5#sir 3.3.3.3
Routing entry for 3.3.3.3/32
Known via "ospf 1", distance 110, metric 21, type intra area
Last update from 10.0.35.3 on Serial1/1, 00:00:15 ago
Routing Descriptor Blocks:
* 10.0.35.3, from 10.0.35.3, 00:00:15 ago, via Serial1/1
Route metric is 21, traffic share count is 1
Can we achieve the same result without using the backdoor command? Of course!
Remove the backdoor from R5:
R5(config)#router bgp 500
R5(config-router)#no network 3.3.3.3 mask 255.255.255.255 backdoor
We reach R3 L0 though AS 100 again:
R5(config-router)#do sir 3.3.3.3
Routing entry for 3.3.3.3/32
Known via "bgp 500", distance 20, metric 0
Tag 100, type external
Last update from 10.0.45.4 00:00:25 ago
Routing Descriptor Blocks:
* 10.0.45.4, from 10.0.45.4, 00:00:25 ago
Route metric is 0, traffic share count is 1
AS Hops 2
Route tag 100
Now on R3 we set AD 200 to prefix 3.3.3.3/32 learnt from 10.0.45.4:
R5(config)# access-list 3 permit 3.3.3.3
R5(config)#router bgp 500
R5(config-router)# distance 200 10.0.45.4 0.0.0.0 3
After clearing the BGP session we get again:
R5(config-router)#do sir 3.3.3.3
Routing entry for 3.3.3.3/32
Known via "ospf 1", distance 110, metric 21, type intra area
Last update from 10.0.35.3 on Serial1/1, 00:06:28 ago
Routing Descriptor Blocks:
* 10.0.35.3, from 10.0.35.3, 00:06:28 ago, via Serial1/1
Route metric is 21, traffic share count is 1
And now again: is there another way to achieve the same result? Actually, there is. Can you guess it?
Here's a clue: "bgp maxas-limit 1"
On AS500 R5 learns prefix 3.3.3.3/32 with AS-PATH "100 300 i":
R5(config-router)#do show ip bgp
BGP table version is 6, local router ID is 5.5.5.5
Network Next Hop Metric LocPrf Weight Path
*> 3.3.3.3/32 10.0.45.4 0 100 300 i
If we set "maxas-limit" to 1 R5 filters all prefixes with an AS-PATH longer than 1, in other words any prefix learnt from AS300. In this particular topology that means that R5 will use the OSPF route to reach prefix 3.3.3.3/32.
This is the message we get after applying the command and clearing the BGP session:
*Mar 1 03:52:25.171: %BGP-6-ASPATH: Long AS path 100 300 received from 10.0.45.4: More than configured MAXAS-LIMIT
And this is the route as expected:
R5(config-router)#do sir 3.3.3.3
Routing entry for 3.3.3.3/32
Known via "ospf 1", distance 110, metric 21, type intra area
Last update from 10.0.35.3 on Serial1/1, 00:08:50 ago
Routing Descriptor Blocks:
* 10.0.35.3, from 10.0.35.3, 00:08:50 ago, via Serial1/1
Route metric is 21, traffic share count is 1
As many trainers say: "CCIE is not best-practices".
HTH
BGP dmzlink-bw
29/01/11 17:52
BGP dmzlink-bw permits to load-balance outgoing traffic through different eBGP links.
In the following topology, R2-R3 and R4-R5 are eBGP peers. We want to balance traffic from R1 to prefix 10.0.35/0 through the two external links and based on the bandwidth of the two links.
So if R2-R3 link has ten times bw than R4/R5 link we take that in consideration when balancing.
The basic configuration of peering is simple, let's look only the dmzlink-bw part;
1) neighbor x.x.x.x dmzlink-bw to eBGP peers
On R2 and R4 we declare neighbors R3 and R5 as dmzlink-bw:
R2(config)#router bgp 100
R2(config-router)#neighbor 10.0.23.3 dmzlink-bw
R4(config)#router bgp 100
R4(config-router)#neighbor 10.0.45.5 dmzlink-bw
2) Community
Since dmzlink-bw information is sent via a community, make sure we send communities to R1 from both R2 and R4:
neighbor IBGP send-community both
3) enable dmzlink-bw and iBGP multipath on R1:
R1(config)#router bgp 100
R1(config-router)#bgp dmzlink-bw
R1(config-router)#maximum-paths ibgp 2
The output on R1 shows that traffic is equally load balanced between the two available links:
Routing entry for 10.0.35.0/24
Known via "bgp 100", distance 200, metric 0
Tag 200, type internal
Last update from 10.0.23.3 00:01:06 ago
Routing Descriptor Blocks:
* 10.0.45.5, from 4.4.4.4, 00:01:06 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 200
10.0.23.3, from 2.2.2.2, 00:01:06 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 200
What happens if we set R2-R3 bandwidth ten times bigger than R4-R5?
R2(config)#inte s1/1
R2(config-if)#ban
R2(config-if)#bandwidth 100000
R4(config)#inte s1/1
R4(config-if)#bana
R4(config-if)#band
R4(config-if)#bandwidth 10000
Check again the output on R1:
Routing entry for 10.0.35.0/24
Known via "bgp 100", distance 200, metric 0
Tag 200, type internal
Last update from 10.0.23.3 00:00:46 ago
Routing Descriptor Blocks:
* 10.0.45.5, from 4.4.4.4, 00:00:46 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 200
10.0.23.3, from 2.2.2.2, 00:00:46 ago
Route metric is 0, traffic share count is 10
AS Hops 1
Route tag 200
Now traffic should be load balanced taking in consideration the link bandwidth.
Verification:
R1#ping 10.0.35.1 repeat 10 timeout 1
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 10.0.35.1, timeout is 1 seconds:
*Mar 1 01:51:27.307: %SYS-5-CONFIG_I: Configured from console by console.
*Mar 1 01:51:28.935: IP: tableid=0, s=10.0.12.1 (local), d=10.0.35.1 (Serial1/0), routed via RIB
*Mar 1 01:51:28.939: IP: s=10.0.12.1 (local), d=10.0.35.1 (Serial1/0), len 100, sending
*Mar 1 01:51:29.935: IP: tableid=0, s=10.0.12.1 (local), d=10.0.35.1 (Serial1/0), routed via RIB
*Mar 1 01:51:29.935: IP: s=10.0.12.1 (local), d=10.0.35.1 (Serial1/0), len 100, sending..
*Mar 1 01:51:30.935: IP: tableid=0, s=10.0.14.1 (local), d=10.0.35.1 (Serial1/1), routed via RIB
*Mar 1 01:51:30.935: IP: s=10.0.14.1 (local), d=10.0.35.1 (Serial1/1), len 100, sending
*Mar 1 01:51:31.935: IP: tableid=0, s=10.0.12.1 (local), d=10.0.35.1 (Serial1/0), routed via RIB
*Mar 1 01:51:31.935: IP: s=10.0.12.1 (local), d=10.0.35.1 (Serial1/0), len 100, sending..
*Mar 1 01:51:32.935: IP: tableid=0, s=10.0.12.1 (local), d=10.0.35.1 (Serial1/0), routed via RIB
*Mar 1 01:51:32.935: IP: s=10.0.12.1 (local), d=10.0.35.1 (Serial1/0), len 100, sending
*Mar 1 01:51:33.935: IP: tableid=0, s=10.0.12.1 (local), d=10.0.35.1 (Serial1/0), routed via RIB
*Mar 1 01:51:33.935: IP: s=10.0.12.1 (local), d=10.0.35.1 (Serial1/0), len 100, sending..
*Mar 1 01:51:34.935: IP: tableid=0, s=10.0.12.1 (local), d=10.0.35.1 (Serial1/0), routed via RIB
*Mar 1 01:51:34.935: IP: s=10.0.12.1 (local), d=10.0.35.1 (Serial1/0), len 100, sending
*Mar 1 01:51:35.935: IP: tableid=0, s=10.0.12.1 (local), d=10.0.35.1 (Serial1/0), routed via RIB
*Mar 1 01:51:35.935: IP: s=10.0.12.1 (local), d=10.0.35.1 (Serial1/0), len 100, sending..
*Mar 1 01:51:36.935: IP: tableid=0, s=10.0.12.1 (local), d=10.0.35.1 (Serial1/0), routed via RIB
*Mar 1 01:51:36.935: IP: s=10.0.12.1 (local), d=10.0.35.1 (Serial1/0), len 100, sending
*Mar 1 01:51:37.935: IP: tableid=0, s=10.0.12.1 (local), d=10.0.35.1 (Serial1/0), routed via RIB
*Mar 1 01:51:37.935: IP: s=10.0.12.1 (local), d=10.0.35.1 (Serial1/0), len 100, sending.
Success rate is 0 percent (0/10)
Great! One ping every ten goes through R4 since it has 1/10 the bw of R3 for that prefix.
Note: this proportion can be broken if interface bw is changed, for example for a QoS task later of the lab.
TIP: if CEF is enabled traffic is not load-balanced since it keeps coherence on the traffic flow. Disable it to get an output like the one above:
R1(config)#no ip cef
Another option is to modify the load sharing on the interface, setting per-packet.
R1(config-if)#ip load-sharing ?
per-destination Deterministic distribution
per-packet Random distribution
Disabling CEF can be a wrong choice, it's needed for many functions of the router, first of all MPLS.
SoO and EIGRP
29/12/10 19:39
Eigrp SoO can be quite difficult to understand, a great INE post HERE can explain some concepts.
Here's a summary for self-reference:
- set SoO extended community on PE routers interfaces towards CE
route-map SOO
set extcomm soo 100:1
inte f0/0
ip vrf sitemap SOO
- verify in EIGRP topology:
R2#sh ip eigrp topology 3.3.3.3/32
IP-EIGRP (AS 10): Topology entry for 3.3.3.3/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 409600
Routing Descriptor Blocks:
10.0.23.3 (FastEthernet0/1), from 10.0.23.3, Send flag is 0x0
Composite metric is (409600/128256), Route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 6000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
10.0.25.5 (FastEthernet0/0), from 10.0.25.5, Send flag is 0x0
Composite metric is (435200/409600), Route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 7000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Extended Community: SoO:4:4
- If required apply the sitemap on CE to CE link (can cause issues, check the post)
BGP local-as
24/12/10 17:05
A quick review of bgp local-as command. This is the topology:
R1 in AS100 expects R2 to be in AS202.
On R1 we get a BGP notification message:
*Mar 1 00:22:30.603: %BGP-3-NOTIFICATION: sent to neighbor 10.0.12.2 2/2 (peer in wrong AS) 2 bytes 00C8
Remember, notification message in BGP alway means something bad is happening. The error message contains the expected AS. hex 00C8 means 200 in decimal.
So how do we fix it?
R2(config-router)#neighbor 10.0.12.1 local-as 202
R1: *Mar 1 00:25:32.743: %BGP-5-ADJCHANGE: neighbor 10.0.12.2 Up
Fine! Let's set next-hop-self on R2 and advertise in BGP the loobpacks of the routers.
R2(config-router)#nei 10.0.23.3 next-hop-self
R2(config-router)#nei 10.0.12.1 next-hop-self
Now we check how locas-as command works on BGP.
****** R1
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
*> 2.2.2.2/32 10.0.12.2 0 0 202 200 i
*> 3.3.3.3/32 10.0.12.2 0 202 200 300 i
On R1 prefixes coming from R2 have AS202 prepended.
***** R2
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 10.0.12.1 0 0 202 100 i
*> 2.2.2.2/32 0.0.0.0 0 32768 i
*> 3.3.3.3/32 10.0.23.3 0 0 300 i
On R2 prefixes coming from R1 have AS202 prepended too.
***** R3
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 10.0.23.2 0 200 202 100 i
*> 2.2.2.2/32 10.0.23.2 0 0 200 i
*> 3.3.3.3/32 0.0.0.0 0 32768 i
On R3 we can see that AS202 is prepended only for prefixes coming from AS100 (1.1.1.1/32), not for prefixes originated by R2 (2.2.2.2/32).
So BGP behaves as if a "ghost" AS 202 is inserted between R1 and R2: AS 100 -- AS 202 -- AS 200 -- AS 300
***** NO-PREPEND *****
Now we insert the "no-prepend" option on R2 to check how the output changes:
R2(config-router)# neighbor 10.0.12.1 local-as 202 no-prepend
***** R1
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
*> 2.2.2.2/32 10.0.12.2 0 0 202 200 i
*> 3.3.3.3/32 10.0.12.2 0 202 200 300 i
Nothing changed on R1
***** R2
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 10.0.12.1 0 0 100 i
*> 2.2.2.2/32 0.0.0.0 0 32768 i
*> 3.3.3.3/32 10.0.23.3 0 0 300 i
On R2 there's no more AS202 on the as-path of prefixes coming from AS 100.
***** R3
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 10.0.23.2 0 200 100 i
*> 2.2.2.2/32 10.0.23.2 0 0 200 i
*> 3.3.3.3/32 0.0.0.0 0 32768 i
Neither on R3 we can see AS 202.
Based on the output the "no-prepend" option hides AS 202 for every prefix except for the ones sent to R1. The "ghost as" AS 202 is seen only by R1.
***** REPLACE-AS
We have another option on the command: "replace-as", let's see how it works:
R2(config-router)# neighbor 10.0.12.1 local-as 202 no-prepend replace-as
***** R1
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
*> 2.2.2.2/32 10.0.12.2 0 0 202 i
*> 3.3.3.3/32 10.0.12.2 0 202 300 i
On R1 we can see no more AS 200 in prefixes coming from R2, only AS 202 is there.
So the "ghost as" is still there and the real AS is gone. From R1's point of view the logical topology would be: AS 100 -- AS 202 -- AS 300
***** R2
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 10.0.12.1 0 0 100 i
*> 2.2.2.2/32 0.0.0.0 0 32768 i
*> 3.3.3.3/32 10.0.23.3 0 0 300 i
Nothing changes on R2.
***** R3
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 10.0.23.2 0 200 100 i
*> 2.2.2.2/32 10.0.23.2 0 0 200 i
*> 3.3.3.3/32 0.0.0.0 0 32768 i
Nothing changed on R3.
R1 is the only one that knows about the existence of AS 202.
***** DUAL-AS
The last option of the command is "dual-as". This command enables R2 to answer as connections to both AS200 and AS202, it became double-face!
How do we check it? Fire-up OSPF on R1 and R2, on loopbacks too, peer loopbacks on AS 100 and AS 200:
Remember to enable ebgp-multihop, tune ttl-security or disable-connected-check on both R1 and R2 since we're peering eBGP between not-connected interfaces.
***** R1
On R1 we have two peering sessions towards R2, one for AS 200 and one for AS 202:
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 200 7 13 30 0 0 00:01:59 2
10.0.12.2 4 202 84 83 30 0 0 00:19:52 2
We can see that R1 can reach prefixes advertised by R2 with two paths:
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
* 2.2.2.2/32 2.2.2.2 0 0 200 i
*> 10.0.12.2 0 0 202 i
* 3.3.3.3/32 2.2.2.2 0 200 300 i
*> 10.0.12.2 0 202 300 i
If you enabled debugs you'll see some messages about routing loops and denied paths:
*Mar 1 01:11:50.747: RT: recursion error routing 2.2.2.2 - probable routing loop
*Mar 1 01:13:18.431: BGP(0): 2.2.2.2 rcv UPDATE about 1.1.1.1/32 -- DENIED due to: AS-PATH contains our own AS;
Just for fun let's fix the routing loop. The easiest way is to set OSPF distance to a value below eBGP, 19 should be good. On both R1 and R2 we set:
R1(config)#router ospf 1
R1(config-router)#distance 19
Done!
How to remember BGP attributes
08/05/10 18:18
“We Love Oranges AS Oranges Mean Pure Refreshment”
W Weight (Highest)
L Local_Pref (Highest)
O Originated (local originate)
AS As_Path (shortest)
O Origin Code (IGP < EGP < Incomplete)
M MED (lowest)
P Paths (External Paths preferred Over Internal)
R Router ID (lowest)
Thanks to Rene Molenaar
LINK