BGP Overview

BGP like any other routing protocol needs a loop prevention mechanism in order to prevent routing loops.  eBGP differs than iBGP in how it implements the loop prevention, eBGP uses the AS_Path attribute in order to do loop prevention – any prefix received with the local AS in its AS-Path attribute is dropped. While with iBGP it uses a split-horizon mechanism (can’t use the AS_PATH, since it is not changed with an AS), stating that a prefix received from an iBGP neighbor is never advertised to another iBGP neighbor, this mechanism obligated the need of full mesh between all the iBGP neighbors in order for each of them to learn all the prefixes.

Doing iBGP in full mesh is not a scalable solution, since it implies a huge number of sessions to be configured and maintained (n(n-1)) plus prefixes replications overhead and waste of resources (impact on CPU, memory and network bandwidth), and thus here came the Route reflectors and Confederation part. They work around the need of iBGP sessions full mesh, and thus provide a scalable network design – We will have an in depth look into them in later posts.

On the other hand, as a method of circumventing black-holes in transit networks, Synchronization was introduced. This rule simply states that inside a transit AS, an IBGP learned prefix is never sent to an EBGP neighbor unless it is validated via the IGP, this prevents a transit router to claim that it knows how to reach a network via BGP while it can’t actually reach this network (creating a black-hole). This rule formerly required the redistribution of the BGP routes into the IGP, in order for the BGP routes to be always validated via the IGP, but this approach has gone very limited and non-scalable, since the internet routing table has exceed 250,000 prefix nowadays (August 2008) and this is a problem for IGPs, thus this approach can’t be implemented anymore, and thus in modern IOS codes the synchronization is disabled by default (since 12.2(8)T). In order to still prevent black-holes in transit networks, we are obligated to run BGP on all the network routers instead, since BGP is the only routing protocol that can handle this amount of prefixes, and thus each and every router in the transit network will be capable to reach each and every destination learned via BGP, and thus preventing back-holes while circumventing the need for enabling synchronization.

As illustrated in the previous paragraph, the need for running BGP on all the network routers came to prevent black-holes in transit networks by making sure that all the destinations are known by all the routers in the transit network, while being able to safely turning synchronization off. This required all the Service providers worldwide to enable BGP on all their routers, even the very fast high capacity core routers. This need was circumvented by the introduction of MPLS, with MPLS the core routers no longer need to learn the destination prefixes since they won’t be doing normal IP lookups, this would be replaced by label switching. Thus, the core routers in the service provider network no longer need to run BGP, only the edge routers do, and this is what is called BGP free core.

eBGP between R1 and R2 should be configured using their loopback interfaces, one way to achieve this  is to configure eBGP multihop where TTL values of the BGP packets is increased. Another way of doing it is to use the disable-connected-check   command under the BGP configuration, this will allow the two routers to become neighbors but only through direct connected links since the TTL is not touched.

When a TCP client attempts to establish a connection to a TCP server it first sends a TCP SYN packet to the server with the destination port as the well-known port (In case of BGP 179). This first SYN essentially is a request to open a session. If the server permits the session it will respond with a TCP SYN ACK saying that it acknowledges the request to open the session, and that it also wants to open the session. In this SYN ACK response the server uses the well-known port as the source port, and a randomly negotiated destination port. The last step of the three way handshake is the client responding to the server with a TCP ACK, which acknowledges the server’s response and completes the connection establishment.

1)    What does a next hop of 0.0.0.0 mean in the show ip bgp command output? A network in the BGP table with a next hop address of 0.0.0.0 means that the network is locally originated via redistribution of Interior Gateway Protocol (IGP) into BGP, or via a network or aggregate command in the BGP configuration.

2)     BGP message types: Open, keep alive, update, notification and route-refresh.

3)     BGP Connection states: Idle, Connect, Active, Open-sent, Open-confirm and Established.

4)    Open messages contains: BGP version no, AS no, Hold time, BGP route-id, optional prams.

