## Cisco – Two LAN, Two WAN ISP and NAT

We recently received a request from a rural customer who was tired of their unreliable 1Mbps ADSL line to add a second ADSL line to their network. The line was ordered and installed and we then added a second ADSL wic interface to their router and set to work making it work. Our brief was to make it work so that each LAN was associated with one WAN link and only used that WAN link. This is how we went about it.

Clearly the second interface needed to be associated with a second dialer created to log in and manage the second connection. Furthermore, we needed to add a second DHCP pool. This new config is shown as follows:

DHCP config:-

```ip dhcp pool pollux
network 192.168.200.0 255.255.255.0
default-router 192.168.200.1
dns-server 62.6.40.178 62.6.40.162

As you can see this connection is using BT DNS servers.```

Dialer config:-

```interface Dialer1
ip mtu 1492
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer pool 2
no cdp enable
ppp authentication chap pap callin
ppp chap hostname xxxxxxx

We then needed to allocate a second default route to the router and this was achieved by means of the following command:-```
```ip route 0.0.0.0 0.0.0.0 Dialer1

We created an access list to handle the new traffic relating to the new DHCP network as follows:-```
`access-list 22 permit 192.168.200.0 0.0.0.255`

and then we added a new access list to ensure that the traffic on each LAN network remained segregated from the other LAN. This was done as follows:-

```access-list 112 deny   ip 192.168.1.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 112 deny   ip 192.168.1.0 0.0.0.255 172.16.0.0 0.15.255.255
access-list 112 deny   ip 192.168.1.0 0.0.0.255 192.168.0.0 0.0.255.255
access-list 112 permit ip 192.168.1.0 0.0.0.255 any
access-list 122 deny   ip 192.168.200.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 122 deny   ip 192.168.200.0 0.0.0.255 172.16.0.0 0.15.255.255
access-list 122 deny   ip 192.168.200.0 0.0.0.255 192.168.0.0 0.0.255.255
access-list 122 permit ip 192.168.200.0 0.0.0.255 any

Finally we needed to apply route maps to mechanise the access lists, putting them to work maintaining segregation and ensuring correct operation. The following two route maps were configured:-```
```route-map pollux permit 22
set interface Dialer1
!
route-map castor permit 12
set interface Dialer0```

Putting it all together our new configuration was as follows:-

