You are on page 1of 13

Advanced

CCIE Routing & Switching


v5.0
www.MicronicsTraining.com

Narbik Kocharians
CCSI, CCIE #12410
R&S, Security, SP

BGP
CCIE R&S by Narbik Kocharians Advanced CCIE R&S Work Book v5.0 Page 1 of 13
© 2015 Narbik Kocharians. All rights reserved
Lab 44 – Establishing a BGP session using the
correct TTL Value

Lo0 Lo0
1.1.1.1/32 2.2.2.2/24

.1 12.1.1.0/24
.2
R1 R2

This lab demonstrates the correct setting of TTL when


configuring BGP.

Let’s configure these two routers:

On R1:
R1(config)#int s1/2
R1(config-if)#ip addr 12.1.1.1 255.255.255.0
R1(config-if)#no shu

R1(config)#int lo0
R1(config-if)#ip addr 1.1.1.1 255.255.255.255

You can use an IGP of your choice to provide reachability to the loopback interfaces, in this case we will
use OSPF:

R1(config)#router ospf 1
R1(config-router)#netw 0.0.0.0 0.0.0.0 area 0

On R2:
R2(config)#int s1/1
R2(config-if)#ip addr 12.1.1.2 255.255.255.0
R2(config-if)#no shu

R2(config)#int lo0

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Work Book v5.0 Page 2 of 13
© 2015 Narbik Kocharians. All rights reserved
R2(config-if)#ip addr 2.2.2.2 255.255.255.255

R2(config)#router ospf 1
R2(config-router)#netw 0.0.0.0 0.0.0.0 area 0

You should see the following console message:

%OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Serial1/1 from LOADING to


FULL, Loading Done

To verify the configuration:

On R1:
R1#sh ip rou ospf | b Gate
Gateway of last resort is not set

2.0.0.0/32 is subnetted, 1 subnets


O 2.2.2.2 [110/65] via 12.1.1.2, 00:01:12, Serial1/2

On R2:
R2#sh ip rou ospf | b Gate
Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets


O 1.1.1.1 [110/65] via 12.1.1.1, 00:01:31, Serial1/1

Let’s establish an EBGP session using the loopback0 interfaces. R1 should be configured in AS 100, and R2
in AS 200:

On R1:
R1(config)#router bgp 100
R1(config-router)#neigh 2.2.2.2 remot 200
R1(config-router)#neigh 2.2.2.2 update-source lo0

On R2:
R2(config)#router bgp 200
R2(config-router)#neigh 1.1.1.1 remot 100
R2(config-router)#neigh 1.1.1.1 update-source lo0

Obviously the above configuration is not working. Is it the hop count?

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Work Book v5.0 Page 3 of 13
© 2015 Narbik Kocharians. All rights reserved
What should the hop count be set to?

Between the two routers the hop count should be set to 1, it is obvious that we don’t have another
router between R1 and R2, so why is it that BGP session between the two routers is not established?

When two BGP routers are forming a BGP session, they consult their routing table to ensure that the
neighbor’s configured IP address is in the routing table as directly connected.

This is the sanity check just like RIP. In RIP we can always disable this sanity check using the “No validate-
update-source”, can we disable the sanity check in BGP?

Yes, we can instruct BGP to disable this check using the “Neighbor disable-connected-check”. Let’s test
this:

On R1:
R1(config)#router bgp 100
R1(config-router)#neigh 2.2.2.2 disable-connected-check

On R2:
R2(config)#router bgp 200
R2(config-router)#neigh 1.1.1.1 disable-connected-check

You should see the following console message stating that the two routers have formed an EBGP session.

%BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up

What is the outgoing TTL? Is it set to one? Let’s verify:

On R1:
R1#sh ip bgp neighbors 2.2.2.2 | i TTL

Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1

Perfect!

Can we establish this session using the “Neighbor ebgp-multihop” command? Let’s configure and verify:

Let’s remove the “Neighbor disable-connected-check” command and replace it with “Neighbor ebgp-
multihop” command:

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Work Book v5.0 Page 4 of 13
© 2015 Narbik Kocharians. All rights reserved
R1(config)#router bgp 100
R1(config-router)#no neighbor 2.2.2.2 disable-connected-check

