User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

Multi Protocol BGP VRF Lab

Lab aims

Helping students develop considerable skills of configuring and diagnosing the networks of operators that use BGP for redistribution of routes between various VRFs. The network is built using GNS3 emulator.

Network scheme

Lab description

  1. Build the network which is presented on the image.
  2. The channel between router R1 and switch SW1 must be configured in the trunk mode. Routers R2, R3, R4, and R5 must be connected to their proprietary virtual networks (VLAN).
  3. Configure the sub-interfaces in router R1 that correspond to the virtual networks from the previous item.
  4. Allocate P2P for vrf A sub-interfaces on R1 in case if they are meant for the connection between R2 and R3 routers. Allocate vrf B for R4 and R5.
  5. Allocate IP addresses for the corresponding interfaces and sub-interfaces of the routers.
  6. Create a loopback 0 interface on R2 to R4 routers and allocate it an IP address from the networks provided on the scheme above.
  7. Configure EIGRP routing protocol for every VRF in a way so that all connected networks fall within it.
  8. Use Multi-Protocol BGP to configure the transfer of routes from vrf A to vrf B in such a way so that only 10.0.3.0/24 network is transferred and nothing is sent in the other direction.
  9. Use ping command to make sure that packets from R5 router get to R3 router, but however are not being sent back.
  10. Make sure that the packets between R3 and R5 are being transferred successfully.

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

Introduction

This lab is meant for the fifth grade students of the Radio Engineering and Сybernetics Department of Moscow Institute of Physics and Technology as well as for the third year students who would like to learn about the additional features of EIGRP on an extracurricular basis. It is implied that the students are already familiar with the basic operation principles of EIGRP and both protocol configuration syntaxes. All commands presented in this lab are for named mode, but the students should be able to perform the same configurations in the classic mode too, if applicable.

It is allowed to use third-party educational materials upon doing this lab.

Description

Addressing scheme for the serial links between the routers is as follows: 192.168.XY.X|Y/24 where X and Y are serial numbers of devices. For example, let's examine the link between routers R1 and R2. Router R1 interface is assigned 192.168.12.1/24 IP address, whilst the router R2 has 192.168.12.2/24. The right Ethernet segment features four networks where the users are located. EIGRP with the autonomous system #1 is used in the network.

The image below shows the L3 scheme of the network. Every network is located in its own VLAN; this is why the respective amount of sub-interfaces should be created on the routers R2 to R4.

Every section in this lab covers a wide range of EIGRP operation features without being limited to what the title says.

Network scheme

K-values

  1. Build the presented scheme using GNS3. Enable all interfaces and assign the IP-addresses to them. Use different encapsulation (PPP, HDLC, and Frame Relay) on all serial links.
  2. Add all physical interfaces and sub-interfaces to EIGRP. Use sho eigrp address-family ipv4 1 neighbors command to make sure that the neighbor relationship between them was formed.
  3. Make sure that router R1 has routes towards all four user networks through all of its three neighbors and that it performs balancing between the three paths with the same metrics. Remember the metrics value for, let's say, 192.168.0.0/24 network.
  4. Learn K-values using the following commands: sho ip protocols or sho eigrp protocols. By default, the weights are the following: K1=1, K2=0, K3=1, K4=0, K5=0 K6=0.
  5. Reconfigure the K-values on router R1in such a way that only the interface delay is considered upon the metric calculation.
  6. Make sure that router R1 lost the EIGRP neighbor relationship with all other three devices.
  7. Reconfigure the K-values the same way on three other routers.
  8. Make sure that the EIGRP neighbor relationship between them was re-established.
  9. Make sure that the metrics for 192.168.0.0/24 has changed.

RIB Scale

  1. Look at the output of sho eigrp address-family ipv4 1 topology | s 192.168.(0|1|2|3).0/24 command and make sure that the metrics of 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24 , and 192.168.3.0/24 networks coincide and are the same irrespective of the path.
  2. Use sho ip ro ei | s 192.168.(0|1|2|3).0/24 command to make sure that the metrics of routes towards the specified networks in RIB is different from the one that was shown in the previous item. The difference is due to the usage of 64-bit metrics in the EIGRP named mode, whilst the value of the RIB metrics is 32-bit long.
  3. Use sho ip protocols or sho eigrp protocols command to make sure that EIGRP uses 64-bit metrics.
  4. A special kind of scaling factor, which is 128 by default, is used in order to convert the EIGRP metrics value into the RIB one. Find its value in the outputs of the following commands: sho ip protocols and sho eigrp protocols. Make sure that the calculation of metrics for networks located in the routing table is correct using integer division of the internal EIGRP metrics by the scaling factor.
  5. Use metric rib-scale 200 command to change the scaling factor value. Make sure that the metrics value in the routing table was changed.
  6. Delete the configuration command from the previous item. Make sure that the metrics in the routing table is now equal to its previous value.
  7. Note that it's possible to change the scaling factor not on all routers in the network.