```version 12.4
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec
service timestamps log datetime msec
service sequence-numbers
!
hostname xxx-core-router
!
boot-start-marker
boot-end-marker
!
security authentication failure rate 3 log
logging buffered 512000 debugging
enable secret xxxxxxx
!
no aaa new-model
no network-clock-participate slot 1
no network-clock-participate wic 0
ip cef
!
!
ip auth-proxy max-nodata-conns 3
no ip dhcp use vrf connected
!
ip dhcp pool pollux
network 192.168.200.0 255.255.255.0
default-router 192.168.200.1
dns-server 62.6.40.178 62.6.40.162
!
ip dhcp pool castor
network 192.168.1.0 255.255.255.0
default-router 192.168.1.1
dns-server 62.6.40.178 62.6.40.162
!
!
ip flow-cache timeout active 1
ip name-server 212.159.13.49
ip name-server 212.159.13.50
ip name-server 141.1.1.1
!
!
!
archive
log config
hidekeys
!
!
!
!
!
!
interface ATM0/0
no ip redirects
no ip unreachables
no ip proxy-arp
no atm ilmi-keepalive
dsl operating-mode itu-dmt
pvc 0/38
encapsulation aal5mux ppp dialer
dialer pool-member 1
!
!
interface FastEthernet0/0
ip flow ingress
ip flow egress
ip nat inside
ip virtual-reassembly
ip route-cache flow
ip policy route-map castor
duplex auto
speed auto
!
interface ATM0/1
no ip redirects
no ip unreachables
no ip proxy-arp
no atm ilmi-keepalive
dsl operating-mode itu-dmt
pvc 0/38
encapsulation aal5mux ppp dialer
dialer pool-member 2
!
!
interface FastEthernet0/1
ip nat inside
ip virtual-reassembly
ip policy route-map pollux
duplex auto
speed auto
!
interface Dialer0
ip mtu 1492
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer pool 1
no cdp enable
ppp authentication chap pap callin
ppp chap hostname xxxxxxx
!
interface Dialer1
ip mtu 1492
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer pool 2
no cdp enable
ppp authentication chap pap callin
ppp chap hostname xxxxxxx
!
router rip
version 2
network 192.168.1.0
network 192.168.200.0
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 Dialer0
ip route 0.0.0.0 0.0.0.0 Dialer1
ip route 192.168.88.0 255.255.255.0 192.168.200.2
ip route 212.159.13.49 255.255.255.255 Dialer1
ip route 212.159.13.50 255.255.255.255 Dialer1
!
no ip http server
no ip http secure-server
ip nat inside source list 12 interface Dialer0 overload
ip nat inside source list 22 interface Dialer1 overload
ip nat inside source route-map castor interface Dialer1 overload
ip nat inside source route-map pollux interface Dialer0 overload
!
access-list 12 permit 192.168.1.0 0.0.0.255
access-list 22 permit 192.168.200.0 0.0.0.255
access-list 112 deny   ip 192.168.1.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 112 deny   ip 192.168.1.0 0.0.0.255 172.16.0.0 0.15.255.255
access-list 112 deny   ip 192.168.1.0 0.0.0.255 192.168.0.0 0.0.255.255
access-list 112 permit ip 192.168.1.0 0.0.0.255 any
access-list 122 deny   ip 192.168.200.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 122 deny   ip 192.168.200.0 0.0.0.255 172.16.0.0 0.15.255.255
access-list 122 deny   ip 192.168.200.0 0.0.0.255 192.168.0.0 0.0.255.255
access-list 122 permit ip 192.168.200.0 0.0.0.255 any
route-map pollux permit 22
set interface Dialer1
!
route-map castor permit 12
set interface Dialer0
!
!
!
control-plane
!
!
!
alias exec arp tclsh flash:arp.tcl
alias exec shutnoshut tclsh flash:shutnoshut.tcl
!
line con 0
line aux 0
line vty 0 4
access-class 12 in
transport input telnet
!
ntp clock-period 17207966
ntp server 85.119.80.233
!
end```

The network worked beautifully. Another elegant solution from Rustyice Solutions.

## The EIGRP (Enhanced Interior Gateway Routing Protocol) metric

EIGRP (Enhanced Interior Gateway Routing Protocol) is a network protocol that lets routers exchange information more efficiently than was the case with older routing protocols. EIGRP which is a proprietary protocol evolved from IGRP (Interior Gateway Routing Protocol) and routers using either EIGRP and IGRP can interoperate because the metric (criteria used for selecting a route) used with one protocol can be translated into the metrics of the other protocol. It is this metric which we will examine in more detail.

Using EIGRP, a router keeps a copy of its neighbour’s routing tables. If it can’t find a route to a destination in one of these tables, it queries its neighbours for a route and they in turn query their neighbours until a route is found. When a routing table entry changes in one of the routers, it notifies its neighbours of the change. To keep all routers aware of the state of neighbours, each router sends out a periodic “hello” packet. A router from which no “hello” packet has been received in a certain period of time is assumed to be inoperative.

EIGRP uses the Diffusing-Update Algorithm (DUAL) to determine the most efficient (least cost) route to a destination. A DUAL finite state machine contains decision information used by the algorithm to determine the least-cost route (which considers distance and whether a destination path is loop-free).

