BGP AllowAS in

The BGP loop-prevention mechanism does not allow a BGP speaker to accept prefixes with the local AS number in the AS_PATH list. However, in some cases, it would be desirable to accept the routes originated in the same AS via another AS.
- The company’s network is partitioned, and every partition connects to the Internet or ISP
- The company connects to an ISP and network becomes segmented due to an emergency. In this case, the prefixes advertised to the ISP must be accepted back by the border peers.


Currently we have multiple paths to learn 3.3.3.0/24 prefix on R2, but due to the loop-prevention mechanism the AS containing same prefix learned having local AS in path are not allowed.


We will configure R2 to allow the prefixes having local AS in path attribute.

R2#show run | s bgp
router bgp 123
 no synchronization
 bgp log-neighbor-changes
 network 2.2.2.0 mask 255.255.255.0
 neighbor 12.1.1.1 remote-as 123
 neighbor 12.1.1.1 next-hop-self
 neighbor 24.1.1.4 remote-as 400
 neighbor 24.1.1.4 send-community
 neighbor 24.1.1.4 allowas-in
 no auto-summary
ip bgp-community new-format

BGP TTL Security

This feature applies to eBGP peering sessions only and specifies the number of hops the remote peer could be away from the local speaker.


R1(config-router)#neighbor 15.1.1.5 ttl-security hops 2

BGP Next-Hop Trigger

This behavior is enabled by default . BGP process registers the NEXT_HOP attribute values with the RIB table watch process. As soon as any change that affects an existing NEXT_HOP occurs, the watch process notifies the BGP router process. If the change results in prefix withdrawn, the BGP process immediately removes the prefix.

The BGP "Rib watcher process" registers all of the next hops reported and will "call back" to BGP whenever there is
- next hop unreachable
- next hop metric change

The 1st one is more important and is reported faster. IGP reports are delayed by default for 5 seconds.

R1(config-router)#bgp nexthop trigger delay 10

BGP Soft Reconfiguration

When a local BGP speaker is configured to apply soft-reconfiguration inbound the speaker will accept ALL prefixes from the remote peer and store them in a separate memory buffer. The prefixes are then processed via the inbound filters and the resulting information imported into Adj-RIB-In and finally to the BGP table. Every time the local policy changes, there is no need to re-establish the peering session but simply apply the filters to the stored information.

R1#show run | s bgp
router bgp 123
 no synchronization
 bgp log-neighbor-changes
 network 1.1.1.0 mask 255.255.255.0
 neighbor 12.1.1.2 remote-as 123
 neighbor 12.1.1.2 next-hop-self
 neighbor 12.1.1.2 send-community
 neighbor 13.1.1.3 remote-as 123
 neighbor 13.1.1.3 next-hop-self
 neighbor 13.1.1.3 send-community
 neighbor 15.1.1.5 remote-as 500
 neighbor 15.1.1.5 capability orf prefix-list send
 neighbor 15.1.1.5 soft-reconfiguration inbound
 neighbor 15.1.1.5 prefix-list ALLOW-PREFIX in
 no auto-summary
ip bgp-community new-format

R5#
router bgp 1500
 no synchronization
 bgp log-neighbor-changes
 network 5.5.5.0 mask 255.255.255.0
 network 10.0.0.0 mask 255.255.255.0
 network 10.0.1.0 mask 255.255.255.0
 network 10.0.2.0 mask 255.255.255.0
 network 10.0.3.0 mask 255.255.255.0
 network 55.55.55.0 mask 255.255.255.0
 neighbor 15.1.1.1 remote-as 123
 neighbor 15.1.1.1 send-community
 neighbor 15.1.1.1 capability orf prefix-list receive
 neighbor 15.1.1.1 soft-reconfiguration inbound
 no auto-summary
ip bgp-community new-format

BGP Outbound Route Filtering-ORF

Enables outbound route filter (ORF) capability exchange and advertise ORF capabilities to a BGP peer,
ORF, or outbound route filtering, is the technique that allows a BGP peer to “push” a filter to the remote neighbor. The neighbor then applies the prefix filter to the outbound updates sent to the peer that pushed the filter. This feature is particularly helpful in situations where BGP peers exchange large amounts of BGP information.
Send and receive capabilities to minimize the number of BGP updates that are sent between BGP peers.

BGP peering sessions must be established, and BGP ORF capabilities must be enabled on each participating router before prefix-based ORF announcements can be sent or received.


we see all the 10.x prefixes advertised by R5 are being learned by R1




Configure both the routers Capability to send and receive the prefix 

R1(config-router)#neighbor 15.1.1.5 capability orf prefix-list send
R5(config-router)#neighbor 15.1.1.1 capability orf prefix-list receive

we will create a prefix list on R1 so that it can only receive the prefix 10.0.0.0/24 and 10.0.1.0/24

R1#
ip prefix-list ALLOW-PREFIX seq 10 permit 10.0.0.0/24
ip prefix-list ALLOW-PREFIX seq 20 permit 10.0.1.0/24
!
router bgp 123
 no synchronization
 bgp log-neighbor-changes
 network 1.1.1.0 mask 255.255.255.0
 neighbor 12.1.1.2 remote-as 123
 neighbor 12.1.1.2 next-hop-self
 neighbor 12.1.1.2 send-community
 neighbor 13.1.1.3 remote-as 123
 neighbor 13.1.1.3 next-hop-self
 neighbor 13.1.1.3 send-community
 neighbor 15.1.1.5 remote-as 500
 neighbor 15.1.1.5 capability orf prefix-list send
 neighbor 15.1.1.5 prefix-list ALLOW-PREFIX in
 no auto-summary
!






R5#show ip bgp neighbors 15.1.1.1
 For address family: IPv4 Unicast
  BGP table version 162, neighbor version 162/0
 Output queue size : 0
  Index 1, Offset 0, Mask 0x2
  1 update-group member
  Inbound soft reconfiguration allowed
  Community attribute sent to this neighbor
  AF-dependant capabilities:
    Outbound Route Filter (ORF) type (128) Prefix-list:
      Send-mode: received
      Receive-mode: advertised
  Outbound Route Filter (ORF): received (2 entries)
  Outbound path policy configured