Tag Archives: bgp

iBGP PE-CE

Different RD values for different sites – mandatory.

neighbor <address> internal-vpn-client
neighbor <address> route-reflector-clinet
neighbor <address> next-hop-self

NHS – mandatory.

ATTR_SET – new BGP attribute, which “embeds” CE BGP attributes. CE attributes are transparent for VPN backbone. VPN backbone attributes are not passed to CE.

The ATTR_SET attribute has this format:

 
                      +------------------------------+
                      | Attr Flags (O|T) Code = 128  |
                      +------------------------------+
                      | Attr. Length (1 or 2 octets) |
                      +------------------------------+
                      | Origin AS (4 octets)         |
                      +------------------------------+
                      | Path Attributes (variable)   |
                      +------------------------------+

The attribute flags are the regular BGP attribute flags (refer to RFC 4271). The attribute length indicates whether the attribute length is one or two octets. The purpose of the Origin AS field is to prevent the leak of one route originated in one AS to be leaked to another AS without the proper manipulation of the AS_PATH. The variable length Path Attributes field carries the VPN BGP attributes that must be carried across the SP core.

When PE1 receives the BGP prefix 10.100.1.1/32 from CE1, it stores it twice:

PE1#show bgp vpnv4 unicast all 10.100.1.1/32
BGP routing table entry for 65000:1:10.100.1.1/32, version 21
Paths: (2 available, best #1, table customer1)
  Advertised to update-groups:
     5         
  Refresh Epoch 1
  Local, (Received from ibgp-pece RR-client)
    10.1.1.4 (via vrf customer1) from 10.1.1.4 (10.100.1.1)
      Origin IGP, metric 0, localpref 200, valid, internal, best
      mpls labels in/out 18/nolabel
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  Local, (Received from ibgp-pece RR-client), (ibgp sourced)
    10.1.1.4 (via vrf customer1) from 10.1.1.4 (10.100.1.1)
      Origin IGP, localpref 100, valid, internal
      Extended Community: RT:1:1
      mpls labels in/out 18/nolabel
      rx pathid: 0, tx pathid: 0

The first path is the actual path on PE1, because it is received from CE1.

The second path is the path that is advertised towards the RRs/PE routers. It is marked with ibgp sourced. It contains the ATTR_SET attribute. Notice that this path has one or more Route Targets (RTs) attached to it.

PE1 advertises the prefix as shown here:

PE1#show bgp vpnv4 unicast all neighbors 192.168.100.3 advertised-routes 
BGP table version is 7, local router ID is 192.168.100.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65000:1 (default for vrf customer1)
 *>i 10.100.1.1/32    10.1.1.4                 0    200      0 i

Total number of prefixes 1

This is how the RR sees the path:

RR#show bgp vpnv4 un all 10.100.1.1/32
BGP routing table entry for 65000:1:10.100.1.1/32, version 10
Paths: (1 available, best #1, no table)
  Advertised to update-groups:
     3         
  Refresh Epoch 1
  Local, (Received from a RR-client)
    192.168.100.1 (metric 11) (via default) from 192.168.100.1 (192.168.100.1)
      Origin IGP, localpref 100, valid, internal, best
      Extended Community: RT:1:1
      Originator: 10.100.1.1, Cluster list: 192.168.100.1
      ATTR_SET Attribute: 
        Originator AS 65000
        Origin IGP
        Aspath 
        Med 0
        LocalPref 200
        Cluster list 
        192.168.100.1, 
        Originator 10.100.1.1
      mpls labels in/out nolabel/18
      rx pathid: 0, tx pathid: 0x0

Notice that the local preference of this VPNv4 unicast prefix in the core is 100. In the ATTR_SET, the original local preference of 200 is stored. However, this is transparent to the RR in the SP core.

On PE2, you see the prefix as shown here:

PE2#show bgp vpnv4 unicast all 10.100.1.1/32
BGP routing table entry for 65000:1:10.100.1.1/32, version 5
Paths: (1 available, best #1, no table)
  Not advertised to any peer
  Refresh Epoch 2
  Local
    192.168.100.1 (metric 21) (via default) from 192.168.100.3 (192.168.100.3)
      Origin IGP, localpref 100, valid, internal, best
      Extended Community: RT:1:1
      Originator: 10.100.1.1, Cluster list: 192.168.100.3, 192.168.100.1
      ATTR_SET Attribute: 
        Originator AS 65000
        Origin IGP
        Aspath 
        Med 0
        LocalPref 200
        Cluster list 
        192.168.100.1, 
        Originator 10.100.1.1
      mpls labels in/out nolabel/18
      rx pathid: 0, tx pathid: 0x0
BGP routing table entry for 65000:2:10.100.1.1/32, version 6
Paths: (1 available, best #1, table customer1)
  Advertised to update-groups:
     1         
  Refresh Epoch 2
  Local, imported path from 65000:1:10.100.1.1/32 (global)
    192.168.100.1 (metric 21) (via default) from 192.168.100.3 (192.168.100.3)
      Origin IGP, metric 0, localpref 200, valid, internal, best
      Originator AS(ibgp-pece): 65000
      Originator: 10.100.1.1, Cluster list: 192.168.100.1
      mpls labels in/out nolabel/18
      rx pathid:0, tx pathid: 0x0

The first path is the one received from the RR, with the ATTR_SET. Note that the RD is 65000:1, the origin RD. The second path is the imported path from the VRF table with RD 65000:1. The ATTR_SET has been removed.

This is the path as seen on CE2:

CE2#show bgp ipv4 unicast 10.100.1.1/32
BGP routing table entry for 10.100.1.1/32, version 10
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.1.2.2 from 10.1.2.2 (192.168.100.2)
      Origin IGP, metric 0, localpref 200, valid, internal, best
      Originator: 10.100.1.1, Cluster list: 192.168.100.2, 192.168.100.1
      rx pathid: 0, tx pathid: 0x0

Notice that the next-hop is 10.1.2.2, which is PE2. The cluster list contains routers PE1 and PE2. These are the RRs that matter inside the VPN. The SP RR (10.100.1.3) is not in the cluster list.

The local preference of 200 has been preserved inside the VPN across the SP network.

 

BGP syncronization

When this is the case, the router ID of the OSPF router acting as the Autonomous System Boundary Router (ASBR) for the redistributed BGP routes must also be the router ID of the advertising IBGP speaker for the same prefix. The route reflector cluster list should match the two previously mentioned router IDs as well.

BGP dampening

Is an evil! But 😉

 

Formula (Really Madly Hate! 😉

max-penalty = reuse-limit * 2 (max-suppress-time / half-life )

Command:

bgp dampening half-life reuse-limit suppress-limit maximum-suppress-time

Defaults:
The default penalty increase for a route flap is 1000. If the route attributes are the only change, the penalty increase is 500. This value is hard-coded.
The penalty on the route is reduced every 5 seconds.
The router checks for prefixes to unsuppress every 10 seconds.

bgp dampening 15 750 2000 60
(max penalty = 6000)

BGP

Confederations

LPref, MED and next-hop are kept across sub-AS eBGP!

network 1.0.0.0/24 backup – set distance 200

MED, Local-pref, NLRI are sent as TLVs.

When an IGP (in this example OSPF) route is redistributed in to BGP it is considered locally generated by BGP and gets assigned a weight of 32768.

Best Path Selection

AIGP – optiona notransitive 8 octet. If AIGP is configured AND the bgp bestpath aigp ignore command is not configured, the decision process considers the AIGP metric.

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

AIGP after Local Preference. AIGP metric reflects IGP cost. Lowest wins.
BGP prefers the path with the AIGP attribute by default.

 

Timers
The default BGP ConnectRetry timer is 120 seconds. Only after this time passes does the BGP process check to see if the passive TCP session is established. If the passive TCP session is not established, then the BGP process starts a new active TCP attempt to connect to the remote BGP speaker. During this idle 120 seconds of the ConnectRetry timer, the remote BGP peer can establish a BGP session to it. Presently, the Cisco IOS ConnectRetry timer cannot be changed from its default of 120 seconds.

Communities
Internet == 0:0 == match all; no such community in RFC

Redistribute & MED
— If the injected BGP route, using the network or redistribute command, is
from an IGP, the BGP MED is derived from the IGP metric.
— If the injected BGP route (using the network or redistribute command) is
from a connected route, the BGP MED is set to 0.
— If the route is injected by the aggregate-address command, MED is not set.

BGP GR
Capability 64
For IPv4, the end-of-RIB marker is a BGP Update message with no reachable NLRI and
empty withdrawn NLRI. Additional address families indicate the end-of-RIB with a BGP
Update containing only the MP_UNREACH_NLRI attribute with no withdrawn routes for
that AFI/SAFI.
Restart Time indicates how long a peer of the restarting router should maintain prefix
information received from the restarting router. The restart time should be less than the holdtime for the BGP peer.
The reception of a BGP-GR capability with no AFI/SAFI information indicates that the sending peer supports the end-of-RIB marker and can support peers that can maintain forwarding state and that want to utilize BGP-GR. The reception of a BGP-GR capability with AFI/SAFI information indicates that the sending peer wants to perform BGP-GR for the included AFI/SAFIs.
Mark all prefixes as stale.
After restart:
The receiving BGP router sends the BGP-GR capability to the restarting BGP router, with
the Restart State set to 0, unless the receiving BGP router also is reset. The receiving BGP
router receives a BGP-GR capability from the restarting BGP router with a Restart State of 1.
This triggers the receiving BGP router to send the initial routing update, followed by the
end-of-RIB marker.

BGP order of preference

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

For outbound updates the order of preference is:
1. filter-list
2. route-map | unsuppress-map
3. advertise-map (conditional-advertisement)
4. prefix-list|distribute-list
5. ORF prefix-list (a prefix-list the neighbor sends us)