BGP Implementation

INTE

RNAL

USE

ONL

Y

BGP Implementation

2 www.juniper.net

IBGP SessionsBGP sessions fall into one of two categories: IBGP or EBGP.

IBGP sessions usually use loopback addresses because the underlying interior gateway protocol (IGP) normally provides redundant paths between two BGP speakers. BGP uses the AS path as a loop detection mechanism. Because the AS path is not changed within an AS, IBGP cannot send updates received from IBGP neighbors to other IBGP neighbors. This constraint requires that IBGP networks be designed with a full mesh of IBGP speakers. Configuring and maintaining a full mesh of sessions poses a challenge in bigger ISP networks. To overcome the problem, Internet service providers (ISPs) use route reflection, confederations, or a combination of the two scaling methods. In the exam, you should be ready to configure any of these methods. We discuss them later in this material.

EBGP SessionsEBGP sessions are usually established with directly connected neighbors across an AS boundary. EBGP takes the IP time to live (TTL) value of 1 by default. You can optionally tune up the parameters of both IBGP and EBGP to establish the sessions as needed.

Upon receiving an update BGP always checks the BGP next hop for reachability. Recall that BGP next hop is changed over EBGP sessions but not over IBGP sessions. You can either change the next hop to self with policy at the AS boundary router (ASBR) before sending an update to IBGP neighbors, or you can configure the ASBR external interface as IGP passive. You should know how to use both approaches for the exam. We review routing policies later in this material.

INTE

RNAL

USE

ONL

Y

BGP Implementation

www.juniper.net 3

4-Byte AS Number Concept4-byte AS numbers have been created to solve the 2-byte AS number depletion problem. There are four BGP data entities that carry AS numbers:

AS_PATH attribute;

AGGREGATOR attribute;

COMMUNITIES attribute;

The Open message.

A new capability code 65 is used in the Open message to negotiate support of the 4-byte AS number between two BGP speakers. Two new optional transitive attributes are added to convey 4-byte AS number information: AS4_PATH and AS4_AGGREGATOR. BGP communities are supported in 4-byte AS number environments by using a new Extended Community attribute called the 4-Octet AS Specific BGP Extended Community.

4-Byte AS Number CompatibilityA reserved 2-byte AS number, 23456, called AS_TRANS, is used for interoperability with the old BGP implementations that do not understand the 4-byte AS numbers

INTE

RNAL

USE

ONL

Y

BGP Implementation

4 www.juniper.net

4-Byte AS Number Compatibility ExampleThe slide shows a sample BGP topology with four autonomous systems. One old AS 65000 that does not understand 4-byte AS numbers. Because of that barrier, the ASBRs of the old AS are configured to peer with AS_TRANS 23456 as a neighboring AS. AS 110000, detecting that the neighboring AS is the old AS, puts the AS_TRANS to the AS_PATH as a placeholder for its own AS and for any other 4-byte AS numbers appearing on the path. AS 120000 uses both AS_PATH and AS4_PATH attributes to reconstruct the path.

Two configuration methods exist to configure a 4 byte AS number in the Junos operating system:

1. AS-plain notation:

[edit routing-options]user@R1# show autonomous-system 100000;

2. AS-dot notation:

[edit routing-options]user@R1# show autonomous-system 1.34464;

Note: We recommend that you use only one method across the domain to avoid confusion.

INTE

RNAL

USE

ONL

Y

BGP Implementation

www.juniper.net 5

Connecting IPv6 Sites Through an IPv4 Core Using 6PE6PE is a technique that provides the interconnection of IPv6 sites over an IPv4 MPLS cloud. A 6PE router is an ASBR that is directly connected to an IPv6 island. The interface between the edge router of the IPv6 island and the 6PE router is a native IPv6 interface. The ISP backbone network is built on IPv4 and MPLS technologies. The 6PE concept is relative to the Layer 3 VPN, where customer packets are transported over the ISP network in MPLS packets.

