Abstract image of a woman sitting on books and studying on a laptop

BGP

A
Anıl Alibeyoğlu

The document provides an overview of the Border Gateway Protocol (BGP). It begins with general information about BGP, including that it is used for routing between autonomous systems and is classified as a path vector routing protocol. It then covers BGP theory in detail over several sections, explaining concepts like neighbors, messages, states, attributes and more. The document aims to provide thorough theoretical understanding needed to implement BGP in a lab.

1 of 74
Downloaded 791 times
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Most read
29
Most read
30
31
32
33
34
35
36
37
Most read
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
1 Border Gateway Protocol Anıl ALİBEYOĞLU Network Consultant CCIE #24974
2 Agenda • General Information, • Theory,  Explains every component in a very detailed fashion.  To understand theory, basic data communication + clear routing knowledge is a pre-req. • Implementation,  Cisco Systems IOS 12.4(25d) Advanced Enterprise code is used during the whole implementation. GNS3 is used for the lab. and Wireshark is used as a packet sniffer.
3 General Information (1) • Used for routing between "Autonomous Systems". • Classified as a "Path Vector" routing protocol. • Uses "Attributes" to manipulate inside/outside traffic flow. • Reliable since it uses TCP as a transport protocol. • Scalable, hierarchical and loop-free. • Secure. • Open standard (RFC 4271). • Internet relies on BGP. • ISPs and enterprise customers can run BGP.
4 General Information (2) • Is not appropriate when:  Single connection to ISP,  Policies aren’t used,  Enough memory & CPU aren’t available,  Technical staff aren’t qualified enough to operate & troubleshoot it, • Is appropriate when:  Multiple connections to ISPs,  Policies are used,  Enough memory & CPU are available,  Technical staff are qualified enough to operate & troubleshoot it.
5 Theory – General Concepts (1) • BGP can be assumed just a regular TCP application that uses TCP port 179. So, to open a TCP connection; proper route for the destination IP address (BGP peer in other words) must exist in the routing table. Then prefixes can be exchanged via established TCP connection. • BGP neighbors can’t be discovered, they must be defined manually. • Only one TCP session is maintained even if both ends attempt for succesful TCP connection. • All BGP messages are sent as unicast.
6 Theory – General Concepts (2) • BGP has 2 types of neighborship:  iBGP (internal-BGP; BGP neighbors are in the same AS)  eBGP (external-BGP; BGP neighbors are in different AS’s) • iBGP administrative distance is 200, eBGP administrative distance is 20. • BGP supports summarization and CIDR. • Uses incremented/triggered updates. • Only installs "best path" into the routing table and only announces "best path" to other BGP peers (prefix will be advertised must exist exactly in the routing table). • Can use MD5 authentication between peerings.
7 Theory – General Concepts (3) • BGP maintains 2 table:  Neighbor table (contains BGP timers and related information, prefix related information, BGP messages sent/received to/from neighbors, address-family and denied prefixes information…etc. In other words, contains all neighbor related information)  BGP table (contains all learned BGP prefixes, their attributes, best/all paths) • Only best paths are put in to the routing table (if multi-path load sharing is enabled, more than one path can be put into the routing table –up to 16 multiple path). • 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. (disable sync. for best practice, mostly it’s not used) • If sync. is enabled and IGP is OSPF, neighbors’ OSPF & BGP router IDs must be same. • Either disable sync. & run BGP in all routers inside the AS or keep it & redistribute prefixes from BGP to IGP. (or Tunnel BGP over GRE, IPIP…etc.)
8 Theory – General Concepts (4) • BGP has a Split Horizon rule which means; a prefix learned from an iBGP neighbor can not be advertised to an other iBGP peer. • When a router receives an UPDATE message that contains its own AS number in AS_PATH attribute, it ignores it (this is known as AS-Path loop prevention mechanism). Because when an UPDATE message leaves an AS, the AS number is prepended and then UPDATE message is sent with this new AS_PATH information.
9 Theory – General Concepts (5) • Inside the AS, all routers must be full-meshed iBGP peer (because of BGP Split Horizon Rule). As you guess, iBGP peers don’t modify the NEXT_HOP attribute in UPDATE messages between each other. • This means when you have N routers in your AS, you can clearly see that you should have (N x [N-1]) / 2 iBGP sessions in your BGP domain. • Of course it’s not scalable for large-scale deployments. Also number of TCP sessions become extra overhead for the routers and multiple duplicate routing traffic traverses all around the network. For this, there are 2 options to solve this problem:  Route reflectors can be used (one or more routers are assigned as a "reflector", these routers advertise routing information to clients –to non-clients in some cases)  Confederations can be used (main AS is divided into sub-ASs, all rules remain same; each sub-AS establishes eBGP session between each other…etc.).
10 Theory – General Concepts (6) • A router can belong to only one AS. • BGP AS numbers can be between 0 to 65535. • 0, 59392–64511 and 65535 are reserved by IANA. • 64512-65534 can be used as a private AS (e.g. in confederation deployments, as a sub-AS). • Remaining part can be used as a public AS. • In eBGP peerings, TTL value is 1. NEXT_HOP attribute is modified between eBGP peers. • In iBGP peerings, TTL value is 255. NEXT_HOP attribute isn’t modified between iBGP peers.
11 Theory – Messages • BGP has 4 message types:  OPEN  KEEPALIVE  UPDATE  NOTIFICATION • Additionally ROUTE REFRESH message (type 5) can be used if it’s aggreed up on the peering.
12 Theory – OPEN Message • After a neighbor has been configured and TCP session has been established, firstly an OPEN message (type 1) is sent to neighbor to form a BGP peering. • This message contains several information such as version of BGP (currently it’s 4), AS number, hold time (timers are negotitated between peers) value, BGP router-ID. Also it contains some optional parameters like capabilities. Capabilities contain which address-family- identifier (AFI) and sub-AFI (SAFI) can be used, also some features such as Route Refresh. • Next slide you can see the capture file of an OPEN message.
13 Theory – OPEN Message Structure
14 Theory – KEEPALIVE Message • After BGP peering has been established, periodical KEEPALIVE messages (type 4) are sent every 60 seconds by default. • It’s just a simple message that doesn’t contain too much information, it just ensures that BGP peering is UP and working without any problem. • If KEEPALIVE messages are not received by a neighbor in a time frame defined in hold time value in OPEN message, then this neighbor assumes that other side is no more a BGP peer and it finishes the BGP session by sending a NOTIFICATION message (we’ll see later) and also it finishes the TCP session by sending TCP FIN packet.
15 Theory – KEEPALIVE Message Structure
16 Theory – UPDATE Message (1) • As we mentioned in previous slides, firstly TCP connection has been established, secondly BGP peering has been established with OPEN messages, now it’s time to exchange prefix information between these peers. As you guess, UPDATE messages (type 2) are used to exchange prefix information. • UPDATE messages contain so much information about related prefix/prefixes and their attributes. NLRI term is used instead of prefix in BGP world, it stands for Network Layer Reachability Information. When the NLRI becomes unreachable somehow, UPDATE message carries this information as "withdrawn routes". • One UPDATE message can contain multiple NLRI information with their attributes. And also with one TCP segment, multiple BGP messages can be transported (see next slide).
17 Theory – UPDATE Message (2) • As you see above, there’s a succesful TCP connection and after that there’s a successful BGP peering connection. Next, UPDATE messages are exchanged between two BGP peers.
18 Theory – UPDATE Message Structure • UPDATE message format with withdrawn routes: • UPDATE message format with new routes:
19 Theory – NOTIFICATION Message • NOTIFICATION message (type 3) is sent when there is a problem. This message closes the BGP connection. • There may be many reasons to send the NOTIFICATION message (wrong neighbor AS number configuration, hold timer expiration…etc.). • Reason is put in the NOTIFICATION message, so you can troubleshoot it easily.
20 Theory – NOTIFICATION Message Structure • Below you can see that hold timer expired here: • Also in the below example, wrong neighbor AS number has been configured, which means other side doesn’t expect that AS number in the OPEN message:
21 Theory – ROUTE REFRESH Message • ROUTE REFRESH message (type 5) is a special message that informs BGP peer to exchange prefix information again which are exchanged before. It doesn’t contain too much information (contains AFI/SAFI), it’s just for information for the BGP peer. • In early deployments of BGP, whenever you change the routing policy, related BGP connection was reset. To avoid this, this open standard feature is used (Route Refresh Capability –RFC 2918). • When you change the routing policy, router sends this message for impacted AFI/SAFI to it’s peer, then if the peer router understands that message, it re-advertises the prefixes. • This capability is sent during the BGP peering (as you learn from previous slides, there’re "capabilities" in "Optional Parameter" field, in the OPEN message).
22 Theory – ROUTE REFRESH Message Structure • Below you can see that routing policy is changed for unicast IPv4 traffic: • As soon as it’s sent, UPDATE messages are exchanged between peers:
23 Theory – States • BGP neighbor states are:  IDLE  ACTIVE  CONNECT  OPEN SENT  OPEN CONFIRM  ESTABLISHED
24 Theory – IDLE & CONNECT State • In IDLE state, router does not allocate any BGP resources and during this time, router does not accept any incoming BGP session. • In CONNECT state, BGP waits for a successful TCP connection. If TCP connection is successful, BGP FSM goes to OPENSENT since it immediately sends an OPEN message to the peer after a successful TCP connection. If TCP connection is not completed, BGP FSM goes to ACTIVE, CONNECT or IDLE state depending on the failure reason.
25 Theory – ACTIVE & OPENSENT State • In ACTIVE state, a TCP connection is initiated. If it’s successful, BGP router sends an OPEN message immediately and BGP FSM goes to OPENSENT state. In the case of failure, BGP FSM goes to ACTIVE or IDLE state . • In OPENSENT state, BGP router has already sent an OPEN message and is waiting OPEN message from its peer. If OPEN message is received succesfully from its peer, BGP FSM goes to OPENCONFIRM state and a KEEPALIVE message has been sent to its peer. In the case of failure, BGP FSM goes to ACTIVE or IDLE state.
26 Theory – OPENCONFIRM & ESTABLISHED State • In OPENCONFIRM state, BGP router has already received OPEN message from its peer and is waiting a KEEPALIVE message from its peer. If it receives a KEEPALIVE, BGP FSM goes to ESTABLISHED state, otherwise BGP FSM goes to IDLE state (as you guess, BGP FSM is one step away from its final state). • In ESTABLISHED state, BGP router receives a KEEPALIVE message from its peer. From this time, BGP peers can exchange information between each other with UPDATE messages (also KEEPALIVE messages are sent periodically between each other, NOTIFICATION messages can be sent in the case of failure).
27 Theory – BGP Finite State Machine
28 Theory – Attributes • BGP has several attributes:  Well-Known Mandatory: Must be supported and recognised by all BGP routers. These attributes must be included in UPDATE messages. They must be passed on to other BGP routers.  Well-Known Discretionary: Must be supported and recognised by all BGP routers. They must be passed on to other BGP routers. But these attributes may/may not be included in UPDATE messages, it’s not mandatory.  Optional Transitive: May be recognised/not recognised by BGP routers. But they must be passed on to other BGP routers. If these type of attributes aren’t recognised, they’re marked as "partial".  Optional Non-transitive: May be recognised/not recognised by BGP routers and isn’t passed on to other BGP routers.  Also some vendors may use additional attribute to manipulate best path selection algoritm such as Cisco Systems, they use weight attribute which is locally significant, higher is better.
29 Theory – Well-Known Mandatory Attributes (1) • NEXT_HOP: Holds IP address of the BGP router that advertises the UPDATE message. Doesn’t change when UPDATE message is sent to an iBGP peer by default, changes when UPDATE message is sent to an eBGP peer. • AS_PATH: Holds an ordered list of AS numbers through that UPDATE message has traversed. With this attribute, incoming traffic to an AS will be manipulated (you can prepend it). • ORIGIN: Holds the information that explains how this NLRI has been learned (will be discussed in more detail in "Implementation" section).
30 Theory – Well-Known Mandatory Attributes (2) • First packet shows that; this UPDATE message is originated from this router, this NLRI has been learned from IGP (you’ll see later what it means) and to reach this destination, next hop must be 10.0.12.1). • Second packet shows that; this UPDATE message is originated from AS 4570 and passed through the AS 60, this NLRI has been learned from IGP (you’ll see later what it means) and to reach this destination, next hop must be 10.0.16.6).
31 Theory – Well-Known Discretionary Attributes (1) • LOCAL_PREF: Holds the value that tells iBGP peers which path they should select to reach a specific NLRI which are outside the AS. In other words it’s a metric for iBGP peers inside the AS to reach destinations that are outside the AS (higher is better). With this attribute, traffic leaving the AS can be manipulated. This attribute is propagated through the local AS (will be discussed in more detail in "Implementation" section). • ATOMIC_AGGREGATE: Informs the i/eBGP neighbor that the originating router aggregated the routes.
32 Theory – Well-Known Discretionary Attributes (2) • This packet shows that; the LOCAL_PREF attribute value is 100 for this/these NLRI(s) and NLRIs are aggregated by a BGP router which originates more specific NLRIs.
33 Theory – Optional Transitive Attributes (1) • AGGREGATOR: Holds the IP address and the AS number of the BGP router that performed the summarization/aggregation. • COMMUNITIES: Route tags that are used for filtering/building specific policies/manupilating routing process.
34 Theory – Optional Transitive Attributes (2) • This packet shows that; BGP router with router-id 1.1.1.1 in AS 1230 has aggregated this NLRI and this packet has a community attribute set to NO_ADVERTISE (will be discussed in more detail in "Implementation" section).
35 Theory – Optional Non-Transitive Attributes (1) • MED (MULTI_EXIT_DISC): This attribute is a metric for eBGP peers, according this attribute, neighbor AS will select the entrance to our AS (lower is better). • CLUSTER_LIST: Holds the IP addresses of the Route Reflectors that UPDATE message has been passed through. With this information, loops are avoided (e.g. A route reflector ignores the UPDATE messages that contain its BGP router-ID in CLUSTER_LIST attribute, that means UPDATE message already traversed its cluster). This attribute isn’t used between RR & its client. • ORIGINATOR_ID: Holds the IP address of the first announcer (originator) of the NLRI in topologies that contain Route Reflectors (you’ll see what it means in next slide). This attribute isn’t used between RR & its client.
36 Theory – Optional Non-Transitive Attributes (2) • First packet shows that; this UPDATE message is originated from 4.4.4.4, then it passes through route-reflector (3.3.3.3) somehow, then this UPDATE message enters an other RR cluster (RR is 1.1.1.1). MED is 0. • Second packet shows that; this UPDATE message is originated from 3.3.3.3 (which may or may not be a Route Reflector, we don’t know), and an RR cluster 1.1.1.1 has received that UPDATE message somehow. MED is again 0.
37 Theory – Best Path Selection Algorithm • Firstly exclude routes which have inaccessible NEXT_HOP. • If NEXT_HOP is accessible, then prefer the path which has higher WEIGHT (for Cisco Systems devices), this is locally significant. In standard implementation, it’s not a selection criteria. • If WEIGHT is not set or same, then prefer the path which has higher LOCAL_PREF. • If LOCAL_PREF attributes are same, then prefer the path that you advertised by yourself as a BGP router. • If LOCAL_PREF attributes are same and you don’t advertise those routes, then prefer the path which has the shortest AS_PATH length. • If AS_PATH lengths are same, then prefer the path which has the lowest ORIGIN type; i (IGP; native) < EGP < ? (incomplete; redistributed). • If ORIGIN types are same, then prefer the path which has the lowest MED (if candidate routes are announced from the same AS). • If MED is not a tie-breaker, then prefer the eBGP routes over iBGP routes (if any confederation exists, then selection order becomes; eBGP over eBGP confederation over iBGP). • If routes are iBGP-learned in previous step, then prefer the path which has the lowest IGP metric for its NEXT_HOP. If routes are eBGP-learned in previous step, then prefer the path which is the oldest one (means more stable). Also if multipath is enabled in BGP and the same IGP metric exists, then traffic is loadbalanced. • As a last tie-breaker, prefer the path which has the lowest BGP router-ID.
38 Implementation – Topology • Will cover basic configurations as well as advanced scenarios. • Topology seen below will be used for all scenarios, we’ll modify if we need. Also pysical IP addresses are seen below:
39 Implementation – Addresses/Subnets • Other than pysical IP addresses, we will use loopback subnets as customer or production subnets. We will announce, filter, summarize, redistribute…etc. these subnets. We will play them  • Loopback0 will be used as a Router-ID and format is X.X.X.X/32 where X is a router number (like R1, R3). • Loopback1-9 format is like that 192.168.[X][Y].1/24 where X is a router number and Y is a Loopback number. E.g. 192.168.53.0/24 subnet belongs to R5- Loopback3.
40 Implementation – Initial Steps • First initiate the BGP process with an AS number: R1(config)#router bgp 1230 !BGP process for AS 1230. • Enable BGP peering logging: R1(config-router)#bgp log-neighbor-changes !In most cases it’s on by default, but if it’s not, it’s good to turn it on. With this, BGP neighbor UP/DOWN and reset reasons are logged as a SYSLOG messages. • Disable the synchronization process: R1(config-router)#no synchronization !It turns off the sync.rule (it’s explained in previous slides). • Disable the auto-summarization: R1(config-router)#no auto-summary !It’s advisable to disable the auto-summarization.
41 Implementation – Peering (1) • Manually define the neighbors and their AS numbers: R1(config-router)#neighbor 10.0.12.2 remote-as 1230 !Neighbor 10.0.12.2 is in AS 1230, we’ll accept a TCP connection from this IP and will initiate TCP connection to this IP. • You can modify NEXT_HOP attribute manually because this attribute isn’t modified for iBGP peerings as i mentioned before, since inter-router segment is not a customer/neighbor AS subnet, you don’t need to advertise it: R1(config-router)#neighbor 10.0.12.2 next-hop-self ! NEXT_HOP attribute of UPDATE messages sent to 10.0.12.2 are modified with the outgoing interfaces’ IP address of R1 (outgoing interface to reach 10.0.12.2).
42 Implementation – Peering (2) • If authentication is done between peers, same passwords must be defined in both ends: R1(config-router)#neighbor 10.0.12.2 password 0 neteksper_lab !If you use type 7 instead of 0, encrypted form must be entered, otherwise in type 0 you must enter the plain text. • If eBGP peering is established through the Loopback addresses, TTL of the IP packet must be changed: R1(config-router)#neighbor 6.6.6.6 ebgp-multihop 20 !As i mentioned before, default TTL value is 1 for eBGP peerings, with this command you change the TTL value to 20, if you dont’t enter any number, it will choose the max.value 255. • If eBGP peering is established through the Loopback addresses, source IP must be specified: R1(config-router)#neighbor 6.6.6.6 update-source Loopback0 !OPEN messages will be sent with this source IP address, since other side expects to see this address for the peering.
43 Implementation – Peering (3) • Basic peering configurations between R1-R2 and R1-R6 are seen below as examples:
44 Implementation – Peering (4) • With show ip bgp neighbors command, you can see all information related with BGP peering. It shows very detailed information. • With show ip bgp summary command, you can see what’s the neighbor IP address, BGP version (4 for current standard), what’s neighbors’ AS number, how many messages are sent and received to/from this neighbor, table version, input & output queue values, for how long neighborship is UP and state (if it’s not ESTABLISHED) & how many prefixes are received from that neighbor (if the state is ESTABLISHED it shows the prefix number): • Since 0 prefix has been received, show ip bgp command shows nothing (this command show the BGP table):
45 Implementation – Peering (5) • Also show ip protocols command shows all routing protocols’ information running on the router. BGP global parameters, route reflector clients, used filters and neighbors can be seen with this command:
46 Implementation – Announcing Prefixes (1) • Prefixes can be announced in 3 ways:  With network command,  With aggregation (with aggregate command)  With redistribution (with redistribute command) • In each method, AS_PATH attribute remains empty (with default parameters), since prefixes are originated from router itself. Other parameters can be affected differently (such as ORIGIN).
47 Implementation – Announcing Prefixes (2) • With network command, we tell BGP router which routes (with their subnets) are announced to other BGP peers. This command has several options such as route- map (to set attribute values…etc.). R1(config-router)#network 192.168.13.0 mask 255.255.255.0 !192.168.13.0/24 subnet is a connected subnet in Loopback 3, with this command, R1 will announce this subnet to all BGP neighbors. • With aggregate command, we tell BGP router to summarize more specific routes which already exist in its BGP table. This command has several options such as route-map, as-set, summary-only…etc. R1(config-router)#aggregate-address 192.168.12.0 255.255.252.0 !192.168.12- 15.0/24 subnets exist in the BGP table (at least one of them), with this command, R1 announces summary 192.168.12.0/22 subnet to all BGP neighbors addition the specific ones. • With redistribute command, prefixes come from any routing information source (IGP routes, connected or static routes) exist in the routing table can be announced to other BGP neighbors, this command also has many different options. R1(config-router)#redistribute connected !All connected subnets exist in the routing table are redistributed in to the BGP table and announced to all BGP neighbors.
48 Implementation – Announcing Prefixes with network • With network command, ORIGIN attribute is set to IGP (‘i’), as mentioned earlier, it’s a preferred value compared to ‘?’ (‘e’ is for EGP which is not used anymore). (also other parameters can be changed with route-maps). In the originating router, NEXT_HOP is 0.0.0.0 since it’s locally originated. Inside the AS, AS_PATH is also empty. • Subnet and mask must be exactly same as it’s seen in routing table (e.g. If entry in routing table is 10.100.2.0/23, subnet and mask must be 10.100.2.0 & 255.255.254.0), otherwise it doesn’t work. • Below example shows that R1 announces Loopback 9, then R2 receives this prefix with ORIGIN value ‘i’:
49 Implementation – Announcing Prefixes with redistribute • With redistribute command, ORIGIN attribute is set to incomplete (‘?’), as mentioned earlier, it’s not a preferred value compared to ‘i’. (route-maps can be used too) • Below example shows that R1 redistributes only Loopback 9 connected interface, then R2 receives this prefix with ORIGIN value ‘?’:
50 Implementation – Announcing Prefixes with aggregate-address (1) • With aggregate-address <address> <mask> command, ORIGIN attribute is set to IGP (‘i’) just like network command. • It has a requirement that needs at least one subnet in the aggregation must be in the BGP table (by network command, by redistribution or by receiving prefix(es) from an other BGP peer) otherwise aggregated subnet is not announced. • If aggregate-address <address> <mask> summary-only command is used, more specific subnets are suppressed in the aggregation range. • If aggregate-address <address> <mask> as-set command is used, it regenerates AS_PATH information for the aggregated subnet (because during the aggregation, AS_PATH information is destroyed, it’s set to empty just like an internal announcement). • There’re other specific parameters/options for aggregate-address command, i’ll try to explain most of them which are used in real world scenarios.
51 Implementation – Announcing Prefixes with aggregate-address (2) • In below example, 192.168.72-75.0/24 subnets (4 subnets) are aggregated to one 192.168.72.0/22 subnet by R1, but also more specific subnets in the aggregation are received by R2 additon to aggregated subnet, also AS_PATH information is restored by R1 (since as-set keyword is added): •
52 Implementation – Announcing Prefixes with aggregate-address (3) • In below example, 192.168.72-75.0/24 subnets (4 subnets) are aggregated as one 192.168.72.0/22 subnet by R1, more specific subnets are suppressed by R1(with summary-only keyword) and AS_PATH information isn’t restored by R1. So R2 only receives 192.168.72.0/22 with no AS_PATH information. In R1s’ BGP table, suppressed routes are tagged with ‘s’: •
53 Implementation – Announcing Prefixes with suppress-map & unsuppress-map • Also with suppress-map, some specific routes can be selectively suppressed rather than all specific routes. The syntax is: R1(config-router)#aggregate-address <address> <mask> suppress-map <route-map> • For that, firstly we define subnets, then we match these subnets with the route-map and finally we assign this route-map as a suppress-map in the aggregation. • Matched routes ARE NOT announced to the neighbors, they’re tagged with ‘s’ in the BGP table of the router itself (who performs the aggregation). • Suppress-map can’t be defined as a neighbor basis, it affects globally all BGP neighbors. • Also with unsuppress-map, some specific routes can be selectively announced. • As you guess, this can be defined as a neighbor basis, you can selectively send specific subnets to any neighbor. • The configuration of unsuppress-map is same (defining subnets, matching them, applying unsuppress-map). The difference is here that matched subnets ARE announced to the neighbor. The syntax is: R1(config-router)#neighbor <address> unsuppress-map <route-map> • Next 2 pages you can see both suppress-map and unsuppress-map cases between R1 & R2.
54 Implementation – Announcing Prefixes with suppress-map • In below example, 192.168.72-75.0/24 subnets (4 subnets) are aggregated as one 192.168.72.0/22 subnet by R1, and only 192.168.72.0/24 and 192.168.75.0/24 subnets are suppressed (in other words 192.168.73.0/24 and 192.168.74.0/24 subnets are announced addition the aggregated /22 subnet).
55 Implementation – Announcing Prefixes with unsuppress-map • In below example, 192.168.72-75.0/24 subnets (4 subnets) are aggregated as one 192.168.72.0/22 subnet by R1, more specific subnets are suppressed by R1(with summary- only keyword), only R2 receives 192.168.73.0/24 and 192.168.74.0/24 subnets in addition to the aggregated /22 subnet:
56 Implementation – Conditionally Announcing Prefixes • For conditionally announcing prefixes, we use advertise-map, exist-map and non-exist-map. • Advertise-map defines which routes will be announced in the case of meeting the condition. • Exist-map and non-exist-map are used to define the condition.:  If exist-map command is used with advertise-map command, this means that "announce prefixes defined in advertise-map ONLY IF prefixes defined in exist- map exists in the BGP table"  If non-exist-map command is used with advertise-map command, this means that "announce prefixes defined in advertise-map ONLY IF prefixes defined in non-exist-map DOES NOT exist in the BGP table" • Conditional announcing is used as a neighbor basis. Syntax is: R1(config-router)#neighbor <IP> advertise-map <route-map> exist-map <route-map> R1(config-router)#neighbor <IP> advertise-map <route-map> non-exist-map <route-map> • Next pages will show both cases.
57 Implementation – Conditionally Announcing Prefixes with advertise-map & exist-map (1) • Below example shows that, if 192.168.72.0/21 subnet exists in BGP table of R1, 192.168.72-74.0/24 subnets (3 subnets) are allowed to advertise to neighbor 10.0.12.2 (addition to other subnets). But if 192.168.71.0/21 disappears from R1s’ BGP table, these 3 subnets are not advertised to this neighbor (other subnets are still advertised). Next page shows that condition is not met.
58 Implementation – Conditionally Announcing Prefixes with advertise-map & exist-map (2) • Here condition is not met (192.168.72.0/21 subnet does NOT exist in R1s’ BGP table). As you see, 3 subnets are NOT sent to the neighbor 10.0.12.2.
59 Implementation – Conditionally Announcing Prefixes with advertise-map & non-exist-map (1) • Below example shows that, if 192.168.72.0/21 subnet does NOT exist in BGP table of R1, 192.168.72-74.0/24 subnets (3 subnets) are allowed to advertise to neighbor 10.0.12.2 (addition to other subnets). But if 192.168.71.0/21 exists in R1s’ BGP table, these 3 subnets are not advertised to this neighbor (other subnets are still advertised). Next page shows that condition is not met.
60 Implementation – Conditionally Announcing Prefixes with advertise-map & non-exist-map (2) • Here condition is not met (192.168.72.0/21 subnet exists in R1s’ BGP table). As you see, 3 subnets are NOT sent to the neighbor 10.0.12.2.
61 Implementation – Conditionally Route Injection (1) • Conditionally route injection means that, BGP router originates specific subnets from the aggregate/summary. • For this purpose inject-map and exist-map are used. • Inject-map defines prefix that will be originated from the aggregate. • Exist-map matches aggregate and source of the aggregate. • Command syntax is: R1(config-router)#bgp inject-map <route-map> exist-map <route-map> • Also if copy-attributes keyword is added to the above command, original attributes are copied to the injected more specific subnet (normally they’re not copied). • In inject-map, prefix-list is set. In exist-map, source and aggregate are matched: R1(config)#route-map INJECT_MAP permit 5 R1(config-route-map)#set ip address prefix-list <specific_subnet> R1(config-route-map)#route-map EXIST_MAP permit 5 R1(config-route-map)#match ip address prefix-list <aggregate_subnet> R1(config-route-map)#match ip route-source prefix-list <src_of_aggregate>
62 Implementation – Conditionally Route Injection (2) • Here condition is met (R1 learns 192.168.72.0/21 aggregate from R3 which is 10.0.13.3), so R1 injects 192.168.73.0/24 from the /21 aggregate. R2 receives both aggregate and specific subnet, but since we didn’t add copy attributes keyword, as you see attributes are not set for 192.168.73.0/24 subnet.
63 Implementation – Route Reflectors (1) • Route Reflector theory and traffic flow between RR–Client Router–Non-Client Router is explained before in theory section. • Configuration syntax is very basic, assume that R1 is route reflector for R2 & R3, command syntax is: R1(config-router)#neighbor 10.0.12.2 route-reflector-client R1(config-router)#neighbor 10.0.13.3 route-reflector-client • There’s no specific configuration in client router, standard neighbor configuration is applied
64 Implementation – Route Reflectors (2) • Below example shows that R1 is configured as an RR, R2 & R3 are configured as an RR clients.
65 Implementation – Confederations (1) • Confederation theory is explained before in theory section. • Configuration syntax is very basic, BGP process is started for sub-AS, main AS is defined under BGP process and for each peered sub-AS, they are defined under BGP process too. R1(config)#router bgp 64520 !initiates BGP process for sub-AS 64520 R1(config-router)#bgp confederation identifier 1230 !defines main AS R1(config-router)#bgp confederation peers 64530 !means R1 has a peering with a router in sub-AS 64530, this has to be defined as a confederation peer. • Everything else is same, eBGP peerings, iBGP peerings…etc.
66 Implementation – Confederations (2) • Below example shows that, R1 & R2 are in sub-AS 64520 and R3 is in sub- AS 64530. All those routers are in AS 1230. In confederations, NEXT_HOP attribute is not modified even if peering is eBGP, for that, it has to be modified manually (with next-hop-self keyword). Also sub-AS is seen in BGP table in paranthesis:
67 Implementation – Traffic Manipulation (1) • Traffic manipulation can be divided into 2 sections; outbound traffic manipulation and inbound traffic manipulation. • Outbound traffic manipulation deals how data traffic leaves your AS. • Inbound traffic manipulation deals how data traffic arrives at your AS. • To manipulate traffic, you have 2 choices; you can change BGP attributes, you can announce/filter subnets by utilizing route decision mechanism of the router based on longer prefix criteria.
68 Implementation – Traffic Manipulation (2) • BGP attributes used for path selection are seen in order below: • WEIGHT (if your equipment is Cisco) (higher is preferrable) • LOCAL_PREF (higher is preferrable) • AS-PATH (shorter is preferrable) • MED (Metric) (lower is preferrable) • First two of them are used for outbound traffic manipulation, applied as an inbound policy on the router. • Last two of them are used for inbound traffic manipulation, applied as an outbound policy on the router. • As you see, you have control over outbound traffic (if peer AS sets LOCAL_PREF during the reception of the prefixes from us, it doesn’t matter how we set AS-PATH and MED values during the advertisement of these prefixes to peer AS, because peer AS router checks LOCAL_PREF before AS-PATH or MED). • After the attribute(s) are set, you may trigger it by soft or hard resetting the BGP peerings, it depends on the attribute, software, vendor…etc.
69 Implementation – Outbound Traffic Manipulation (1) • To manipulate outbound traffic, you can change LOCAL_PREF or WEIGHT (if your equipment is Cisco) attributes and apply them as an inbound policy. • This applied inbound policy affects outbound traffic. • You decide for which prefix(es) you will change attribute(s) to manipulate traffic flow (e.g. by defining a prefix-list), then you create a route-map to match prefix(es) & set attribute(s), finally you apply this policy under BGP process for a specific neighbor. • You can find the syntax below: R1(config)#route-map <X> permit 10 R1(config-route-map)#match ip address prefix-list <Y> !matches the subnets. R1(config-route-map)#set local-preference <value> !sets the LOCAL_PREF attribute. R1(config)#route-map <X> permit 20 !accepts the other remaining subnets, but does not modify anything on them. R1(config-router)#neighbor <a.a.a.a> route-map <X> in !under BGP process, inbound policy is applied for the neighbor.
70 Implementation – Outbound Traffic Manipulation (2) • Below example shows that, R1 sets LOCAL_PREF attribute to 300 for 192.168.41.0/24, 192.168.42.0/24, 192.168.43.0/24, and this policy is applied for neighbor R6 as an inbound policy. So, R1 receives those subnets from R6, and R1 modifies that attribute for 3 subnets and announces to iBGP peers. Now all iBGP peers know that for any traffic going to these 3 subnets, they will route them to R1. (as you see below, even if R3 is connected directly to R4, it chooses R1  R6  R5  R4 path) R1 changes the outbound traffic by doing this, all outbound traffic for these 3 subnets will go through R6.
71 Implementation – Outbound Traffic Manipulation (3) • Below example shows that, R1 sets WEIGHT attribute to 300 for 192.168.41.0/24, 192.168.42.0/24, 192.168.43.0/24, and this policy is applied for neighbor R6 as an inbound policy. So, R1 receives those subnets from R6, and R1 modifies that attribute for 3 subnets. But in this case, this only affects R1, because as you remember WEIGHT is only locally significant and is not announced. R1 sends traffic to R6 for these 3 subnets but other iBGP peers don’t, they’ll use R3 to reach them. R1 changes the outbound traffic by doing this, all outbound traffic for these 3 subnets will go through R6.
72 Implementation – Inbound Traffic Manipulation (1) • To manipulate inbound traffic, you can change AS_PATH or MED (Metric) attributes and apply them as an outbound policy. • This applied outbound policy affects inbound traffic. • You decide for which prefix(es) you will change attribute(s) to manipulate traffic flow (e.g. by defining a prefix-list), then you create a route-map to match prefix(es) & set attribute(s), finally you apply this policy under BGP process for a specific neighbor. • You can find the syntax below: R1(config)#route-map <X> permit 10 R1(config-route-map)#match ip address prefix-list <Y> !matches the subnets. R1(config-route-map)#set metric <value> !sets the MED attribute. R1(config)#route-map <X> permit 20 !advertises the other remaining subnets, but does not modify anything on them. R1(config-router)#neighbor <a.a.a.a> route-map <X> out !under BGP process, outbound policy is applied for the neighbor.
73 Implementation – Inbound Traffic Manipulation (2) • Below example shows that, R1 sets AS_PATH attribute by prepending 3 more AS numbers addition to original AS (1230 1230 1230 + 1230) for 192.168.11.0/24, 192.168.12.0/24, 192.168.13.0/24, and this policy is applied for neighbor R6 as an outbound policy. So, R1 advertises those subnets to R6 with a modified AS_PATH attribute, and R6 sees that those subnets are 4 AS / 4 hop away to reach. R6 also sees 4570 1230 for same subnets from R5, so R6 prefers R5 to reach them. R1 changes the inbound traffic by doing this, all inbound traffic for these 3 subnets will enter AS 1230 through R3.
74 Implementation – Inbound Traffic Manipulation (3) • Below example shows that, R1 sets MED (Metric) attribute to 1000 for 192.168.11.0/24, 192.168.12.0/24, 192.168.13.0/24, and this policy is applied for neighbor R6 as an outbound policy (since AS_PATH has a higher preference than MED, to make both paths same, we’ve prepended one more AS to our advertisements for 3 subnets). So, R1 advertises those subnets to R6 with a modified MED (Metric) attribute, and R6 sees that those subnets have a MED (Metric) value 1000. R6 also sees 0 MED (Metric) for same subnets from R5, so R6 prefers R5 to reach them. R1 changes the inbound traffic by doing this, all inbound traffic for these 3 subnets will enter AS 1230 through R3.

