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,

    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

     

    I have tested ip vrf sitemap for tagging SoO successfully in the same scenario.

    regards

  • 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

     

    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 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

Sign In or Register to comment.