Feasible successor

  1. Use sho eigrp address-family ipv4 1 topology | s 192.168.(0|1|2|3).0/24 command to review the information located in the topology table about the client networks. At this moment all three routes have the same metrics and balancing is performed over all three paths with the same metrics.
  2. Use delay interface command to change the delay values on all four routers in such a way so that they coincide with the values presented on the scheme above.
  3. Review the routing table on R1 and make sure that balancing for client networks is not performed any more and all the traffic is transferred only through router R2.
  4. Use sho eigrp address-family ipv4 1 topology command to review the topology table on router R1 and make sure that there are no routes towards client networks through routers R3 and R4.
  5. The routes towards clients networks through routers R3 and R4 have disappeared from the topology table because feasible condition is not met any more. Remember and write it down.
  6. Use sho eigrp address-family ipv4 1 topology all-links command to review the full topology table on router R1. Make sure that the routes toward client networks through routers R3 and R4 are not met feasible condition.
  7. Make up and change the delay values on the interfaces in such a way so that two paths appear in the topology table: one through successor and the other one through feasible successor. The metrics value for all three routes must be different.
  8. Make sure that there is still only one route for every client network in the routing table.

Unequal cost load balancing

  1. Use the corresponding commands on router R1 to make sure that after performing all tasks from the previous section correctly the topology table has two paths with different metrics for every client network and the routing table has only one best route.
  2. Use variance 128 command to change the multiplier that is used for choosing the routes that are placed into the routing table.
  3. Make sure that two routes for every client network appeared in the routing table.
  4. Change variance command in such a way so that the smallest possible multiplier, letting both routes make it into the routing table, is used.
  5. Explain in what way the selection of routes that are placed into the routing table is made.
  6. Change the delay value on the interfaces of routers in such a way so that feasible condition is met for all three routes towards client networks.
  7. Make sure that all three routes towards client networks (change the value of variance command if necessary) appeared in the routing table.
  8. Use sho ip protocols and sho eigrp protocols commands to learn what is the largest number of prefixes that one can place in the routing table.
  9. Use maximum-paths 2 command to limit the number of routes placed in RIB.
  10. Make sure that the routing table has only two routes toward every client network.
  11. Use maximum-paths command to increase the number of routes placed in the routing table in such a way so that all the routes successfully appear in RIB once more.
  12. Use traffic-share balanced command to choose one of the balancing modes. Explain the differences between the modes.
  13. Use one of the review commands to learn the ratio for traffic balancing for every user network.
  14. Use traffic-share min across-interfaces command to change the balancing mode. Learn what would be the traffic balancing ratio now.

Passive interfaces

  1. Use sho eigrp address-family ipv4 topology 192.168.0.0/24 command on router R1 to make sure that the topology table has all three paths towards the corresponding network.
  2. Use shutdown command on router R2 in the corresponding section of the routing protocol settings to disable EIGRP for the interface that is assigned 192.168.0.2 IP address.
  3. Use sho eigrp address-family ipv4 interfaces command on the same router to make sure that the corresponding interface doesn't participate in EIGRP any more.
  4. Use sho eigrp address-family ipv4 topology 192.168.0.0/24 command to make sure that router R2 doesn't announce routing information about 192.168.0.0/24 network toward router R1.
  5. Use redistribute connected command to make R2 announce information via EIGRP about the directly connected networks.
  6. Review the topology table on R1 for 192.168.0.0/24 prefix once more. Explain what you saw.
  7. Use passive-interface command on R3 in the corresponding section of the routing protocol settings to switch the interface that is assigned 192.168.0.3 IP-address to the passive mode.
  8. Use review commands on router R4 to make sure that R4 doesn't have EIGRP neighbors in 192.168.0.0/24 network.
  9. Use sho eigrp address-family ipv4 topology 192.168.0.0/24 command on R1 to make sure that the topology table still has three paths, two of which are internal.
  10. Use sho eigrp address-family ipv4 1 interfaces command on router R3. Make sure that there is no interface assigned 192.168.0.3 IP-address among EIGRP interfaces.
  11. Use sho ip protocols command on R3 to find out what interfaces operate in the EIGRP passive mode.
  12. Use sho ip ro ei 1 command on router R1 and find the metrics and administrative distance values for 192.168.0.0/24 prefix from the output of this command.
  13. Use distance eigrp 200 100 command on R1 to change the administrative distance values for internal and external EIGRP routes.
  14. Use sho ip protocols or sho eigrp protocols command to make sure that the changes have been added successfully.
  15. Re-establish the EIGRP neighbourship from R1 with all other routers.
  16. Review the routing table on R1 for 192.168.0.0/24 prefix once again. Please explain the changes that took place.
  17. Examine the topology table for 192.168.0.0/24 prefix on R1. Find and explain the changes.
  18. Delete distance eigrp 200 100 command from the EIGRP settings on router R1 and re-establish EIGRP neighbourship between all routers.
  19. Use sho ip protocols or sho eigrp protocols command to find out the default value that limits the diameter of the EIGRP network.
  20. Use sho eigrp address-family ipv4 topology 192.168.0.0/24 command on router R1 and examine its output to learn how far away (in terms of L3 hops) 192.168.0.0/24 network is located from this router upon usage of every of the three available paths.
  21. Use metric maximum-hops command on router R1 to increase the supported EIGRP network diameter.
  22. Use sho ip protocols or sho eigrp protocols command to make sure that the changes have been added successfully.
  23. Delete metric maximum-hops command that you had used earlier on router R1.
  24. Delete shutdown command on R2 in the module of EIGRP settings for the interface that's assigned 192.168.0.2 IP address. Also, disable announcing of the connected networks in EIGRP.
  25. Delete passive-interface command on router R3 in the section of EIGRP settings for the interface that's assigned 192.168.0.3 IP address.

