Advanced CCIE Routing & Switching: Narbik Kocharians CCSI, CCIE #12410 R&S, Security, SP

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
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)#int lo0
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

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)#neigh 1.1.1.1 update-source lo0
Obviously the above configuration is not working. Is it the hop count?
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)#neigh 2.2.2.2 disable-connected-check
On R2:
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:
R1(config-router)#no neighbor 2.2.2.2 disable-connected-check
On R2:
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)#neighbor 1.1.1.1 ebgp-multihop 2
On R1:
R1(config-router)#neigh 2.2.2.2 ebgp-multihop 2
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:
R1(config-router)#no neigh 2.2.2.2 ebgp-multihop 2
R1#cle ip bgp *
On R2:
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)#neigh 1.1.1.1 ttl-security hops 2
On R1:
R1(config-router)#neighbor 2.2.2.2 ttl-security hops 2
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:
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)#no neigh 1.1.1.1 ttl-security hops 2
On R1:
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:
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
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

C 1.1.1.1 is directly connected, Loopback0
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)#int lo0
On R2:
R2(config)#int s1/1
R2(config-if)#no shut
R2(config)#int lo0
R2(config)#int s1/3
On R3:
R3(config)#int s1/2
R3(config-if)#no shut
R3(config)#int lo0
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)#neigh 3.3.3.3 remote 300
R1(config-router)#neigh 3.3.3.3 update lo0
On R3:
R3(config-router)#neigh 1.1.1.1 update lo0
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.
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)#neighbor 1.1.1.1 disable-connected-check
R3#cle ip bgp *
R3#
On R1:
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
%LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (1) is UP
R2(config)#int s1/3
On R3:
R3(config)#int s1/2
%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:
On All Routers:
Rx(config)#no mpls ip propagate-ttl
We should see the following console message on R1:
Erase the configuration and reload the routers before proceeding to the next lab.

Advanced CCIE Routing & Switching: Narbik Kocharians CCSI, CCIE #12410 R&S, Security, SP

Uploaded by

Copyright:

Available Formats

Advanced CCIE Routing & Switching: Narbik Kocharians CCSI, CCIE #12410 R&S, Security, SP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Advanced CCIE Routing & Switching: Narbik Kocharians CCSI, CCIE #12410 R&S, Security, SP

Uploaded by

Copyright:

Available Formats

Advanced

CCIE Routing & Switching

This lab demonstrates the correct setting of TTL when

Let’s configure these two routers:

You should see the following console message:

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

To verify the configuration:

2.0.0.0/32 is subnetted, 1 subnets

1.0.0.0/32 is subnetted, 1 subnets

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

%BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up

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

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

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

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

R2(config)#router bgp 200

You should see the following console message:

%BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up

R2(config)#router bgp 200

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

To summarize the three commands:

We can use this command in two different situations:

Yes, let’s configure and verify:

R2(config)#router bgp 200

router bgp 100

router bgp 200

You should see the following console message:

%BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up

Interface IP-Address OK? Method Status Protocol

R1#sh ip route | b Gate

1.0.0.0/32 is subnetted, 1 subnets

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

To provide reachability, we will use OSPF:

You should see the following console message:

%BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up

Yes. Let’s configure and verify:

R3(config)#router bgp 300

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

You should see the following console message:

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

You should see the following console message:

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

R1(config)#mpls ldp explicit-null

To verify this configuration:

lib entry: 1.1.1.1/32, rev 2

We should see the following console message on R1:

%BGP-5-ADJCHANGE: neighbor 3.3.3.3 Up

You might also like