More Related Content

PDF
Route Redistribution
Netwax Lab
 
PPT
Bgp
Febrian ‎
 
PDF
How BGP Works
ThousandEyes
 
PPTX
Border Gateway Protocol (BGP)
Nutan Singh
 
PPTX
Border Gatway Protocol
Shashank Asthana
 
PPT
BGP protocol presentation
Gorantla Mohanavamsi
 
PPTX
An Overview of Border Gateway Protocol (BGP)
Jasim Alam
 
PPTX
IP Multicasting
Tharindu Kumara
 
Route Redistribution
Netwax Lab
 
Bgp
Febrian ‎
 
How BGP Works
ThousandEyes
 
Border Gateway Protocol (BGP)
Nutan Singh
 
Border Gatway Protocol
Shashank Asthana
 
BGP protocol presentation
Gorantla Mohanavamsi
 
An Overview of Border Gateway Protocol (BGP)
Jasim Alam
 
IP Multicasting
Tharindu Kumara
 

What's hot (20)

PDF
Troubleshooting BGP
APNIC
 
PPTX
Border Gateway Protocol
Kashif Latif
 
PPSX
MPLS
Saif Ullah Khan
 
PPTX
Mpls technology
Naveen Sihag
 
PPTX
BGP (Border Gateway Protocol)
NetProtocol Xpert
 