5)    IBGP split-horizon: - Routing information that is received through an IBGP session is never forwarded to another IBGP neighbor, only toward EBGP neighbors, because of BGP split-horizon, no router can relay IBGP information within the AS, all routers must be directly updated from the border router that received the EBGP update.

6)    Packet forwarding in a Transit AS: - Routes learned via BGP do not have an outgoing interface associated with them in the routing table. Recursive lookup is performed to forward IP packets toward external destination.

7)    In Cisco IOS software BGP, there are three ways to advertise the prefix:

               

a)      Using the network statement: prefix must exist in the routing table in order to advertise.

b)      Using the redistribute connected: command “no auto-summary” is used because BGPs by default advertise redistributed routes to their classful mask.

c)      Using the aggregate statement: prefixes are aggregated or summarized to reduce the number of prefix announcements and reduce the size of the routing table. You need to understand two important rules to aggregate routes.

a)     Rule1: Aggregation or summarization of subnets can happen only if those subnets exist in the  BGP table

b)    Rule2: For the aggregated (summarized) route, Cisco IOS installs an IP route with the next hop to Null0 in the ip routing table. This is done to insure that a valid exists in the routing table to announce it to other BGP peers.

c)    With th aggregate-address command in Cisco IOS, BGP advertises the aggregate and the sub-netted routes as well. In order to announce only aggregated prefix use “summary-only” keyword at the end of aggregate command. “aggregate-address 131.108.1.0 255.255.255.0 summary-only”

8)    First off the router will order the paths from the newest to the oldest.  By default all factors in the BGP best path decision process being the same; the oldest path will be selected as best.  BGP does to this reduce the amount of churn in the routing table.  To change this behavior and not use the oldest path as the best, the BGP router-ID can be used to determine the best path.  To enable this use the bgp bestpath compare-routerid router configuration command. First off it’s important to understand that the paths are compared in pairs starting with the newest path and comparing it with the second newest.  The winning path between the first and second is then compared to the third and so on. http://blog.ine.com/2011/10/12/understanding-bgp-med-and-bgp-deterministic-med/ .  Ideally we want the MED compared between advertisements from the same AS irrespective of their age.  This is where the bgp deterministic-med router configuration command is useful.  When this command is enabled the router will group all paths from the same AS and compare them together before comparing them to paths from different ASes.

9)     What is the BGP path selection criteria?Routers ignore paths in these circumstances:

a)      Paths that are marked as not synchronized in the show ip bgp longer-prefixes output

b)      Paths for which the NEXT_HOP is inaccessible: Be sure that there is an Interior Gateway Protocol (IGP) route to the NEXT_HOP that is associated with the path.

a)     Prefer the path with the highest WEIGHT; It is local to the router on which it is configured.

b)     Prefer the path with the highest LOCAL_PREF.

c)      Prefer the path that was locally originated via a network or aggregate BGP subcommand or through redistribution from an IGP.

d)     Prefer the path with the shortest AS_PATH:

§   This step is skipped if you have configured the bgp bestpath as-path ignore command.

§    An AS_SET counts as 1, no matter how many ASs are in the set.

§    The AS_CONFED_SEQUENCE and AS_CONFED_SET are not included in the AS_PATH length.

e)      Prefer the path with the lowest origin type.: IGP is lower than Exterior Gateway Protocol (EGP), and EGP is lower than INCOMPLETE.

f)      Prefer the path with the lowest multi-exit discriminator (MED).

§  This comparison only occurs if the first (the neighboring) AS is the same in the two paths. Any confederation sub-ASs are ignored. In other words, MEDs are compared only if the first AS in the AS_SEQUENCE is the same for multiple paths. Any preceding AS_CONFED_SEQUENCE is ignored

§   If bgp always-compare-med is enabled, MEDs are compared for all paths. You must disable this option over the entire AS. Otherwise, routing loops can occur.

§  The bgp deterministic med command can also influence this step.

g)     Prefer eBGP over iBGP paths

h)     Prefer the path with the lowest IGP metric to the BGP next hop.

i)       Determine if multiple paths require installation in the routing table for BGP Multipath.