You can run either LDP or RSVP signalled LSPs in the core. Configure BGP PE to PE sessions as multiprotocol sessions supporting IPv4 and IPv6 families. The Junos OS sets the BGP next hop in IPv4-mapped IPv6 address in the form of ::ffff:172.27.255.1 automatically. You must include IPv6 tunneling setting under protocols mpls to enable the Junos OS to populate the inet6.3 table with these addresses in addition to the matching IPv4 loopback addresses in inet.3 table.

The following configuration example emphasizes the essential steps required to provision the 6PE service. The ge-0/0/1 is the native IPv6 interface that is connected to the IPv6 island. All core-facing interfaces must be configured with family inet, inet6, and MPLS support. In our case, ge-0/0/2 is the core-facing interface. Protocols MPLS is configured with IPv6-tunneling to make use of the inet6.3 table. Finally, BGP is configured to support the inet6 labeled-unicast family. The labeled-unicast knob makes BGP convey an inner label along with an IPv6 route that allows the advantage of label stacking. Explicit null is mandatory configuration for the 6PE application. This setting makes BGP always advertise the inner label of 2, which is known as the IPv6 explicit null label.

Continued on next page.

INTE

RNAL

USE

ONL

Y

BGP Implementation

6 www.juniper.net

Connecting IPv6 Sites Through an IPv4 Core Using 6PE (contd.)[edit interfaces]user@PE1# showge-0/0/1 { unit 0 { family inet6 { address 8001::2/126; } } } ge-0/0/2 { unit 0 { family inet { address 10.255.2.1/24; } family inet6; family mpls; } } lo0 { unit 0 { family inet { address 10.255.255.16/32; } } }

[edit protocols]user@PE1# showldp { interface ge-0/0/2.0; } mpls { ipv6-tunneling; interface ge-0/0/2.0; }bgp { group to_PE2 { type internal; local-address 10.255.255.16; family inet6 { labeled-unicast { explicit-null; } } neighbor 10.255.255.15; } group to_CE1 { local-address 8001::2; family inet6 { unicast; } peer-as 200; neighbor 8001::1; }}

INTE

RNAL

USE

ONL

Y

BGP Implementation

www.juniper.net 7

Additional 6PE DetailsYou do not need to configure BGP next hop self policy to change the next hop for EBGP-received IPv6 routes before sending them to remote 6PE routersthis change is done automatically. The Junos OS sets the IPv4-mapped IPv6 address as the next hop.

When the 6PE router receives an update, it checks the BGP next hop in the inet6.3 table and once an MPLS LSP is established to the advertising peer, the update is processed.

If the routing between the 6PE ASBR and the IPv6 island is not BGP, then you must configure proper redistribution policy on the 6PE router.

INTE

RNAL

USE

ONL

Y

BGP Implementation

8 www.juniper.net

MP-BGP Next HopIf you use IPv4 BGP session to convey multiprotocol routing information, then according to MP-BGP specification, BGP next hop is encoded using the same address family as the carried NLRI. To fulfill the requirement for conveying IPv6 network layer reachability information (NLRI), the Junos OS encodes BGP next hop into IPv4-compatible address. This address takes a form of ::172.27.255.1. (::ac1b:ff01) for the matching 172.27.255.1 IPv4 address. For a BGP-receiving peer to use the next hop, it must know how to reach it. You must configure both exchanging sides with IPv4-compatible IPv6 addresses.

IPv6 Link Local Address PeeringFor IPv6 native peering, you can use either global addresses or link-local autogenerated addresses if the neighbor is on the same connected network (EBGP). Note though, that in the latter case, you must configure local interface in the BGP stanza because the link-local address is unique only on the link.

INTE

RNAL

USE

ONL

Y

BGP Implementation

www.juniper.net 9

BGP AuthenticationOne possible exam task might be configuring BGP authentication. By default, authentication for BGP sessions is disabled. There are two approaches to configuring BGP authentication: configuring a static key or configuring key chains. The latter method allows hitless authentication key rollover because a key chain can be configured with several keyseach of them having a specified activation date and time. Key chains also allow you to choose which authentication algorithm to use. If you are using static key chains, there is only one authentication algorithmMD5. Hence, you must configure only one authentication key.

Recall that authentication can be configured under BGP protocol, group, or neighbor level, and the most specific application overrides those of less specific. The following snippet shows an example configuration for the MD5 authentication. The authentication key is always shown in the hashed form, however, you must enter it as a plain text while configuring the key from the keyboard.

