BGP Local AS, BGP Peer Groups.

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.