j)      When both paths are external, prefer the path that was received first (the oldest one).

k)     Prefer the route that comes from the BGP router with the lowest router ID.

l)       If the originator or router ID is the same for multiple paths, prefer the path with the minimum cluster list length.

m)   Prefer the path that comes from the lowest neighbor address.

10)      What is the difference between always-compare-med and deterministic-med? Enabling the bgp deterministic-med command ensures the comparison of the MED variable when choosing routes advertised by different peers in the same autonomous system. Enabling the bgp always-compare-med command ensures the comparison of the MED for paths from neighbors in different autonomous systems. The bgp always-compare-med command is useful when multiple service providers or enterprises agree on a uniform policy for setting MED. Thus, for network X, if Internet Service Provider A (ISP A) sets the MED to 10, and ISP B sets the MED to 20, both ISPs agree that ISP A has the better performing path to X.

Note: The bgp deterministic-med and bgp always-compare-med commands are not enabled by default. Also, the two commands are separate; enabling one does not automatically enable the other.

11)     Does the route reflector change the next hop attribute of a reflected prefix? By default, the next hop attribute is not changed when a prefix is reflected by route reflector. However, you can issue the neighbor next-hop-self-command in order to change the attribute of the next hop for prefixes reflected from an eBGP peer to any route reflector client.

12)     Why IGP in BGP?: BGP uses TCP to communicate between the neighbors.

13)     BGP sends BGP/TCP keep lives by default every 60 seconds.

14)    Black holes (for example, advertising a destination to an external neighbor when not all the  routers within the autonomous system can reach the destination) within the autonomous system.

15)     BGP Synchronization Rule: The BGP synchronization rule states that a BGP (Any BGP router within the AS) router should not use, or advertise to an external neighbor, a route learned by IBGP, unless that route is local or is learned from the IGP. 

Transient black-holing can still happen, but by turning off synchronization, IGP is not required to carry full BGP routes. In cases where some routers are not running BGP and they are in transit path of the IBGP neighbor, synchronization cannot be turned off and BGP must be redistributed in the IGP.

16)     What is synchronization, and how does it influence BGP routes installed in the IP routing table? If you’re AS passes traffic from another AS to a third AS, BGP should not advertise a route before all routers in your AS learn about the route via IGP. BGP waits until IGP propagates the route within the AS and then advertises it to external peers. A BGP router with synchronization enabled does not install iBGP learned routes into its routing table if it is not able to validate those routes in its IGP. Issue the no synchronization command under router bgp in order to disable synchronization. This prevents BGP from validating iBGP routes in IGP.

17)     What does r RIB-Failure mean in the show ip bgp command output? When BGP tries to install the bestpath prefix into Routing Information Base (RIB) (for example, the IP Routing table), RIB might reject the BGP route due to any of these reasons:

·        Route with better administrative distance already present in IGP. For example, if a static route already exists in IP Routing table.

·        Memory failure.

·        The number of routes in VPN routing/forwarding (VRF) exceeds the route-limit configured under the VRF instance.

In such cases, the prefixes that are rejected for these reasons are identified by r RIB Failure in the show ip bgp command output and are not advertised to the peers.

18)     WELL KNOWN, MANDATORY: This attribute MUST appear in every UPDATE message. It must be supported by all BGP software implementations. If a well-known, mandatory attribute is missing from an UPDATE message, a NOTIFICATION message must be sent to the peer. Examples:AS_path, ORIGIN, NEXT_HOP

19)     WELL KNOWN, DISCRETIONARY: This attribute may or may not appear in an UPDATE message, but it MUST be supported by any BGP software implementation. Examples:LOCAL_PREF, ATOMIC_AGGREGATE

20)  OPTIONAL, TRANSITIVE: These attributes may or may not be supported in all BGP implementations. If it is sent in an UPDATE message, but not recognized by the receiver, it should be passed on to the next AS.Examples: AGGREGATOR, COMMUNITY

