EBGP Default Reject Policy
This chapter describes EBGP Default Reject Policy.
Topics in this chapter include:
Applicability
The information and MD-CLI configuration in this chapter are based on SR OS Release 20.7.R2. The eBGP default reject policy is supported in SR OS Release 19.5.R1 and later.
Overview
To improve security and reliability of Internet routing in the base router and in VPRN routing instances, a default eBGP reject policy rejects all BGP routes when no import or export policies are configured. This policy prevents accidental route leaks. In MD-CLI, the implicit ebgp-default-reject-policy is used by default for import and export, which is compliant with RFC 8212, Default External BGP (EBGP) Route Propagation Behavior without Policies.
The ebgp-default-reject-policy command can be configured in the general bgp context, in the BGP group context, and in the BGP neighbor context. It can be enabled for import direction only, for export direction only, or for both directions. The syntax of the command is as follows:
[ex:configure router "Base" bgp group "eBGP"]
A:admin@PE-2# ebgp-default-reject-policy
ebgp-default-reject-policy
export - Enable default reject export policy for external peers
import - Enable default reject import policy for external peers
The eBGP default reject policy is the last policy in a policy chain.
In MD-CLI, the default behavior is compliant with RFC 8212 (ebgp-default-reject-policy import/export true). However, when BGP was initially configured in classic CLI and afterward converted to MD-CLI, the insecure behavior remains for backward compatibility (ebgp-default-reject-policy import/export false).
Configuration
Example topology shows the example topology with three nodes. An eBGP session is established between PE-1 and PE-2; an iBGP session between PE-2 and PE-3.
The initial configuration includes:
-
Cards, MDAs, ports
-
Router interfaces
-
SR-ISIS on PE-2 and PE-3 in AS 64500
On PE-1, BGP is configured as follows:
# on PE-1:
configure {
router "Base" {
autonomous-system 64501
bgp {
split-horizon true
group "eBGP" {
peer-as 64500
local-as {
as-number 64501
}
}
neighbor "192.168.12.2" {
group "eBGP"
family {
ipv4 true
ipv6 true
label-ipv4 true
label-ipv6 true
}
export {
policy ["export-10.1" "export-10.2" "export-10.131" "export-10.132"]
}
}
}
On PE-2, BGP is configured as follows:
# on PE-2:
configure {
router "Base" {
autonomous-system 64500
bgp {
split-horizon true
next-hop-resolution {
labeled-routes {
transport-tunnel {
family label-ipv4 {
resolution-filter {
ldp false
sr-isis true
}
}
}
}
}
group "eBGP" {
peer-as 64501
local-as {
as-number 64500
}
}
group "iBGP-IPv4" {
peer-as 64500
family {
ipv4 true
label-ipv4 true
}
}
group "iBGP-IPv6" {
peer-as 64500
family {
ipv6 true
label-ipv6 true
}
}
neighbor "192.0.2.3" {
group "iBGP-IPv4"
next-hop-self true
}
neighbor "192.168.12.1" {
group "eBGP"
family {
ipv4 true
ipv6 true
label-ipv4 true
label-ipv6 true
}
export {
policy ["export-bgp"]
}
}
neighbor "2001:db8::2:3" {
group "iBGP-IPv6"
next-hop-self true
}
}
Advertised BGP and BGP-LU IPv4 routes and Advertised BGP and BGP-LU IPv6 routes show the advertised BGP and BGP Labeled Unicast (BGP-LU) routes between PE-1 and PE-2:
In this example, an export policy is configured toward eBGP peer 192.168.12.1 on PE-2:
[]
A:admin@PE-2# show router bgp neighbor 192.168.12.1 | match "Export Policy"
Export Policy : export-bgp
By default, in MD-CLI, the eBGP default reject policy is used. When no eBGP import-policy is configured on PE-2, any route received from an eBGP peer is rejected, as follows:
[]
A:admin@PE-2# show router bgp neighbor 192.168.12.1 | match "Import Policy"
Import Policy : None Specified - Default Reject
This behavior only applies to eBGP sessions. For iBGP sessions, the reverse is true and the default behavior is to accept. When no iBGP export-policy is configured on PE-2, any received eBGP route is advertised to the iBGP peer (PE-3 in this example), as follows:
[]
A:admin@PE-2# show router bgp neighbor 192.0.2.3 | match "Export Policy"
Export Policy : None Specified - Default Accept
The BGP default reject policy is implicitly used for import and export. There is no need to configure it explicitly. Both on PE-1 and PE-2, export policies are configured, so the corresponding routes are advertised. However, no import policies are configured, so any route received from an eBGP peer is rejected. The BGP summary on PE-2 shows that for each of the address families, two routes are received from eBGP peer 192.168.12.1, but these routes are rejected:
[]
A:admin@PE-2# show router bgp summary all
===============================================================================
BGP Summary
===============================================================================
Legend : D - Dynamic Neighbor
===============================================================================
Neighbor
Description
ServiceId AS PktRcvd InQ Up/Down State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
-------------------------------------------------------------------------------
192.0.2.3
Def. Instance 64500 7 0 00h01m34s 0/0/0 (IPv4)
12 0 0/0/0 (Lbl-IPv4)
192.168.12.1
Def. Instance 64501 16 0 00h01m55s 2/0/1 (IPv4)
11 0 2/0/1 (IPv6)
2/0/0 (Lbl-IPv4)
2/0/0 (Lbl-IPv6)
2001:db8::2:3
Def. Instance 64500 7 0 00h01m34s 0/0/0 (IPv6)
12 0 0/0/0 (Lbl-IPv6)
-------------------------------------------------------------------------------
The following output shows that the received BGP routes are invalid:
[]
A:admin@PE-2# show router bgp routes
===============================================================================
BGP Router ID:192.0.2.2 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP IPv4 Routes
===============================================================================
Flag Network LocalPref MED
Nexthop (Router) Path-Id IGP Cost
As-Path Label
-------------------------------------------------------------------------------
i 10.1.0.1/32 None None
192.168.12.1 None 0
64501 -
i 10.131.0.1/32 None None
192.168.12.1 None 0
64501 -
-------------------------------------------------------------------------------
Routes : 2
===============================================================================
The status of the IPv6, BGP-LU IPv4, and BGP-LU IPv6 routes is the same. The flags for the received routes for the different address families include the ‛Rejected’ flag:
[]A:admin@PE-2# show router bgp routes hunt | match Flags
Flags : Invalid IGP Rejected
Flags : Invalid IGP Rejected
[]
A:admin@PE-2# show router bgp routes ipv6 hunt | match Flags
Flags : Invalid IGP Rejected
Flags : Invalid IGP Rejected
[]
A:admin@PE-2# show router bgp routes label-ipv4 hunt | match Flags
Flags : Invalid IGP Rejected
Flags : Invalid IGP Rejected
[]
A:admin@PE-2# show router bgp routes label-ipv6 hunt | match Flags
Flags : Invalid IGP Rejected
Flags : Invalid IGP Rejected
Import policy
When an import policy is configured, it is possible that some of these routes are accepted. The following import policy on PE-2 accepts incoming routes with communities "1:1" or "2:2":
# on PE-2:
configure {
policy-options {
community "1:1" {
member "1:1" { }
}
community "2:2" {
member "2:2" { }
}
policy-statement "import-1:1-2:2" {
entry 10 {
from {
community {
name "1:1"
}
}
action {
action-type accept
}
}
entry 20 {
from {
community {
name "2:2"
}
}
action {
action-type accept
}
}
}
}
router "Base" {
bgp {
group "eBGP" {
peer-as 64501
local-as {
as-number 64500
}
import {
policy ["import-1:1-2:2"]
}
}
}
PE-2 accepts BGP route 10.1.0.1/32 with community "1:1", but it rejects route 10.131.0.1/32 because this route has no communities:
[]
A:admin@PE-2# show router bgp routes
===============================================================================
BGP Router ID:192.0.2.2 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP IPv4 Routes
===============================================================================
Flag Network LocalPref MED
Nexthop (Router) Path-Id IGP Cost
As-Path Label
-------------------------------------------------------------------------------
u*>i 10.1.0.1/32 None None
192.168.12.1 None 0
64501 -
i 10.131.0.1/32 None None
192.168.12.1 None 0
64501 -
-------------------------------------------------------------------------------
Routes : 2
===============================================================================
The BGP summary on PE-2 shows that one route is accepted and one route is rejected for the IPv4, IPv6, BGP-LU IPv4, and BGP-LU IPv6 address families:
[]
A:admin@PE-2# show router bgp summary all
===============================================================================
BGP Summary
===============================================================================
Legend : D - Dynamic Neighbor
===============================================================================
Neighbor
Description
ServiceId AS PktRcvd InQ Up/Down State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
-------------------------------------------------------------------------------
192.0.2.3
Def. Instance 64500 81 0 00h38m35s 0/0/1 (IPv4)
94 0 0/0/1 (Lbl-IPv4)
192.168.12.1
Def. Instance 64501 90 0 00h38m56s 2/1/1 (IPv4)
85 0 2/1/1 (IPv6)
2/1/0 (Lbl-IPv4)
2/1/0 (Lbl-IPv6)
2001:db8::2:3
Def. Instance 64500 81 0 00h38m35s 0/0/1 (IPv6)
96 0 0/0/1 (Lbl-IPv6)
-------------------------------------------------------------------------------
The following shows that the routes with communities "1:1" or "2:2" are accepted while the other routes are rejected. For each of the address families, there are two routes in the RIB-IN: a first one with community "1:1" or "2:2" (with flags "Used Valid Best IGP") and second one with "No community members" (with flags "Invalid IGP Rejected"), as follows:
[]
A:admin@PE-2# show router bgp routes hunt | match expression "Comm|Flags"
Community : 1:1
Flags : Used Valid Best IGP
Community : No Community Members
Flags : Invalid IGP Rejected
Community : 1:1 # RIB-OUT
Community : No Community Members # RIB-OUT (172.31.0.1/32)
[]
A:admin@PE-2# show router bgp routes ipv6 hunt | match expression "Comm|Flags"
Community : 1:1
Flags : Used Valid Best IGP
Community : No Community Members
Flags : Invalid IGP Rejected
Community : 1:1 # RIB-OUT
Community : No Community Members # RIB-OUT (172.31.0.1/32)
[]
A:admin@PE-2# show router bgp routes label-ipv4 hunt | match expression "Comm|Flags"
Community : 2:2
Flags : Used Valid Best IGP
Community : No Community Members
Flags : Invalid IGP Rejected
Community : 2:2 # RIB-OUT
[]
A:admin@PE-2# show router bgp routes label-ipv6 hunt | match expression "Comm|Flags"
Community : 2:2
Flags : Used Valid Best IGP
Community : No Community Members
Flags : Invalid IGP Rejected
Community : 2:2 # RIB-OUT
Conclusion
The eBGP default reject policy is used to improve the security and reliability of Internet routing. The eBGP default reject policy can be combined with other policies and is always evaluated last in the list of policies.