Let’s have the following scenario:
R4/AS65004 is the source for networks 192.168.41-45.0/24, where
R5 is just binding between R2 and R3. Now the current situation is where
everyone advertises all the networks to everyone…
R5 is also doing prepending toward R2 as part of AS65005
policy.
The result:
-
R1 learns the following networks
directly from R4
-
R3 learns the following networks
directly from R4
-
R2 learns the following networks
from R1
R2#sh ip bgp
BGP table
version is 34, local router ID is 10.1.123.2
Status codes:
s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes:
i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 192.168.41.0 10.1.25.5 0 65005 65005
65003 65004 i
*> 10.1.12.1 0 65001 65004 i
* 192.168.42.0 10.1.25.5 0 65005 65005
65003 65004 i
*> 10.1.12.1 0 65001 65004 i
* 192.168.43.0 10.1.25.5 0 65005 65005
65003 65004 i
*> 10.1.12.1 0 65001 65004 i
*>
192.168.44.0 10.1.25.5 0 65005 65005
65003 65004 i
*>
192.168.45.0 10.1.25.5 0 65005 65005
65003 65004 i
|
R2#sh ip bgp
BGP table
version is 42, local router ID is 10.1.123.2
Status codes:
s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes:
i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>
192.168.41.0 10.1.12.1 0 65001 65003
65004 i
* 10.1.25.5 0 65005 65005
65003 65004 i
*>
192.168.42.0 10.1.12.1 0 65001 65003
65004 i
* 10.1.25.5 0 65005 65005
65003 65004 i
*>
192.168.43.0 10.1.12.1 0 65001 65003
65004 i
* 10.1.25.5 0 65005 65005
65003 65004 i
*> 192.168.44.0 10.1.12.1 0 65001 65003
65004 i
* 10.1.25.5 0 65005 65005
65003 65004 i
*>
192.168.45.0 10.1.12.1 0 65001 65003
65004 i
* 10.1.25.5 0 65005 65005
65003 65004 i
|
R1 can’t control other AS’s BGP policy and AS65001 must
learn AS65004 networks in order to be able to reach them.
So here is a very simple solution: R1 will mark each BGP
peer learned prefixes with special extended community and will avoid advertising
prefixes learned from one peer to the other.
First configure the extended community:
ip extcommunity-list
2 permit rt 222:222
ip
extcommunity-list 3 permit rt 333:333
|
route-map
R2_OUTBOUND deny 10
match extcommunity 3
route-map
R2_OUTBOUND permit 20
!
route-map R3_OUTBOUND
deny 10
match extcommunity 2
route-map R3_OUTBOUND
permit 20
|
And inbound route-map, for each peer:
route-map R2_INBOUND
permit 10
set extcommunity rt 222:222
!
route-map R3_INBOUND
permit 10
set extcommunity rt 333:333
|
Finally apply these route-maps to each peer:
Router bgp
65001
neighbor
10.1.12.2 route-map R2_INBOUND in
neighbor
10.1.12.2 route-map R2_OUTBOUND out
neighbor
10.1.13.3 route-map R3_INBOUND in
neighbor
10.1.13.3 route-map R3_OUTBOUND out
|
R1 will mark R2 and R3 learned prefixes in extended community
rt 222:222 and 333:333 respectively and will deny advertise them based on the opposite
extcommunity.
The result:
R2#sh ip bgp
BGP table
version is 47, local router ID is 10.1.123.2
Status codes:
s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes:
i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>
192.168.41.0 10.1.25.5 0 65005 65005
65003 65004 i
*>
192.168.42.0 10.1.25.5 0 65005 65005
65003 65004 i
*>
192.168.43.0 10.1.25.5 0 65005 65005
65003 65004 i
*>
192.168.44.0 10.1.25.5 0 65005 65005
65003 65004 i
*> 192.168.45.0 10.1.25.5 0 65005 65005
65003 65004 i
|
Although R1 can’t control R5 policy he can avoid being
transit in case of failure of directly peer.
Marking peer prefixes with extcommunity can help for many
route manipulations and policies and provide better control.
No comments:
Post a Comment