Lessons Learned:
iBGP Peering Rules:
iBGP packets default to TTL 255
-implies neighbors do not have to be connected as long as
IGP reachability exists
Loop preventions via route filtering
-iBGP learned routes cannot be advertised on to another iBGP
neighbor.
-implies need for either….. .
--Fully meshed iBGP peerings
--Route reflection
--Confederation.
====================================
Topology:
Now before we even configure BGP we can test the low level
connectivity by sending a telnet to the peer IP address using port 179. This
would imply that the remote session is configured, it it’s not configured on
the way back the connection will simple be refused.
We can verify basic TCP reachability with just a basic
Telnet session to the IP of the peer. This can also rule any filters in the
network.
Note: There can be design cases where s single router is
peering with an EBGP router that is in a different AS than the rest of the
routers, for example during a migration from.
To handle this under the BGP process we would configure
The peer address #neighbor x.x.x.x remote-as XX
Then we would need to configure the local AS (migrating one)
#Neighbor x.x.x.x remote-as local-as XX
We can also send two separate open message for to the new AS
and one for the migrating AS for ex:
# Neighbor x.x.x.x remote-as
local-as XX no-prepend replace-as dual-as
All internal routers in the
topology are configured for AS 100
Each edge routers is configured
for AS 400 / 200 / and 300 respectively
We can verify using a simple
command of # s hip bgp summary
Neighbor V
AS MsgRcvd MsgSent TblVer
InQ OutQ Up/Down State/PfxRcd
204.12.28.253 4
100 55 55
5 0 0 00:51:07 1
What we want to see here is the
for starters – any integer 0 or above under the State/PfxRcd – will show the number of routes we’re receiving from that
neighbor. What we don’t want to see is Active of Idle – this will indicate
something is wrong with the peering.
If there are peering issues we can
use a # debug IP bgp or # debug ip packet – as long as we apply an ACL that
permits only BGP
Note: verify there’s no authentication
configured before debugs.
Ex:
#access-list 100 permit tcp any eq bgp any
#access-list 100 permit tcp and any eq bgp
# debug IP packet detail 100
If possible we can always do a #clear ip bgp *
Now based on the topology – without
having to do route-reflection or confederation. It means we will need a full
mesh of peering’s in the topology. So configuration wise it would mean that
each router would need a different neighbor statement pointed at each router in
the topology.
Which is not feasible with 100 +
routers in the topology.
One way we can simply this is to
take the iBGP peers and put them into a template of configuration that is
called a peer group.
The peer group will be actual
optimization the update state machine because there is one update sent to the
entire peer group instead of individual updates that are sent to the neighbors.
To configure the Peer Groups:
Start the BGP process
Router BGP 100 –start process
Neighbor IBGP_PEERS peer-group - give it a name
Neighbor IBGP_PEERS remote-as 100 -
all peers will be in AS 100
Neighbor IBGP_PEERS update-source
Loopback0 – optional peer feature
Neighbor 100.100.4.4 peer-group
IBGP_PEERS – all iBGP peer addresses.
Neighbor 100.100.5.5 peer-group
IBGP_PEERS
Neighbor 100.100.6.6 peer-group
IBGP_PEERS
Neighbor 100.100.7.7 peer-group
IBGP_PEERS
Neighbor 100.100.8.8 peer-group
IBGP_PEERS
Now what makes easier about this configuration
- not only is it an optimization behind the scenes of how the update process
works, it makes it easier because we can apply this template onto all of the
routers.
Note: you won’t be able to peer
with your own local address.
% Cannot configure the local
system as neighbor
Now if we look at the #sh ip bgp summary we should see all
the routes are up and that we still have a peering with the EBGP peers.
R5#sh ip bgp summary
BGP router identifier 100.100.5.5,
local AS number 100
BGP table version is 7, main
routing table version 7
8 network entries using 936 bytes
of memory
8 path entries using 416 bytes of
memory
6/3 BGP path/bestpath attribute
entries using 744 bytes of memory
3 BGP AS-PATH entries using 72
bytes of memory
0 BGP route-map cache entries
using 0 bytes of memory
0 BGP filter-list cache entries
using 0 bytes of memory
BGP using 2168 total bytes of
memory
BGP activity 12/4 prefixes, 12/4
paths, scan interval 60 secs
Neighbor V
AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
100.100.4.4 4
100 8 8
7 0 0 00:02:22 4
100.100.6.6 4
100 6 6
7 0 0 00:00:08 2
100.100.7.7 4
100 6 8
7 0 0 00:02:52 0
100.100.8.8 4
100 4 6
7 0
0 00:00:38 0
206.22.22.2 4
200 148 152
7 0 0 00:09:19 1
R5#
So now – we should have a full
mesh of peering’s inside the network as well as the peering’s for the EBGP
neighbors.
The result is that for every peer –
we should see the EBGP update that came in was passed along ot all the IBGP
neighbors.
However – once the route comes in
it will not be advertises the neighbors based on the iBGP rules.
Without route-reflection you
cannot exchange any iBGP learned routes to other iBGP neighbors.
We should only see the routes
updated from the EBGP source:
Neighbor V
AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
100.100.4.4 4
100 15 15
7 0 0 00:09:45 4
100.100.6.6 4
100 13 13
7 0 0 00:07:30 2
100.100.7.7 4
100 14 16
7 0 0 00:10:14 0
100.100.8.8 4
100 12 14
7 0 0 00:08:01 0
206.22.22.2 4
200 155 159
7 0 0 00:16:42 1
R5#
R5#sh ip bgp summary
BGP router identifier 100.100.5.5,
local AS number 100
BGP table version is 8, main
routing table version 8
9 network entries using 1053 bytes
of memory
9 path entries using 468 bytes of
memory
6/3 BGP path/bestpath attribute
entries using 744 bytes of memory
3 BGP AS-PATH entries using 72
bytes of memory
0 BGP route-map cache entries
using 0 bytes of memory
0 BGP filter-list cache entries
using 0 bytes of memory
BGP using 2337 total bytes of
memory
BGP activity 13/4 prefixes, 13/4
paths, scan interval 60 secs
Neighbor V
AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
100.100.4.4 4
100 17 18
8 0 0 00:11:41 4
100.100.6.6 4
100 15 16
8 0 0 00:09:26 2
100.100.7.7 4
100 16 19
8 0 0 00:12:10 0
100.100.8.8 4
100 13 16
8 0 0 00:09:57 0
206.22.22.2 4 200
158 161 8
0 0 00:18:38 2
R5#sh ip bgp
R5#sh ip bgp
BGP table version is 8, local
router ID is 100.100.5.5
Status codes: s suppressed, d
damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ?
- incomplete
Network Next Hop Metric LocPrf Weight Path
*>i4.4.4.0/24 100.100.4.4 0 100
0 i
*> 5.5.5.0/24 0.0.0.0 0 32768 i
*>i6.6.6.0/24 100.100.6.6 0 100
0 i
* i10.1.1.0/24 204.12.28.254 0
100 0 400 i
* i10.2.1.0/24 204.12.28.254 0
100 0 400 i
* i10.3.1.0/24 204.12.28.254 0
100 0 400 i
* i172.16.1.0/24 206.33.33.1 0 100 0 300 i
*> 172.16.2.0/24
206.22.22.2 0 0 200 i
*> 222.222.222.0
206.22.22.2 0 0 200 i
R5#
R5#
How to read the output of #sh ip
bgp
Starting from the left.
Between the asterisks and the
lowercase letter I – we should be seeing the > sign (or a null value,
depending on who we learn the update from) sign – this indicates the best route.
The best route is the one that’s candidate to be installed in the routing table
and the one we advertise.
The lower case letter I – this mean
the route came from an internal BGP peer.
Next we have the actual prefix – note:
if the subnet mask doesn’t show up here, is means they have the classful mask. Anything
that is a subnet or an aggregate is going to show the actual mask value.
Next it the next hop value, this
is what we would need to know via IGP in order to actual use the prefix.
Next is the MED – which is a non-transitive
attribute. Only locally significant between me and my directly connected AS.
The loca-pref is 100 by default
The Weight value is zero for anything
that’s not originated
Then the AS-PATH
Followed by the origin code. Where
lowercase I for igp is better than ? for incomplete
Note: anytime we redistribute a route into BGP it’s going to get
the origin code of incomplete. This would be less preferred that a route that
was configured under the network statement under BGP process.
R5#sh ip route bgp
B 222.222.222.0/24 [20/0] via 206.22.22.2,
00:18:11
4.0.0.0/24 is subnetted, 1 subnets
B 4.4.4.0 [200/0] via 100.100.4.4,
00:29:45
6.0.0.0/24 is subnetted, 1 subnets
B 6.6.6.0 [200/0] via 100.100.6.6,
00:27:30
172.16.0.0/24 is subnetted, 1 subnets
B 172.16.2.0 [20/0] via 206.22.22.2,
00:36:07
R5#
Here we can see that the routers
is only installing the routes learned from the EBGP neighbors instead of the
iBGP neighbors. The reason is as issue-with the next-hop reachability.