21)  OPTIONAL, NON-TRANSITIVE: May or may not be supported, but if received, it is not required that the router pass it on. It may safely and quietly ignore the optional attribute.Examples: MULTI_EXIT_DISC, ORIGINATOR_ID,Cluster List

22)     Route dampening: - Route dampening is the feature that reduces propagation of flapping routes in the Internet. Route flapping occurs when IP routes are removed and put back in a routing table. This can be because of physical layer failure, routing protocol failure, or router node failure, and so on. When these flaps are announced through BGP to the Internet, all of Internet routers running BGP are affected, as they have to remove and install such flapping routes. In an unstable internal network where IP routes continuously flaps, this instability is propagated through BGP throughout the Internet. Route dampening is the feature that minimizes this instability by assigning a penalty to such flapping routes. When the penalty reaches a predefined limit (suppress limit 2000), that route is removed from the routing table and is not advertised to Internet. When the route stops flapping, the penalty decreases exponentially. When the penalty is reduced to a predefined limit (reuse limit 750), that route is installed again and propagated through BGP. Route dampening applies to EBGP neighbors only. 

23)     BGP Finite-state machine : In order to make decisions in its operations with other BGP peers, a BGP peer uses a simple finite state machine (FSM) that consists of six states: Idle; Connect; Active; OpenSent; OpenConfirm; and Established. For each peer-to-peer session, a BGP implementation maintains a state variable that tracks which of these six states the session is in. The BGP protocol defines the messages that each peer should exchange in order to change the session from one state to another. The first state is the “Idle” state. In the “Idle” state, BGP initializes all resources, refuses all inbound BGP connection attempts and initiates a TCP connection to the peer. The second state is “Connect”. In the “Connect” state, the router waits for the TCP connection to complete and transitions to the "OpenSent" state if successful. If unsuccessful, it starts the ConnectRetry timer and transitions to the "Active" state upon expiration. In the "Active" state, the router resets the ConnectRetry timer to zero and returns to the "Connect" state. In the "OpenSent" state, the router sends an Open message and waits for one in return. Keepalive messages are exchanged and, upon successful receipt, the router is placed into the “Established” state. In the “Established” state, the router can send/receive: Keepalive; Update; and Notification messages to/from its peer.

1)     Idle State:

      Refuse all incoming BGP connections

      Start event triggers the initialization of

      Initiates a TCP connection with its configured BGP peer.

      Listens for a TCP connection from its peer.

      Changes its state to Connect.

      If an error occurs at any state of the FSM process, the BGP session is terminated immediately and returned to the Idle state. Some of the reasons why a router does not progress from the Idle state are: 

     §  TCP port 179 is not open.

§  A random TCP port over 1023 is not open.

§  Peer address configured incorrectly on either router.

§  AS number configured incorrectly on either router .

2)     Connect State: 

       Waits for successful TCP negotiation with peer.

       BGP does not spend much time in this state if the TCP session has been successfully established.

       Sends Open message to peer and changes state to OpenSent.

       If an error occurs, BGP moves to the Active state. Some reasons for the error are: 

     §  TCP port 179 is not open.

§  A random TCP port over 1023 is not open.

§  Peer address configured incorrectly on either router.

§  AS number configured incorrectly on either router.

3)     Active State:

       If the router was unable to establish a successful TCP session, then it ends up in the Active state.

       BGP FSM will try to restart another TCP session with the peer and, if successful, then it 

       will send an Open message to the peer.

       If it is unsuccessful again, the FSM is reset to the Idle state.

       Repeated failures may result in a router cycling between the Idle and Active states. 

       Some of the reasons for this include: 

       

     §  TCP port 179 is not open.

§  A random TCP port over 1023 is not open.

§  BGP configuration error.

§  Network congestion.

§  Flapping network interface.

4)     OpenSent State:

 BGP FSM listens for an Open message from its peer.

Once the message has been received, the router checks the validity of the Open message.

If there is an error it is because one of the fields in the Open message doesn’t match between the peers, e.g. BGP version mismatch, MD5 password mismatch, the peering router expects a different My AS. The router will then send a Notification message to the peer indicating why the error occurred.