The Diffusing Update Algorithm (DUAL) is a modification of the way distance-vector routing typically works that allows the router to identify loop free failover paths.  This concept is easier to grasp if you imagine it geographically. Consider the map of the UK midlands shown in Figure1. The numbers show approximate travel distance, in miles. Imagine that you live in Glasgow. From Glasgow, you need to determine the best path to Hull. Imagine that each of Glasgow’s neighbours advertises a path to Hull. Each neighbour advertises its cost (travel distance) to get to Hull. The cost from the neighbour to the destination is called the advertised distance. The cost from Glasgow itself is called the feasible distance.
In this example, Newcastle reports that if Glasgow routed to Hull through Newcastle, the total cost (feasible distance) is 302 miles, and that the remaining cost once the traffic gets to Newcastle is only 141 miles. Table1 shows distances reported from Glasgow to Hull going through each of Glasgow’s neighbours.

Glasgow will select the route with the lowest feasible distance which is the path through Newcastle.

If the Glasgow-Newcastle road were to be closed, Glasgow knows it may fail over to Carlisle without creating a loop. Notice that the distance from Carlisle to Hull (211 miles) is less than the distance from Glasgow to Hull (302 miles). Because Carlisle is closer to Hull, routing through Hull does not involve driving to Carlisle and then driving back to Glasgow (as it would for Ayr). Carlisle is a guaranteed loop free path.

The idea that a path through a neighbour is loop free if the neighbour is closer is called the feasibility requirement and can be restated as “using a path where the neighbour’s advertised distance is less than our feasible distance will not result in a loop.”

The neighbour with the best path is referred to as the successor. Neighbours that meet the feasibility requirement are called feasible successors. In emergencies, EIGRP understands that using feasible successors will not cause a routing loop and instantly switches to the backup paths.

Notice that Ayr is not a feasible successor. Ayr’s AD (337) is higher than Newcastle’s FD (302). For all we know, driving to Hull through Ayr involves driving from Glasgow to Ayr, then turning around and driving back to Glasgow before continuing on to Hull (in fact, it does). Ayr will still be queried if the best path is lost and no feasible successors are available because potentially there could be a path that way; however, paths that do not
meet the feasibility requirement will not be inserted into the routing table without careful consideration.

EIGRP uses a sophisticated metric that considers bandwidth, load, reliability and delay. That metric is:

 $256, *, left(K_1, *, bandwidth ,+, dfrac {K_2 ,*, bandwidth}{256 - load}, +, K_3 ,*, delayright), *,dfrac {K_5}{reliability ,+, K_4}$

Although this equation looks intimidating, a little work will help you understand the maths and the impact the metric has on route selection.

You first need to understand that EIGRP selects path based on the fastest path. To do that it uses K-values to balance bandwidth and delay. The K-values are constants that are used to adjust the relative contribution of the various parameters to the total metric. In other words, if you wanted delay to be much more relatively important than bandwidth, you might set K3 to a much larger number.

You next need to understand the variables:

• Bandwidth—Bandwidth is defined as (100 000 000 / slowest link in the path) kbps. Because routing protocols select the lowest metric, inverting the bandwidth (using it as the divisor) makes faster paths have lower costs.
• Load and reliability—Load and reliability are 8-bit calculated values based on the performance of the link. Both are multiplied by a zero K-value, so neither is used.
• Delay—Delay is a constant value on every interface type, and is stored in terms of microseconds. For example, serial links have a delay of 20,000 microseconds and Ethernet lines have a delay of 1000 microseconds. EIGRP uses the sum of all delays along the path, in tens of microseconds.

By default, K1=K3=1 and K2=K4=K5=0. Those who followed the maths will note that when K5=0 the metric is always zero. Because this is not useful, EIGRP simply ignores everything outside the parentheses. Therefore, given the default K-values the equation becomes:

 $256, *, left(1, *, bandwidth ,+, dfrac {0 ,*, bandwidth}{256 - load}, +, 1 ,*, delayright), *,dfrac {0}{reliability ,+, 0}$

Substituting the earlier description of variables, the equation becomes 100,000,000 divided by the chokepoint bandwidth plus the sum of the delays:

 $256, *, left(dfrac {10^7}{min(bandwidth)}, +,sum,dfrac {delays}{10}right)$

As a final note, it is important to remember that routers running EIGRP will not become neighbours unless they share K-values. That said however you really should not change the K-values from the default without a compelling reason.