[edit protocols bgp]user@R1# showgroup int-65503 { type internal; authentication-key "$9$cT7SvLbs4aZjNd2aZjkq69Au1tO"; ## SECRET-DATA local-address 192.168.100.1; neighbor 192.168.100.2;}

Continued on next page.

INTE

RNAL

USE

ONL

Y

BGP Implementation

10 www.juniper.net

BGP Authentication (contd.)To enable key chain BGP authentication. you must configure three parts. The following configuration is an example of enabling key chain BGP authentication. First, you must specify which authentication algorithm you want to use under the BGP protocol, group, or neighbor level. You can choose md5, hmac-sha-1-96, or aes-128-cmac-96 authentication algorithms. Then, you must reference a key chain that will be used. Finally, you must configure the key chain under the security authentication-key-chains hierarchy. Each key in a key chain is identified by its number from 0 to 63, and you must specify a secret and a start-time.

[edit protocols bgp]user@R1# showgroup int-65503 { type internal; authentication-algorithm hmac-sha-1-96; authentication-key-chain my-key-chain; local-address 192.168.100.1; neighbor 192.168.100.2;}

[edit security]user@R1# showauthentication-key-chains { key-chain my-key-chain { key 0 { secret "$9$mPz69Cu1EytuNb2aiHtuOBIc"; ## SECRET-DATA start-time 2011-01-01.06:00:00; } key 1 { secret "$9$cHArK8-VYZUHX7UHqmF3Sre"; ## SECRET-DATA start-time 2011-07-01.06:00:00; } }}

INTE

RNAL

USE

ONL

Y

BGP Implementation

www.juniper.net 11

Default BGP Load BalancingFor IBGP, if a BGP peer receives more than one copy of the same route from several neighbors, the BGP algorithm always selects only one best route. For IBGP, if a preferred neighbor advertises more than one prefix and the path to the preferred neighbor uses IGP with equal-cost multipath (ECMP), then the Junos OS uses per-prefix load-balancing.

For EBGP, each session is usually associated with one physical path to the neighbor, so for the EBGP-received prefixes, the algorithm selects only one best path associated with only one physical next hop for each of the routes.

Load Balancing with MultihopYou might be asked to take advantage of having more than one physical connections between two EBGP peers. Such a setup provides redundancy as well as the ability to load-balance traffic over several physical links. To implement the balancing with multihop, you must establish a multihop EBGP session. Recall that the default IP TTL for EBGP sessions is 1, so explicit multihop configuration is required. You can adjust the TTL value in the multihop configuration, which by default is 64. Once the multihop EBGP session is established, when BGP receives updates from an EBGP neighbor, the BGP next-hop evaluation reveals more than one physical next hop, so BGP selects among them in the per-prefix manner.

Continued on next page.

INTE

RNAL

USE

ONL

Y

BGP Implementation

12 www.juniper.net

Load Balancing with Multipath (contd.)Multipath is another way of load-balancing with EBGP. In contrast to multihop, multipath is a balancing over many sessions. In other words, when a BGP speaker has more than one EBGP session with a neighboring AS with multipath enabled, the speaker does not compare the router ID and peer IP address in the BGP route selection algorithm. So, when the same prefix is received from one of the neighbors configured with multipath, and this prefix is equal from the BGP route selection algorithm view up to the step comparing router ID, BGP selects one of the updates in a pseudo-random fashion. If multiple prefixes exist, they are balanced among the sessions and the corresponding physical next hops in the per-prefix manner.

Note that in both multihop and multipath load-balancing, the balancing type is per-prefix, hence the kernel puts only one physical next hop for a prefix into the forwarding table. You can extend the balancing by configuring per-flow load-balancing that makes the kernel list all the physical next hops in the forwarding table.

INTE

RNAL

USE

ONL

Y

BGP Implementation

www.juniper.net 13

IBGP Scaling Using Route ReflectionRoute reflection network solves the full-mesh IBGP problem by allowing IBGP-learned routes to be re-advertised to IBGP peers. This re-advertisement is allowed only on route reflectors (RR). Together, the RR and its peers, called clients, form a cluster. RR does not change any of the BGP attributes and adds two additional ones: cluster list and originator that are used to prevent loops. Usually in an ISP environment, the RRs are redundant to protect clients from isolation in case of link failure or router failure.

In the exam, you might be asked to design your network with route reflection given certain constraints such as the amount of clusters, the amount of RRs, or the amount of clients within a single cluster.

From an RR perspective, all the peering sessions fall into one of three categories: client IBGP sessions, non-client IBGP sessions, and EBGP sessions. Reflectors re-advertise updates that they receive from clients to other clients, non-clients, and EBGP peers. Reflectors re-advertise updates received from non-clients to clients and EBGP peers but not to other non-clients. Note that because of this activity, RRs must be fully meshed.

Clients within a cluster can be fully meshed as well. You can reduce the amount of advertisements within a cluster where clients are fully meshed by configuring an RR with no-client-reflect knob.

In a redundant cluster with more than one route reflector, the RRs can be either clients or non-clients to each other. You can configure them both ways in the exam.

INTE

RNAL

USE

ONL

Y

BGP Implementation

14 www.juniper.net

IBGP Scaling Using ConfederationsConfederation network is another approach to solving the full-mesh IBGP problem. The confederation concept is breaking up the network into smaller pieces named sub-ASs. The connectivity between sub-ASs is maintained using EBGP-type sessions, referred to as confederation BGP (CBGP) sessions. CBGP peers add their sub-AS number to the AS path, which is used to prevent loops. When routes are advertised out of the confederation, the ASBRs remove the sub-AS numbers from the AS_PATH attribute. Other BGP attributes are not modified over the CBGP sessions.

Recall that the sub-AS numbers are not used by BGP route selection algorithm when comparing AS path lengths.

In the exam, you might be asked to configure a confederation network, providing redundancy to ensure that none of the routers in the confederation become isolated in case of a single link or router failure. This requirement forces you to carefully design your network, for instance, with each of the sub-AS islands connected to other sub-ASs with at least two peering sessions.

To configure confederation, you must specify a router AS as the sub-AS and configure the confederation by using the confederation keyword with all the sub-ASs listed as members of the confederation. The CBGP sessions are configured as EBGP sessions. However, CBGP can utilize the redundant paths of an IGP, similar to IBGP sessions. Normally, you might want to configure the CBGP sessions with the local-address loopback. Note also that because the CBGP sessions are external, you must configure multihop.

INTE

RNAL

USE

ONL

Y

BGP Implementation

www.juniper.net 15

Time-Saving TipsRead the entire exam, and each scenario task carefully before starting the configurations for the given scenario to avoid making unnecessary mistakes and having to redo tasks. If you plan well, you can complete all tasks in the scenario more efficiently, avoiding mistakes.

Using the topology maps provided, or alternatively redrawing the topology and planning the route reflection or confederation design will make it easier to ensure that the design meets all the exam criteria in terms of redundancy and so on.

You can consider decomposing the tasks into IPv4 and IPv6 tasks. For instance, you can configure your 6PE application as a standalone task. Be careful to properly integrate the tasks.

The Junos OS BGP implementation mandates the use of BGP groups for all neighbors. Carefully consider the efficient grouping of neighbors to apply your policies in more logical manner. Think in terms of policies.

Consider reusing configurations when possible, using copy and paste. Efficient use of an off-line text editor such as Notepad can speed up these tasks significantly. Remember that the Junos OS has multiple ways of achieving copy and paste. Take time to explore the benefits of using these different tools.

INTE

RNAL

USE

ONL

Y

BGP Implementation

16 www.juniper.net

Attribute Manipulation with PolicyThe Junos OS routing policy language provides a flexible framework for modifying any of the attributes listed on the slide.

INTE

RNAL

USE

ONL

Y

BGP Implementation

www.juniper.net 17

Modifying BGP AttributesBecause the default BGP behavior is to leave the BGP next-hop unchanged when re-advertising and EBGP learned destination to IBGP neighbors, and in the event that this prefix is not reachable within the AS, routing policy to modify the BGP next-hop will often be used to avoid routes being hidden on other routers in the same AS. The IP address used will be the address used for the IBGP session.