If there is no error, a Keepalive message is sent, various timers are set and the state is changed to OpenConfirm.

5)     OpenConfirm State:

 The peer is listening for a Keepalive message from its peer.

If a Keepalive message is received and no timer has expired before reception of the Keepalive, BGP transitions to the Established state.

If a timer expires before a Keepalive message is received, or if an error condition occurs, the router transitions back to the Idle state.

6)     Established State:

In this state, the peers send Update messages to exchange information about each route being advertised to the BGP peer.

If there is any error in the Update message then a Notification message is sent to the peer, and BGP transitions back to the Idle state.

If a timer expires before a Keepalive message is received, or if an error condition occurs, the router transitions back to the Idle state.

BGP Route-reflectors:-  Since I am vpnv4 route-reflector , I am going to except all the updates from my clients, and then reflect them down to other clients or other EBGP peers, or other IBGP peers, ie if I learn it from clients, I can advertise it to anybody. If I learn it from eBGP neighbor, I can advertise it to anybody. If I learn it from someone who is not a client, I can advertise it to eBGP peers or clients but no other non-clients. So between to iBGP peers that are not-clients of me I can’t advertise between them. Key point to note in about route-reflection in BGP , we are using it to just to advertise the prefix, it doesn’t necessarily mean we are going to be in the date plane forwarding path, means it doesn’t change the the next-hop. RR just used in the control plane to advertise the routes on. Cluster-list is the router-id of the route-reflector. Cluster-list is used in large scale route-reflection designs, where we have multiple RR’s that are peering with each-other; this is an additional loop prevention mechanism. If I advertise route to a client I am gonna tag with my own route-id inside the cluster-list, then for some reason route comes back around to me again, then I see my own identifier in the cluster-list, I know that I already reflected it so I need to drop that route.

How is this accomplished route-reflector? BGP Route Reflector follows the below listed rules to achieve this goal:

• iBGP routers are divided into Route Reflectors, Route Reflector clients and non-client Peers.
• Routes received from a Route-Reflector-client are reflected to other clients and non-client neighbors.
• Routes received from non-client neighbors are reflected to Route-Reflector-client neighbors only.
• Setting the Originator-ID attribute in the reflected update if it is not already set.
• Adding the Cluster-ID  to the Cluster-list attribute in the reflected update.
• A Route Reflector reflects routes considered as best routes only. If more than one update is received for the same destination,  only the BGP best route is reflected.
• A Route Reflector is not allowed to change any attributes of the reflected routes including the next-hop attribute.

Route Reflectors and Loop Prevention:

The following rules are used to detect and avoid routing loops caused by route reflection:

• If a router received an iBGP route with the Originator-ID attribute set to its own router-id, the route is discarded.
• If a route reflector receives a route with a cluster-list attribute containing its cluster-id, the route is discarded.

24)     MP-BGP: - Once PE routers learn routing information from the customer they need someway internally to keep track which route belongs to which customer, this achieved using MP-BGP.  The MP-BGP is used to advertise the IPv6 VPN routes in the MP_REACH NLRI.

a)      MP-BGP defines AFI 1 and SAFI 128 as vpn-ipv4 or vpnv4 . vpvn4 accomplish two things, its taking the routing information learning from the customer and then encoding two additional pieces of information,

a)     RD (Unique per VPN or per VPN site) ASN:nn or IP-address:nn

b)     4 byte ipv4 address (unique per VPN)

b)      VPNV4 includes MPLS VPN label.

25)   Why IGP in BGP?:- The entire secret behind IGP is THE NEXT HOP address reachability. Running a Full Mesh of IBGP Peer can be cumbersome. so IGP can be used on a partially peered IBGP routers just to make sure that IBGP next Hop for any advertised route is reachable. The reason is that IBGP Peers (The routers running BGP inside Autonomous System) is that One IBGP router cannot advertise a Route to other IBGP router. The Routers must be directly connected over a TCP segment.