## Could ants power Web3.0 to new heights? OSPF v’s ANTS

One of our engineers having recently completed their latest M.Eng block on the subject of “Natural and Artificial Intelligence“, became aware of advances made in the recent decade towards a new paradigm of network traffic engineering that was being researched. This new model turns its back on traditional destination based solutions, (OSPF, EIGRP, MPLS) to the combinatorial problem of decision making in network routing  favouring instead a constructive greedy heuristic which uses stochastic combinatorial optimisation. Put in more accessible terms, it leverages the emergent ability of sytems comprised of quite basic autonomous elements working together, to perform a variety of complicated tasks with great reliability and consistency.

In 1986, the computer scientist Craig Reynolds set out to investigate this phenomenon through computer simulation. The mystery and beauty of a flock or swarm is perhaps best described in the opening words of his classic 1986 paper on the subject:

The motion of a flock of birds is one of nature’s delights. Flocks and related synchronized group behaviors such as schools of fish or herds of land animals are both beautiful to watch and intriguing to contemplate. A flock … is made up of discrete birds yet overall motion seems fluid; it is simple in concept yet is so visually complex, it seems randomly arrayed and yet is magnificently synchronized. Perhaps most puzzling is the strong impression of intentional, centralized control. Yet all evidence dicates that flock motion must be merely the aggregate result of the actions of individual animals, each acting solely on the basis of its own local perception of the world.

An analogy with the way ant colonies function has suggested that the emergent behaviour of ant colonies to reliably and consistently optimise paths could be leveraged to enhance the way that the combinatorial optimisation problem of complex network path selection is solved.

The fundamental difference between the modelling of a complex telecommunications network and more commonplace problems of combinatorial optimisation such as the travelling salesman problem is that of the dynamic nature of the state at any given moment of a network such as the internet. For example, in the TSP the towns, the routes between them and the associated distances don’t change. However, network routing is a dynamic problem. It is dynamic in space, because the shape of the network – its topology – may change: switches and nodes may break down and new ones may come on line. But the problem is also dynamic in time, and quite unpredictably so. The amount of network traffic will vary constantly: some switches may become overloaded, there may be local bursts of activity that make parts of the network very slow, and so on. So network routing is a very difficult problem of dynamic optimisation. Finding fast, efficent and intelligent routing algorithms is a major headache for telcommunications engineers.

So how you may ask, could ants help here? Individual ants are behaviourally very unsophisticated insects. They have a very limited memory and exhibit individual behaviour that appears to have a large random component. Acting as a collective however, ants manage to perform a variety of complicated tasks with great reliability and consistency, for example, finding the shortest routes from their nest to a food source.

These behaviours emerge from the interactions between large numbers of individual ants and their environment. In many cases, the principle of stigmergy is used. Stigmergy is a form of indirect communication through the environment. Like other insects, ants typically produce specific actions in response to specific local environmental stimuli, rather than as part of the execution of some central plan. If an ant’s action changes the local environment in a way that affects one of these specific stimuli, this will influence the subsequent actions of ants at that location. The environmental change may take either of two distinct forms. In the first, the physical characteristics may be changed as a result of carrying out some task-related action, such as digging a hole, or adding a ball of mud to a growing structure. The subsequent perception of the changed environment may cause the next ant to enlarge the hole, or deposit its ball of mud on top of the previous ball. In this type of stigmergy, the cumulative effects of these local task-related changes can guide the growth of a complex structure. This type of influence has been called sematectonic. In the second form, the environment is changed by depositing something which makes no direct contribution to the task, but is used solely to influence subsequent behaviour which is task related. This sign-based stigmergy has been highly developed by ants and other exclusively social insects, which use a variety of highly specific volatile hormones, or pheromones, to provide a sophisticated signalling system. It is primarily this second mechanism of sign based sigmergy that has been successfully simulated with computer models and applied as a model to a system of network traffic engineering.

In the traditional network model, packets move around the network completely deterministically. A packet arriving at a given node is routed by the device which simply consults the routing table and takes the optimum path based on its destination. There is no element of probability as the values in the routing table represent not probabilities, but the relative desirability of moving to other nodes.

In the ant colony optimisation model, virtual ants also move around the network, their task being to constantly adjust the routing tables according to the latest information about network conditions. For an ant, the values in the table are probabilities that their next move will be to a certain node.The progress of an ant around the network is governed by the following informal rules:

• Ants start at random nodes.
• They move around the network from node to node, using the routing table at each node as a guide to which link to cross next.
• As it explores, an ant ages, the age of each individual being related to the length of time elapsed since it set out from its source. However, an ant that finds itself at a congested node is delayed, and thus made to age faster than ants moving through less choked areas.
• As an ant crosses a link between two nodes, it deposits pheromone however, it leaves it not on the link itself, but on the entry for that link in the routing table of the node it left. Other ‘pheromone’ values in that column of the nodes routing table are decreased, in a process analogous to pheromone decay.
• When an ant reaches its final destination it is presumed to have died and is deleted from the system.R.I.P.

Testing the ant colony optimisation system, and measuring its performance against that of a number of other well-known routing techniques produced good results and the system outperformed all of the established mechanisms however there are potential problems of the kind that constantly plague all dynamic optimisation algorithms. The most significant problem is that, after a long period of stability and equilibrium, the ants will have become locked into their accustomed routes. They become unable to break out of these patterns to explore new routes capable of meeting new conditions which could exist if a sudden change to the networks conditions were to take place. This can be mitigated however in the same way that evolutionary computation introduces mutation to fully explore new possibilities by means of the introduction of an element of purely random behaviour to the ant.

‘Ant net’ routing has been tested on models of US and Japanese communications networks, using a variety of different possible traffic patterns. The algorithm worked at least as well as, and in some cases much better than, four of the best-performing conventional routing algorithms. Its results were even comparable to those of an idealised ‘daemon’ algorithm, with instantaneous and complete knowledge of the current state of the network.

It would seem we have not heard the last of these routing antics…. (sorry, couldnt resist).

## Layer 3 interfaces on Cisco Catalyst switches

Cisco Catalyst multilayer switches support three different types of Layer 3 interfaces:

Routed Port – A pure Layer 3 interface similar to a routed port on a Cisco IOS router.

Switch Virtual Interface (SVI) – A virtual VLAN interface for inter-VLAN routing. In other words, SVI’s are the virtual routed VLAN interfaces.

Bridge Virtual Interface (BVI) – A Layer 3 virtual bridging interface.

With the advent of high-performance switches such as the Catalyst 6500 and 4500, almost every function from spanning tree to routing is done through hardware switching using features such as MLS and Cisco Express Forwarding (CEF)-based MLS.

All Layer 3 Cisco Catalyst switches support routing protocols, but several models of Catalyst switches require enhanced software for specific routing protocol features.

Routed Ports

A routed port is a physical port that acts similarly to a port on a traditional router with Layer 3 addresses configured. Unlike an access port, a routed port is not associated with a particular VLAN. A routed port behaves like a regular router interface, except that it does not support subinterfaces as with Cisco IOS routers. Routed ports are used for point-to-point links; connecting WAN routers and security devices are examples of the use of routed ports.

To configure routed ports, make sure to configure the respective interface as a Layer 3 interface using the no switchport interface command, if the default configurations of the interfaces are Layer 2 interfaces as with the Catalyst 3550 family of switches. In addition, assign IP addresses and other Layer 3 parameters as necessary. After assigning the IP address, make certain that IP routing is globally enabled and that applicable routing protocols are configured. Note that routed ports are available only in Cisco IOS.

Take note: Issuing the no switchport command shuts down the interface and then re-enables it, which might generate messages on the device to which the interface is connected. When you use this command to put the interface into Layer 3 mode, you delete any Layer 2 characteristics configured on the interface.

Switch Virtual Interfaces (SVI)