PDF
MPLS L3 VPN Deployment
APNIC
 
PDF
BGP (border gateway routing protocol)
Netwax Lab
 
PPT
Ospf
DeeN Mohammad
 
PDF
Deploying IP/MPLS VPN - Cisco Networkers 2010
Febrian ‎
 
PDF
Inter as vpn option c
Goerge Micheal Gerges
 
PDF
MPLS Traffic Engineering
APNIC
 
PDF
Troubleshooting BGP
Duane Bodle
 
PPTX
Cisco Live Milan 2015 - BGP advance
Bertrand Duvivier
 
PDF
MPLS Traffic Engineering
APNIC
 
PDF
Cisco ospf
sarasanandam
 
PDF
Bgp tutorial for ISP
Wahyu Nasution
 
PPTX
HSRP ccna
MohamedJafar5
 
PPTX
OSPF Basics
Martin Bratina
 
PPTX
Hot standby router protocol (hsrp) using
ShubhiGupta94
 
PDF
Layer 3 redundancy hsrp
Edgardo Scrimaglia
 
Troubleshooting BGP
APNIC
 
Border Gateway Protocol
Kashif Latif
 
MPLS
Saif Ullah Khan
 
Mpls technology
Naveen Sihag
 
BGP (Border Gateway Protocol)
NetProtocol Xpert
 