On R2:
R2(config)#router bgp 200
R2(config-router)#no neighbor 1.1.1.1 disable-connected-check

R2#cle ip bgp *

As we can see neighbor 1.1.1.1 is in idle state:

R2#sh ip bgp summ | b Neigh

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd


1.1.1.1 4 100 0 0 1 0 0 00:01:24 Idle

Let’s configure the “Neighbor ebgp-multihop” and test:

R2(config)#router bgp 200


R2(config-router)#neighbor 1.1.1.1 ebgp-multihop 2

On R1:
R1(config)#router bgp 100
R1(config-router)#neigh 2.2.2.2 ebgp-multihop 2

You should see the following console message:

%BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up

The reason this worked is NOT because the TTL should be set to two going from one loopback to the
other, we have tested that already in the previous example. The reason this worked is because we are
telling BGP that the neighbor is more than one hop away so don’t check your routing table because the
neighbor’s configured IP address is not going to be directly connected. Basically lying to BGP so it does
not perform the sanity check.

Can we establish an EBGP session using another method without using the previously used two
commands?
Yes, let configure and verify:

Let’s remove the “Neighbor ebgp-multihop” command and replace it with “Neighbor ttl-security hops”
command and verify:

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Work Book v5.0 Page 5 of 13
© 2015 Narbik Kocharians. All rights reserved
R1(config)#router bgp 100
R1(config-router)#no neigh 2.2.2.2 ebgp-multihop 2

R1#cle ip bgp *

On R2:
R2(config)#router bgp 200
R2(config-router)#no neigh 1.1.1.1 ebgp-multihop

We can see that neighbor adjacency between these two routers is down. Let’s configure the “Neighbor
ttl-security hops” command and verify:

R2(config)#router bgp 200


R2(config-router)#neigh 1.1.1.1 ttl-security hops 2

On R1:
R1(config)#router bgp 100
R1(config-router)#neighbor 2.2.2.2 ttl-security hops 2

You should see the following console message:

%BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up

Let’s verify the outgoing TTL:

R1#sh ip bgp neigh 2.2.2.2 | i TTL

Connection is ECN Disabled, Mininum incoming TTL 253, Outgoing TTL 255

With the “Neighbor ttl-security hops” command we are telling BGP to send the packets out with a TTL of
255, and accept a packet with TTL of 253 or higher. This means that the TTL should be 253…254 meaning
that the neighbor is two hops away.
Remember when we send a packet, it goes out with a TTL of 255 and the TTL decrements as it traverses
the routers. How did we get 253 or higher? Subtract 2 from 255, two is the configured TTL value.
Since we told BGP to accept a packet with a TTL of 2 it no longer consults the local routing table for the
neighbor’s configured IP address to be directly connected.

NOTE: If the “Neighbor ttl-security hops” command is set to 1, BGP will perform a sanity check and they
will fail to establish a BGP peer session.

To summarize the three commands:

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Work Book v5.0 Page 6 of 13
© 2015 Narbik Kocharians. All rights reserved
Neighbor ebgp-multihop – Sets the TTL of the packet to the configured value, if the value is omitted, it
will auto-set the value to 255. This is the IP TTL, there is no TTL field in any BGP packets, and it is wrong
to say EBGP packets have a TTL of 1. The correct statement is the IP TTL and NOT BGP TTL.

We can use this command in two different situations:


1 – If the EBGP neighbor is multiple hops away
2 – If the EBGP neighbor is directly connected but the peering is based on the Loopback interfaces. This is
one of the optional parameters that tells BGP not to consult its routing table to see if the neighbor’s
configured IP address is directly connected, this command will bypass BGP’s sanity check.

Neighbor disable-connected-check – Sets the IP TTL to 1. We use this command to tell BGP NOT to
consult its routing table to see if the neighbor’s configured IP address is directly connected, this
command disables BGP’s sanity check.