Switch Virtual Interfaces (SVI) areLayer 3 interfaces that are configured on multilayer Catalyst switches that are used for inter-VLAN routing. An SVI is a VLAN interface that is associated with only one VLAN-ID to enable routing capability on that VLAN.

To configure an SVI for inter-VLAN routing on a Catalyst switch, such as the Catalyst 6000 series, perform these steps:

1. (Optional) Enable IP routing on the router.
Switch (config) #ip routing
2. (Optional) Specify an IP routing protocol or use static routes.
Switch (config) #router ip_routing_protocol options
3. Specify an SVI by using a VLAN interface command.
Switch (config) #interface vlan vlan-id
4. Assign an IP address to the VLAN.
5. Enable the interface.
Switch (config-if) #no shutdown

Note: Make sure that VLAN’s are present in the VLAN database before creating SVI (VLAN) interfaces. Interfaces do not forward traffic for a VLAN until the VLAN is present in the VLAN database.

The number of routed ports and SVI’s supported by the Layer 3 Catalyst switches is not limited by software; however, the relationship between the number of routed ports and the number of Layer 3 interfaces and other features might affect CPU utilisation because of hardware limitations. One such example is NAT, because several models of Catalyst switches do not support NAT in hardware. Most Catalyst families have different limitations with regard to the number of SVI’s supported. In addition the number of VLAN’s and SVI’s supported per Catalyst family is not always the same. For example, a switch may support 256 VLAN’s, but only 64 SVI’s (routed VLAN interfaces). Always refer to product release notes for the latest details about the number of VLAN’s and SVI’s supported per Catalyst family of switch.

Bridge Virtual Interfaces (BVI)

A bridge virtual interface (BVI) is a Layer 3 virtual interface that acts like a normal SVI to route packets across bridged or routed domains. Bridging Layer 2 packets across Layer 3 interfaces is a legacy method of moving frames in a network. To configure a BVI to route, use the integrated routing and bridging (IRB) feature, which makes it possible to route a given protocol between routed interfaces and bridge groups within the same device. Specifically, routable traffic is routed to other routed interfaces and bridge groups, while local or unroutable traffic is bridged among the bridged interfaces in the same bridge group. As a result, bridging creates a single instance of spanning tree in multiple VLAN’s or routed subnets. This type of configuration complicates spanning tree and the behaviour of other protocols, which in turn makes troubleshooting difficult.

In todays network, however, bridging across routed domains is highly discouraged. A BVI is useful for migrating bridged networks to routed networks, while hosts on the bridged network can reach hosts on the routed network during the migration phase.

Only Cisco IOS routers support BVI’s. The exceptions to this rule are the Catalyst 2948G-L3 and 4908G-L3 switches and the WS-X4232 Layer 3 module for the Catalyst 4000 switches. These switches use BVI’s in place of SVI’s for configuration. However these switches are the only models to use BVI’s instead of SVI’s. In addition, Cisco intends to have all future models of Catalyst switches use the SVI method of configuring inter-VLAN routing. Again, except for the Catalyst 2948G-L3 and 4908G-L3 switches and the WS-X4232 Layer 3 module, BVI’s are not supported on multilayer switches, and the use of BVI’s on Cisco IOS routers is discouraged.

Moreover, several Catalyst multilayer switches support fallback bridging methods of forwarding traffic between VLAN’s. Fallback bridging forwards traffic not routed by the switch such as SNA, and connects multiple VLAN’s into one bridge domain by bridging between two or more SVI’s or routed ports. As a result, bridging the spanning tree in multiple VLAN’s creates a single instance of spanning tree for all VLAN’s. When configuring fallback bridging, you assign SVI’s or routed ports to bridge groups, with each SVI or routed port assigned to only one bridge group. All interfaces in the same group belong to the same bridge domain. Cisco does not recommend this practice however. Instead it recommends using fallback bridging exclusively for migration because of the hardware-switching limitations of fallback bridging, confusing spanning tree topologies, and other factors that make troubleshooting difficult.