This is hopefully my next to last blog post on OER. 🙂
Up to this point, OER has influenced outbound traffic selection. 12.4(9)T added the BGP Inbound Optimization feature. OER does this by route withdrawal, AS_PATH prepending and setting communities which allow the neighbor AS to prepend or set local preference based on the community values. The inbound options are more limited as it only supports passive monitoring. OER learns inside prefixes based on what is advertised to eBGP peers from the border routers. This can cause a weird issue after routes have been controlled where you are advertising a route learned from one BR back out to the same AS. Technically, the other AS drops the advertisement, but it still gets reported to the MC as an inside route. It’s best to have the outside routers set no-export community in a route-map to the eBGP peers.
A few lessons (bugs?) I’ve learned in my testing on 12.4(15)T14:
1) Using match [traffic-class | ip address ] prefix-list inside in an oer-map doesn’t work like the documentation shows. When I configured it, the matching routes were put in the external database instead. match oer learn inside works fine.
2) Oer-maps can’t contain both inside and outside sequences. Everything either ends up in the external or internal prefix database, depending on the order you configured them in the oer-map.
Once you have an OER topology up and running, adding BGP inbound optimization is just a few more commands. Most of this is optional, but it was included to show some of the features.
R3CoreMC#conf t
R3CoreMC(config)#oer master
R3CoreMC(config-oer-mc)#border 1.1.1.1
R3CoreMC(config-oer-mc-br)#interface s 0/0 ext
R3CoreMC(config-oer-mc-br-if)#maximum utilization receive percentage 65
R3CoreMC(config-oer-mc-br-if)#border 2.2.2.2
R3CoreMC(config-oer-mc-br)#interface s 0/0 ext
R3CoreMC(config-oer-mc-br-if)#maximum utilization receive percentage 65
R3CoreMC(config-oer-mc-br-if)#oer master
R3CoreMC(config-oer-mc)#max range receive percent 20
R3CoreMC(config-oer-mc)#learn
R3CoreMC(config-oer-mc-learn)#inside bgp
The command to inspect the inside prefix database is slightly different. The control is verified by inspecting the bgp table of the eBGP peers. R1 has prepended AS100 once to the advertisement.
R3CoreMC#show oer master prefix inside
OER Prefix Statistics:
Prefix (inside) State Time Curr BR CurrI/F Protocol
PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos
ActSDly ActLDly ActSUn ActLUn EBw IBw
——————————————————————————–
3.0.0.0/24 INPOLICY 0 2.2.2.2 Se0/0 BGP
104 108 0 0 4752 4763
N N N N 140 45
4.0.0.0/24 INPOLICY* 0 1.1.1.1 Se0/0 U
101 98 0 0 4591 4831
N N N N 142 40R9#show ip bgp 3.0.0.0/24
BGP routing table entry for 3.0.0.0/24, version 27
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
2
100
110.0.0.10 (metric 2) from 119.0.0.1 (101.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 95.0.0.1, Cluster list: 101.1.1.1
100 100
19.0.0.1 from 19.0.0.1 (1.1.1.1)
Origin IGP, localpref 100, valid, external
Another way to influence inbound traffic is by setting a community so the eBGP peers can prepend or set a downgraded local preference.
R1B1#conf t
R1B1(config)#router bgp 100
R1B1(config-router)#neighbor 19.0.0.9 send-community standardR2B2#conf t
R2B2(config)#router bgp 100
R2B2(config-router)#neighbor 210.0.0.10 send-community standardR3CoreMC#conf t
R3CoreMC(config)#oer master
R3CoreMC(config-oer-mc)#border 1.1.1.1
R3CoreMC(config-oer-mc-br)#int s 0/0 e
R3CoreMC(config-oer-mc-br-if)#downgrade bgp community 100:1234
R3CoreMC(config-oer-mc-br-if)#border 2.2.2.2
R3CoreMC(config-oer-mc-br)#int s 0/0 ext
R3CoreMC(config-oer-mc-br-if)#downgrade bgp community 100:1234R3CoreMC#show oer master prefix inside
OER Prefix Statistics:
Prefix (inside) State Time Curr BR CurrI/F Protocol
PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos
ActSDly ActLDly ActSUn ActLUn EBw IBw
——————————————————————————–
3.0.0.0/24 INPOLICY* 0 2.2.2.2 Se0/0 BGP
76 76 0 0 2959 2959
N N N N 168 19
4.0.0.0/24 HOLDDOWN 58 1.1.1.1 Se0/0 BGP
104 102 0 0 4469 4848
N N N N 152 38
AS 200 can now match that community to set a poor local preference or prepend an ASN.
R9#conf t
R9(config)#ip community-list 1 permit 100:1234
R9(config)#route-map DOWNGRADE
R9(config-route-map)#match community 1
R9(config-route-map)#set local-preference 5
R9(config-route-map)#route-map DOWNGRADE permit 20
R9(config)#router bgp 200
R9(config-router)#neighbor 19.0.0.1 route-map DOWNGRADE inR10#conf t
R10(config)#ip community-list 1 permit 100:1234
R10(config)#route-map DOWNGRADE
R10(config-route-map)#match community 1
R10(config-route-map)#set local-preference 5
R10(config-route-map)#route-map DOWNGRADE perm 20
R10(config-route-map)#router bgp 200
R10(config-router)#neighbor 210.0.0.2 route-map DOWNGRADE in
The results are checked on R9. The community is visible and the local preference is set to 5. R9 will use the internal route learned from R10 as the next-hop. Once the downgrade community is configured for a BR’s interface, OER automatically have that BR cease prepending as a means of control.
R9#show ip bgp 4.0.0.0
BGP routing table entry for 4.0.0.0/24, version 30
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Flag: 0x9C0
Advertised to update-groups:
2
100
110.0.0.10 (metric 2) from 119.0.0.1 (101.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 95.0.0.1, Cluster list: 101.1.1.1
100
19.0.0.1 from 19.0.0.1 (1.1.1.1)
Origin IGP, localpref 5, valid, external
Community: 100:1234