following the lab from my previous post -MPLS-VPN and Dual DM-VPN networks - Part I
(http://www.madari.co.il/2014/10/step-by-step-mpls-vpn-and-dual-dm-vpn.html) now we have fully operational network and i need to do some traffic manipulations from the branches to the data center.
Now the customer network is built from two layers:
Layer-1 – Configured using BGP over the SP network and
advertise the loopback interfaces only as an infrastructure to the DM-VPN.
Layer-2 – Customer network which runs over the DM-VPN
network using EIGRP as routing protocol.
In the following tasks I will show the necessary steps to
change the topology to redundant active/active deterministic topology.
Task 1: Dual link branch configuration
All branch routers which have dual uplinks to the SP network
will utilize both links, one for each tunnel.
In order to accomplish this we will use 2 loopbacks and inbound
and outbound route-maps on BGP peer advertisement.
R9 outbound policy:
interface Loopback91
ip address 9.9.9.1 255.255.255.255
!
interface Loopback92
ip address 9.9.9.2 255.255.255.255
!
ip prefix-list PL_LO91 seq 5
permit 9.9.9.1/32
!
ip prefix-list PL_LO92 seq 5
permit 9.9.9.2/32
!
route-map RM_BGP_R7_OUTBOUND
permit 10
match ip address prefix-list PL_LO92
set as-path prepend 65009 65009 65009
!
route-map RM_BGP_R7_OUTBOUND
permit 999
!
route-map RM_BGP_R8_OUTBOUND
permit 10
match ip address prefix-list PL_LO91
set as-path prepend 65009 65009 65009
!
route-map RM_BGP_R8_OUTBOUND
permit 999
|
This will assure inbound traffic from the SP network to R9 loopback
91 through R7 and R9 loopback 92 through R8.
R4#sh ip
route vrf ABC 9.9.9.1
Routing
Table: ABC
Routing entry
for 9.9.9.1/32
Known via "bgp 65006", distance
200, metric 0
Tag 65009, type internal
Last update from 7.7.7.7 00:14:08 ago
Routing Descriptor Blocks:
* 7.7.7.7 (default), from 6.6.6.6, 00:14:08 ago
Route metric is 0, traffic share count
is 1
AS Hops 1
Route tag 65009
MPLS label: 26
MPLS Flags: MPLS Required
R4#sh ip
route vrf ABC 9.9.9.2
Routing
Table: ABC
Routing entry
for 9.9.9.2/32
Known via "bgp 65006", distance
200, metric 0
Tag
65009, type internal
Last update from 8.8.8.8 00:13:40 ago
Routing Descriptor Blocks:
* 8.8.8.8 (default), from 6.6.6.6, 00:13:40 ago
Route metric is 0, traffic share count
is 1
AS Hops 1
Route tag 65009
MPLS label: 27
MPLS Flags: MPLS Required
R4#
|
Now let’s change R9 outbound traffic:
ip prefix-list PL_NET_LO1 seq
5 permit 1.1.1.1/32
!
ip prefix-list PL_NET_LO2 seq
5 permit 2.2.2.2/32
!
route-map RM_R8_INBOUND
permit 10
match ip address prefix-list PL_NET_LO2
set weight 1500
!
route-map RM_R8_INBOUND
permit 999
!
route-map RM_R7_INBOUND
permit 10
match ip address prefix-list PL_NET_LO1
set weight 1500
!
route-map RM_R7_INBOUND
permit 999
!
router bgp 65009
neighbor 10.1.79.7 route-map RM_R7_INBOUND
in
neighbor 10.1.89.8 route-map RM_R8_INBOUND
in
|
Again this will assure outgoing traffic from R9 to R1
through R7 and R9 to R2 though R8.
R9# show ip route 1.1.1.1
Routing entry
for 1.1.1.1/32
Known via "bgp 65009", distance
20, metric 0
Tag 65006, type external
Last update from 10.1.79.7 00:13:47 ago
Routing Descriptor Blocks:
* 10.1.79.7, from 10.1.79.7, 00:13:47 ago
Route metric is 0, traffic share count
is 1
AS Hops 2
Route tag 65006
MPLS label: none
R9# show ip route 2.2.2.2
Routing entry
for 2.2.2.2/32
Known via "bgp 65009", distance
20, metric 0
Tag 65006, type external
Last update from 10.1.89.8 00:00:03 ago
Routing Descriptor Blocks:
* 10.1.89.8, from 10.1.89.8, 00:00:03 ago
Route metric is 0, traffic share count
is 1
AS Hops 2
Route tag 65006
MPLS label: none
|
Now let’s advertise Lo91 and Lo92 through BGP and change the
tunnel source interface accordingly on R9:
router bgp 65009
bgp log-neighbor-changes
network 9.9.9.1 mask 255.255.255.255
network 9.9.9.2 mask 255.255.255.255
!
interface Tunnel1
tunnel source Loopback91
!
interface Tunnel2
tunnel source Loopback92
|
Now all the traffic on tunnel 1, from/to R1, is going
through R9-R7 link and all traffic on tunnel 2, from/to R2, goes through R9-R8
link - both directions!
Note that this has no influence on the upper layer network
(customer networks) between the branch and the center which runs EIGRP over
DM-VPN on the tunnels.
Task 2: EIGRP traffic influence from branch to center
In the current situation all branch routers learn data
center networks (192.168.31-33.0/24) through both tunnels hence we have ECMP
from the branch to the data center and the traffic is load-balanced.
R9:
R9#show ip
route 192.168.31.0
Routing entry
for 192.168.31.0/24
Known via "eigrp 1", distance 90,
metric 27010560, type internal
Redistributing via eigrp 1
Last update from 172.2.0.2 on Tunnel2,
00:01:57 ago
Routing Descriptor Blocks:
* 172.2.0.2, from 172.2.0.2, 00:01:57 ago, via Tunnel2
Route metric is 27010560, traffic share
count is 1
Total delay is 55100 microseconds,
minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1420
bytes
Loading 1/255, Hops 2
172.1.0.1, from 172.1.0.1, 00:01:57 ago, via Tunnel1
Route metric is 27010560, traffic share
count is 1
Total delay is 55100 microseconds,
minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1420
bytes
Loading 2/255, Hops 2
R9#show ip
route 192.168.32.0
Routing entry
for 192.168.32.0/24
Known via "eigrp 1", distance 90,
metric 26882560, type internal
Redistributing via eigrp 1
Last update from 172.1.0.1 on Tunnel1,
00:00:47 ago
Routing Descriptor Blocks:
* 172.1.0.1, from 172.1.0.1, 00:00:47 ago, via Tunnel1
Route metric is 26882560, traffic share
count is 1
Total delay is 50100 microseconds,
minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1420
bytes
Loading 2/255, Hops 1
172.1.0.2, from 172.1.0.2, 00:03:50 ago, via Tunnel2
Route metric is 27010560, traffic share
count is 1
Total delay is 55100 microseconds,
minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1420
bytes
Loading 1/255, Hops 2
R9#show ip
route 192.168.33.0
Routing entry
for 192.168.33.0/24
Known via "eigrp 1", distance 90,
metric 27010560, type internal
Redistributing via eigrp 1
Last update from 172.2.0.2 on Tunnel2,
00:03:50 ago
Routing Descriptor Blocks:
* 172.2.0.2, from 172.2.0.2, 00:03:50 ago, via Tunnel2
Route metric is 27010560, traffic share
count is 1
Total delay is 55100 microseconds,
minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1420
bytes
Loading 1/255, Hops 2
172.1.0.1, from 172.1.0.1, 00:03:50 ago, via Tunnel1
Route metric is 27010560, traffic share
count is 1
Total delay is 55100 microseconds,
minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1420
bytes
Loading 1/255, Hops 2
|
There are several ways to influence EIGRP traffic and I will
focus on two of them: route-map and offset list.
According to Marko Milivojevic post on
Cisco support forums (URL: https://learningnetwork.cisco.com/thread/26400)
as far as I understand we can’t change the metric of an EIGRP internal route
using route-map and set metric command.
My tests on this lab shows slightly different, on the
current configuration I see that both R1 and R2 are advertising network
192.168.31.0/24 as follow:
R1 EIGRP update pcap:
R2 EIGRP update pcap:
You can see the wide metric setting for bandwidth which set
to 100000.
Now I have configured the following on R1:
ip prefix-list PL_NET31 seq 5
permit 192.168.31.0/24
!
route-map RM_EIGRP_OUT permit
10
match ip address prefix-list PL_NET31
set metric 1000 10 255 1 1500
!
route-map RM_EIGRP_OUT permit
999
!
router eigrp 1
distribute-list route-map RM_EIGRP_OUT out
Tunnel1
|
Now R1 is advertising network 192.168.31.0/24 with wide
metric bandwidth of 100,
R1 EIGRP update pcap:
And we can see that R9 has now only one preferred path to
network 192.168.31.0/24:
R9# show ip route 192.168.31.0
Routing entry
for 192.168.31.0/24
Known via "eigrp 1", distance 90,
metric 26882560, type internal
Redistributing via eigrp 1
Last update from 172.1.0.1 on Tunnel1,
00:16:04 ago
Routing Descriptor Blocks:
* 172.1.0.1, from 172.1.0.1, 00:16:04 ago, via Tunnel1
Route metric is 26882560, traffic share
count is 1
Total delay is 50100 microseconds,
minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1420
bytes
Loading 1/255, Hops 1
|
While all other networks are still multi-path equal cost:
R9# show ip route 192.168.32.0
Routing entry
for 192.168.32.0/24
Known via "eigrp 1", distance 90,
metric 27010560, type internal
Redistributing via eigrp 1
Last update from 172.2.0.2 on Tunnel2,
00:18:20 ago
Routing Descriptor Blocks:
* 172.2.0.2, from 172.2.0.2, 00:18:20 ago, via Tunnel2
Route metric is 27010560, traffic share
count is 1
Total delay is 55100 microseconds,
minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1420
bytes
Loading 1/255, Hops 2
172.1.0.1, from 172.1.0.1, 00:18:21 ago, via Tunnel1
Route metric is 27010560, traffic share
count is 1
Total delay is 55100 microseconds,
minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1420
bytes
Loading 1/255, Hops 2
R9# show ip route 192.168.33.0
Routing entry
for 192.168.33.0/24
Known via "eigrp 1", distance 90,
metric 27010560, type internal
Redistributing via eigrp 1
Last update from 172.2.0.2 on Tunnel2,
00:25:33 ago
Routing Descriptor Blocks:
* 172.2.0.2, from 172.2.0.2, 00:25:33 ago, via Tunnel2
Route metric is 27010560, traffic share
count is 1
Total delay is 55100 microseconds,
minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1420
bytes
Loading 1/255, Hops 2
172.1.0.1, from 172.1.0.1, 00:25:33 ago, via Tunnel1
Route metric is 27010560, traffic share
count is 1
Total delay is 55100 microseconds,
minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1420
bytes
Loading 1/255, Hops 2
|
So what’s happen here actually??? Also note that I lowered the
bandwidth for this network (metric 1000 10 255 1 1500)
and it made the opposite result – it made this network more preferred!!!
I think the reason for this behavior related to the fact
that I changed the EIGRP bandwidth and not the bandwidth setting of a particular
interface.
As you may recall EIGRP metric calculation is (Bandwidth +
Delay) * 256 = composite metric.
But before we run our calculation we need to scale the interface
bandwidth and delay using the following formulas:
Scaled Bandwidth = (10 in power of 7 / Interface bandwidth)
Scaled Delay = (Delay/10)
When we use set metric on the route-map it change the EIGRP bandwidth
without scaling it and as a result lower is better!
As for offset list things are pretty much straight forward,
here is the configuration of R1:
ip access-list standard 32
permit 192.168.32.0 0.0.0.255
deny
any
!
router eigrp 1
offset-list 32 out 10000 Tunnel1
|
We configure an ACL to express the network which we want to
make less preferable and we advertise it out with offset list which
actually just add more delay
R1 PIC
And R9 route table:
R9# show ip route 192.168.32.0
Routing entry
for 192.168.32.0/24
Known via "eigrp 1", distance 90,
metric 27010560, type internal
Redistributing via eigrp 1
Last update from 172.2.0.2 on Tunnel2,
00:01:32 ago
Routing Descriptor Blocks:
* 172.2.0.2, from 172.2.0.2, 00:01:32 ago, via Tunnel2
Route metric is 27010560, traffic share
count is 1
Total delay is 55100 microseconds,
minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1420
bytes
Loading 1/255, Hops 2
|
No R1 for this network in the routing table!
Although it’s still exist the EIGRP topology table:
R9#sh ip eigrp topology 192.168.32.0
EIGRP-IPv4 Topology Entry for AS(1)/ID(192.168.93.1) for 192.168.32.0/24
State is Passive, Query
origin flag is 1, 1 Successor(s), FD is 27010560
Descriptor Blocks:
172.2.0.2 (Tunnel2), from
172.2.0.2, Send flag is 0x0
Composite metric is
(27010560/156160), route is Internal
Vector metric:
Minimum bandwidth is
100 Kbit
Total delay is 55100
microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1420
Hop count is 2
Originating router is
192.168.33.1
172.1.0.1 (Tunnel1), from 172.1.0.1, Send flag is 0x0
Composite metric is
(27020544/166144), route is Internal
Vector metric:
Minimum bandwidth is
100 Kbit
Total delay is 55490
microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1420
Hop count is 2
Originating router is
192.168.33.1
|
Hence in case of failure of tunnel 2/ R2 we still have route
to this network.
In order to continue this lab I used the route-maps method
on both R1 and R2 for getting this final result:
R9#sh ip
route 192.168.31.0
Routing entry
for 192.168.31.0/24
Known via "eigrp 1", distance 90,
metric 26882560, type internal
Redistributing via eigrp 1
Last update from 172.1.0.1 on Tunnel1,
00:00:09 ago
Routing Descriptor Blocks:
* 172.1.0.1, from 172.1.0.1, 00:00:09 ago, via Tunnel1
Route metric is 26882560, traffic share
count is 1
Total delay is 50100 microseconds,
minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1420
bytes
Loading 1/255, Hops 1
R9#sh ip
route 192.168.32.0
Routing entry
for 192.168.32.0/24
Known via "eigrp 1", distance 90,
metric 26882560, type internal
Redistributing via eigrp 1
Last update from 172.2.0.2 on Tunnel2,
00:00:02 ago
Routing Descriptor Blocks:
* 172.2.0.2, from 172.2.0.2, 00:00:02 ago, via Tunnel2
Route metric is 26882560, traffic share
count is 1
Total delay is 50100 microseconds,
minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1420
bytes
Loading 1/255, Hops 1
R9#sh ip
route 192.168.33.0
Routing entry
for 192.168.33.0/24
Known via "eigrp 1", distance 90,
metric 27010560, type internal
Redistributing via eigrp 1
Last update from 172.2.0.2 on Tunnel2,
00:50:30 ago
Routing Descriptor Blocks:
* 172.2.0.2, from 172.2.0.2, 00:50:30 ago, via Tunnel2
Route metric is 27010560, traffic share
count is 1
Total delay is 55100 microseconds,
minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1420
bytes
Loading 1/255, Hops 2
172.1.0.1, from 172.1.0.1, 00:50:30 ago, via Tunnel1
Route metric is 27010560, traffic share
count is 1
Total delay is 55100 microseconds,
minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1420
bytes
Loading 1/255, Hops 2
|
Network 192.168.31.0/24 through R1
Network 192.168.32.0/24 through R2
And network 192.168.33.0/24 through both R1 and R2.
Next post I will have to handle traffic from the center to
the branches…
Bye!
References:
Manipulating
EIGRP metrics with route maps post on Cisco Support Forums
Enhanced Interior Gateway Routing Protocol (EIGRP) Wide
Metrics
No comments:
Post a Comment