Neighbor ttl-security hops – The IP TTL configured in this command is the result of subtracting the
configured value from 255. If the value is set to 5, the outgoing TTL will always be set to 255 but you will
accept the incoming packets with a TTL of 250 (255-5) or higher, in this case we are claiming that the
neighbor is 5 hops away.
Another use of this command is to tell BGP not to consult its routing table to see if the neighbor’s
configured IP address is directly connected.

Is it possible to establish an EBGP session based on the loopback interfaces without using any of the
three commands?

Yes, let’s configure and verify:

On R2:

R2(config)#router bgp 200


R2(config-router)#no neigh 1.1.1.1 ttl-security hops 2

On R1:
R1(config)#router bgp 100
R1(config-router)#no neighbor 2.2.2.2 ttl-security hops 2

R1#cle ip bgp *
R1#

To accomplish this task in a creative way, we will use the IP unnumber command and change the
encapsulation of this link to PPP. To see the existing BGP’s configuration:

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Work Book v5.0 Page 7 of 13
© 2015 Narbik Kocharians. All rights reserved
R1#sh run | s router bgp

router bgp 100


bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 update-source Loopback0

R1(config)#int s1/2
R1(config-if)#ip unnumbered lo0
R1(config-if)#encap ppp

On R2:
R2#sh run | s router bgp

router bgp 200


bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 update-source Loopback0

R2(config)#int s1/1
R2(config-if)#ip unnumbered lo0
R2(config-if)#encap ppp

You should see the following console message:

%BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up

The big question is why and how did BGP form a BGP session?

When we configured “IP unnumbered lo0” it set the IP address of R1’s serial 1/2 interface to 1.1.1.1, let’s
verify:

R1#sh ip int br | ex un

Interface IP-Address OK? Method Status Protocol


Serial1/2 1.1.1.1 YES TFTP up up
Loopback0 1.1.1.1 YES manual up up

Then the PPP encapsulation is configured. In IPv4 when we encapsulate with a link with PPP, peer’s
neighbor route is injected into our routing table. This is the IP address of R2’s serial interface which is set
based on its loopback interface. Let’s verify:

R1#sh ip route | b Gate

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Work Book v5.0 Page 8 of 13
© 2015 Narbik Kocharians. All rights reserved
Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets


C 1.1.1.1 is directly connected, Loopback0
2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Serial1/2

Since the neighbors configured IP address is in our routing table as directly connected, BGP will form a
peer session.

Now, let’s raise this to a CCIE level:


Reload the routers and configure the following topology:
Lo0 Lo0 Lo0
1.1.1.1/32 2.2.2.2/32 3.3.3.3/32

.1 12.1.1.0/24
.2 .3
23.1.1.0/24
R1 R2 R3

On R1:
R1(config)#int s1/2
R1(config-if)#ip addr 12.1.1.1 255.255.255.0
R1(config-if)#no shu

R1(config)#int lo0
R1(config-if)#ip addr 1.1.1.1 255.255.255.255

On R2:
R2(config)#int s1/1
R2(config-if)#ip addr 12.1.1.2 255.255.255.0
R2(config-if)#no shut

R2(config)#int lo0
R2(config-if)#ip addr 2.2.2.2 255.255.255.255

R2(config)#int s1/3
R2(config-if)#ip addr 23.1.1.2 255.255.255.0
R2(config-if)#no shu

On R3:

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Work Book v5.0 Page 9 of 13
© 2015 Narbik Kocharians. All rights reserved
R3(config)#int s1/2
R3(config-if)#ip addr 23.1.1.3 255.255.255.0
R3(config-if)#no shut

R3(config)#int lo0
R3(config-if)#ip addr 3.3.3.3 255.255.255.0

To provide reachability, we will use OSPF:

On All Routers:
Rx(config)#router ospf 1
Rx(config-router)#netw 0.0.0.0 0.0.0.0 a 0

Now, let’s establish an EBGP session between R1 and R3 using their loopback0 interfaces. The question is
what should the TTL be set to?

Well, from R1’s perspective to get to the loopback0 interface of R3 we have to go over two routers, so
the TTL should be set to two. Let’s configure R1 in AS 100, and R3 in AS 300. Let’s configure and verify:

