10 mins read
BGP – Inter-AS Option A
1. Intro
BGP Option A is one of the methods for implementing Inter-AS MPLS L3VPNs (VPNs spanning multiple Autonomous Systems). It is the simplest and most isolated of the three common options (A, B, and C).
Find next the Test Topology :
Our aim is to advertise the 192.45.6.1/32 prefix all the way to R7. To achieve this we will just configure back to back VRFs as follows.
2. Basic Config
### R4 Configuration:
set routing-instances Cust-A instance-type vrf
set routing-instances Cust-A protocols bgp group CustA-Option-A type external
set routing-instances Cust-A protocols bgp group CustA-Option-A family inet unicast
set routing-instances Cust-A protocols bgp group CustA-Option-A peer-as 200
set routing-instances Cust-A protocols bgp group CustA-Option-A neighbor 17.8.3.2
set routing-instances Cust-A interface ge-0/0/2.0
set routing-instances Cust-A interface lo0.456
set routing-instances Cust-A route-distinguisher 64512:1
set routing-instances Cust-A vrf-target import target:64512:456
set routing-instances Cust-A vrf-target export target:64512:456
set routing-instances Cust-A vrf-table-label
### R5 Configuration:
set routing-instances Cust-A instance-type vrf
set routing-instances Cust-A protocols bgp group CustA-Option-A type external
set routing-instances Cust-A protocols bgp group CustA-Option-A family inet unicast
set routing-instances Cust-A protocols bgp group CustA-Option-A peer-as 100
set routing-instances Cust-A protocols bgp group CustA-Option-A neighbor 17.8.3.1
set routing-instances Cust-A interface ge-0/0/1.0
set routing-instances Cust-A interface lo0.444
set routing-instances Cust-A route-distinguisher 64512:1
set routing-instances Cust-A vrf-target import target:64512:444
set routing-instances Cust-A vrf-target export target:64512:444
set routing-instances Cust-A vrf-table-labelThis is enough to get the prefix to R7.
### R4 is receiving the prefix from R1
root@R4# run show route table Cust-A.inet 192.45.6.1/32 detail
Cust-A.inet.0: 5 destinations, 5 routes (5 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: 0x7bbef84
Next-hop reference count: 3, key opaque handle: 0x0, non-key opaque handle: 0x0
Kernel Table Id: 0
Source: 17.0.0.1
Next hop type: Router, Next hop index: 663
Next hop: 17.8.11.1 via ge-0/0/4.0, selected
Label operation: Push 16, Push 299808(top)
Label TTL action: prop-ttl, prop-ttl(top)
Load balance label: Label 16: None; Label 299808: None;
Label element ptr: 0x9f5eb90
Label parent element ptr: 0x9f5ebe0
Label element references: 1
Label element child references: 0
Label element lsp id: 0
Session Id: 140
Protocol next hop: 17.0.0.1
Label operation: Push 16
Label TTL action: prop-ttl
Load balance label: Label 16: None;
Indirect next hop: 0x791d6f0 1048575 INH Session ID: 322
State: <Secondary Active Int Ext ProtectionCand>
Local AS: 100 Peer AS: 100
Age: 2:42:09 Metric2: 2000
Validation State: unverified
Task: BGP_100.17.0.0.1
Announcement bits (2): 0-KRT 1-BGP_RT_Background
AS path: I
Communities: 64512:456 target:64512:456
Import Accepted
VPN Label: 16
Localpref: 100
Router ID: 17.0.0.1
Primary Routing Table: bgp.l3vpn.0
Thread: junos-main
### Via eBGP, R5 will get the prefix from R4, then it will send it to R7:
root@R7> show route table bgp.l3vpn.0 192.45.6.1/32 detail
bgp.l3vpn.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
64512:1:192.45.6.1/32 (1 entry, 0 announced)
*BGP Preference: 170/-101
Route Distinguisher: 64512:1
Next hop type: Indirect, Next hop index: 0
Address: 0x7bbf294
Next-hop reference count: 14, 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: 674
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: 0x9f5af28
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 1048574 INH Session ID: 321
State: <Active Int Ext ProtectionPath ProtectionCand>
Local AS: 200 Peer AS: 200
Age: 1:52:53 Metric2: 2000
Validation State: unverified
Task: BGP_200.17.0.0.5
AS path: 100 I
Communities: 64512:456 target:64512:444 target:64512:456
Import Accepted
VPN Label: 16
Localpref: 100
Router ID: 17.0.0.5
Secondary Tables: Cust-A.inet.0 Cust-RED.inet.0
Thread: junos-main 2. BGP Route Target problem
We see a problem on R7. the prefix from R1 will end up in two different VRFs on R7: Cust-A and Cust-RED:
root@R7> show route table Cust- 192.45.6.1/32 detail
Cust-A.inet.0: 5 destinations, 5 routes (5 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: 0x7bbf294
Next-hop reference count: 14, 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: 674
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: 0x9f5af28
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 1048574 INH Session ID: 321
State: <Secondary Active Int Ext ProtectionCand>
Local AS: 200 Peer AS: 200
Age: 1:50:22 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 target:64512:456
Import Accepted
VPN Label: 16
Localpref: 100
Router ID: 17.0.0.5
Primary Routing Table: bgp.l3vpn.0
Thread: junos-main
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: 0x7bbf294
Next-hop reference count: 14, 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: 674
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: 0x9f5af28
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 1048574 INH Session ID: 321
State: <Secondary Active Int Ext ProtectionCand>
Local AS: 200 Peer AS: 200
Age: 1:50:22 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 target:64512:456
Import Accepted
VPN Label: 16
Localpref: 100
Router ID: 17.0.0.5
Primary Routing Table: bgp.l3vpn.0
Thread: junos-main
### This is the R7 config for Cust-RED:
root@R7> show configuration | display set | match Cust-RED
set routing-instances Cust-RED instance-type vrf
set routing-instances Cust-RED interface lo0.22
set routing-instances Cust-RED route-distinguisher 64512:456
set routing-instances Cust-RED vrf-target import target:64512:456
set routing-instances Cust-RED vrf-target export target:64512:456
set routing-instances Cust-RED vrf-table-labelOften times, the Inter-AS Option A interconnect is configured between two MPLS domains under a different administration. Most likely the two domains will not have consistent Router target assignments, hence we can have overlapping problems with the assigned Route Targets that by default will pass from one side to the other.
In our example, we have the following assignments:
- Service Provider 1: Cust-A -> target:64512:456
- Service Provider 2: Cust-A -> target:64512:444
- Service Provider 2: Cust-RED -> target:64512:456
Service Provider 1 is using target:64512:456 for Cust-A, whereas Service Provider 2 is using the same for Cust-RED.
As per configuration above, R1 will add the 64512:456 and target:64512:456 communities, and R5 will add target:64512:444.
This is how R7 get’s the prefix with two route target communities. The solution is to remove all BGP communies on the Inter-AS Option A interconnect.
3. Remove BGP communities
To remove all communities, we will use community CM-ALL members *:*:
### Remove All Route Target communities:
root@R4# show | compare
[edit policy-options]
+ policy-statement CustA-BGP-EXPORT {
+ then {
+ community delete CM-ALL;
+ accept;
+ }
+ }
[edit policy-options]
+ community CM-ALL members *:*;
[edit routing-instances Cust-A protocols bgp group CustA-Option-A]
+ export CustA-BGP-EXPORT;
[edit]
root@R4# commit
commit complete
### Now, only Cust-A VRF will get the prefix:
root@R7> show route 192.45.6.1/32
Cust-A.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.45.6.1/32 *[BGP/170] 00:00:11, localpref 100, from 17.0.0.5
AS path: 100 I, validation-state: unverified
> to 17.8.14.1 via ge-0/0/2.0, Push 16, Push 299792(top)
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:00:11, localpref 100, from 17.0.0.5
AS path: 100 I, validation-state: unverified
> to 17.8.14.1 via ge-0/0/2.0, Push 16, Push 299792(top)
root@R7> show route 192.45.6.1/32 table bgp detail
bgp.l3vpn.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
64512:1:192.45.6.1/32 (1 entry, 0 announced)
*BGP Preference: 170/-101
Route Distinguisher: 64512:1
Next hop type: Indirect, Next hop index: 0
Address: 0x7bbf294
Next-hop reference count: 12, 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: 674
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: 0x9f5af28
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 1048574 INH Session ID: 321
State: <Active Int Ext ProtectionPath ProtectionCand>
Local AS: 200 Peer AS: 200
Age: 1:28 Metric2: 2000
Validation State: unverified
Task: BGP_200.17.0.0.5
AS path: 100 I
Communities: target:64512:444
Import Accepted
VPN Label: 16
Localpref: 100
Router ID: 17.0.0.5
Secondary Tables: Cust-A.inet.0
Thread: junos-main
BGP community wildcard “*:*” wildcard delete both Standard and Route Target communities.
Let’s assume we only want to remove all Route Target communities, but keep the Standard Community. In this case we will use the “target:*:*” wildcard:
### Use the 'target:*:*' wildcard to remove only the Route Target:
root@R4# show | compare
[edit policy-options policy-statement CustA-BGP-EXPORT then]
+ community delete CM-ALL-RT;
- community delete CM-ALL;
[edit policy-options]
+ community CM-ALL-RT members target:*:*;
[edit]
root@R4# commit
commit complete
### We have the original Standard community, but the Route Target was removed:
root@R7> show route 192.45.6.1/32 table bgp detail | match Communities:
Communities: 64512:456 target:64512:444For completeness, if we want to remove all the standard communities, but keep the Route Targets, then the wildcard is “^[0-9]+:*“
### Use the '^[0-9]+:*' wildcard to remove only the Standard Communities:
root@R4# show | compare
[edit policy-options policy-statement CustA-BGP-EXPORT then]
+ community delete CM-ALL-STANDARD;
- community delete CM-ALL-RT;
[edit policy-options]
+ community CM-ALL-STANDARD members "^[0-9]+:*";
[edit]
root@R4# commit
commit complete
### We have the original Route Target community, but the Standard community was removed:
root@R7> show route 192.45.6.1/32 table bgp detail | match Communities:
Communities: target:64512:444 target:64512:456Note: We encounter this problem with BGP communities only when we are using BGP between the two AS domains. You will not have this problem when using static routing or some IGP.
External Resources: