IN

TE

AL

SE

O
N

LY

<Course
BGP
Implementation
Title>

AL

SE

O
N

LY

BGP Implementation

IBGP Sessions

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

IN

TE

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 Sessions
EBGP 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.

www.juniper.net

AL

SE

O
N

LY

BGP Implementation

4-Byte AS Number Concept

4-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:

IN

TE

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 Compatibility

A 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

www.juniper.net

AL

SE

O
N

LY

BGP Implementation

4-Byte AS Number Compatibility Example

TE

The 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.

IN

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.

www.juniper.net

AL

SE

O
N

LY

BGP Implementation

Connecting IPv6 Sites Through an IPv4 Core Using 6PE

IN

TE

6PE 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.

www.juniper.net

BGP Implementation

O
N
SE

IN

TE

AL

[edit protocols]
user@PE1# show
ldp {
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;
}
}

[edit interfaces]
user@PE1# show
ge-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;
}
}
}

LY

Connecting IPv6 Sites Through an IPv4 Core Using 6PE (contd.)

www.juniper.net

AL

SE

O
N

LY

BGP Implementation

Additional 6PE Details

You 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.

TE

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.

IN

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.

www.juniper.net

AL

SE

O
N

LY

BGP Implementation

MP-BGP Next Hop

TE

If 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.

IN

IPv6 Link Local Address Peering

For 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.

www.juniper.net

AL

SE

O
N

LY

BGP Implementation

BGP Authentication

IN

TE

One 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# show
group 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.

www.juniper.net

BGP Implementation

BGP Authentication (contd.)

O
N

[edit protocols bgp]

user@R1# show
group 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;
}

LY

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.

IN

TE

AL

SE

[edit security]
user@R1# show
authentication-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;
}
}
}

10

www.juniper.net

AL

SE

O
N

LY

BGP Implementation

Default BGP Load Balancing

TE

For 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.

IN

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 Multihop

You 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.

www.juniper.net

11

BGP Implementation

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.

IN

TE

AL

SE

O
N

LY

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.

12

www.juniper.net

AL

SE

O
N

LY

BGP Implementation

IBGP Scaling Using Route Reflection

IN

TE

Route 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.

www.juniper.net

13

AL

SE

O
N

LY

BGP Implementation

IBGP Scaling Using Confederations

TE

Confederation 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.

IN

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.

14

www.juniper.net

AL

SE

O
N

LY

BGP Implementation

Time-Saving Tips

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 tasks in the scenario more efficiently, avoiding mistakes.

IN

TE

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.

www.juniper.net

15

AL

SE

O
N

LY

BGP Implementation

Attribute Manipulation with Policy

IN

TE

The Junos OS routing policy language provides a flexible framework for modifying any of the
attributes listed on the slide.

16

www.juniper.net

AL

SE

O
N

LY

BGP Implementation

Modifying BGP Attributes

TE

Because 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.

IN

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.

www.juniper.net

17

AL

SE

O
N

LY

BGP Implementation

Attribute Manipulation without Policy

In 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.

TE

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.

IN

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.

18

www.juniper.net

AL

SE

O
N

LY

BGP Implementation

Regular Community

IN

TE

Regular 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.

www.juniper.net

Extended Community
Because 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.

19

AL

SE

O
N

LY

BGP Implementation

Community Tag and Removal

IN

TE

The 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).

20

www.juniper.net

AL

SE

O
N

LY

BGP Implementation

Using Regex

Regex 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.

IN

TE

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.

www.juniper.net

21

BGP Implementation

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.

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

LY

The CLI show route aspath-regex command is also extremely useful troubleshooting tool and
helpful to quicken your verification steps through the exam
{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

IN

TE

AL

SE

O
N

22

www.juniper.net

AL

SE

O
N

LY

BGP Implementation

Remote Triggered Black Hole Concept

TE

Remote 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.

IN

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

www.juniper.net

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.

23

AL

SE

O
N

LY

BGP Implementation

RTBH Sample Topology

The 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.

IN

TE

24

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.

www.juniper.net

AL

SE

O
N

LY

BGP Implementation

RTBH Trigger Router Example Configuration

IN

TE

The 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.

www.juniper.net

25

AL

SE

O
N

LY

BGP Implementation

RTBH Filtering Router Example Configuration

IN

TE

The 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.

26

www.juniper.net

AL

SE

O
N

LY

BGP Implementation

Policy Creation

TE

When 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.

IN

Applying Policies

www.juniper.net

Make 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.

27

AL

SE

O
N

LY

BGP Implementation

Policy Time-Savers

TE

As 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.

IN

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.

28

www.juniper.net

AL

SE

O
N

LY

BGP Implementation

Sample Task and Topology

IN

TE

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

www.juniper.net

29

AL

SE

O
N

LY

BGP Implementation

What Is Really Being Asked?

IN

TE

The slide illustrates the required steps to accomplish the sample task.

30

www.juniper.net

AL

SE

O
N

LY

BGP Implementation

Verifying BGP Neighborships

IN

TE

Before 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.

www.juniper.net

31

AL

SE

O
N

LY

BGP Implementation

Route Verification

IN

TE

The 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.

32

www.juniper.net

AL

SE

O
N

LY

BGP Implementation

Define the Communities

TE

Define 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.

IN

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.

www.juniper.net

33

AL

SE

O
N

LY

BGP Implementation

Configure Import Policies

The 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.

TE

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.

IN

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

34

www.juniper.net

AL

SE

O
N

LY

BGP Implementation

Configure Export Policies

Next, 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.

IN

TE

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.

www.juniper.net

35

AL

SE

O
N

LY

BGP Implementation

Apply Import and Export Policies

The 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.

IN

TE

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

36

www.juniper.net

AL

SE

O
N

LY

BGP Implementation

Verify Exported Routes on R1

IN

TE

There 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.

www.juniper.net

37

AL

SE

O
N

LY

BGP Implementation

Verify Exported Routes on R1

IN

TE

The 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.

38

www.juniper.net