Stub routers

  1. Create Loopback 0 interface with х.х.х.х/32 IP address, where x is the router number, on all routers and add it to EIGRP.
  2. Examine the topology table on router R1 for х.х.х.х/32 networks.
  3. Configure R2, R3, and R4 as stub routers with announcing of only the connected networks.
  4. Use sho ip protocols or sho eigrp protocols command on R2, R3, and R4 to make sure that the changes have been added successfully.
  5. Use sho eigrp address-family ipv4 neighbors detail command on R1 to review the detailed information about routers R2, R3, and R4.
  6. Examine the topology table on R1 for х.х.х.х/32 networks. Please explain the changes that took place.
  7. Create prefix list that allows the following prefixes on R2: 3.3.3.3/32 and 4.4.4.4/32.
  8. Create a route-map on router R2 that will allow what would be allowed by the prefix-list created in the previous item.
  9. Change eigrp stub command on R2 in such a way that not only the directly connected networks but also the ones that are allowed using the previously created route-map are included in the EIGRP announcements.
  10. Review the topology table on R1. Please explain the changes that took place.
  11. Use deb eigrp fsm command on R1 to enable the output of debugging data about EIGRP FSM events.
  12. Disable the sub-interface that is assigned 192.168.0.2 IP address on router R2.
  13. Examine the debugging messages shown in the console of R1.
  14. Use u all command on R1 to disable the output of debugging messages in the console.
  15. Enable the sub-interface that is assigned 192.168.0.2 IP address on R2.
  16. Configure traffic capturing on all L2 segments on the scheme using Wireshark.
  17. Disable Loopback 0 interface on router R2.
  18. Examine all QUERY and REPLY messages that the routers have been interchanging. Examine the distribution area of EIGRP QUERY messages.
  19. Disable all performing traffic captures.
  20. Enable Loopback 0 interface on R2.
  21. On routers R2, R3, and R4, delete setting that makes them perform functions of stub routers.
  22. Use sho eigrp address-family ipv4 interfaces detail command on R1 to examine default values of hello and hold intervals.
  23. On routers R1 and R2, specify the value of the hold interval as 10000 seconds for the interface that connects these devices.
  24. Use sho eigrp address-family ipv4 interfaces detail command to make sure that the changes have been made successfully.
  25. Create an extended access list that allows all traffic types except EIGRP on R2 and apply it for the incoming direction to the interface that interconnects R1 and R2.
  26. Make sure that R2 does not receive EIGRP HELLO packets from R1 any more.
  27. Perform capturing of all EIGRP messages on the link between R1 and R2 using Wireshark.
  28. Disable Loopback 0 interface on router R3.
  29. Use sho ei address-family ipv4 topology 3.3.3.3/32 command on R1 and learn in what state 3.3.3.3/32 prefix is being from the output of this command.
  30. Use sho eigrp address-family ipv4 topology active command to review all prefixes that are active.
  31. Delete the access list previously created on R2.
  32. Enable Loopback 0 interface on R3.
  33. Specify the default values for hold intervals on routers R1 and R2.
  34. Review EIGRP messages captured via Wireshark. Disable all captures that are being performed.

Route summarization

  1. Configure summarization for client routes to 192.168.0.0/22 prefix on R2 and R3.
  2. Examine the routing table and topology table on R1. Explain what you saw.
  3. Also, configure summarization for client routes to 192.168.0.0/22 prefix on R4.
  4. Examine the routing table and topology table for 192.168.0.0/22 prefix on R2. Explain what you saw.
  5. Use summary-metric 192.168.0.0/22 distance 10 command to change the value of the administrative distance for 192.168.0.0/22 prefix on R2.
  6. Use summary-metric 192.168.0.0/22 distance 255 command on R3.
  7. Examine the routing table and topology table on routers R1 and R3. Explain what you saw.
  8. Delete the commands that change the administrative distance on R2 and R3.
  9. Use show ip protocols command on routers to which the client networks are connected to learn what kind of route summarization is being performed.
  10. Create a prefix-list that allows 192.168.1.0/24 prefix on R4.
  11. Create a route-map on router R4 that will allow what would be allowed by the prefix-list created in the previous item.
  12. Delete the command that performs summarization of client prefixes on R4.
  13. Use summary-address 192.168.0.0/22 leak-map name command, where name is the name of the previously created route-map, on R4.
  14. Examine the routing table and topology table on R1. Explain what you saw.

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