MPLS L3 VPN Deployment
APNIC
 
BGP (border gateway routing protocol)
Netwax Lab
 
Ospf
DeeN Mohammad
 
Deploying IP/MPLS VPN - Cisco Networkers 2010
Febrian ‎
 
Inter as vpn option c
Goerge Micheal Gerges
 
MPLS Traffic Engineering
APNIC
 
Troubleshooting BGP
Duane Bodle
 
Cisco Live Milan 2015 - BGP advance
Bertrand Duvivier
 
MPLS Traffic Engineering
APNIC
 
Cisco ospf
sarasanandam
 
Bgp tutorial for ISP
Wahyu Nasution
 
HSRP ccna
MohamedJafar5
 
OSPF Basics
Martin Bratina
 
Hot standby router protocol (hsrp) using
ShubhiGupta94
 
Layer 3 redundancy hsrp
Edgardo Scrimaglia
 
Ad

Viewers also liked (19)

PPT
BGP Overview
Matt Bynum
 
PDF
BGP Advance Technique by Steven & James
Febrian ‎
 
PPTX
Using BGP To Manage Dual Internet Connections
Rowell Dionicio
 
PPTX
BGP Traffic Engineering / Routing Optimisation
Andy Davidson
 
PPTX
bgp protocol
Sukanya Sanyal
 
PPT
Bgp For Presentation
Alp isik
 
PPTX
Implementing Internet and MPLS BGP
Private
 
PPTX
Open Shortest Path First
Kashif Latif
 
PPT
Routing and OSPF
arpit
 
PPTX
Routing Information Protocol
Kashif Latif
 
DOC
Er Adarsh.doc 3ye
adarsh kumar
 
PPTX
Bgpcep odl summit 2015
Giles Heron
 
PDF
BGP Techniques for Network Operators
APNIC
 
PPTX
Network topologies for management
Saugata Palit
 
PDF
2015.7.17 JANOG36 BGP Flowspec Interoperability Test @ Interop Tokyo 2015 Sho...
Shuichi Ohkubo
 