Use of the Local Preference attribute is commonplace in Service Provider policy deployment, and is used to determine the exit point from the local AS. The Local Preference attribute cannot be sent to EBGP neighbors, however is maintained when advertising to CBGP neighbors.

The default value of the Origin attribute is IGP, which is the strongest value. This can be changed in routing policy to negatively bias the advertisement from the local router in most cases. An interesting note regarding the Origin attribute is that it can be changed in an export policy to other BGP speakers, but can also be applied in an import policy to change the local routers perspective on a better/worse path for the respective destinations.

The MED attribute will most commonly be used to affect the inbound traffic from a neighboring AS when there are multiple links between the two ASs. Similarly to Origin changing the MED is by default a negative bias mechanism.

AS path prepending (local AS) or expanding (previous AS) is used to negatively bias the advertised prefixes.

INTE

RNAL

USE

ONL

Y

BGP Implementation

18 www.juniper.net

Attribute Manipulation without PolicyIn some circumstances, it might be simpler to apply changes to attributes without requiring policies. This affects all destinations equally, and of course does not provide the flexibility of the Junos OS routing policy language.

The as-override option is most commonly used in the Layer 3 VPN environment when the customers AS number is the same for different sites in a VPN to avoid the inevitable BGP path loop detection mechanism.

When private AS numbers are used, they should not be advertised outside of the service providers network, and using the remove-private configuration parameter results in any 2-byte AS numbers in the 64512 through 65534 range being stripped off the AS path attribute.

The metric-out can be configured at the global, group, or neighbor level to affect the MED value advertised, but can also be parameterised with a value, or derive the value advertised from the IGP metric. In the event that topological changes result in this value constantly changing, the minimum-igp parameter is recommended.

Similarly, the local-preference value can be configured globally, at the group level, or for individual neighbors. Note that this parameter applied to EBGP neighbors will set the local preference on imported routes before putting the routes into the routing table.

INTE

RNAL

USE

ONL

Y

BGP Implementation

www.juniper.net 19

Regular CommunityRegular communities are 32-bit long communities divided into two main sections: first 16 bits to encode an AS number, last 16 bits to encode a unique number assigned by the AS. Three community attribute values are designated as well-known communities. The three communities are no-export, no-advertise, and no-export-subconfed. No-export is used to limit a route propagation scope to a neighboring AS only. Similarly, no-export-subconfed is used to limit a route propagation scope to a neighboring sub-AS only. No-advertise is the strictest one, which limits a route propagation scope to a neighboring router only.

Extended CommunityBecause regular communities do not provide enough expansion for services such as VPN, Extended community are used. An extended community is an 8-bytes value divided into two main sections: a 2-bytes type field and a 6-bytes unique set of data in a format defined by the type field. Different types of extended communities exist, such as 2-byte AS specific, 4-byte AS specific, IPv4 address specific, IPv6 address specific communities.

INTE

RNAL

USE

ONL

Y

BGP Implementation

20 www.juniper.net

Community Tag and RemovalThe Junos OS policy then clause allows multiple actions for the community setting. To overwrite the community results in all other previously set communities, use the set action. If the desired result is to not affect other communities, use the add action. To remove all or some communities, use the delete action in combination with the flexible regular expressions (regex).

INTE

RNAL

USE

ONL

Y

BGP Implementation

www.juniper.net 21

Using RegexRegex offer powerful pattern matching capabilities. You can use regex with both AS path and community BGP attributes in routing policy. The regex format is term operator, where the term represents an AS number in AS path regular expressions.

There are two steps to using the as-path option in the Junos OS routing policy language. The first involves the definition of the actual regular expressions, which in turn are referenced by a user defined name.

You can use regular expression with BGP communities to find communities that match a given pattern. Similarly to the AS path regex discussed, community use in routing policy follows the same format, requiring the community to first be defined and then referenced in the routing policy. There is one difference with communities compared to aspath-regex, in that where aspath-regex typically only gets used as a match condition in a policy, a community not only can be used as a match condition but also in the action part of a term or policy to either set the community, add the community or delete the community.

