Lessons learned:
BGP Transport
BGP used TCP port 179 for
transport
-implies that BGP needs IGP first
BGP neighbor statement tells process to….
-listen for remote address via TCP 179
-initiate a session to remote address via TCP 179
-if collision, higher router-id becomes TCP client
If we cannot establish basic IP reachability then we cannot
establish the TCP session.
Enabling basic BGP
process between two routers.
TOPOLOGY:
Let’s firs setup a basic peering – from the topology I will
user R9 and R8, with their AS numbers being the numbers of the routers.
Before we start the process – we can turn on a few debugs -
One to look at the actual BGP peering messages and the other
is a low level debug for the IP transport.
The current underlying IGP is EIGRP. When we run the debug
we want to make sure we filter out the EIGRP and only debug the BGP packets.
To do this we will need to create an extended access-list.
access-list 100 deny
eigrp any any
access-list 100
permit ip any any
We can then turn on the debug on both R8 and R9. So then in
our output we shouldn’t see any EIGRP hellos and updates.
R9#debug ip packet detail 100
IP packet debugging is on (detailed) for access list 100
R9#
-------------------------------------------------------------------------------------------------------------------------------
We can verify the debug is working by sending a ping to
neighbor and look at the debug output.
R9#ping 192.168.89.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.89.8, timeout is 2
seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max =
1/8/16 ms
R9#
*Mar 1 02:11:19.183: IP:
tableid=0, s=192.168.89.9 (local), d=192.168.89.8 (Serial0/0), routed via FIB
*Mar 1 02:11:19.187:
IP: s=192.168.89.9 (local), d=192.168.89.8 (Serial0/0), len 100, sending
*Mar 1
02:11:19.187: ICMP type=8, code=0
*Mar 1 02:11:19.191:
IP: tableid=0, s=192.168.89.8 (Serial0/0), d=192.168.89.9 (Serial0/0), routed
via RIB
-------------------------------------------------------------------------------------------------------------------------------
FYI this debug generates a large amount of data – we would
normally want send this output to a syslog of buffer.
To limit the output we can also turn off timestamps
EX:
R9(config)#no service timestamps
We will also turn on debug ip bgp
This will essential turn on all debugs for the address
family – Ipv4 Unicast.
R9#debug ip bgp
BGP debugging is on for address family: IPv4 Unicast
R9#
Under each router I’ve setup basic BGP peering. With the
neighbor remote-as command and advertised each routers loopbacks networks
R8 = 8.8.8.0 /24
R9 = 9.9.9.0/24
===================
IP: s=192.168.89.8 (Serial0/0), d=192.168.89.9, len 44, rcvd
0
TCP src=17950, dst=179, seq=488103526,
ack=0, win=16384 SYN -- Note: here from
the debug we see the TCP src port, then the destination is port = 179 . We also
see this is a SYN packet.
IP: tableid=0, s=192.168.89.9 (local), d=192.168.89.8
(Serial0/0), routed via FIB
IP: s=192.168.89.9 (local), d=192.168.89.8 (Serial0/0), len
40, sending
TCP src=179,
dst=17950, seq=0, ack=488103527, win=0
ACK RST
Notice: the final
part of the output is an ACK RST> this is because I have not yet added the
neighbor statement on this router only (R9)
Now here’s the full
output after Ive added the neighbor statement.
BGP: 192.168.89.8 went from OpenConfirm to Established
%BGP-5-ADJCHANGE: neighbor 192.168.89.8 Up
IP: tableid=0, s=192.168.89.9 (local), d=192.168.89.8
(Serial0/0), routed via FIB
IP: s=192.168.89.9 (local), d=192.168.89.8 (Serial0/0), len
92, sending
TCP src=179,
dst=29773, seq=2220868845, ack=3315269002, win=16268 ACK PSH
IP: s=192.168.89.8 (Serial0/0), d=192.168.89.9, len 78, rcvd
0
TCP src=29773,
dst=179, seq=3315269002, ack=2220868897, win=16268 ACK PSH
IP: tableid=0, s=192.168.89.9 (local), d=192.168.89.8
(Serial0/0), routed via FIB
IP: s=192.168.89.9 (local), d=192.168.89.8 (Serial0/0), len
78, sending
TCP src=179,
dst=29773, seq=2220868897, ack=3315269040, win=16230 ACK PSH
IP: s=192.168.89.8 (Serial0/0), d=192.168.89.9, len 40, rcvd
0
TCP src=29773,
dst=179, seq=3315269040, ack=2220868935, win=16230 ACK
Once I configured the neighbor statement, the router is now
listening for the session. The key is that BGP is not dynamic and it cannot
learn its peers automatically they must be specified manually.
Note: It’s important in the BGP network to figure out what
is the actual route between the two neighbors before we actually establish the
peering. This scenario was between two neighbors only but you can see in the
RST in the debugs, if there was multiple paths and the router was not
configured correctly, it could keep us from establishing the peering.
Especially if the routers are more than one HOP away. It’s then going to depend
on the routing table to determine where the session is going to be allowed.
-------------------------------
EBGP Multi-hop.
Based on the topology let’s assume now that R9 (BGP AS9)
want to peer with R3 (BGP AS 3) – this would be considered a multi-hop BGP
peering.
When R9 configures the neighbor statement – let’s say we
point it at the FA0/1 interface on R3. When R3 configures the neighbor
statement we point the neighbor statement at S0/0 interface of Router 9.
Now we need to consider that when R9 generates the TCP
packet that’s going to R3. What is the local interface we would use to reach that
destination?
We can obviously verify this by looking at the routing table
for that route.
R3:
FastEthernet0/1
172.16.37.3
R9#sh ip route 172.16.37.3
Routing entry for 172.16.37.0/24
Known via
"eigrp 1", distance 90, metric 2172416, type internal
Redistributing via
eigrp 1
Last update from
172.16.79.7 on Serial0/1, 03:20:17 ago --
this is the source of the packet to R3.
Routing Descriptor
Blocks:
* 172.16.79.7, from
172.16.79.7, 03:20:17 ago, via Serial0/1
Route metric is
2172416, traffic share count is 1
Total delay is
20100 microseconds, minimum bandwidth is 1544 Kbit
Reliability
255/255, minimum MTU 1500 bytes
Loading 1/255,
Hops 1
Problem: on R3 we cannot guarantee the return path to R9 is
going to be via the same interface.
R3#sh ip route 172.16.79.9
Routing entry for 172.16.79.0/24
Known via
"eigrp 1", distance 90, metric 2172416, type internal
Redistributing via
eigrp 1
Last update from
172.16.37.7 on FastEthernet0/1, 02:28:42 ago
Routing Descriptor
Blocks:
* 172.16.37.7, from
172.16.37.7, 02:28:42 ago, via FastEthernet0/1
Route metric is
2172416, traffic share count is 1
Total delay is
20100 microseconds, minimum bandwidth is 1544 Kbit
Reliability
255/255, minimum MTU 1500 bytes
Loading 1/255,
Hops 1
In this case it is coming from the same interface. This
means that each BGP update it going to come from the IP address: 172.16.37.7
IF THIS DOES NOT match the neighbor statement that’s
configured under the process, then the TCP session will not work.
The way around this issue is by using the # update-source
command. In any situation that we’re not peering over a direct connection
between the neighbors, we should manually specify where the packet is coming
from so the remote end is then going to agree with that.
Most real world designs for this – the update source will be
a loopback interface.
The reason behind this is if I’m advertising my loopback
into my IGP then is really doesn’t matter as long the path is available.
How we configure this is simple.
Under the process we would simply say:
BGP (AS#)
# Neighbor x.x.x.x update-source serial0/0
Basically in the case where the BGP peering’s have multiple
paths between them, then you might want to consider using the update-source
command and sourcing from the loopback interface.
Let’s change the peering now and keep the same debugs
running. This time we’ll add the update-source of each routers loopback
interface.
The current configs look like this:
R9 –
router bgp 9
no synchronization
bgp log-neighbor-changes
network 9.9.9.0 mask 255.255.255.0
neighbor 192.168.89.8 remote-as 8
no auto-summary
R8 -
router bgp 8
no synchronization
bgp log-neighbor-changes
network 8.8.8.0 mask 255.255.255.0
neighbor 192.168.89.9 remote-as 9
no auto-summary
Basically were adding this command respectively.
Neighbor 192.168.89.9 update-source lo8
Neighbor 192.168.89.8 update-source lo9
Also before we can establish the TCP session we need to
verify reachability.
R9#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2
seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max =
1/7/28 ms
R9#
Since the destination is an EBGP peer and the route is not
via a connected interface. Then neither the processes are going to establish by
default. No one is essentially going to send the initial TCP SYN.
We can correct this using the #disable connected check
feature is used for.
EX: R9(config-router)#neighbor 192.168.89.8
disable-connected-check
We can view all the details with the command
# sh ip bgp neighbor
9#sh ip bgp neighbors
BGP neighbor is 192.168.89.8, remote AS 8, external link – here
it shows the neighbor ID
BGP version 4,
remote router ID 8.8.8.8 -- We’re running Version 4 and the router id is
8.8.8.8
BGP state =
Established, up for 00:00:15
Last read 00:00:15,
last write 00:00:15, hold time is 180, keepalive interval is 60 seconds – Note:
The KA and HT do nt have to match this will be negotiated
Neighbor
capabilities:
Route refresh:
advertised and received(old & new)
Address family
IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 2 2
Notifications: 0 0
Updates: 2 2
Keepalives: 24 24
Route
Refresh: 0 0
Total: 28 28
Default minimum time
between advertisement runs is 30 second
For address family: IPv4 Unicast
BGP table version 5,
neighbor version 5/0
Output queue size : 0
Index 1, Offset 0,
Mask 0x2
1 update-group
member
Sent Rcvd
Prefix
activity: ---- ----
Prefixes
Current: 1 1 (Consumes 52 bytes)
Prefixes
Total: 1 1
Implicit Withdraw: 0 0
Explicit
Withdraw: 0 0
Used as
bestpath: n/a 1
Used as
multipath: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: --------
-------
Bestpath from this
peer: 1 n/a
Total: 1 0
Number of NLRIs in
the update sent: max 1, min 1
Connections
established 2; dropped 1
Last reset 00:09:52,
due to Peer closed the session
Connection state is ESTAB, I/O status: 1, unread input
bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing
TTL 1 – This show the TTL
Local host: 192.168.89.9, Local port: 42146 -- These
next two lines will tell us who is the server and the client
Foreign host: 192.168.89.8, Foreign port: 179
NOTE: Remember the server Sources its traffic from TCP 179 so the
Router is the client ant the traffic is coming from the client port 42146 and
going to the server 192.168.89.8 on port 179. Really this won’t matter unless there’s
is filtering in-place for port 179. Normally the client is the one who
initiates the session first. We will only look to the router-id if we send at
the same time.
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x1B28EC):
Timer
Starts Wakeups Next
Retrans
4 0 0x0
TimeWait
0 0 0x0
AckHold
3 1 0x0
SendWnd
0 0 0x0
KeepAlive
0 0 0x0
GiveUp
0 0 0x0
PmtuAger
0 0 0x0
DeadWait
0 0 0x0
iss: 4093217048
snduna: 4093217203 sndnxt:
4093217203 sndwnd: 16230
irs: 2835067880
rcvnxt: 2835068035 rcvwnd: 16230
delrcvwnd: 154
SRTT: 124 ms, RTTO: 1405 ms, RTV: 1281 ms, KRTT: 0 ms
minRTT: 8 ms, maxRTT: 300 ms, ACK hold: 200 ms
Flags: active open, nagle
IP Precedence value : 6
Datagrams (max data segment is 1460 bytes):
Rcvd: 5 (out of order: 0), with data: 3, total data bytes:
154
Sent: 7 (retransm
EBGP – TTL
Example: Based on the lab image – if I wanted to peer with R3
(running AS3) from R9.
Under the BGP process –
I would need to configure the neighbor statement for R3 and
add the remote as
I would then also need to configure my update-source
I would also then configure the neighbor statement for R3
and configure ebgp-multihop
Ex:
# neighbor x.x.x.x ebgp-mulithop # (default is 255)
Note: if we do no configure the multi-hop command it
defaults to one.
This would mean essentially no matter how far away I am form
them I’ll establish the session.
Once again we can verify this with the #sh ip bgp neighbor command
R9#sh ip bgp neighbors
BGP neighbor is 3.3.3.3,
remote AS 3, external link
BGP version 4,
remote router ID 3.3.3.3
BGP state =
Established, up for 00:00:38
Last read 00:00:38,
last write 00:00:08, hold time is 180, keepalive interval is 60 seconds
Neighbor
capabilities:
Route refresh:
advertised and received(old & new)
Address family
IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 1 1
Notifications: 0 0
Updates: 2 1
Keepalives: 3 1
Route
Refresh: 0 0
Total: 6 3
Default minimum time
between advertisement runs is 30 seconds
For address family:
IPv4 Unicast
BGP table version 4,
neighbor version 4/0
Output queue size : 0
Index 1, Offset 0,
Mask 0x2
1 update-group
member
Sent Rcvd
Prefix
activity: ---- ----
Prefixes
Current: 3 1 (Consumes 52 bytes)
Prefixes
Total: 3 1
Implicit
Withdraw: 0 0
Explicit
Withdraw: 0 0
Used as
bestpath: n/a 1
Used as
multipath: n/a 0
Outbound Inbound
Local Policy Denied
Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the
update sent: max 2, min 1
Connections
established 1; dropped 0
Last reset never
External BGP neighbor may be up to 255 hops away.
Connection state is ESTAB, I/O status: 1, unread input
bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255
Local host: 192.168.89.9, Local port: 179
Foreign host: 3.3.3.3, Foreign port: 63387
Note: By default the ebgp-multihop
command is only going to control what the TTL is on your outgoing packets.
No comments:
Post a Comment