PDF
Network Topologies
Ahsan Rahim
 
PPTX
RIP RTCP RTSP
Dev Heba
 
PDF
junos-firewall-filter
kj teoh
 
PPTX
智能广域网及开源项目更新
Bertrand Duvivier
 
BGP Overview
Matt Bynum
 
BGP Advance Technique by Steven & James
Febrian ‎
 
Using BGP To Manage Dual Internet Connections
Rowell Dionicio
 
BGP Traffic Engineering / Routing Optimisation
Andy Davidson
 
bgp protocol
Sukanya Sanyal
 
Bgp For Presentation
Alp isik
 
Implementing Internet and MPLS BGP
Private
 
Open Shortest Path First
Kashif Latif
 
Routing and OSPF
arpit
 
Routing Information Protocol
Kashif Latif
 
Er Adarsh.doc 3ye
adarsh kumar
 
Bgpcep odl summit 2015
Giles Heron
 
BGP Techniques for Network Operators
APNIC
 
Network topologies for management
Saugata Palit
 
2015.7.17 JANOG36 BGP Flowspec Interoperability Test @ Interop Tokyo 2015 Sho...
Shuichi Ohkubo
 
Network Topologies
Ahsan Rahim
 
RIP RTCP RTSP
Dev Heba
 
junos-firewall-filter
kj teoh
 
智能广域网及开源项目更新
Bertrand Duvivier
 
Ad

Similar to BGP (20)

PDF
Computer network (14)
NYversity
 
DOC
Study Notes BGP Exam
Duane Bodle
 
PDF
Solution against BGP vulnerabilities
iosrjce
 
PDF
D017351725
IOSR Journals
 
PDF
Cisco ccnp 642-902 practice tests for quick preparation
Cisco-642-902
 
DOCX
CCNP Route 642 902 BGP
IT Tech
 
PPTX
15 coms 525 tcpip - border gateway protocols
Palanivel Kuppusamy
 
PDF
bgp features presentation routing protocle
Badr Belhajja
 
PPTX
Bgp protocol
Smriti Tikoo
 
PPT
Bigbgp (1)
acharyanirali
 
DOCX
Cisco BGP Exam 642-661 Review Notes
Duane Bodle
 
PDF
Bgp Toc
bigb0206
 
PDF
Border Gateway Protocol BGP Info abot dynamic
Lakshmi101519
 
PPT
bgp.ppt
aozcan1
 
PDF
Dynamische Routingprotokolle Aufzucht und Pflege - BGP
Maximilan Wilhelm
 
PDF
Apnic_bgp_training_cisco_ciscosaicoc.pdf
PCCW GLOBAL
 
PDF
A Survey of Border Gateway Protocol
International journal of scientific and technical research in engineering (IJSTRE)
 
PDF
Bgpeuro
gigicaltea
 
PPT
Bgp
Raghu Kiran
 
PDF
Halabi Bgp4 Case Studies Tutorial
Hussein Elmenshawy
 
Computer network (14)
NYversity
 
Study Notes BGP Exam
Duane Bodle
 
Solution against BGP vulnerabilities
iosrjce
 
D017351725
IOSR Journals
 
Cisco ccnp 642-902 practice tests for quick preparation
Cisco-642-902
 
CCNP Route 642 902 BGP
IT Tech
 
15 coms 525 tcpip - border gateway protocols
Palanivel Kuppusamy
 
bgp features presentation routing protocle
Badr Belhajja
 
Bgp protocol
Smriti Tikoo
 
Bigbgp (1)
acharyanirali
 
Cisco BGP Exam 642-661 Review Notes
Duane Bodle
 
Bgp Toc
bigb0206
 
Border Gateway Protocol BGP Info abot dynamic
Lakshmi101519
 
bgp.ppt
aozcan1
 
Dynamische Routingprotokolle Aufzucht und Pflege - BGP
Maximilan Wilhelm
 
Apnic_bgp_training_cisco_ciscosaicoc.pdf
PCCW GLOBAL
 
A Survey of Border Gateway Protocol
International journal of scientific and technical research in engineering (IJSTRE)
 
Bgpeuro
gigicaltea
 
Bgp
Raghu Kiran
 
Halabi Bgp4 Case Studies Tutorial
Hussein Elmenshawy
 