The second step is to redistribute the BGP routes into the IGP otherwise the Routes will not be learned in IGP Routing table and anything not in Routing Table will cause the Non-BGP Router to drop the packets. This is called a BLACK HOLE in your Autonomous System. Secondly take cautionary steps while redistributing BGP routes into IGP, and not overwhelm your IGP routing process because the sheer size of INTERNET routing table is not designed to be handled by IGPs, use wisely.

Another solution if you don’t want to use IGP is to disable Synchronization, and run Full Mesh IBGP with lots of neighbour commands under each router inside your Autonomous System.

    26)     Local-as, no-prepend, replace-as and dual-as options in BGP:-

For example, ISP A, with an AS of 1000, acquires ISP B, with an AS of 100. ISP B has a customer, ISP C, which does not want to change its configuration. After ISP B becomes part of ISP A, a local AS number of 100 is configured for use in EBGP peer sessions with ISP C. Consequently, the local AS number of 100 is prepended before the global AS number of 1000 in the AS path used to export routes to direct external peers in ISP C. sometime down the road, if ISP C decided to migrate to AS 1000, but we don’t know when, in that we can use dual-as option to pear whichever the value they want either 100 or 1000. So bgp sending two separate open messages one for 100 and one for 1000

a)      local-as  Prepends both incoming and outgoing updates.

b)      no-prepend  Do not prepend local-as to updates coming in from ebgp peers

c)      replace-as  Replace real AS with local AS in the EBGP updates

d)      Dual-as Any AS is acceptable i.e. either with local-as or original as

1     27)     BGP communities: - its 32 bit integer, common format <local-ASN>:xx. 
            BGP Community attribute is used to group common routes and treat them in a certain manner.

“A community is a group of prefixes that share some common property and can be configured with the BGP community attribute. The BGP Community attribute is an optional transitive attribute of variable length. The attribute consists of a set of four octet values that specify a community. The community attribute values are encoded with an Autonomous System (AS) number in the first two octets, with the remaining two octets defined by the AS. A prefix can have more than one community attribute. A BGP speaker that sees multiple community attributes in a prefix can act based on one, some or all the attributes. A router has the option to add or modify a community attribute before the router passes the attribute on to other peers.”

  

a)      For example “No customer AS should ever be used as a transit between ISPs, configures this on the customer and ISP sides of the BGP relationship.” We see that AS 9300(Customer) is advertising “internet” routes to each provider, potentially making it a transit AS. On CE configure below

     route-map No-Export permit 10

                               set community no-export

                              !

                              router bgp 9300

                               neighbor 38.19.4.1 remote-as 1200

                               neighbor 38.19.4.1 route-map No-Export in

                               neighbor 91.7.36.1 remote-as 6500

                               neighbor 91.7.36.1 route-map No-Export in

The above configuration lets customer to advertise the prefixes that are originated in AS 9300. http://blog.alwaysthenetwork.com/tutorials/bgp-communities/

b)      Below configuration RTB (AS 200) to set the community attribute to the BGP routes it is advertising such that RTC (3.3.3.1) which is in AS 300 would not propagate these routes to its external peers. The no-export community attribute is used:

RTB# 

router bgp 200
network 160.10.0.0
neighbor 3.3.3.1 remote-as 300
neighbor 3.3.3.1 send-community
neighbor 3.3.3.1 route-map set-community out

!

route-map set-community
match ip address 1
set community no-export

!

access-list 1 permit 0.0.0.0 255.255.255.255 

c)      R1 is directly connected to R2 with an IBGP session between them; the example will show you how to use communities to manipulate BGP attributes:

R1(config)#ip bgp-community new-format

R1(config)#route-map SETCOM

R1(config-route-map)#set community 1:10

              

R1(config)#router bgp 12

R1(config-router)#neighbor 192.168.12.2 remote-as 12

R1(config-router)#neighbor 192.168.12.2 send-community

R1(config-router)#network 150.1.1.0 mask 255.255.255.0 route-map SETCOM

!

R2(config)#router bgp 12

R2(config-router)#nei 192.168.12.1 remote-as 12