It should be noted that when multiple community definitions are listed in the FROM statement, this list is evaluated as a logical OR for match purposes. However, listing multiple communities when defining them results in logical AND functionality.

Continued on next page.

INTE

RNAL

USE

ONL

Y

BGP Implementation

22 www.juniper.net

Using Regex (contd.)Two forms of regular expressions can be used with communities: simple and complex. Simple community regex can contain only asterisk * or dot . wildcard characters. The asterisk matches any single value and the dot matches any single digit.

You can also use complex regular expressions with communities. The complex regex format is term operator. A community regex is character based, unlike the regular expressions used with AS paths, which match entire AS numbers.

The Junos CLI allows for matching routes that have the respective community by using the community regex or using the name of a regex configured on the local router.

The CLI show route aspath-regex command is also extremely useful troubleshooting tool and helpful to quicken your verification steps through the exam

Below is a list of some common regex operators and their definitions.

{m} Matches exactly m instances of the term

{m,} Matches m or more instances of the term

{m,n} Matches at least m and at most n instances of the term

* Matches 0 or more instances of the term

+ Matches one or more instances of the term

? Matches 0 or 1 instances of the term

| Matches one of the two terms on either side of the pipe symbol

- Matches an inclusive range of terms

() Matches a null value as a term

[] Matches a range or an array of digits

INTE

RNAL

USE

ONL

Y

BGP Implementation

www.juniper.net 23

Remote Triggered Black Hole ConceptRemote Triggered Black Hole (RTBH) is a technique for the mitigation of denial of service (DoS) attacks normally used by ISPs to protect their customers. RTBH is based on triggered advertisement of a route with discard next hop upon detection of DoS attack. This technique allows the DoS traffic to be discarded.

RTBH filtering is more efficient than firewall filters because routers can forward traffic at a much higher rate than they can filter with firewall filters.

Two types of RTBH exist: destination-based and source-based.

The destination-based RTBH sets the discard route for the address range of a customer being attacked. All packets towards this range are dropped.

The source-based RTBH works in combination with unicast RPF. It sets the discard route for the address ranges where DoS packets are originated. These packets do not pass the unicast RPF check and are dropped. The source-based RTBH can selectively drop packets directed to a customer being attacked.

INTE

RNAL

USE

ONL

Y

BGP Implementation

24 www.juniper.net

RTBH Sample TopologyThe slide shows a sample network topology for Remote Triggered Black Hole discussions. To implement the RTBH, you must configure several steps:

Configure a trigger router that will generate triggered updates in case of DoS attack detection. Make sure that the triggered updates will not leave the local AS.

Configure a BGP policy on ASBR so that triggered updates with a chosen community will have their next hop set to the discard.

If source-based filtering is used, configure unicast RPF on the ASBRs external interfaces.IN

TERN

AL U

SE O

NLY

BGP Implementation

www.juniper.net 25

RTBH Trigger Router Example ConfigurationThe slide shows a trigger router example configuration. The key point in the configuration is using a special community defined for RTBH application 100:666. Upon detection of a DoS attack, the trigger router will advertise a route that has to be black-holed to ASBRs.

INTE

RNAL

USE

ONL

Y

BGP Implementation

26 www.juniper.net

RTBH Filtering Router Example ConfigurationThe slide shows a filtering router (usually an ASBR) example configuration. The filtering router applies an import policy that sets the next hop to discard for the routes tagged with RTBH community.

INTE

RNAL

USE

ONL

Y

BGP Implementation

www.juniper.net 27

Policy CreationWhen creating your policies it is very important to consider the order of your terms. As you are aware, a route can only be accepted or rejected once. If you are not careful you might accept or reject a route before you get to the term that you created to address this route. Make sure you are aware of the BGP default policy and which routes are accepted and rejected.

Applying PoliciesMake sure you apply the policies you create. It seems very obvious, but it is easily overlooked when configuring multiple routers and multiple policies. You must also make sure you apply the policy correctly as an import or export policy. It is also important to keep in mind that the order of your policies being applied is very important.INTE

RNAL

USE

ONL

Y

BGP Implementation

28 www.juniper.net

