Lessons Learned:
Topology:
Issue, in a fully meshed iBGP implementation with multiple
edge routers peering with the provider at different exit points. There can be a
case where one edge router doesn’t have a full path the other edge router. When
it comes to BGP as long as we have reachability we can establish adjacency.
One way to correct this issue would be to advertise the
transit networks on the edge devices into our IGP.
This would allow full reachability to the other edge devices
and our iBGP to install the routes in the routing table.
Before adding the transit network to for the peer
advertising the 10.x.x.x routes. We see that we have no best path to these
prefixes and they cannot be installed in to the routing table.
R8#sh ip route 10.3.1.0
% Network not in table
Network Next Hop Metric LocPrf Weight Path
*>i4.4.4.0/24
100.100.4.4 0 100
0 i
*>i5.5.5.0/24
100.100.5.5 0 100
0 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
*>i172.16.2.0/24
206.22.22.2 0 100
0 200 i
-------------------------------------------------------------------------------------
After adding the transit network to into our IBGP
Network Next Hop Metric LocPrf Weight Path
*>i4.4.4.0/24
100.100.4.4 0 100
0 i
*>i5.5.5.0/24
100.100.5.5 0 100
0 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
*>i172.16.2.0/24
206.22.22.2 0 100
0 200 i
R8#sh ip route 10.3.1.0
Routing entry for 10.3.1.0/24
Known via "bgp 100", distance 200,
metric 0
Tag 400, type
internal
Last update from
204.12.28.254 00:00:05 ago
Routing Descriptor
Blocks:
* 204.12.28.254, from 100.100.4.4, 00:00:05 ago
Route metric is
0, traffic share count is 1
AS Hops 1
Route tag 400
Now the route is in the table. It’s learned from BGP 100
(metric 200 iBGP).
We also the next hop of the route is 204.12.28.254 0 which
is not directly connected to this router.
We can continue our recursive lookup by showing the route
for 204.12.28.254
R8#sh ip route 204.12.28.254
Routing entry for 204.12.28.0/24
Known via "eigrp
10", distance 90, metric 30720, type internal
Redistributing via
eigrp 10
Last update from
192.168.48.4 on FastEthernet0/1, 00:03:49 ago
Routing Descriptor
Blocks:
* 192.168.48.4, from 192.168.48.4, 00:03:49
ago, via FastEthernet0/1
Route metric is
30720, traffic share count is 1
Total delay is
200 microseconds, minimum bandwidth is 100000 Kbit
Reliability
255/255, minimum MTU 1500 bytes
Loading 1/255,
Hops 1
R8#
We’re learning this route form 192.168.4.4 through our FastEthernet0/1
interface.
interface FastEthernet0/1
ip address 192.168.48.8 255.255.255.0
speed 100
full-duplex
end
We also could have done the verification by looking at the
CEF table, ex:
R8#sh ip cef 204.12.28.254
204.12.28.0/24, version 57, epoch 0, cached adjacency
192.168.48.4
0 packets, 0 bytes
via 192.168.48.4,
FastEthernet0/1, 3 dependencies
next hop
192.168.48.4, FastEthernet0/1
valid cached
adjacency
R8#
CEF in reality is pre-calculating the recursion and the
layer 2 header that’s going to be used on that link
If we look at the #Sh IP CEF detail we can see the interface
that it’s using.
And #sh ip cef internal –
R8#sh ip cef 204.12.28.254 internal – This destination
204.12.28.0/24, version 57, epoch 0, cached adjacency
192.168.48.4 – Points to this next Hop
0 packets, 0 bytes
via 192.168.48.4,
FastEthernet0/1, 3 dependencies – Out
this interface.
next hop
192.168.48.4, FastEthernet0/1
valid cached
adjacency
refcount 5
The “SH ip cef Internal “would show the load distribution
and if there was multiple paths. This lookup is ultimately what the routing
process is looking for.
The above solution was to advertise a route to the next hop
by adding the transit networks into our IGP.
Which is a perfectly valid design solution. The other
solution is to change the next hop to something the routers already do have a
route to.
We can do this by using our existing peer-group
configuration;
Router BGP 100
Neighbor IBGP_PEERS peer-group
Neighbor IBGP_PEERS remote-as 100
Neighbor
_PEERS update-source loopback 10
Neighbor 100.100.4.4 peer-group IBGP_PEERS
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
To test this I’ll remove the transit networks from our IGP
for R4 and for R5
R4 = 204.12.28.253 255.255.255.0
R5 = 206.22.22.5 255.255.255.0
So under the peer-group, I need to say. When I learn a route
from an EBGP neighbor and I turn around and advertise it to an iBGP neighbor, I
want to set the next hop value to my own local peering address.
Ex:
Router bgp 100
Neighbor IBGP_PEERS
next-hop-self
Now since my update source for the peer group is my loopback
10 interface, it would then mean than all of my BGP routes that are advertised
to these neighbors are all going to have the next-hop address of the loopback
10.
Once I make the change I’m going to need to send an update
to all my neighbors – I can do this is with the automatically enabled
route-refresh capability.
We can do a clear ip bgp *
Or
We can just do a clear ip bgp 100 out – this will not reset the
TCP session, it will just send them a new triggered updated.
We can now see that the next hops are all the Loopbacks:
Network Next Hop Metric LocPrf Weight Path
*>i0.0.0.0
100.100.6.6 0 100
0 300 i
*>i4.4.4.0/24
100.100.4.4 0 100
0 i
*>i5.5.5.0/24
100.100.5.5 0 100
0 i
*>i6.6.6.0/24
100.100.6.6 0 100
0 i
*>i10.1.1.0/24
100.100.4.4 0 100
0 400 i
*>i10.2.1.0/24
100.100.4.4 0 100
0 400 i
*>i10.3.1.0/24
100.100.4.4 0 100
0 400 i
*>i172.16.1.0/24
100.100.6.6 0 100
0 300 i
*>i172.16.2.0/24
100.100.5.5 0 100
0 200 i
R7#
Also because my loopback is advertised in my IGP I should be
able to perform route recursion and I can also verify that again via the CEF
table.
R7#sh ip cef 10.1.1.0 detail
10.1.1.0/24, version 37, epoch 0, per-destination sharing
0 packets, 0 bytes
via 100.100.4.4, 0
dependencies, recursive
next hop
192.168.67.6, FastEthernet0/0 via 100.100.4.0/24
valid adjacency
Recursive load
sharing using 100.100.4.0/24.
R7#
OR # sh IP cef internal – this will show how the load distribution
for a route
R7#sh ip cef 10.1.1.0 inter
10.1.1.0/24, version 37, epoch 0, per-destination sharing
0 packets, 0 bytes
via 100.100.4.4, 0
dependencies, recursive
next hop
192.168.67.6, FastEthernet0/0 via 100.100.4.0/24
valid adjacency
Recursive load
sharing using 100.100.4.0/24
Load distribution: 0
1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 (refcount 5)
Hash OK
Interface
Address Packets
1 Y
FastEthernet0/0
192.168.67.6 0
2 Y
FastEthernet0/1
192.168.57.5 0
3 Y
FastEthernet0/0
192.168.67.6 0
4 Y
FastEthernet0/1
192.168.57.5 0
5 Y
FastEthernet0/0
192.168.67.6 0
6 Y
FastEthernet0/1
192.168.57.5 0
7 Y
FastEthernet0/0
192.168.67.6 0
8 Y
FastEthernet0/1
192.168.57.5 0
9 Y
FastEthernet0/0
192.168.67.6 0
10 Y
FastEthernet0/1
192.168.57.5 0
11 Y
FastEthernet0/0
192.168.67.6 0
12 Y
FastEthernet0/1
192.168.57.5 0
13 Y
FastEthernet0/0
192.168.67.6 0
14 Y
FastEthernet0/1
192.168.57.5 0
15 Y
FastEthernet0/0 192.168.67.6 0
16 Y
FastEthernet0/1
192.168.57.5 0
refcount 5
R7#
So the next-hop self-command basically says: When learning
routes from my EBGP Peers, and I then send those routes on to my iBGP peers.
Change the next-hop value so my own local loopback interface – in this case loopback
10.
We’re using the loopback 10 because that’s what’s called out in the “update-source command”. Ex, if my update-source was set to my FA0/0 interface that’s what the next hop would be changed to.
We’re using the loopback 10 because that’s what’s called out in the “update-source command”. Ex, if my update-source was set to my FA0/0 interface that’s what the next hop would be changed to.
Next-HOP – Route-map.
We can also use a route-map to manually change the next hop
value.
So based on the topology, I’ll use router7.
Current BGP config:
router bgp 100
no synchronization
bgp
log-neighbor-changes
neighbor IBGP_PEERS
peer-group
neighbor IBGP_PEERS
remote-as 100
neighbor IBGP_PEERS
update-source Loopback10
neighbor IBGP_PEERS
next-hop-self
neighbor 100.100.4.4
peer-group IBGP_PEERS
neighbor 100.100.5.5
peer-group IBGP_PEERS
neighbor 100.100.6.6
peer-group IBGP_PEERS
neighbor 100.100.8.8
peer-group IBGP_PEERS
no auto-summary
New config:
route-map CHANGE_NEXT_HOP permit 10
set ip next-hop 100.100.7.7
Router bgp 100
Neighbor IBGP_PEERS
route-map CHANGE_NEXT_HOP out
---------------------------------------
Note: for the next-hop value, all we’re really looking for
is that the other routers can do the full route recursion. If I set the next to
a value that’s not in the routing table, that’s not going to work.
We can use out own IP address the neighbors or even a physical
link. The only issue is if we use a physical link and the link goes down. The BGP
peers would to be able to use any of those routes associated to that router.
Where the physical interface can be a good thing, is if we
want to control traffic and if the interface does go down, we don’t want
traffic to choose another path.
We can even use and IP SLA statement to track the interface and
then tie it to a static route to then set the next hop value.
Example:
On R4 – which peers with an EBGP Neighbor (R1)
ip sla 1
icmp-echo 10.3.1.1
timeout 2000
frequency 5
ip sla schedule 1 life forever start-time now
ip route 69.254.0.1 255.255.255.255 Null0 track 2 (note this
is the IPv4 automatic IP)
route-map CHANGE_NEXT_HOP permit 10
set ip next-hop
169.254.0.1
Router bgp 100
Neighbor IBGP_PEERS
route-map CHANGE_NEXT_HOP out.
Just verifying I can actually ping the IP address.
---------------------------------------------------------------------------------
R4(config-sla-monitor-echo)#do ping 10.3.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.1.1, timeout is 2
seconds:
!!!!!
---------------------------------------------------------------------------------
So now if the route goes down the
IPSA will kick in, remote the tracked route and my routes will now show as
invalid paths.
No comments:
Post a Comment