Lab aims

To make students acquainted with operating of QinQ technology frequently used in service provider networks or local networks of large companies. The network is built with the help of GNS3 emulator.

Network scheme

Lab description

The lab emulates a network of a provider who has points of presence in two cities: Moscow and St. Petersburg. The operator provides clients with L2-connectivity but does not restrict them to the only virtual network, it means that the provider gets 802.1Q trunk from clients. The operator also provides routing between virtual networks of the same client.

Studying of QinQ settings for real switches is out of scope of this lab, so ordinary emulator’s switches (Ethernet switch) are appropriate as L2 devices. Cisco 7200 model with the version of the operating system (IOS) recommended by the tutor is used as a router.

SW1, SW5, PC1, PC2, PC5 and PC6 devices belong to A company. The company B has the following devices: SW2, SW6, PC3, PC4, PC7 and PC8. The network operator has R1 router and two switches (SW3 and SW4).

The table below presents mapping between clients’ computers, numbers of virtual networks and PCs’ IP addresses.

PC VLAN IP-address
PC1 2 192.168.0.2
PC2 3 192.168.1.2
PC3 2 192.168.2.2
PC4 3 192.168.3.2
PC5 2 192.168.0.3
PC6 3 192.168.1.3
PC7 2 192.168.2.3
PC8 3 192.168.3.3

 

As the numbers of clients’ virtual networks overlap, there is no ability to transmit them via an ordinary trunk between cities.

  • Perform all connections presented at the scheme and turn on the equipment.
  • On switches SW1, SW2, SW5 and SW6 perform all necessary settings for connection of the clients’ computers. Interfaces #1 should be configured in trunk mode.
  • Assign IP-addresses, subnet masks and default gateways on all PCs of both companies. As a gateway set IP address with the first three octets equal to the workstation’s address and the last one equal to 1. For example, for PC1 192.168.0.1 address should be set up as a default gateway. Subnet masks should be equal to /24. Thus, setting of the network parameters for PC1 host is performed with the help of ip 192.168.0.2/24 192.168.0.1 command. One can view current settings with the help of sho ip command.
  • Configure SW3 switch as shown in the picture below. The ports to which clients’ trunks are connected should be in qinq mode. VLAN number means an assigned external tag with the help of which frames of one client will differ from the frames of another one. Thus, in the operator network virtual network VLAN11 is mapped to A client and VLAN 12 is mapped to B client. An internal tag obtained from the client via the trunk is not changed, and only an additional tag is added.

  • Perform settings of SW4 switch similarly to SW3.
  • With the help of ping command (with corresponding arguments), make sure that the connection between computers in Moscow and their corresponding hosts in St. Petersburg is available.
  • With the help of Wireshark network analyzer, capture traffic between switches of the client and service provider, for example, SW1 and SW3. Make sure that the trunk operating is normal.
  • With the help of Wireshark network analyzer, capture traffic between two provider’s switches that means the link between Moscow and St. Petersburg. Generate traffic between PC1 and PC5. Study captured frames and make sure of the presence of 802.1Q double tag.

  • Turn on the interface Gi0/0 on R1 router.
  • Go to configuration mode of Gi0/0.112 subinterface. With the help of encapsulation dot1Q 11 second-dot1q 2 command set up that the subinterface should process traffic with a double tag. At first, an external tag is specified, and then with the help of second-dot1q option an internal tag is specified.
  • Assign IP address 192.168.0.1 with /24 subnet mask to Gi0/0.112 subinterface.
  • Perform similar settings for Gi0/0.113, Gi0/0.122 and Gi0/0.123 subinterfaces (processing tags and IP addresses).
  • From all hosts make sure of the default gateway availability.
  • Capture traffic on the link between R1 and SW3 and analyze it. Which tags present in the frames?
  • Make sure that at this point from each host all other hosts are available, even those placed in the networks of another company.
  • On R1 router configure access lists (ACLs) to deny transmitting traffic between IP networks belonging to different companies.
  • * On the technical site of the provider in St. Petersburg set R2 router and connect it to SW4 switch similarly to the connection of R1 to SW3.
  • * Propose failover solution that allows protecting from failure of one of the routers, so that L3-connectivity between different IP networks of the same client is saved.
  • * Implement the solution proposed in the previous point.

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

Task description

This lab models a situation where two provider's clients need to logically connect their remote networks in a way so that the traffic of one client never intercepts with the other client's traffic. In order to do this one needs to adjust virtual devices as part of the provider edge routers using VRF technology and create GRE-tunnels so that their ends go to the corresponding virtual routers.

Procedure description