Policy Time-SaversAs mentioned before, read the entire exam, and each scenario task carefully before starting the configurations for the given scenario to avoid making unnecessary mistakes and having to redo tasks. If you plan well, you can complete all policy tasks in the exam more efficiently, avoiding costly mistakes.

Do not just start configuring your policies. Strategically plan which tasks can be combined into a single policy using separate terms. It might be a good idea to outline which tasks apply to each router so you know what policies need to be created as you move from router to router during the exam.

Many routers require the same policies. To save crucial time, reuse as many policies and terms that you can by using some method of copy and paste.INTE

RNAL

USE

ONL

Y

BGP Implementation

www.juniper.net 29

Sample Task and TopologyThe slide displays the sample task and topology. We analyze this task in the next set of slides.

INTE

RNAL

USE

ONL

Y

BGP Implementation

30 www.juniper.net

What Is Really Being Asked?The slide illustrates the required steps to accomplish the sample task.

INTE

RNAL

USE

ONL

Y

BGP Implementation

www.juniper.net 31

Verifying BGP NeighborshipsBefore you start configuring it is important to verify the baseline for the task. You must verify that you at least have BGP neighbors, both internal and external neighborships. As the slide illustrates, R1 has three internal neighbors and one external neighbor. These neighbors are consistent with the topology. You may also not that we are learning routes from three of the four neighbors.

INTE

RNAL

USE

ONL

Y

BGP Implementation

32 www.juniper.net

Route VerificationThe slide outputs show that there are routes present from each of the external network in R1s routing table. This output indicates that we are receiving routes from the external peers. It also indicates that the next hops for the external routes are being altered within the IBGP network.

INTE

RNAL

USE

ONL

Y

BGP Implementation

www.juniper.net 33

Define the CommunitiesDefine the communities that will be used to differentiate the routes. In our example network we have separate unique networks to assist with illustrating the behavior. With unique individual network routes you could easily match on the prefix range and block the routes that way. In the exam you could see overlapping networks as well as duplicate routes from multiple peers, so we are using community tags.

It is recommended that you use the same community names throughout your IBGP core to avoid confusion. This task is a prime example where copy and paste can save you some time.

INTE

RNAL

USE

ONL

Y

BGP Implementation

34 www.juniper.net

Configure Import PoliciesThe next step is to create import policy. Creating the import policy to accomplish this task is simple, but can become complicated when you add additional constraints to incoming routes. Be sure to account for policy evaluation rules when you are configuring a policy with multiple terms.

As the output indicates, the routes learned from the Provider peer are being tagged with the p-routes community that was defined in the previous step.

Though not shown here, you must also define similar import policies on the other two ASBR routers.

INTE

RNAL

USE

ONL

Y

BGP Implementation

www.juniper.net 35

Configure Export PoliciesNext, you should define the export policy. The export policy should block routes learned from the Transit-1 router from being advertised to the Provider router. This slide provides an example of the steps to create this policy.

Though not shown here you must also create a similar policy on R3 to block routes learned from the Provider router from being advertised to the Transit-1 router.

INTE

RNAL

USE

ONL

Y

BGP Implementation

36 www.juniper.net

Apply Import and Export PoliciesThe final configuration step is applying the import and export policies to the appropriate EBGP sessions. Remember to be careful with directionality when applying the policies.

Make sure you also apply to import and export policies on the other ASBRs where applicable.

INTE

RNAL

USE

ONL

Y

BGP Implementation

www.juniper.net 37

Verify Exported Routes on R1There are many ways to verify this task. The example on the slide is one method. You can see that we are not advertising any of the 100.100.0/16 routes to the Provider peer. The slide also highlights the AS paths indicating all routes originated in the Customer-1 AS.

INTE

RNAL

USE

ONL

Y

BGP Implementation

38 www.juniper.net

Verify Exported Routes on R1The output on the slide is from the perspective of R3. During the verification phase of your exam, you should make sure you accomplished the entire task. You can see that we are not advertising any of the 150.150.0/16 routes to the Provider peer. The slide also highlights the AS paths indicating all routes originated in the Customer-1 AS.

INTE

RNAL

USE

ONL

Y