On R1:
R1(config)#router bgp 100
R1(config-router)#neigh 3.3.3.3 remote 300
R1(config-router)#neigh 3.3.3.3 update lo0
R1(config-router)#neigh 3.3.3.3 ebgp-multihop 2

On R3:
R3(config)#router bgp 300
R3(config-router)#neigh 1.1.1.1 remot 100
R3(config-router)#neigh 1.1.1.1 update lo0
R3(config-router)#neigh 1.1.1.1 ebgp-multihop 2

You should see the following console message:

%BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up

What if we remove the “Neighbor ebgp-multihop” command and replace it with “Neighbor disable-
connected-check”? will the neighbor adjacency be established?

The answer is a big NO, because the “Neighbor disable-connected-check” command sets the TTL to 1,
and the TTL must be 2 or more.

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Work Book v5.0 Page 10 of 13
© 2015 Narbik Kocharians. All rights reserved
Can we make this work without removing any BGP command, configuring GRE tunnel, IPsec or an IPnIP
tunnel?

Yes. Let’s configure and verify:

R3(config)#router bgp 300


R3(config-router)#no neigh 1.1.1.1 ebgp-multihop 2
R3(config-router)#neighbor 1.1.1.1 disable-connected-check

R3#cle ip bgp *
R3#

On R1:
R1(config)#router bgp 100
R1(config-router)#no neigh 3.3.3.3 ebgp-multihop 2
R1(config-router)#neigh 3.3.3.3 disable-connected-check

We can see that the neighbor adjacency is not established:

R1#sh ip bgp summ | b Neigh

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd


3.3.3.3 4 300 0 0 1 0 0 00:02:10 Idle

To configure an adjacency, we will configure “mpls ip” on the links that interconnect the routers:

R1(config)#int s1/2
R1(config-if)#mpls ip

On R2:
R2(config)#int s1/1
R2(config-if)#mpls ip

You should see the following console message:

%LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (1) is UP

R2(config)#int s1/3
R2(config-if)#mpls ip

On R3:
R3(config)#int s1/2

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Work Book v5.0 Page 11 of 13
© 2015 Narbik Kocharians. All rights reserved
R3(config-if)#mpls ip

You should see the following console message:

%LDP-5-NBRCHG: LDP Neighbor 2.2.2.2:0 (1) is UP

By default, the penultimate hop popper, in this case R2 will remove the label. In this step we will instruct
R2 not to remove the label.

On R1:
R1#sh mpls ldp binding 1.1.1.1 32
lib entry: 1.1.1.1/32, rev 10
local binding: label: imp-null
remote binding: lsr: 2.2.2.2:0, label: 16

The following command instructs the neighboring LSR (R2) not to remove the label:

R1(config)#mpls ldp explicit-null

To verify this configuration:

On R2:
R2#sh mpls ldp binding 1.1.1.1 32

lib entry: 1.1.1.1/32, rev 2


local binding: label: 16
remote binding: lsr: 3.3.3.3:0, label: 16
remote binding: lsr: 1.1.1.1:0, label: exp-null

On R3:
R3(config)#mpls ldp explicit-null

So far we have instructed the PHP (R2) not to pop the label, now the second problem that we face is the
TTL.
When an IP packet enters an MPLS network, the TTL of the IP packet is propagated to the TTL field in the
label, and as the labeled packet traverses hop by hop from router to router, the TTL field of the labeled
packet is decremented, and when the packet exits the MPLS network, the TTL of the labeled packet is
propagated to the TTL field in the IP packet.

Let’s instruct MPLS not to propagate the TTL back to the TTL field of the IP packet. With this
configuration, the routers (R1 and R3) will receive the packets with a TTL of 1. Let’s configure and verify:

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Work Book v5.0 Page 12 of 13
© 2015 Narbik Kocharians. All rights reserved
On All Routers:
Rx(config)#no mpls ip propagate-ttl

We should see the following console message on R1:

%BGP-5-ADJCHANGE: neighbor 3.3.3.3 Up

Erase the configuration and reload the routers before proceeding to the next lab.

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Work Book v5.0 Page 13 of 13
© 2015 Narbik Kocharians. All rights reserved