At first one should understand what VRF is. VRF (Virtual Routing and Forwarding) is a mechanism of virtual routers creation within one physical device. Among the advantages of this method are almost complete independence of routing tables and the settings of various virtual devices. That's where we get its obvious application: if there's a large provider network where one needs to connect a certain number of new clients with peculiar settings (for example a new DHCP server or default gateway), one will simply need to create a virtual device and configure it in the right way. In our case VRF is used in order to partition traffic of different clients and build necessary logical topology.

The following network must be built on the basis of this task.

Over here LeftSPRouter, CentralSPRouter, and RightSPRouter routers model the provider network, 1Lan1Client and 2Lan1Client are the first client's remote networks, and 1Lan2Client and 2Lan2Client are the remote networks of the second client. One should use Cisco 7200 routers for the provider network and Cisco 3600 routers for building the office networks.

Modelling

Let's add the necessary routers and switches. And configure the switches: interface 1 on SW1 is in the trunk mode (the same mode is called dot1q on GNS3 switch), interface 2 is in the access mode and belongs to VLAN 2, interface 3 is in the access mode too and belongs to VLAN 3, and SW2 has the same settings. Let's connect the device as shown on the scheme, but connecting 1Lan1Client to the second interface of SW1, 1Lan2Client to the third interface of SW1, 2Lan2Client to the third interface of SW2, and 2Lan1Client to the second interface of SW2. That's where modelling section is about to be over and we are passing on to the setup.

Setup

Let's configure the above-mentioned scheme for the first client. In order to do this one will need to create virtual devices on the routers, adjust all necessary interfaces on these devices, create a GRE-tunnel on loopbacks, and finally apply the dynamic routing.

At first one must configure the VRF routers. Add a new virtual router on LeftSPRouter in the global configuration mode.

LeftSPRouter(config)# ip vrf Client1vrf

Assign it a unique ID.

LeftSPRouter(config-vrf)# rd 1:1

Repeat the same with RightSPRouter.

RightSPRouter(config)# ip vrf Client1vrf
RightSPRouter(config-vrf)#rd 1:2

