Configuring SOO for eBGP
Hi there,
I noticed that there is two methods of configuring SOO for eBGP.
1) using route-map and apply under neighbor command.
2) using route-map and apply under interfae by using command ip vrf sitemap
Is there any circumstances of the types of topology that need to be aware of before applying these two methods?
Thanks in advance.
maher
Comments
Normally option #2 is used for SP networks.
Hello mate
Here is my uderstanding:
If the PE-CE routig protocol is BGP we configure SOO by neighbor command (neighbor x.x.x.x soo 65000:12 ). But if the PE-CE routing protocol is non BGP (i.e. RIP etc) we configure SOO under vrf interface (i.e. interface connected to CE) by ip vrf sitemap command.
So in case of eBGP I tend to use option 1.
This is a good document for BGP SOO implementation:
http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/htbgpsoo.html
regards
Testing also shows that BGP will not use 'ip vrf sitemap SOO', meaning you have to use BGP neighbour route-map.
1) using route-map and apply under neighbor command. - use for PE-CE eBGP
2) using route-map and apply under interfae by using command ip vrf sitemap - use for PE-CE EIGRP/RIP (did not test OSPF)
2) will not work for BGP
Jon
Hi,
If the question was to make sure a particular route/network had particular SoO value of X:X in the bgp vpn table for a vrf would the following be a viable solution:
route-map SET_SoO permit 10
set extcommunity soo 12:12
router bgp 12
add ipv4 vrf VRF_SOO
network 1.1.1.1 mask 255.255.255.255 route-map SET_SoO
or would I be better off using the sitemap method and matching a prefix and setting its SoO value to X:X and applying it with "ip vrf sitemap X"
Thanks in advance.
Joe.
Hi mpls-te,
I would use the same solution as yours.
If you have doubts - test it. On the lab you can talk to a proctor, to clarify their expectations.
To be honest I don't remember any example on CCO with ip vrf sitemap for BGP SoO.
Cheers,
Seba
Hi
I have tested ip vrf sitemap for tagging SoO successfully in the same scenario.
regards
Cheers, I tested it too! So I guess its how the question would be interpretted and hopefully the proctor would be able to "guide" us in the right direction!
My testing shows ip vrf sitemap does not apply the soo attribute when the route is learnt via eBGP. I'm using the 12.4(12) IOS IE recommend for their lab workbook.
R7 is a CE dual-homed to R3 and R4 PE's.
R3 Config:
interface Ethernet0/0
ip vrf forwarding ONE
ip vrf sitemap SOO
ip address 1.1.37.3 255.255.255.0
full-duplex
router bgp 1
no synchronization
bgp log-neighbor-changes
neighbor 150.1.2.2 remote-as 1
neighbor 150.1.2.2 update-source Loopback0
neighbor 150.1.4.4 remote-as 1
neighbor 150.1.4.4 update-source Loopback0
no auto-summary
!
address-family vpnv4
neighbor 150.1.2.2 activate
neighbor 150.1.2.2 send-community extended
neighbor 150.1.4.4 activate
neighbor 150.1.4.4 send-community extended
exit-address-family
!
address-family ipv4 vrf ONE
neighbor 1.1.37.7 remote-as 100
neighbor 1.1.37.7 activate
neighbor 1.1.37.7 as-override
no synchronization
exit-address-family
route-map SOO permit 10
set extcommunity soo 100:1
R3 is not tagging R7's loopback (7.7.7.7) with the SOO.
Rack1R4#sh ip bgp vpnv4 all 7.7.7.7
BGP routing table entry for 1:1:7.7.7.7/32, version 31
Paths: (2 available, best #1, table ONE)
Flag: 0x820
Advertised to update-groups:
1
100
150.1.3.3 (metric 66) from 150.1.3.3 (150.1.3.3)
Origin IGP, metric 0, localpref 100, weight 50000, valid, internal, best
Extended Community: RT:1:1
mpls labels in/out nolabel/19
100
1.1.47.7 from 1.1.47.7 (7.7.7.7)
Origin IGP, metric 0, localpref 100, valid, external
Extended Community: RT:1:1
Now I'll configure the route-map to set SOO.
Rack1R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Rack1R3(config)#int e0/0
Rack1R3(config-if)#no ip vrf sitemap SOO
Rack1R3(config-if)#router bgp 1
Rack1R3(config-router)#add
Rack1R3(config-router)#address-family ip
Rack1R3(config-router)#address-family ipv4 v ONE
Rack1R3(config-router-af)#neigh 1.1.37.7 route-map SOO in
Rack1R3(config-router-af)#end
Rack1R3#clear ip b
*Mar 1 00:53:45.119: %SYS-5-CONFIG_I: Configured from console by console
Rack1R3#clear ip bgp * in
Rack1R3#clear ip bgp * out
Rack1R3#
Now R4 sees the SOO attribute on the 7.7.7.7 prefix from R3.
Rack1R4#sh ip bgp vpnv4 all 7.7.7.7
BGP routing table entry for 1:1:7.7.7.7/32, version 32
Paths: (2 available, best #1, table ONE)
Flag: 0xA20
Advertised to update-groups:
1
100
150.1.3.3 (metric 66) from 150.1.3.3 (150.1.3.3)
Origin IGP, metric 0, localpref 100, weight 50000, valid, internal, best
Extended Community: SoO:100:1 RT:1:1
mpls labels in/out nolabel/19
100
1.1.47.7 from 1.1.47.7 (7.7.7.7)
Origin IGP, metric 0, localpref 100, valid, external
Extended Community: RT:1:1
I don't know how you guys are getting this to work with ip vrf sitemap and BGP CE-PE. Maybe it's the IOS release?
One other point about BGP SOO.
The MPLS Fundamentals book states (page 235) that if a PE sees an MP-iBGP prefix with the same SOO as that configured for a local CE it will not insert this prefix into the VRF. My testing shows that the actual behaviour is different to this. Rather the PE will accept the prefix and even insert it into the VRF but it will not advertise it to the eBGP peer that has this SOO set on an inbound route-map.
Is everyone else seeing this behaviour? Should the PE not be injecting the route into the VRF?
Here's an example with the same topology I used above. (R7 CE dual homed to R3 and R4 PE's).
I've configured R4 to prefer R3's routes with the weight command. Otherwise R4 will always prefer the direct eBGP route to R7's loopback and so R4 won't advertise it to R7 no matter if the SOO is set or not.
Without any SOO configured R4 learns the R7 loopback via R3 and R7 (MP-iBGP and eBGP). R4 prefers the R3 path and advertises it to R7.
Rack1R4#sh ip bgp vpnv4 all 7.7.7.7
BGP routing table entry for 1:1:7.7.7.7/32, version 33
Paths: (2 available, best #1, table ONE)
Flag: 0xA00
Advertised to update-groups:
1
100
150.1.3.3 (metric 66) from 150.1.3.3 (150.1.3.3)
Origin IGP, metric 0, localpref 100, weight 50000, valid, internal, best
Extended Community: RT:1:1
mpls labels in/out nolabel/19
100
1.1.47.7 from 1.1.47.7 (7.7.7.7)
Origin IGP, metric 0, localpref 100, valid, external
Extended Community: RT:1:1
Rack1R7#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
* 7.7.7.7/32 1.1.47.4 0 1 1 i
*> 0.0.0.0 0 32768 i
Next I configure the SOO route-maps on the R4 and R3 neighbour statements for R7.
Now R4 still prefers the R3 path but it no longer advertises this to R7.
Rack1R4#sh ip bgp vpnv4 all 7.7.7.7
BGP routing table entry for 1:1:7.7.7.7/32, version 34
Paths: (2 available, best #1, table ONE)
Flag: 0xA00
Not advertised to any peer
100
150.1.3.3 (metric 66) from 150.1.3.3 (150.1.3.3)
Origin IGP, metric 0, localpref 100, weight 50000, valid, internal, best
Extended Community: SoO:100:1 RT:1:1
mpls labels in/out nolabel/19
100
1.1.47.7 from 1.1.47.7 (7.7.7.7)
Origin IGP, metric 0, localpref 100, valid, external
Extended Community: SoO:100:1 RT:1:1
Rack1R7#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 7.7.7.7/32 0.0.0.0 0 32768 i
According to how I understand what is said in MPLS Fundamentals, R4 shouldn't be installing the R3 route in the VRF table. However it is...
Rack1R4#sh ip route vrf ONE 7.7.7.7
Routing entry for 7.7.7.7/32
Known via "bgp 1", distance 200, metric 0
Tag 100, type internal
Last update from 150.1.3.3 00:02:24 ago
Routing Descriptor Blocks:
* 150.1.3.3 (Default-IP-Routing-Table), from 150.1.3.3, 00:02:24 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 100
hey all,
I have a scenario where I have 3 VRFs, say V1, V2, & V3. V1 & V2 are part of AS1 and V3 is part of AS11. I want a particular network LAN range to be assigned a SoO attirbute value of 11:11 when it appears in the other VRF tables (V1 & V2). They are using import/export route-targets to share routes. There is eBGP and MP-eBGP (obviously) between AS1 & AS11. I will lab this up and try both scenario's (vrf sitemap or bgp route-map attached to the network statement). I'll share my results shortly.
Regards,
mpls-te
The Cisco site explains it the way I see it operating, rather than the MPLS Fundamentals way.
"The configuration of SoO values for BGP neighbors is performed on a provider edge (PE) router, which is the VPN entry point. When SoO is enabled, the PE router forwards prefixes to the customer premises equipment (CPE) only when the SoO tag of the prefix does not match the SoO tag configured for the CPE. "
From here http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/htbgpsoo.html
As promised I have labbed this according to my scenario:
With sitemap SOO:
R2#sh ip bgp v v ABC 172.9.66.0
BGP routing table entry for 9:9:172.9.66.0/24, version 9
Paths: (1 available, best #1, table ABC)
Not advertised to any peer
1009, imported path from 1009:9:172.9.66.0/24
9.9.24.4 from 9.9.24.4 (9.9.0.4)
Origin IGP, localpref 100, valid, external, best
Extended Community: SoO:1009:1009 RT:1009:9,
mpls labels in/out nolabel/604
R2#
Configurations (missing the obvious BGP and IGP configurations):
ip vrf ABC
rd 1009:9
route-target export 1009:9
route-target import 1009:9
route-target import 9:9
interface FastEthernet0/0.66
encapsulation dot1Q 66
ip vrf forwarding ABC
ip vrf sitemap SOO
ip address 172.9.66.6 255.255.255.0
!
access-list 10 permit 172.9.66.0
!
route-map SOO permit 10
match ip address 10
set extcommunity soo 1009:1009
Using network statement route-map:
R2#sh ip bgp v v ABC 172.9.66.6
BGP routing table entry for 9:9:172.9.66.0/24, version 58
Paths: (1 available, best #1, table ABC)
Not advertised to any peer
1009, imported path from 1009:9:172.9.66.0/24
9.9.24.4 from 9.9.24.4 (9.9.0.4)
Origin IGP, localpref 100, valid, external, best
Extended Community: RT:1009:9,
mpls labels in/out nolabel/625
R2#
Configurations:
router bgp 1009
!
address-family ipv4 vrf ABC
no auto-summary
no synchronization
network 172.9.66.0 mask 255.255.255.0 route-map SOO
exit-address-family
!
ip classless
!
no ip http server
!
ip bgp-community new-format
!
!
route-map SOO permit 10
set extcommunity soo 1009:1009
As you all can see, using vrf sitemap works for this scenario as apposed to just trying to take a network in the vrf address family.
Hi mpls-te,
What platform and IOS did you use for your tests?
Cheers,
Seba
HI Seba,
I am using 7206VXRs on GNS3 with the 12.2S (c7200-k91p-mz.122-25.S15) as per CCIE SP Lab IOS and hardware specifications.
The config I noted was from a eBGP peer R6 in AS1009 and the output was on R2 in AS9.
Cheers,
mpls-te