R2(config-router)#nei 192.168.12.1 route-map COM in

              

R2(config)#ip community-list 1 permit 1:10

R2(config)#route-map COM

R2(config-route-map)#match community 1

R2(config-route-map)#set metric 100

28)     BGP outbound route filtering:- Outbound Route Filtering Capability for BGP-4 is currently an IETF draft (http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-16.txt) that describes an optimization on how prefix filtering can occur between a Customer Edge (CE) router and a Provider Edge (PE) router that are exchanging IPv4 unicast BGP prefixes. In the design we saw above the upstream PE router sent the full BGP table downstream to the CE router, and filtering was applied inbound on the downstream CE. With BGP ORF the downstream CE router dynamically tells the upstream PE router what routes to filter *outbound*. This means that the downstream CE router will only receive update messages about the prefixes that it wants.

Since some resources are consumed when a BGP sender generates and transmits routing updates, as well as when the receiver processes these updates, it can be useful if the generation of these routing updates be avoided in the first place.

Implementation wise the first step of this feature is for the BGP neighbors to negotiate that they both support the BGP ORF capability. Configuration-wise this looks as follows:

The ORF Capability is a BGP Capability defined as follows-
   
    Capability code: 3 (as per RFC), Cisco uses 130
    Capability length: variable
    Capability value: one or more of the ORF entries which carries AFI/SAFI, number of ORFs, ORF-Type and Send/ Receive.

Carrying ORF entries in BGP: ORF entries are carried in the BGP Route Refresh message. A single Route Refresh message can carry multiple ORF entries or more ORFs, as long as the entries share the same AFI/ SAFI.

if router wants to change its configuration to allow only 1.1.1.1/32 prefix from R2 router. It advertises this change using ORF. The clear ip bgp 10.1.1.2 in prefix-filter command initiates an inbound soft-reset to clear a BGP ORF.

Once the ORF is cleared, R1 router sends 2 BGP Route Refresh messages (Type 5) to R2 router to notify the changes. The first RR message is REMOVE-ALL to remove all previously installed ORF entries. The second RR message is ADD to add the newly configured ORF entry.

AS100_PE#

router bgp 100

 neighbor 10.0.0.200 remote-as 200

 !

 address-family ipv4

 neighbor 10.0.0.200 capability orf prefix-list receive

 neighbor 204.12.25.254 activate

!

AS200_CE#

router bgp 200

 neighbor 10.0.0.100 remote-as 100

 !

 address-family ipv4

 neighbor 10.0.0.100 capability orf prefix-list send

 neighbor 10.0.0.100 prefix-list AS_100_INBOUND in

!

ip prefix-list AS_100_INBOUND seq 5 permit 0.0.0.0/0

ip prefix-list AS_100_INBOUND seq 10 permit 28.119.16.0/24

ip prefix-list AS_100_INBOUND seq 15 permit 28.119.17.0/24

The logic of this configuration is that AS 200 is “sending” a prefix-list of what routes it wants, while AS 100 is “receiving” the prefix-list of what the downstream neighbor wants. The reception of the prefix-list by the upstream PE can be verified as follows.

29)     Allowas-in and as-override:-  "allowas-in" is usually used on the CE and "as-override" on the PE. In my experience, SPs prefer to configure "as-override" for consistency since the CE is most of the time own by the customer and as you said you can't really be sure what IOS is running and therefore what commands will be available. Allow-as-in allowed the loop prevention to be ignored for the configured amount of instances, and the as-override caused the PE routers to modify the AS_PATH.

Ex: CE1(config-router)#neighbor 192.168.12.2 allowas-in 1 è in this case if we see our ASN once in the path already, it's ok to allow it in

PE2(config-router-af)#neighbor 192.168.34.1 as-override è

30)     BGP order of preference.

a)      For inbound updates the order of preference is:
1. route-map
2. filter-list
3. prefix-list, distribute-list'

b)      For outbound updates the order of preference is:
1. prefix-list, distribute-list
2. filter-list
3. route-map