Then configure 1Lan1Client. Enter the interface configuration mode towards the switch (in our case it's called fa0/0) and assign it the IP address with a mask using ip address 10.10.10.2 255.255.255.0 command. Enable the interface using no shutdown command. Also, please create a loopback interface that models the client network.

1Lan1Client(config)# int loopback 1
1Lan1Client(config-if)# ip address 10.10.11.1 255.255.255.0

Let's switch to the configuration of LeftSPRouter. Assign it the IP address with a mask using ip address 192.168.10.1 255.255.255.252 command in the interface configuration mode (towards CentralSPRouter). Enable the interface using no shutdown command.

Repeat the same with the interface towards RightSPRouter.

LeftSPRouter(config-if)# ip address 192.168.30.1 255.255.255.252
LeftSPRouter(config-if)# no shutdown

Now let's configure the interface towards SW1 switch. Enable a sub-interface, associate it with the virtual router, set encapsulation, and assign it the IP-address and mask.

LeftSPRouter(config)# int fa0/0.2
LeftSPRouter(config-if)# ip vrf forwarding Client1vrf
LeftSPRouter(config-if)# encapsulation dot1Q 2
LeftSPRouter(config)# ip address 10.10.10.1 255.255.255.0

Let's switch to the configuration of CentralSPRouter.

CentralSPRouter(config)# int fa0/0
CentralSPRouter(config-if)# ip address 192.168.10.2 255.255.255.252
CentralSPRouter(config-if)# no shutdown
CentralSPRouter(config)# int fa0/1
CentralSPRouter(config-if)# ip address 192.168.20.2 255.255.255.252
CentralSPRouter(config-if)# no shutdown

And then to RightSPRouter. Use the same settings as for LeftSPRouter. Configure and enable interfaces towards LeftSPRouter and CentralSPRouter using ip address 192.168.20.1 255.255.255.252 and ip address 192.168.30.2 255.255.255.252 commands, respectively. Now let's configure the interface towards SW2. Enable a sub-interface, add it to the virtual router, configure encapsulation, and assign it the IP-address and mask.

RightSPRouter(config)# int fa0/0.2
RightSPRouter(config-if)# ip vrf forwarding Client1vrf
RightSPRouter(config-if)# encapsulation dot1Q 2
RightSPRouter(config)# ip address 10.10.40.1 255.255.255.0

The only thing left now is to configure 2Lan1Client. Enter the interface configuration mode towards the switch and assign it the IP address with a mask using ip address 10.10.40.2 255.255.255.0 command. Launch the interface using no shutdown command. Also, please create a loopback interface that emulates the client network.

2Lan1Client(config)# int loopback 1
2Lan1Client(config-if)# ip address 10.10.41.1 255.255.255.0

That's where the first configuration phase ends. Now we need to configure a GRE-tunnel on loopback interfaces between RightSPRouter and LeftSPRouter. Add loopback1 interface in the global configuration mode on LeftSPRouter.

LeftSPRouter(config)# int loopback1
LeftSPRouter(config-if)# ip address 1.1.3.1 255.255.255.252

The tunnel configuration: create a tunnel interface, associate it with the virtual router, and configure the tunnel.

LeftSPRouter(config)# int tunnel1
LeftSPRouter(config-if)# ip vrf forwarding Client1vrf
LeftSPRouter(config-if)# ip address 1.1.1.1 255.255.255.252
LeftSPRouter(config-if)# tunnel source loopback1
LeftSPRouter(config-if)# tunnel destination 1.1.4.1
LeftSPRouter(config-if)# tunnel key 1

The second to the last command shows the address of the other endpoint of the tunnel, which we will configure later, whilst the last command is necessary for tunnel identification.

Let's explain the objective of tunnel key tunnel identification command. Client tunnels are often built on the same interfaces (in our case they are loopback interfaces), which leads to ambiguity in identifying whether an incoming packet belongs to this or that tunnel. One can find it out really easily themselves: only one tunnel will function (the one that was configured the last) if there's no specified key, which means that in our case the first client's tunnel will be switched off after the building of the second client's tunnel on the same loopback interfaces. The ambiguity issue may be solved by building client tunnels on various interfaces, which is pretty resource-intensive. It's really easier to specify the tunnel identification key, which we already did.

Now let's configure RightSPRouter.

RightSPRouter(config)# int loopback1
RightSPRouter(config-if)# ip address 1.1.4.1 255.255.255.252

The tunnel configuration: create a tunnel interface, associate it with the virtual router, and configure the tunnel.

RightSPRouter(config)# int tunnel1
RightSPRouter(config-if)# ip vrf forwarding Client1vrf
RightSPRouter(config-if)# ip address 1.1.1.2 255.255.255.252
RightSPRouter(config-if)# tunnel source loopback1
RightSPRouter(config-if)# tunnel destination 1.1.3.1
RightSPRouter(config-if)# tunnel key 1

Now the tunnel is configured, but it won't work unless the dynamic routing is configured and enabled.

Let's switch to the last phase in the configuration. Choose OSPF as the dynamic routing protocol.

In the provider network for LeftSPRouter.

LeftSPRouter(config)# router ospf 1
LeftSPRouter(config-router)# network 192.168.10.0 0.0.0.3 area 0
LeftSPRouter(config-router)# network 192.168.30.0 0.0.0.3 area 0
LeftSPRouter(config-router)# network 1.1.3.0 0 0.0.0.3 area 0

Now one needs to use the following commands in order to enable routing on LeftSPRouter inside VRF Client1vrf .

LeftSPRouter(config)# router ospf 2 vrf Client1vrf
LeftSPRouter(config-router)# network 10.10.10.0 0.0.0.255 area 0
LeftSPRouter(config-router)# network 1.1.1.0 0.0.0.3 area 0

In the provider network for RightSPRouter.

RightSPRouter(config)# router ospf 1
RightSPRouter(config-router)# network 192.168.20.0 0.0.0.3 area 0
RightSPRouter(config-router)# network 192.168.30.0 0.0.0.3 area 0
RightSPRouter(config-router)# network 1.1.4.0 0 0.0.0.3 area 0

And now the commands for routing on RightSPRouter inside VRF Client1vrf.

RightSPRouter(config)# router ospf 2 vrf Client1vrf
RightSPRouter(config-router)# network 10.10.40.0 0.0.0.255 area 0
RightSPRouter(config-router)# network 1.1.1.0 0.0.0.3 area 0

In the provider network for CentralSPRouter.

CentralSPRouter(config)# router ospf 1
CentralSPRouter(config-router)# network 192.168.20.0 0.0.0.3 area 0
CentralSPRouter(config-router)# network 192.168.10.0 0.0.0.3 area 0

On 1Lan1Client (OSPF process number – VLAN number).

1Lan1Client(config)# router ospf 2
1Lan1Client(config-router)# network 10.10.10.0 0.0.0.255 area 0
1Lan1Client(config-router)# network 10.10.11.0 0.0.0.255 area 0

On 2Lan1Client (OSPF process number – VLAN number).

2Lan1Client(config)# router ospf 2
2Lan1Client(config-router)# network 10.10.40.0 0.0.0.255 area 0
2Lan1Client(config-router)# network 10.10.41.0 0.0.0.255 area 0

That's where the first client configuration ends.

The configuration of the second client is not that different. Below you can see the settings for every device with explanations for the most complicate parts.

1Lan2Client

1Lan2Client(config)# int fa0/0
1Lan2Client(config-if)# ip address 10.10.20.2 255.255.255.0
1Lan2Client(config)# no shutdown
1Lan2Client(config)# int loopback 1
1Lan2Client(config-if)# ip address 10.10.21.1 255.255.255.0
1Lan2Client(config)# router ospf 3
1Lan2Client(config-router)# network 10.10.20.0 0.0.0.255 area 0
1Lan2Client(config-router)# network 10.10.21.0 0.0.0.255 area 0

LeftSPRouter

LeftSPRouter(config)# ip vrf Client2vrf\\new vrf router
LeftSPRouter(config-vrf)# rd 2:1
LeftSPRouter(config)# int fa0/0.3\\interface configuration towards the client network
LeftSPRouter(config-if)# ip vrf forwarding Client2vrf
LeftSPRouter(config-if)# encapsulation dot1Q 3
LeftSPRouter(config)# ip address 10.10.20.1 255.255.255.0
LeftSPRouter(config)# int tunnel2\\new tunnel
LeftSPRouter(config-if)# ip vrf forwarding Client2vrf
LeftSPRouter(config-if)# ip address 1.1.2.1 255.255.255.252
LeftSPRouter(config-if)# tunnel source loopback1\\launch the tunnel on the same loopback as
LeftSPRouter(config-if)# tunnel destination 1.1.4.1\\the first one
LeftSPRouter(config-if)# tunnel key 2\\the ID key will come in handy here
LeftSPRouter(config)# router ospf 3 vrf Client2vrf\\add 1Lan2Client in Client2vrf table
LeftSPRouter(config-router)# network 10.10.20.0 0.0.0.255 area 0
LeftSPRouter(config-router)# network 1.1.2.0 0.0.0.3 area 0

RightSPRouter

RightSPRouter(config)# ip vrf Client2vrf
RightSPRouter(config-vrf)# rd 2:2
RightSPRouter(config)# int fa0/0.3
RightSPRouter(config-if)# ip vrf forwarding Client2vrf
RightSPRouter(config-if)# encapsulation dot1Q 3
RightSPRouter(config)# ip address 10.10.30.1 255.255.255.0
RightSPRouter(config)# int tunnel2
RightSPRouter(config-if)# ip vrf forwarding Client2vrf
RightSPRouter(config-if)# ip address 1.1.2.2 255.255.255.252
RightSPRouter(config-if)# tunnel source loopback1
RightSPRouter(config-if)# tunnel destination 1.1.3.1
RightSPRouter(config-if)# tunnel key 2
RightSPRouter(config)# router ospf 3 vrf Client2vrf
RightSPRouter(config-router)# network 10.10.30.0 0.0.0.255 area 0
RightSPRouter(config-router)# network 1.1.2.0 0.0.0.3 area 0

2Lan2Client

2Lan2Client(config)# int fa0/0
2Lan2Client(config-if)# ip address 10.10.30.2 255.255.255.0
2Lan2Client(config)# no shutdown
2Lan2Client(config)# int loopback 1
2Lan2Client(config-if)# ip address 10.10.31.1 255.255.255.0
2Lan2Client(config)# router ospf 3
2Lan2Client(config-router)# network 10.10.30.0 0.0.0.255 area 0
2Lan2Client(config-router)# network 10.10.31.0 0.0.0.255 area 0

CentralSPRouter doesn't need to be configured. That's where the setup procedure ends and we pass on to testing the network.

Testing

  1. At first one must use ping 10.10.40.2 source 10.10.11.1 command from 1Lan1Client and ping 10.10.30.2 source 10.10.41.1 from 1Lan2Client in order to make sure that the packets successfully reach the network. Also, we will examine the packet path using traceroute command from the same devices and for the same addresses.
  2. Then we will make sure that OSPF protocol functions well by using show ip protocols and show ip route commands on all devices in the network. Think how the above-mentioned commands allow for understanding whether OSPF protocol functions well or not.
  3. Review the operation result of show ip protocols vrf Client1vrf command (show ip protocols vrf Client2vrf) on LeftSPRouter and RightSPRouter. Analyse the data you have received.
  4. Review the output of show ip route vrf Client1vrf command (show ip route vrf Client2vrf) on LeftSPRouter and RightSPRouter.
  5. Use Wireshark to capture the packets on channels between LeftSPRouter and RightSPRouter. Analyse the capture results.
  6. And finally we must check the network fault-tolerance: disable the channel between LeftSPRouter and RightSPRouter to make sure that the network is still functioning. Specify what devices can detect the changes in the provider network.
  7. Switch the channel you just disabled back on. Make sure that the routing in the provider network started functioning well again.
  8. Suggest a solution that allows for transmission of IPv6 user traffic between the client networks in such a way so that the readjustment of the provider network won't be necessary.
  9. *Implement the solution put forward in the previous item.

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

Introduction

Cisco SLB (Server Load Balancing) is meant to distribute load between several servers as well as to ensure fault-tolerance of the provided service since it supports its operation even upon failure of certain servers. SLB is not the only technology that is used for load distribution and quite often the network administrator use NLB or balance the load using DNS too. Using several load balancing techniques at the same time and applying various hardware balancers can also be done.

Cisco Server Load Balancing functions in two modes: L2 and L3. The easiest mode to understand and implement is L3; during this mode the router doesn't only distribute TCP or UDP sessions between the servers, but also change the receiver's IP-addresses (NAT), occasionally together with TCP/UDP port of the receiver (PAT). The real server address is chosen as the receiver's address. The advantage of this load balancing method is a possibility to locate the balancing router and servers in various L3 subnets. Among its drawbacks is a higher CPU utilization which is due to NAT/PAT operation.

NAT/PAT translations do not function in L2 mode, or in other words the receiver's address and port remain the same. So-called selection of the server is performed only on the grounds of the change of receiver's MAC-address. This way all servers will be applied an additional requirement: the OS interface to which the service IP-address has been assigned must be always active. Assigning this kind of IP-address directly to the Ethernet-interface (or a secondary address) is not the best idea since its activation will lead to sending a broadcast ARP query about this address, resulting in an error message about IP-address duplication (which all other similar servers will reply to). In effect, special loopback interfaces are used for that.

The example of a network in which SLB functions is presented below. It's worth noticing that loopback interfaces on the servers in this scheme will only be used upon operation of SLB L2 mode. Client and router external interfaces masks are not shown since in the real network these addresses will obviously come from various sub-networks and may be random.

Task

Configuration of devices featured in this lab is divided into three parts: at first the L3 mode scheme is built, then the reconfiguration is done in order to switch to L2, and then (strictly in the emulation mode) building of a fail-proof load balancing scheme is carried out. It's worth pointing out separately that this lab should be done only when one knows how to do all previous and simpler labs. There's no exact sequence of actions for each setup item, which lets the student be creative and get him/herself familiar with all supportive features. The third part is done strictly in the emulator mode.

When doing this lab using real equipment, please use Cisco 3640 as the router with SLB and choose Cisco 7200 router upon operation in the emulator mode. Also, in the emulator mode one can use routers as the clients and servers.

Part One

  1. Perform all necessary connections and manage all settings for the initial setup (assigning IP-addresses, managing routing, configuring virtual networks on the switch). Make sure that the scheme that you built is operable. One should understand that in the real network there won't be access to the servers externally due to two reasons: firstly, private IP-addresses are not routed globally and secondly, all excessive accesses can be blocked with the access lists.
  2. Switch from the global configuration mode to the virtual server farm test management mode on SLB router using ip slb serverfarm test command.
  3. Type nat server command in order to switch the server farm to L3 mode.
  4. Decide what service needs to be launched in order to test the scheme being built. Upon operation in the emulator mode one can use telnet with the routers-servers as a service. Switch to 10.0.0.2 server management mode in the farm using real 10.0.0.2 port command where port is the port number with the active service under test. Activate the server in the farm using inservice command. Repeat this procedure with the second server. Generally, the port number of a certain server may be different from the port numbers of other servers and the service external port.
  5. Examine the following supportive features: faildetect, maxconns, predictor, retry, and weight.
  6. Use sho ip slb serverfarms, sho ip slb serverfarms detail, and sho ip slb reals privileged mode commands to review statuses of the server farms and servers that are assigned to them.
  7. Use ip slb vserver test command to switch to the test virtual server management mode.
  8. Use serverfarm test command to assign test server farm that you previously created to this virtual server.
  9. One can specify the address (it's 1.1.1.1 in this lab), protocol, and port of the external server using virtual 1.1.1.1 protocol port command.
  10. Switch the virtual server to the service mode using inservice command. Additionally examine capabilities of the following features: advertise, client, sticky, and synguard.
  11. Examine capabilities of sho ip slb conns, sho ip slb reals, sho ip slb stats, sho ip slb sticky, sho ip slb vservers, and sho ip slb wildcard review commands.
  12. Launch test service on the test servers and connect to them via the client. Use netcps, iperf, and similar utilities to measure the performance of the router with SLB in L3 mode on the real equipment.
  13. Make sure that disabling of any server doesn't lead to the failure of the service.

Part Two

  1. Create loopback interface with 1.1.1.1 address assigned to it on the test servers or routers in the emulator mode.
  2. Create a new server farm, but do not use nat server command.
  3. Add servers to the new server farm. One doesn't need to specify the port upon adding the server to L2 farm.
  4. Shut down test virtual server.
  5. Change the server farm on test virtual server with a new one.
  6. Activate test virtual server.
  7. Make sure that the new operation mode of SLB functions well.
  8. Test the service availability upon disabling any of the servers.

Part Three

  1. Build a new scheme in such a way so that apart from SLB router there is also another router of the same model and with the same IOS version.
  2. Set up HSRP with a named group on both of the routers.
  3. Shut down test virtual server.
  4. Copy the settings from the first SLB router to the second.
  5. Activate test virtual server on both of the routers using inservice standby name command where name is the name of the preconfigured HSRP group.
  6. Make sure that the virtual server status depends on the node status in the configured HSRP group.
  7. Test fault-tolerance of the scheme by separately disabling both SLB routers.