BGP

  • 2. 2 Agenda • General Information, • Theory,  Explains every component in a very detailed fashion.  To understand theory, basic data communication + clear routing knowledge is a pre-req. • Implementation,  Cisco Systems IOS 12.4(25d) Advanced Enterprise code is used during the whole implementation. GNS3 is used for the lab. and Wireshark is used as a packet sniffer.
  • 3. 3 General Information (1) • Used for routing between "Autonomous Systems". • Classified as a "Path Vector" routing protocol. • Uses "Attributes" to manipulate inside/outside traffic flow. • Reliable since it uses TCP as a transport protocol. • Scalable, hierarchical and loop-free. • Secure. • Open standard (RFC 4271). • Internet relies on BGP. • ISPs and enterprise customers can run BGP.
  • 4. 4 General Information (2) • Is not appropriate when:  Single connection to ISP,  Policies aren’t used,  Enough memory & CPU aren’t available,  Technical staff aren’t qualified enough to operate & troubleshoot it, • Is appropriate when:  Multiple connections to ISPs,  Policies are used,  Enough memory & CPU are available,  Technical staff are qualified enough to operate & troubleshoot it.
  • 5. 5 Theory – General Concepts (1) • BGP can be assumed just a regular TCP application that uses TCP port 179. So, to open a TCP connection; proper route for the destination IP address (BGP peer in other words) must exist in the routing table. Then prefixes can be exchanged via established TCP connection. • BGP neighbors can’t be discovered, they must be defined manually. • Only one TCP session is maintained even if both ends attempt for succesful TCP connection. • All BGP messages are sent as unicast.
  • 6. 6 Theory – General Concepts (2) • BGP has 2 types of neighborship:  iBGP (internal-BGP; BGP neighbors are in the same AS)  eBGP (external-BGP; BGP neighbors are in different AS’s) • iBGP administrative distance is 200, eBGP administrative distance is 20. • BGP supports summarization and CIDR. • Uses incremented/triggered updates. • Only installs "best path" into the routing table and only announces "best path" to other BGP peers (prefix will be advertised must exist exactly in the routing table). • Can use MD5 authentication between peerings.
  • 7. 7 Theory – General Concepts (3) • BGP maintains 2 table:  Neighbor table (contains BGP timers and related information, prefix related information, BGP messages sent/received to/from neighbors, address-family and denied prefixes information…etc. In other words, contains all neighbor related information)  BGP table (contains all learned BGP prefixes, their attributes, best/all paths) • Only best paths are put in to the routing table (if multi-path load sharing is enabled, more than one path can be put into the routing table –up to 16 multiple path). • 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. (disable sync. for best practice, mostly it’s not used) • If sync. is enabled and IGP is OSPF, neighbors’ OSPF & BGP router IDs must be same. • Either disable sync. & run BGP in all routers inside the AS or keep it & redistribute prefixes from BGP to IGP. (or Tunnel BGP over GRE, IPIP…etc.)
  • 8. 8 Theory – General Concepts (4) • BGP has a Split Horizon rule which means; a prefix learned from an iBGP neighbor can not be advertised to an other iBGP peer. • When a router receives an UPDATE message that contains its own AS number in AS_PATH attribute, it ignores it (this is known as AS-Path loop prevention mechanism). Because when an UPDATE message leaves an AS, the AS number is prepended and then UPDATE message is sent with this new AS_PATH information.
  • 9. 9 Theory – General Concepts (5) • Inside the AS, all routers must be full-meshed iBGP peer (because of BGP Split Horizon Rule). As you guess, iBGP peers don’t modify the NEXT_HOP attribute in UPDATE messages between each other. • This means when you have N routers in your AS, you can clearly see that you should have (N x [N-1]) / 2 iBGP sessions in your BGP domain. • Of course it’s not scalable for large-scale deployments. Also number of TCP sessions become extra overhead for the routers and multiple duplicate routing traffic traverses all around the network. For this, there are 2 options to solve this problem:  Route reflectors can be used (one or more routers are assigned as a "reflector", these routers advertise routing information to clients –to non-clients in some cases)  Confederations can be used (main AS is divided into sub-ASs, all rules remain same; each sub-AS establishes eBGP session between each other…etc.).
  • 10. 10 Theory – General Concepts (6) • A router can belong to only one AS. • BGP AS numbers can be between 0 to 65535. • 0, 59392–64511 and 65535 are reserved by IANA. • 64512-65534 can be used as a private AS (e.g. in confederation deployments, as a sub-AS). • Remaining part can be used as a public AS. • In eBGP peerings, TTL value is 1. NEXT_HOP attribute is modified between eBGP peers. • In iBGP peerings, TTL value is 255. NEXT_HOP attribute isn’t modified between iBGP peers.
  • 11. 11 Theory – Messages • BGP has 4 message types:  OPEN  KEEPALIVE  UPDATE  NOTIFICATION • Additionally ROUTE REFRESH message (type 5) can be used if it’s aggreed up on the peering.
  • 12. 12 Theory – OPEN Message • After a neighbor has been configured and TCP session has been established, firstly an OPEN message (type 1) is sent to neighbor to form a BGP peering. • This message contains several information such as version of BGP (currently it’s 4), AS number, hold time (timers are negotitated between peers) value, BGP router-ID. Also it contains some optional parameters like capabilities. Capabilities contain which address-family- identifier (AFI) and sub-AFI (SAFI) can be used, also some features such as Route Refresh. • Next slide you can see the capture file of an OPEN message.
  • 13. 13 Theory – OPEN Message Structure
  • 14. 14 Theory – KEEPALIVE Message • After BGP peering has been established, periodical KEEPALIVE messages (type 4) are sent every 60 seconds by default. • It’s just a simple message that doesn’t contain too much information, it just ensures that BGP peering is UP and working without any problem. • If KEEPALIVE messages are not received by a neighbor in a time frame defined in hold time value in OPEN message, then this neighbor assumes that other side is no more a BGP peer and it finishes the BGP session by sending a NOTIFICATION message (we’ll see later) and also it finishes the TCP session by sending TCP FIN packet.
  • 15. 15 Theory – KEEPALIVE Message Structure
  • 16. 16 Theory – UPDATE Message (1) • As we mentioned in previous slides, firstly TCP connection has been established, secondly BGP peering has been established with OPEN messages, now it’s time to exchange prefix information between these peers. As you guess, UPDATE messages (type 2) are used to exchange prefix information. • UPDATE messages contain so much information about related prefix/prefixes and their attributes. NLRI term is used instead of prefix in BGP world, it stands for Network Layer Reachability Information. When the NLRI becomes unreachable somehow, UPDATE message carries this information as "withdrawn routes". • One UPDATE message can contain multiple NLRI information with their attributes. And also with one TCP segment, multiple BGP messages can be transported (see next slide).
  • 17. 17 Theory – UPDATE Message (2) • As you see above, there’s a succesful TCP connection and after that there’s a successful BGP peering connection. Next, UPDATE messages are exchanged between two BGP peers.
  • 18. 18 Theory – UPDATE Message Structure • UPDATE message format with withdrawn routes: • UPDATE message format with new routes:
  • 19. 19 Theory – NOTIFICATION Message • NOTIFICATION message (type 3) is sent when there is a problem. This message closes the BGP connection. • There may be many reasons to send the NOTIFICATION message (wrong neighbor AS number configuration, hold timer expiration…etc.). • Reason is put in the NOTIFICATION message, so you can troubleshoot it easily.
  • 20. 20 Theory – NOTIFICATION Message Structure • Below you can see that hold timer expired here: • Also in the below example, wrong neighbor AS number has been configured, which means other side doesn’t expect that AS number in the OPEN message:
  • 21. 21 Theory – ROUTE REFRESH Message • ROUTE REFRESH message (type 5) is a special message that informs BGP peer to exchange prefix information again which are exchanged before. It doesn’t contain too much information (contains AFI/SAFI), it’s just for information for the BGP peer. • In early deployments of BGP, whenever you change the routing policy, related BGP connection was reset. To avoid this, this open standard feature is used (Route Refresh Capability –RFC 2918). • When you change the routing policy, router sends this message for impacted AFI/SAFI to it’s peer, then if the peer router understands that message, it re-advertises the prefixes. • This capability is sent during the BGP peering (as you learn from previous slides, there’re "capabilities" in "Optional Parameter" field, in the OPEN message).
  • 22. 22 Theory – ROUTE REFRESH Message Structure • Below you can see that routing policy is changed for unicast IPv4 traffic: • As soon as it’s sent, UPDATE messages are exchanged between peers:
  • 23. 23 Theory – States • BGP neighbor states are:  IDLE  ACTIVE  CONNECT  OPEN SENT  OPEN CONFIRM  ESTABLISHED
  • 24. 24 Theory – IDLE & CONNECT State • In IDLE state, router does not allocate any BGP resources and during this time, router does not accept any incoming BGP session. • In CONNECT state, BGP waits for a successful TCP connection. If TCP connection is successful, BGP FSM goes to OPENSENT since it immediately sends an OPEN message to the peer after a successful TCP connection. If TCP connection is not completed, BGP FSM goes to ACTIVE, CONNECT or IDLE state depending on the failure reason.
  • 25. 25 Theory – ACTIVE & OPENSENT State • In ACTIVE state, a TCP connection is initiated. If it’s successful, BGP router sends an OPEN message immediately and BGP FSM goes to OPENSENT state. In the case of failure, BGP FSM goes to ACTIVE or IDLE state . • In OPENSENT state, BGP router has already sent an OPEN message and is waiting OPEN message from its peer. If OPEN message is received succesfully from its peer, BGP FSM goes to OPENCONFIRM state and a KEEPALIVE message has been sent to its peer. In the case of failure, BGP FSM goes to ACTIVE or IDLE state.
  • 26. 26 Theory – OPENCONFIRM & ESTABLISHED State • In OPENCONFIRM state, BGP router has already received OPEN message from its peer and is waiting a KEEPALIVE message from its peer. If it receives a KEEPALIVE, BGP FSM goes to ESTABLISHED state, otherwise BGP FSM goes to IDLE state (as you guess, BGP FSM is one step away from its final state). • In ESTABLISHED state, BGP router receives a KEEPALIVE message from its peer. From this time, BGP peers can exchange information between each other with UPDATE messages (also KEEPALIVE messages are sent periodically between each other, NOTIFICATION messages can be sent in the case of failure).
  • 27. 27 Theory – BGP Finite State Machine
  • 28. 28 Theory – Attributes • BGP has several attributes:  Well-Known Mandatory: Must be supported and recognised by all BGP routers. These attributes must be included in UPDATE messages. They must be passed on to other BGP routers.  Well-Known Discretionary: Must be supported and recognised by all BGP routers. They must be passed on to other BGP routers. But these attributes may/may not be included in UPDATE messages, it’s not mandatory.  Optional Transitive: May be recognised/not recognised by BGP routers. But they must be passed on to other BGP routers. If these type of attributes aren’t recognised, they’re marked as "partial".  Optional Non-transitive: May be recognised/not recognised by BGP routers and isn’t passed on to other BGP routers.  Also some vendors may use additional attribute to manipulate best path selection algoritm such as Cisco Systems, they use weight attribute which is locally significant, higher is better.
  • 29. 29 Theory – Well-Known Mandatory Attributes (1) • NEXT_HOP: Holds IP address of the BGP router that advertises the UPDATE message. Doesn’t change when UPDATE message is sent to an iBGP peer by default, changes when UPDATE message is sent to an eBGP peer. • AS_PATH: Holds an ordered list of AS numbers through that UPDATE message has traversed. With this attribute, incoming traffic to an AS will be manipulated (you can prepend it). • ORIGIN: Holds the information that explains how this NLRI has been learned (will be discussed in more detail in "Implementation" section).
  • 30. 30 Theory – Well-Known Mandatory Attributes (2) • First packet shows that; this UPDATE message is originated from this router, this NLRI has been learned from IGP (you’ll see later what it means) and to reach this destination, next hop must be 10.0.12.1). • Second packet shows that; this UPDATE message is originated from AS 4570 and passed through the AS 60, this NLRI has been learned from IGP (you’ll see later what it means) and to reach this destination, next hop must be 10.0.16.6).
  • 31. 31 Theory – Well-Known Discretionary Attributes (1) • LOCAL_PREF: Holds the value that tells iBGP peers which path they should select to reach a specific NLRI which are outside the AS. In other words it’s a metric for iBGP peers inside the AS to reach destinations that are outside the AS (higher is better). With this attribute, traffic leaving the AS can be manipulated. This attribute is propagated through the local AS (will be discussed in more detail in "Implementation" section). • ATOMIC_AGGREGATE: Informs the i/eBGP neighbor that the originating router aggregated the routes.
  • 32. 32 Theory – Well-Known Discretionary Attributes (2) • This packet shows that; the LOCAL_PREF attribute value is 100 for this/these NLRI(s) and NLRIs are aggregated by a BGP router which originates more specific NLRIs.
  • 33. 33 Theory – Optional Transitive Attributes (1) • AGGREGATOR: Holds the IP address and the AS number of the BGP router that performed the summarization/aggregation. • COMMUNITIES: Route tags that are used for filtering/building specific policies/manupilating routing process.
  • 34. 34 Theory – Optional Transitive Attributes (2) • This packet shows that; BGP router with router-id 1.1.1.1 in AS 1230 has aggregated this NLRI and this packet has a community attribute set to NO_ADVERTISE (will be discussed in more detail in "Implementation" section).
  • 35. 35 Theory – Optional Non-Transitive Attributes (1) • MED (MULTI_EXIT_DISC): This attribute is a metric for eBGP peers, according this attribute, neighbor AS will select the entrance to our AS (lower is better). • CLUSTER_LIST: Holds the IP addresses of the Route Reflectors that UPDATE message has been passed through. With this information, loops are avoided (e.g. A route reflector ignores the UPDATE messages that contain its BGP router-ID in CLUSTER_LIST attribute, that means UPDATE message already traversed its cluster). This attribute isn’t used between RR & its client. • ORIGINATOR_ID: Holds the IP address of the first announcer (originator) of the NLRI in topologies that contain Route Reflectors (you’ll see what it means in next slide). This attribute isn’t used between RR & its client.
  • 36. 36 Theory – Optional Non-Transitive Attributes (2) • First packet shows that; this UPDATE message is originated from 4.4.4.4, then it passes through route-reflector (3.3.3.3) somehow, then this UPDATE message enters an other RR cluster (RR is 1.1.1.1). MED is 0. • Second packet shows that; this UPDATE message is originated from 3.3.3.3 (which may or may not be a Route Reflector, we don’t know), and an RR cluster 1.1.1.1 has received that UPDATE message somehow. MED is again 0.
  • 37. 37 Theory – Best Path Selection Algorithm • Firstly exclude routes which have inaccessible NEXT_HOP. • If NEXT_HOP is accessible, then prefer the path which has higher WEIGHT (for Cisco Systems devices), this is locally significant. In standard implementation, it’s not a selection criteria. • If WEIGHT is not set or same, then prefer the path which has higher LOCAL_PREF. • If LOCAL_PREF attributes are same, then prefer the path that you advertised by yourself as a BGP router. • If LOCAL_PREF attributes are same and you don’t advertise those routes, then prefer the path which has the shortest AS_PATH length. • If AS_PATH lengths are same, then prefer the path which has the lowest ORIGIN type; i (IGP; native) < EGP < ? (incomplete; redistributed). • If ORIGIN types are same, then prefer the path which has the lowest MED (if candidate routes are announced from the same AS). • If MED is not a tie-breaker, then prefer the eBGP routes over iBGP routes (if any confederation exists, then selection order becomes; eBGP over eBGP confederation over iBGP). • If routes are iBGP-learned in previous step, then prefer the path which has the lowest IGP metric for its NEXT_HOP. If routes are eBGP-learned in previous step, then prefer the path which is the oldest one (means more stable). Also if multipath is enabled in BGP and the same IGP metric exists, then traffic is loadbalanced. • As a last tie-breaker, prefer the path which has the lowest BGP router-ID.
  • 38. 38 Implementation – Topology • Will cover basic configurations as well as advanced scenarios. • Topology seen below will be used for all scenarios, we’ll modify if we need. Also pysical IP addresses are seen below:
  • 39. 39 Implementation – Addresses/Subnets • Other than pysical IP addresses, we will use loopback subnets as customer or production subnets. We will announce, filter, summarize, redistribute…etc. these subnets. We will play them  • Loopback0 will be used as a Router-ID and format is X.X.X.X/32 where X is a router number (like R1, R3). • Loopback1-9 format is like that 192.168.[X][Y].1/24 where X is a router number and Y is a Loopback number. E.g. 192.168.53.0/24 subnet belongs to R5- Loopback3.
  • 40. 40 Implementation – Initial Steps • First initiate the BGP process with an AS number: R1(config)#router bgp 1230 !BGP process for AS 1230. • Enable BGP peering logging: R1(config-router)#bgp log-neighbor-changes !In most cases it’s on by default, but if it’s not, it’s good to turn it on. With this, BGP neighbor UP/DOWN and reset reasons are logged as a SYSLOG messages. • Disable the synchronization process: R1(config-router)#no synchronization !It turns off the sync.rule (it’s explained in previous slides). • Disable the auto-summarization: R1(config-router)#no auto-summary !It’s advisable to disable the auto-summarization.
  • 41. 41 Implementation – Peering (1) • Manually define the neighbors and their AS numbers: R1(config-router)#neighbor 10.0.12.2 remote-as 1230 !Neighbor 10.0.12.2 is in AS 1230, we’ll accept a TCP connection from this IP and will initiate TCP connection to this IP. • You can modify NEXT_HOP attribute manually because this attribute isn’t modified for iBGP peerings as i mentioned before, since inter-router segment is not a customer/neighbor AS subnet, you don’t need to advertise it: R1(config-router)#neighbor 10.0.12.2 next-hop-self ! NEXT_HOP attribute of UPDATE messages sent to 10.0.12.2 are modified with the outgoing interfaces’ IP address of R1 (outgoing interface to reach 10.0.12.2).
  • 42. 42 Implementation – Peering (2) • If authentication is done between peers, same passwords must be defined in both ends: R1(config-router)#neighbor 10.0.12.2 password 0 neteksper_lab !If you use type 7 instead of 0, encrypted form must be entered, otherwise in type 0 you must enter the plain text. • If eBGP peering is established through the Loopback addresses, TTL of the IP packet must be changed: R1(config-router)#neighbor 6.6.6.6 ebgp-multihop 20 !As i mentioned before, default TTL value is 1 for eBGP peerings, with this command you change the TTL value to 20, if you dont’t enter any number, it will choose the max.value 255. • If eBGP peering is established through the Loopback addresses, source IP must be specified: R1(config-router)#neighbor 6.6.6.6 update-source Loopback0 !OPEN messages will be sent with this source IP address, since other side expects to see this address for the peering.
  • 43. 43 Implementation – Peering (3) • Basic peering configurations between R1-R2 and R1-R6 are seen below as examples:
  • 44. 44 Implementation – Peering (4) • With show ip bgp neighbors command, you can see all information related with BGP peering. It shows very detailed information. • With show ip bgp summary command, you can see what’s the neighbor IP address, BGP version (4 for current standard), what’s neighbors’ AS number, how many messages are sent and received to/from this neighbor, table version, input & output queue values, for how long neighborship is UP and state (if it’s not ESTABLISHED) & how many prefixes are received from that neighbor (if the state is ESTABLISHED it shows the prefix number): • Since 0 prefix has been received, show ip bgp command shows nothing (this command show the BGP table):
  • 45. 45 Implementation – Peering (5) • Also show ip protocols command shows all routing protocols’ information running on the router. BGP global parameters, route reflector clients, used filters and neighbors can be seen with this command:
  • 46. 46 Implementation – Announcing Prefixes (1) • Prefixes can be announced in 3 ways:  With network command,  With aggregation (with aggregate command)  With redistribution (with redistribute command) • In each method, AS_PATH attribute remains empty (with default parameters), since prefixes are originated from router itself. Other parameters can be affected differently (such as ORIGIN).
  • 47. 47 Implementation – Announcing Prefixes (2) • With network command, we tell BGP router which routes (with their subnets) are announced to other BGP peers. This command has several options such as route- map (to set attribute values…etc.). R1(config-router)#network 192.168.13.0 mask 255.255.255.0 !192.168.13.0/24 subnet is a connected subnet in Loopback 3, with this command, R1 will announce this subnet to all BGP neighbors. • With aggregate command, we tell BGP router to summarize more specific routes which already exist in its BGP table. This command has several options such as route-map, as-set, summary-only…etc. R1(config-router)#aggregate-address 192.168.12.0 255.255.252.0 !192.168.12- 15.0/24 subnets exist in the BGP table (at least one of them), with this command, R1 announces summary 192.168.12.0/22 subnet to all BGP neighbors addition the specific ones. • With redistribute command, prefixes come from any routing information source (IGP routes, connected or static routes) exist in the routing table can be announced to other BGP neighbors, this command also has many different options. R1(config-router)#redistribute connected !All connected subnets exist in the routing table are redistributed in to the BGP table and announced to all BGP neighbors.
  • 48. 48 Implementation – Announcing Prefixes with network • With network command, ORIGIN attribute is set to IGP (‘i’), as mentioned earlier, it’s a preferred value compared to ‘?’ (‘e’ is for EGP which is not used anymore). (also other parameters can be changed with route-maps). In the originating router, NEXT_HOP is 0.0.0.0 since it’s locally originated. Inside the AS, AS_PATH is also empty. • Subnet and mask must be exactly same as it’s seen in routing table (e.g. If entry in routing table is 10.100.2.0/23, subnet and mask must be 10.100.2.0 & 255.255.254.0), otherwise it doesn’t work. • Below example shows that R1 announces Loopback 9, then R2 receives this prefix with ORIGIN value ‘i’:
  • 49. 49 Implementation – Announcing Prefixes with redistribute • With redistribute command, ORIGIN attribute is set to incomplete (‘?’), as mentioned earlier, it’s not a preferred value compared to ‘i’. (route-maps can be used too) • Below example shows that R1 redistributes only Loopback 9 connected interface, then R2 receives this prefix with ORIGIN value ‘?’:
  • 50. 50 Implementation – Announcing Prefixes with aggregate-address (1) • With aggregate-address <address> <mask> command, ORIGIN attribute is set to IGP (‘i’) just like network command. • It has a requirement that needs at least one subnet in the aggregation must be in the BGP table (by network command, by redistribution or by receiving prefix(es) from an other BGP peer) otherwise aggregated subnet is not announced. • If aggregate-address <address> <mask> summary-only command is used, more specific subnets are suppressed in the aggregation range. • If aggregate-address <address> <mask> as-set command is used, it regenerates AS_PATH information for the aggregated subnet (because during the aggregation, AS_PATH information is destroyed, it’s set to empty just like an internal announcement). • There’re other specific parameters/options for aggregate-address command, i’ll try to explain most of them which are used in real world scenarios.
  • 51. 51 Implementation – Announcing Prefixes with aggregate-address (2) • In below example, 192.168.72-75.0/24 subnets (4 subnets) are aggregated to one 192.168.72.0/22 subnet by R1, but also more specific subnets in the aggregation are received by R2 additon to aggregated subnet, also AS_PATH information is restored by R1 (since as-set keyword is added): •
  • 52. 52 Implementation – Announcing Prefixes with aggregate-address (3) • In below example, 192.168.72-75.0/24 subnets (4 subnets) are aggregated as one 192.168.72.0/22 subnet by R1, more specific subnets are suppressed by R1(with summary-only keyword) and AS_PATH information isn’t restored by R1. So R2 only receives 192.168.72.0/22 with no AS_PATH information. In R1s’ BGP table, suppressed routes are tagged with ‘s’: •
  • 53. 53 Implementation – Announcing Prefixes with suppress-map & unsuppress-map • Also with suppress-map, some specific routes can be selectively suppressed rather than all specific routes. The syntax is: R1(config-router)#aggregate-address <address> <mask> suppress-map <route-map> • For that, firstly we define subnets, then we match these subnets with the route-map and finally we assign this route-map as a suppress-map in the aggregation. • Matched routes ARE NOT announced to the neighbors, they’re tagged with ‘s’ in the BGP table of the router itself (who performs the aggregation). • Suppress-map can’t be defined as a neighbor basis, it affects globally all BGP neighbors. • Also with unsuppress-map, some specific routes can be selectively announced. • As you guess, this can be defined as a neighbor basis, you can selectively send specific subnets to any neighbor. • The configuration of unsuppress-map is same (defining subnets, matching them, applying unsuppress-map). The difference is here that matched subnets ARE announced to the neighbor. The syntax is: R1(config-router)#neighbor <address> unsuppress-map <route-map> • Next 2 pages you can see both suppress-map and unsuppress-map cases between R1 & R2.
  • 54. 54 Implementation – Announcing Prefixes with suppress-map • In below example, 192.168.72-75.0/24 subnets (4 subnets) are aggregated as one 192.168.72.0/22 subnet by R1, and only 192.168.72.0/24 and 192.168.75.0/24 subnets are suppressed (in other words 192.168.73.0/24 and 192.168.74.0/24 subnets are announced addition the aggregated /22 subnet).
  • 55. 55 Implementation – Announcing Prefixes with unsuppress-map • In below example, 192.168.72-75.0/24 subnets (4 subnets) are aggregated as one 192.168.72.0/22 subnet by R1, more specific subnets are suppressed by R1(with summary- only keyword), only R2 receives 192.168.73.0/24 and 192.168.74.0/24 subnets in addition to the aggregated /22 subnet:
  • 56. 56 Implementation – Conditionally Announcing Prefixes • For conditionally announcing prefixes, we use advertise-map, exist-map and non-exist-map. • Advertise-map defines which routes will be announced in the case of meeting the condition. • Exist-map and non-exist-map are used to define the condition.:  If exist-map command is used with advertise-map command, this means that "announce prefixes defined in advertise-map ONLY IF prefixes defined in exist- map exists in the BGP table"  If non-exist-map command is used with advertise-map command, this means that "announce prefixes defined in advertise-map ONLY IF prefixes defined in non-exist-map DOES NOT exist in the BGP table" • Conditional announcing is used as a neighbor basis. Syntax is: R1(config-router)#neighbor <IP> advertise-map <route-map> exist-map <route-map> R1(config-router)#neighbor <IP> advertise-map <route-map> non-exist-map <route-map> • Next pages will show both cases.
  • 57. 57 Implementation – Conditionally Announcing Prefixes with advertise-map & exist-map (1) • Below example shows that, if 192.168.72.0/21 subnet exists in BGP table of R1, 192.168.72-74.0/24 subnets (3 subnets) are allowed to advertise to neighbor 10.0.12.2 (addition to other subnets). But if 192.168.71.0/21 disappears from R1s’ BGP table, these 3 subnets are not advertised to this neighbor (other subnets are still advertised). Next page shows that condition is not met.
  • 58. 58 Implementation – Conditionally Announcing Prefixes with advertise-map & exist-map (2) • Here condition is not met (192.168.72.0/21 subnet does NOT exist in R1s’ BGP table). As you see, 3 subnets are NOT sent to the neighbor 10.0.12.2.
  • 59. 59 Implementation – Conditionally Announcing Prefixes with advertise-map & non-exist-map (1) • Below example shows that, if 192.168.72.0/21 subnet does NOT exist in BGP table of R1, 192.168.72-74.0/24 subnets (3 subnets) are allowed to advertise to neighbor 10.0.12.2 (addition to other subnets). But if 192.168.71.0/21 exists in R1s’ BGP table, these 3 subnets are not advertised to this neighbor (other subnets are still advertised). Next page shows that condition is not met.
  • 60. 60 Implementation – Conditionally Announcing Prefixes with advertise-map & non-exist-map (2) • Here condition is not met (192.168.72.0/21 subnet exists in R1s’ BGP table). As you see, 3 subnets are NOT sent to the neighbor 10.0.12.2.
  • 61. 61 Implementation – Conditionally Route Injection (1) • Conditionally route injection means that, BGP router originates specific subnets from the aggregate/summary. • For this purpose inject-map and exist-map are used. • Inject-map defines prefix that will be originated from the aggregate. • Exist-map matches aggregate and source of the aggregate. • Command syntax is: R1(config-router)#bgp inject-map <route-map> exist-map <route-map> • Also if copy-attributes keyword is added to the above command, original attributes are copied to the injected more specific subnet (normally they’re not copied). • In inject-map, prefix-list is set. In exist-map, source and aggregate are matched: R1(config)#route-map INJECT_MAP permit 5 R1(config-route-map)#set ip address prefix-list <specific_subnet> R1(config-route-map)#route-map EXIST_MAP permit 5 R1(config-route-map)#match ip address prefix-list <aggregate_subnet> R1(config-route-map)#match ip route-source prefix-list <src_of_aggregate>
  • 62. 62 Implementation – Conditionally Route Injection (2) • Here condition is met (R1 learns 192.168.72.0/21 aggregate from R3 which is 10.0.13.3), so R1 injects 192.168.73.0/24 from the /21 aggregate. R2 receives both aggregate and specific subnet, but since we didn’t add copy attributes keyword, as you see attributes are not set for 192.168.73.0/24 subnet.
  • 63. 63 Implementation – Route Reflectors (1) • Route Reflector theory and traffic flow between RR–Client Router–Non-Client Router is explained before in theory section. • Configuration syntax is very basic, assume that R1 is route reflector for R2 & R3, command syntax is: R1(config-router)#neighbor 10.0.12.2 route-reflector-client R1(config-router)#neighbor 10.0.13.3 route-reflector-client • There’s no specific configuration in client router, standard neighbor configuration is applied
  • 64. 64 Implementation – Route Reflectors (2) • Below example shows that R1 is configured as an RR, R2 & R3 are configured as an RR clients.
  • 65. 65 Implementation – Confederations (1) • Confederation theory is explained before in theory section. • Configuration syntax is very basic, BGP process is started for sub-AS, main AS is defined under BGP process and for each peered sub-AS, they are defined under BGP process too. R1(config)#router bgp 64520 !initiates BGP process for sub-AS 64520 R1(config-router)#bgp confederation identifier 1230 !defines main AS R1(config-router)#bgp confederation peers 64530 !means R1 has a peering with a router in sub-AS 64530, this has to be defined as a confederation peer. • Everything else is same, eBGP peerings, iBGP peerings…etc.
  • 66. 66 Implementation – Confederations (2) • Below example shows that, R1 & R2 are in sub-AS 64520 and R3 is in sub- AS 64530. All those routers are in AS 1230. In confederations, NEXT_HOP attribute is not modified even if peering is eBGP, for that, it has to be modified manually (with next-hop-self keyword). Also sub-AS is seen in BGP table in paranthesis:
  • 67. 67 Implementation – Traffic Manipulation (1) • Traffic manipulation can be divided into 2 sections; outbound traffic manipulation and inbound traffic manipulation. • Outbound traffic manipulation deals how data traffic leaves your AS. • Inbound traffic manipulation deals how data traffic arrives at your AS. • To manipulate traffic, you have 2 choices; you can change BGP attributes, you can announce/filter subnets by utilizing route decision mechanism of the router based on longer prefix criteria.
  • 68. 68 Implementation – Traffic Manipulation (2) • BGP attributes used for path selection are seen in order below: • WEIGHT (if your equipment is Cisco) (higher is preferrable) • LOCAL_PREF (higher is preferrable) • AS-PATH (shorter is preferrable) • MED (Metric) (lower is preferrable) • First two of them are used for outbound traffic manipulation, applied as an inbound policy on the router. • Last two of them are used for inbound traffic manipulation, applied as an outbound policy on the router. • As you see, you have control over outbound traffic (if peer AS sets LOCAL_PREF during the reception of the prefixes from us, it doesn’t matter how we set AS-PATH and MED values during the advertisement of these prefixes to peer AS, because peer AS router checks LOCAL_PREF before AS-PATH or MED). • After the attribute(s) are set, you may trigger it by soft or hard resetting the BGP peerings, it depends on the attribute, software, vendor…etc.
  • 69. 69 Implementation – Outbound Traffic Manipulation (1) • To manipulate outbound traffic, you can change LOCAL_PREF or WEIGHT (if your equipment is Cisco) attributes and apply them as an inbound policy. • This applied inbound policy affects outbound traffic. • You decide for which prefix(es) you will change attribute(s) to manipulate traffic flow (e.g. by defining a prefix-list), then you create a route-map to match prefix(es) & set attribute(s), finally you apply this policy under BGP process for a specific neighbor. • You can find the syntax below: R1(config)#route-map <X> permit 10 R1(config-route-map)#match ip address prefix-list <Y> !matches the subnets. R1(config-route-map)#set local-preference <value> !sets the LOCAL_PREF attribute. R1(config)#route-map <X> permit 20 !accepts the other remaining subnets, but does not modify anything on them. R1(config-router)#neighbor <a.a.a.a> route-map <X> in !under BGP process, inbound policy is applied for the neighbor.
  • 70. 70 Implementation – Outbound Traffic Manipulation (2) • Below example shows that, R1 sets LOCAL_PREF attribute to 300 for 192.168.41.0/24, 192.168.42.0/24, 192.168.43.0/24, and this policy is applied for neighbor R6 as an inbound policy. So, R1 receives those subnets from R6, and R1 modifies that attribute for 3 subnets and announces to iBGP peers. Now all iBGP peers know that for any traffic going to these 3 subnets, they will route them to R1. (as you see below, even if R3 is connected directly to R4, it chooses R1  R6  R5  R4 path) R1 changes the outbound traffic by doing this, all outbound traffic for these 3 subnets will go through R6.
  • 71. 71 Implementation – Outbound Traffic Manipulation (3) • Below example shows that, R1 sets WEIGHT attribute to 300 for 192.168.41.0/24, 192.168.42.0/24, 192.168.43.0/24, and this policy is applied for neighbor R6 as an inbound policy. So, R1 receives those subnets from R6, and R1 modifies that attribute for 3 subnets. But in this case, this only affects R1, because as you remember WEIGHT is only locally significant and is not announced. R1 sends traffic to R6 for these 3 subnets but other iBGP peers don’t, they’ll use R3 to reach them. R1 changes the outbound traffic by doing this, all outbound traffic for these 3 subnets will go through R6.
  • 72. 72 Implementation – Inbound Traffic Manipulation (1) • To manipulate inbound traffic, you can change AS_PATH or MED (Metric) attributes and apply them as an outbound policy. • This applied outbound policy affects inbound traffic. • You decide for which prefix(es) you will change attribute(s) to manipulate traffic flow (e.g. by defining a prefix-list), then you create a route-map to match prefix(es) & set attribute(s), finally you apply this policy under BGP process for a specific neighbor. • You can find the syntax below: R1(config)#route-map <X> permit 10 R1(config-route-map)#match ip address prefix-list <Y> !matches the subnets. R1(config-route-map)#set metric <value> !sets the MED attribute. R1(config)#route-map <X> permit 20 !advertises the other remaining subnets, but does not modify anything on them. R1(config-router)#neighbor <a.a.a.a> route-map <X> out !under BGP process, outbound policy is applied for the neighbor.
  • 73. 73 Implementation – Inbound Traffic Manipulation (2) • Below example shows that, R1 sets AS_PATH attribute by prepending 3 more AS numbers addition to original AS (1230 1230 1230 + 1230) for 192.168.11.0/24, 192.168.12.0/24, 192.168.13.0/24, and this policy is applied for neighbor R6 as an outbound policy. So, R1 advertises those subnets to R6 with a modified AS_PATH attribute, and R6 sees that those subnets are 4 AS / 4 hop away to reach. R6 also sees 4570 1230 for same subnets from R5, so R6 prefers R5 to reach them. R1 changes the inbound traffic by doing this, all inbound traffic for these 3 subnets will enter AS 1230 through R3.
  • 74. 74 Implementation – Inbound Traffic Manipulation (3) • Below example shows that, R1 sets MED (Metric) attribute to 1000 for 192.168.11.0/24, 192.168.12.0/24, 192.168.13.0/24, and this policy is applied for neighbor R6 as an outbound policy (since AS_PATH has a higher preference than MED, to make both paths same, we’ve prepended one more AS to our advertisements for 3 subnets). So, R1 advertises those subnets to R6 with a modified MED (Metric) attribute, and R6 sees that those subnets have a MED (Metric) value 1000. R6 also sees 0 MED (Metric) for same subnets from R5, so R6 prefers R5 to reach them. R1 changes the inbound traffic by doing this, all inbound traffic for these 3 subnets will enter AS 1230 through R3.