BGP – Inter-AS Option B
1. Intro
BGP Option B is an Inter-AS MPLS L3VPN method in which the ASBRs exchange VPNv4/VPNv6 routes directly using MP-eBGP. It provides better scalability than Option A because the ASBRs do not maintain per-customer VRFs.
Find next the our Test Topology :
Our aim is to advertise the 192.45.6.1/32 prefix all the way to R7.
2. Basic Config
### R4 config:
set protocols bgp group Option-B family inet-vpn unicast
set protocols bgp group Option-B peer-as 200
set protocols bgp group Option-B neighbor 17.8.3.2
set interfaces ge-0/0/2 unit 0 family inet address 17.8.3.1/24
set interfaces ge-0/0/2 unit 0 family mpls
set protocols mpls interface ge-0/0/2.0
### R5 Config:
set protocols bgp group Option-B family inet-vpn unicast
set protocols bgp group Option-B peer-as 100
set protocols bgp group Option-B neighbor 17.8.3.1
set interfaces ge-0/0/1 unit 0 family inet address 17.8.3.2/24
set interfaces ge-0/0/1 unit 0 family mpls
set protocols mpls interface ge-0/0/1.0The configuration is straightforward, we have BGP with address family inet-vpn unicast (AFI 1, SAFI 128). Additionally we need to activate mpls on the interface between R4 and R5.
We also need to remember that configuring Cust-A routing instance VRF on R4 and R5 is not needed.
3. BGP l3vpn table
Interesting to highlight that on R4 is receiving the prefix from R1, even if we don’t have any VRF configured on R4.
root@R4# run show route table bgp.l3vpn.0 rd-prefix 64512:1:192.45.6.1/32
bgp.l3vpn.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
64512:1:192.45.6.1/32
*[BGP/170] 00:40:17, localpref 100, from 17.0.0.1
AS path: I, validation-state: unverified
> to 17.8.11.1 via ge-0/0/4.0, Push 16, Push 299808(top)
Typically, R4 should not have any prefix from R1 in the bgp.l3vpn table. By default, R4 will receive that prefix from R1, but it should discard it, because there is no matching Route Target import configured on R4 (no VRF configured on R4).
But, configuring an eBGP session with inet-vpn address family will override this behavior.
To demonstrate this, we will deactivate the Option B BGP session, and we will see the default in action, no more routes in the bgp.l3vpn table.
root@R4# show | compare
[edit protocols bgp]
! inactive: group Option-B { ... }
[edit]
root@R4# commit
commit complete
[edit]
root@R4# run show route table bgp.l3vpn.0
[edit]
root@R4# 4. Next hop self
When we check the prefix on R7, we see that the next hop is Router 5. By default, when the prefix is passing from eBGP to iBGP it should not change the next hop. But in our case this happened automatically, without any configuration.
root@R7> show route table Cust- 192.45.6.1 detail
Cust-RED.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
192.45.6.1/32 (1 entry, 1 announced)
*BGP Preference: 170/-101
Route Distinguisher: 64512:1
Next hop type: Indirect, Next hop index: 0
Address: 0x7bbf3e4
Next-hop reference count: 6, key opaque handle: 0x0, non-key opaque handle: 0x0
Kernel Table Id: 0
Source: 17.0.0.5
Next hop type: Router, Next hop index: 699
Next hop: 17.8.14.1 via ge-0/0/2.0, selected
Label operation: Push 17, Push 299792(top)
Label TTL action: prop-ttl, prop-ttl(top)
Load balance label: Label 17: None; Label 299792: None;
Label element ptr: 0x9f5b1d0
Label parent element ptr: 0x9f5a938
Label element references: 1
Label element child references: 0
Label element lsp id: 0
Session Id: 140
Protocol next hop: 17.0.0.5
Label operation: Push 17
Label TTL action: prop-ttl
Load balance label: Label 17: None;
Indirect next hop: 0x791da20 1048577 INH Session ID: 322
State: <Secondary Active Int Ext ProtectionCand>
Local AS: 200 Peer AS: 200
Age: 4 Metric2: 2000
Validation State: unverified
Task: BGP_200.17.0.0.5
Announcement bits (1): 0-KRT
AS path: 100 I
Communities: 64512:456 target:64512:456
Import Accepted
VPN Label: 17
Localpref: 100
Router ID: 17.0.0.5
Primary Routing Table: bgp.l3vpn.0
Thread: junos-main This is just something specific for inet-vpn address family. The next hop is changed automatically, and this helps the Option B forwarding plane to function correctly:
- R7 to R5 is forwarded using whatever mpls protocol is configured on that MPLS domain (it can be LDP, RSVP or SR)
- R5 to R4 is using the Service label for forwarding
But there is a problem, we can see this prefix in the Cust-RED table instead of Cust-A table. We will fix this in the next section.
5. Route Targets
Our prefix should end up in Cust-A table, but this is not happening because the Route Targets are not matching between the two MPLS domains.
Similar to what we did for BGP Option A, we will apply a routing policy that will delete community target:64512:456 and add the correct one target:64512:444.
### Remove target:64512:456 and add target:64512:444 instead:
root@R5# show | compare
[edit]
+ policy-options {
+ policy-statement Option-B-Import {
+ term Cust-A {
+ from community Cust-A-SP1;
+ then {
+ community delete Cust-A-SP1;
+ community add Cust-A-SP2;
+ accept;
+ }
+ }
+ term DENY {
+ then reject;
+ }
+ }
+ community Cust-A-SP1 members target:64512:456;
+ community Cust-A-SP2 members target:64512:444;
+ }
[edit protocols bgp group OptionB]
+ import Option-B-Import;
[edit]
root@R5# commit
commit complete
### Now the prefix has the correct Route Target and installed in the correct table:
root@R7> show route table Cust- 192.45.6.1 detail
Cust-A.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
192.45.6.1/32 (1 entry, 1 announced)
*BGP Preference: 170/-101
Route Distinguisher: 64512:1
Next hop type: Indirect, Next hop index: 0
Address: 0x7bbf144
Next-hop reference count: 6, key opaque handle: 0x0, non-key opaque handle: 0x0
Kernel Table Id: 0
Source: 17.0.0.5
Next hop type: Router, Next hop index: 698
Next hop: 17.8.14.1 via ge-0/0/2.0, selected
Label operation: Push 16, Push 299792(top)
Label TTL action: prop-ttl, prop-ttl(top)
Load balance label: Label 16: None; Label 299792: None;
Label element ptr: 0x9f5a208
Label parent element ptr: 0x9f5a938
Label element references: 1
Label element child references: 0
Label element lsp id: 0
Session Id: 140
Protocol next hop: 17.0.0.5
Label operation: Push 16
Label TTL action: prop-ttl
Load balance label: Label 16: None;
Indirect next hop: 0x791d888 1048576 INH Session ID: 322
State: <Secondary Active Int Ext ProtectionCand>
Local AS: 200 Peer AS: 200
Age: 2 Metric2: 2000
Validation State: unverified
Task: BGP_200.17.0.0.5
Announcement bits (1): 0-KRT
AS path: 100 I
Communities: 64512:456 target:64512:444
Import Accepted
VPN Label: 16
Localpref: 100
Router ID: 17.0.0.5
Primary Routing Table: bgp.l3vpn.0
Thread: junos-main External Resources: