Sunday, February 16, 2014

Puzzle #2 - Find what is broken - OSPF to EIGRP migration


For this puzzle, the organization will be adding a new Ethernet based circuit in between two sites, site 1 with router R1, and site 2 with R2, to alleviate congestion problems between the two sites.  The original circuit had 3 Mbps in both directions while the new circuit has only 1.5 Mbps.


Because the links are of different sizes and the original link had an issue with congestion the organization has decided to switch from OSPF between R1 and R2 to EIGRP because of the ease of configuration for unequal cost load balancing with the variance command.

The change plan is to configure EIGRP in parallel with OSPF.  Verify unequal cost load balancing and remove OSPF from the routers.  The planned configuration for the routers when both protocols are running is found below:


!R1
hostname R1
!
interface FastEthernet0/0
 description ***3M CIRCUIT TO R2***
 bandwidth 3000
 ip address 192.168.0.1 255.255.255.252
 duplex auto
 speed auto
!
interface FastEthernet0/1
 description ***1.5M CIRCUIT TO R2***
 bandwidth 1500
 ip address 192.168.0.5 255.255.255.252
 duplex auto
 speed auto
!
interface FastEthernet1/0
 description ***SERVER SUBNET 192.168.1.0/24***
 ip address 192.168.1.1 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet2/0
 description ***CLIENT SUBNET 192.168.3.0/25***
 ip address 192.168.3.1 255.255.255.128
 duplex auto
 speed auto
!
!
router ospf 1
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet0/1
 network 192.168.0.0 0.0.255.255 area 0
!
router eigrp 1
 variance 2
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet0/1
 network 192.168.0.0 0.0.255.255



!R2
hostname R2
!
interface FastEthernet0/0
 description ***3M CIRCUIT TO R1***
 bandwidth 3000
 ip address 192.168.0.2 255.255.255.252
 duplex auto
 speed auto
!
interface FastEthernet0/1
 description ***1.5M CIRCUIT TO R1***
 bandwidth 1500
 ip address 192.168.0.6 255.255.255.252
 duplex auto
 speed auto
!
interface FastEthernet1/0
 description ***CLIENT SUBNET 192.168.2.0/24***
 ip address 192.168.2.1 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet2/0
 description ***CLIENT SUBNET 192.168.3.128/25***
 ip address 192.168.3.129 255.255.255.128
 duplex auto
 speed auto
!
!
router ospf 1
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet0/1
 network 192.168.0.0 0.0.255.255 area 0
!
router eigrp 1
 variance 2
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet0/1
 network 192.168.0.0 0.0.255.255



The changes seem to go as planned when both protocols are running.  The network administrator performs the "show ip route" command and sees EIGRP routes with unequal cost and performs a traceroute to verify load balancing.

R2#sho ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     192.168.0.0/30 is subnetted, 2 subnets
C       192.168.0.0 is directly connected, FastEthernet0/0
C       192.168.0.4 is directly connected, FastEthernet0/1
D    192.168.1.0/24 [90/1734656] via 192.168.0.5, 00:35:30, FastEthernet0/1
                    [90/881408] via 192.168.0.1, 00:35:30, FastEthernet0/0
C    192.168.2.0/24 is directly connected, FastEthernet1/0
     192.168.3.0/24 is variably subnetted, 3 subnets, 2 masks
O       192.168.3.0/25 [110/34] via 192.168.0.1, 00:17:01, FastEthernet0/0
D       192.168.3.0/24 is a summary, 00:17:03, Null0
C       192.168.3.128/25 is directly connected, FastEthernet2/0
R2#traceroute 192.168.1.1

Type escape sequence to abort.
Tracing the route to 192.168.1.1

  1 192.168.0.1 44 msec
    192.168.0.5 48 msec *
R2#

But shortly after removing OSPF with "no router ospf 1," calls start coming in from site 2 with clients that cannot reach the server subnet.  What happened?  What did the administrator miss before removing OSPF?






Sunday, February 9, 2014

10 Good Network Administration Habits That Can Help You Run a More Reliable Network

There are all types of networks with different types of redundancy and connections and all types of environments with all levels of skills and change management processes, but the uptime of the network will often be dependent on the diligence of the network administrator.  This list outlines good habits that prevent common pitfalls.  Although this one is geared towards Cisco, it is true across many platforms.

1. Train your eyes for mistakes.

I’ve seen networks down for not just hours but days because one part of the configuration has a mistyped IP address in the second or third octet and it just keeps getting looked over.  Read the entire IP address; memorize valid masks and their corresponding wildcard masks. 

2. If you redistribute, filter.

Route redistribution will kick you in the teeth if you do it carelessly.  Redistribute only when it is the right solution for the job.  Use a distribution list, prefix list, or route map to obtain the specific results you want. 

You should be even more careful with two-way route redistribution, look into using tags to tag the routes you’ve already redistributed to make sure you are not bringing them back into the process again. 

3. Improve your test plan.

Making a network change and then pinging a couple of interfaces may be a typical test plan in many environments but it doesn’t mean too much if your customers come in the next day and their systems can’t get across the network. Test your change by running or having a customer run critical systems after the change.

4. Turn on logging for any critical process and interface.

Enabling log-neighbor-changes on your routing processes, logging event link-status on important interfaces, setting the logging level to informational, expanding the logging buffer, and sending logs to one or more syslog servers will allow you to get key incite to a network outage.  It’s better to be told what is wrong then for fishing around for clues later.

5. Be vigilant; look for errors, and if you don’t know why something is in your configs, research.

Take a little time in a device if you haven’t logged into it in a while, or schedule some time to go through and review each device.  Check for interface errors and queue drops.  Look for configuration items that look wrong, out of place, or you are unfamiliar with and find out why they are there or if they are supposed to be there.  Identify parts of the configuration that should have been removed during a previous maintenance.

6. Dump the ‘do’ command mentality.

I have a real love-hate relationship with the "do" command.  While it may be convenient at times to make sure things are progressing as expected, it drives me absolutely bonkers when I am assisting other network administrators who log in and go straight into global configuration mode.  Be sure to separate all of your work in to the stages of planning, implementation, and verification; and you’ll find you get much better results.

7. Get another pair of eyes on your implementation plan.

Have an implementation plan that is very detailed, so you can basically paste in the changes you need to make and let someone else perform a serious review.  Many environments have a peer review process or a Change Advisory Board that is supposed to do this, but all too often something slips through the cracks.  The other benefit behind a detailed implementation plan is that your time implementing is significantly reduced. 

8. Take your duplex seriously.

Auto-duplex could be the biggest gremlin in the history of networking.  Vendors have not been so careful in their implementation of 802.3u and there is no such thing as a Fast Ethernet compliancy testing body like there is for WIFI.  There have been documented cases of auto-duplex working fine for years and then it just stops and you have an awful duplex mismatch problem on your hands.  Because of the manufacturer’s lack of diligence, that means it falls on you.  Never take your duplex settings lightly, it is a serious network change.  Even when both sides negotiate full-duplex, switching from auto to full-duplex can bring the link down as it can also disable MDIX when MDIX was making up for your lack of a cross-over cable.

9. Include other sections in your plans.

Let your server administrators and desktop support in on your plans.  They will have input on how it will affect them and take their input seriously.  If you have a separate engineering and administration section, check with the administrators who will end up maintaining the design you come up with and get their input on the old design; you’ll have a better product.

10. Practice gathering all the information you can without "show run."

The novice knows to look at their configuration for errors.  This really only lets you verify the commands you think are there, are actually there.   The expert, however, is familiar with the cornucopia of show commands and (use with caution) debug commands out there to tell you the specific problem or verify your implementation.

Saturday, February 8, 2014

Routing a Specific Network over a Dedicating Link

Administrators and engineers often live in an environment where we don't get everything we want.  We may strongly recommend the purchase of some equipment, software, or circuits, and even come up with the business case to back our recommendations, but in the end; it’s not our money or our decision.  So sometimes, or all the time, depending on your environment our your disposition, we have to come up with a solution that is a little more complicated to make the best of what we have.  This also can be rewarding because we get a challenge.

In this scenario, you had a single circuit to your ISP and were running low on bandwidth.  A new requirement was coming and you had to add a new router, R3 to your network, and a new subnet, 212.15.80.192/27, of users and server behind it. You had told your boss, that he would need more bandwidth and recommended upgrading the existing circuit to accommodate the additional traffic of the new subnet and a redundant circuit of the same size.  Disregarding your advice, he ordered a new circuit, and insisted you dedicate the new subnet to the circuit while existing networks traverse the old circuit and you allow both networks across that either link for redundancy.







Rather than getting upset, because he didn't listen to your advice, get excited, because you get to try something a little different.  First let’s take a look at the diagram below and talk about your network before adding router R3 to the topology.


In this topology you were using BGP up to your ISP and advertised the entire IP space that you owned, the 212.15.80.0/24 network.  The ISP gave you only a partial route, which means, you did not receive the entire Internet's routing table, and what would you need that for? You only had one link.  So, you took one reliable network from the ISP, the 12.0.0.0/8 network, and filtered out all other BGP advertisements.  And you set that network to be your default network in the router, so your gateway of last resort was to always route to the 12.0.0.0/8 network, this is a fairly standard practice and you can usually call your ISP and they will tell you what network is best to use as a default network, or it can be found in your contract with the ISP.

On the inside of your network, you are using EIGRP to R2 and you’re redistributing your EIGRP routes into BGP.  To create the /24 advertisement to the ISP, you do and aggregate-address statement in BGP, which says basically that as long as you know a route to something in the /24 network, create and advertisement for the whole network because it belongs to you.

Your configuration before you start looks like this:


!Existing Config
hostname R1
!
ip cef
!
interface FastEthernet0/0
 description ***LINK_TO_R2***
 ip address 212.15.80.1 255.255.255.252
 duplex auto
 speed auto
!
interface Serial0/0
 description ***CIRCUIT_1***
 ip address 12.63.78.2 255.255.255.252
 clock rate 2000000
!
router eigrp 1
 passive-interface default
 no passive-interface FastEthernet0/0
 network 212.15.80.0
 no auto-summary
!
router bgp 3999
 no synchronization
 bgp log-neighbor-changes
 aggregate-address 212.15.80.0 255.255.255.0
 redistribute eigrp 1
 neighbor 12.63.78.1 remote-as 456
 no auto-summary
!
ip default-network 12.0.0.0
!
!
end

Now we have a starting point.  My goal in this demonstration is to make it as simple as possible, so there are several different variations of this configuration you can do; often when manipulating BGP, you end up using route-maps, but I decided to show how to do BGP route-manipulation without route-maps and instead perform the majority of the route selection by using the most specific route.

What do I mean by that?  Well, we already identified that we have 3 subnets in our 212.15.80.0/24 network that need to be routed to the Internet, the 212.15.80.32/27, the 212.15.80.64/27, and new the 212.15.80.192/27.  So how I plan to do this is to advertise the 212.15.80.0/24 to the ISP out of both links, but advertise the old two out of the old link with a 212.15.80.0/25 advertisement and the new network out the new link.  This will allow traffic returning to your old subnets to go over the old link and the traffic returning to the new subnet to go over the new link because the ISP router to choose the /27 routes over the /24 routes because they are more specific.  This should handle your incoming/return traffic.  So for you outgoing traffic, you will first set your old circuit as primary by assigning a higher weight to it.

To do these steps, you will apply the following changes:

First, use ACLs as filters for what advertisements you will send out each link.


ip access-list extended CIRCUIT1-OUT
 permit ip host 212.15.80.0 host 255.255.255.0
 permit ip host 212.15.80.0 host 255.255.255.128
ip access-list extended CIRCUIT2-OUT
 permit ip host 212.15.80.0 host 255.255.255.0
 permit ip host 212.15.80.192 host 255.255.255.224

Then configure BGP, to first enable the new connection, then use the new filters, aggregate the .32/27 and .64/27subnets into a .0/25, and set the weight of the neighbor so the old link will remain primary for most Internet bound traffic.

router bgp 3999
 !enable the new connection
 neighbor 12.78.45.49 remote-as 456
 !use the new filters for outbound advertisements
 neighbor 12.63.78.1 distribute-list CIRCUIT1-OUT out
 neighbor 12.78.45.49 distribute-list CIRCUIT2-OUT out
 !aggregate .32/27 and .64/27 to .0/25
 aggregate-address 212.15.80.0 255.255.255.128
 !keep the old link as primary for Internet bound traffic
 neighbor 12.63.78.1 weight 200
 neighbor 12.78.45.49 weight 100

With this complete, go ahead and enable the new circuit.

interface Serial0/1
 description ***CIRCUIT_2***
 ip address 12.78.45.50 255.255.255.252
 no shutdown

If everything goes well, you should have a BGP neighbor adjacency with 12.78.45.49, which you are not using yet.  You can see the status of a neighbor with, "show ip bgp summary."  If the state has a word like, "idle" or "active" the neighbor adjacency has not formed, but if a number is shown, it has.

R1#sho ip bgp sum
BGP router identifier 212.15.80.5, local AS number 3999
BGP table version is 10, main routing table version 10
9 network entries using 1080 bytes of memory
10 path entries using 520 bytes of memory
6/5 BGP path/bestpath attribute entries using 744 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 3 (at peak 3) using 96 bytes of memory
BGP using 2464 total bytes of memory
BGP activity 9/0 prefixes, 10/0 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
12.63.78.1      4   456     179     177       10    0    0 02:53:46        4
12.78.45.49     4   456     179     178       10    0    0 02:53:48        4

And you can check to see that our gateway of last resort is set to the old neighbor, 12.63.78.1.

R1#sho ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 12.63.78.1 to network 12.0.0.0

B    216.99.15.0/24 [20/0] via 12.63.78.1, 00:00:32
     212.15.80.0/24 is variably subnetted, 7 subnets, 4 masks
C       212.15.80.0/30 is directly connected, FastEthernet0/0
B       212.15.80.0/25 [200/0] via 0.0.0.0, 16:03:13, Null0
B       212.15.80.0/24 [200/0] via 0.0.0.0, 16:03:13, Null0
D       212.15.80.32/27 [90/307200] via 212.15.80.2, 16:04:01, FastEthernet0/0
D       212.15.80.64/27 [90/284160] via 212.15.80.2, 16:04:01, FastEthernet0/0
 *   12.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
B*      12.0.0.0/8 [20/0] via 12.63.78.1, 16:03:15
C       12.78.45.48/30 is directly connected, Serial0/1
C       12.63.78.0/30 is directly connected, Serial0/0
B       12.128.0.0/9 [20/0] via 12.63.78.1, 00:00:34
B    148.78.0.0/16 [20/0] via 12.63.78.1, 00:00:34

At this point, return traffic should come back to you using its respective circuits, but outbound traffic is preferred out only the old circuit.  How can you send traffic destined to the same places (Internet) over a separate circuit based upon its source when normal routing is sent based on its destination?

Your answer is a policy based route.

Such an example is as follows:

You would first define which traffic will be routed differently with an ACL.

ip access-list extended LINK2_PREFERRED
 permit ip 212.15.80.192 0.0.0.31 any

Then you would create a route-map that defines the traffic and the action to take.

route-map PUSH_OVER_LINK2 permit 10
 match ip address LINK2_PREFERRED
 set ip next-hop 12.78.45.49

And finally you would assign that policy to the traffic on the interface it would enter the router.

interface FastEthernet0/1
 description ***LINK_TO_R3***
 ip policy route-map PUSH_OVER_LINK2

But this is not what you are going to do.  You are going to use an extra technique to make sure that the new link is still a feasible next hop.  A very easy way is based on what you have already done.  Right now, you are using the default network of 12.0.0.0/8, and you are basing your 0.0.0.0/0 route upon that.  What you can do is base the 0.0.0.0/0 based upon the policy based route to another potential default network.  In this example, you look at your BGP routes and see the 12.128.0.0/9 and ask the ISP if this is a good 'extra' default network.

To perform this you will first need to filter out the BGP advertisements from the ISP, so that on the old link you will only receive the 12.0.0.0/8, and on the new link, you will receive the 12.0.0.0/8 and the 12.128.0.0/9.

ip access-list extended CIRCUIT1-IN
 permit ip host 12.0.0.0 host 255.0.0.0
ip access-list extended CIRCUIT2-IN
 permit ip host 12.0.0.0 host 255.0.0.0
 permit ip host 12.128.0.0 host 255.128.0.0

router bgp 3999
 neighbor 12.63.78.1 distribute-list CIRCUIT1-IN in
 neighbor 12.78.45.49 distribute-list CIRCUIT2-IN in

After some time, or a clear neighbor soft, your routing table will change:

R1#clear ip bgp * soft in
R1#sho ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 12.63.78.1 to network 12.0.0.0

     212.15.80.0/24 is variably subnetted, 7 subnets, 4 masks
C       212.15.80.0/30 is directly connected, FastEthernet0/0
B       212.15.80.0/25 [200/0] via 0.0.0.0, 14:11:23, Null0
B       212.15.80.0/24 [200/0] via 0.0.0.0, 14:11:23, Null0
D       212.15.80.32/27 [90/307200] via 212.15.80.2, 14:12:09, FastEthernet0/0
D       212.15.80.64/27 [90/284160] via 212.15.80.2, 14:12:11, FastEthernet0/0
 *   12.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
B*      12.0.0.0/8 [20/0] via 12.63.78.1, 14:11:25
C       12.78.45.48/30 is directly connected, Serial0/1
C       12.63.78.0/30 is directly connected, Serial0/0
B       12.128.0.0/9 [20/0] via 12.78.45.49, 14:11:25

You now receive the 12.128.0.0/9 route only if you have a BGP connection to your ISP on the new circuit.  Now you track the condition of the route using a track statement.

track 1 ip route 12.128.0.0 255.128.0.0 reachability

If the connection is up, the track will look like this:

R1#sho track
Track 1
  IP route 12.128.0.0 255.128.0.0 reachability
  Reachability is Up (BGP)
    2 changes, last change 02:54:26
  First-hop interface is Serial0/1

If it is down, it will look like this:

R1#sho track
Track 1
  IP route 12.128.0.0 255.128.0.0 reachability
  Reachability is Down (no route)
    3 changes, last change 00:00:01
  First-hop interface is unknown

Now you can create the policy-based route, the way you wanted it, where it ensures the new link is up.

ip access-list extended LINK2_PREFERRED
 permit ip 212.15.80.192 0.0.0.31 any

route-map PUSH_OVER_LINK2 permit 10
 match ip address LINK2_PREFERRED
 set ip next-hop verify-availability 12.78.45.49 1 track 1

interface FastEthernet0/1
 description ***LINK_TO_R3***
 ip policy route-map PUSH_OVER_LINK2

And enable the link to R3.

interface FastEthernet0/1
 description ***LINK_TO_R3***
 ip address 212.15.80.5 255.255.255.252
 no shutdown

router eigrp 1
 no passive-interface FastEthernet0/1


When R3 is configured and forms an EIGRP neighbor adjacency we should be ready to do a little testing.  First you should ensure that you are sending the right routes to the ISP on each link.

R1#sho ip bgp nei 12.63.78.1 advertised-routes
BGP table version is 10, local router ID is 212.15.80.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 212.15.80.0/25   0.0.0.0                            32768 i
*> 212.15.80.0      0.0.0.0                            32768 i

Total number of prefixes 2

R1#sho ip bgp nei 12.78.45.49 advertised-routes
BGP table version is 10, local router ID is 212.15.80.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 212.15.80.0      0.0.0.0                            32768 i
*> 212.15.80.192/27 212.15.80.6         307200         32768 ?

Total number of prefixes 2

Just as planned, right?  Now check to see if your policy based route is going as planned with a couple of traceroutes, one from R2, the normal path, and one from R3, for the policy based route.  (In this example, 8.8.8.8 is a loopback address created at the ISP router.)

R2#traceroute 8.8.8.8 source fa0/1

Type escape sequence to abort.
Tracing the route to 8.8.8.8

  1 212.15.80.1 32 msec 20 msec 44 msec
  2 12.63.78.1 64 msec *  64 msec
R2#

R3#traceroute 8.8.8.8 source fa0/1

Type escape sequence to abort.
Tracing the route to 8.8.8.8

  1 212.15.80.5 72 msec 16 msec 48 msec
  2 12.78.45.49 64 msec *  40 msec

They both have a different 2nd hop, which is through the expected circuit.

Here is a traceroute from the ISP, demonstrating the return traffic is correct:

ISP#traceroute 212.15.80.193

Type escape sequence to abort.
Tracing the route to 212.15.80.193

  1 12.78.45.50 20 msec 40 msec 20 msec
  2 212.15.80.6 [AS 3999] 24 msec *  68 msec

ISP#traceroute 212.15.80.33

Type escape sequence to abort.
Tracing the route to 212.15.80.33

  1 12.63.78.2 12 msec 16 msec 24 msec
  2 212.15.80.2 [AS 3999] 56 msec *  8 msec

Your final configuration should look something like the one below.  Now maybe with the money your boss saved in circuits, he can give it to you for a raise.  But, he probably won't.  As for this example, it can be used and expanded in other ways.  Often, it may be desirable to dedicate the traffic to a specific protocol.  This can often be done with NAT, where you NAT the traffic of a specific type to a pool of IP addresses, allowing you to advertise that pool over the link the same way.


!New config
hostname R1
!
ip cef
!
track 1 ip route 12.128.0.0 255.128.0.0 reachability
!
interface FastEthernet0/0
 description ***LINK_TO_R2***
 ip address 212.15.80.1 255.255.255.252
 duplex auto
 speed auto
!
interface Serial0/0
 description ***CIRCUIT_1***
 ip address 12.63.78.2 255.255.255.252
 clock rate 2000000
!
interface FastEthernet0/1
 description ***LINK_TO_R3***
 ip address 212.15.80.5 255.255.255.252
 ip policy route-map PUSH_OVER_LINK2
 duplex auto
 speed auto
!
interface Serial0/1
 description ***CIRCUIT_2***
 ip address 12.78.45.50 255.255.255.252
 clock rate 2000000
!
router eigrp 1
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet0/1
 network 212.15.80.0
 no auto-summary
!
router bgp 3999
 no synchronization
 bgp log-neighbor-changes
 aggregate-address 212.15.80.0 255.255.255.0
 aggregate-address 212.15.80.0 255.255.255.128
 redistribute eigrp 1
 neighbor 12.63.78.1 remote-as 456
 neighbor 12.63.78.1 weight 200
 neighbor 12.63.78.1 distribute-list CIRCUIT1-IN in
 neighbor 12.63.78.1 distribute-list CIRCUIT1-OUT out
 neighbor 12.78.45.49 remote-as 456
 neighbor 12.78.45.49 weight 100
 neighbor 12.78.45.49 distribute-list CIRCUIT2-IN in
 neighbor 12.78.45.49 distribute-list CIRCUIT2-OUT out
 no auto-summary
!
ip default-network 12.0.0.0
!
ip access-list extended CIRCUIT1-IN
 permit ip host 12.0.0.0 host 255.0.0.0
ip access-list extended CIRCUIT1-OUT
 permit ip host 212.15.80.0 host 255.255.255.0
 permit ip host 212.15.80.0 host 255.255.255.128
ip access-list extended CIRCUIT2-IN
 permit ip host 12.0.0.0 host 255.0.0.0
 permit ip host 12.128.0.0 host 255.128.0.0
ip access-list extended CIRCUIT2-OUT
 permit ip host 212.15.80.0 host 255.255.255.0
 permit ip host 212.15.80.192 host 255.255.255.224
ip access-list extended LINK2_PREFERRED
 permit ip 212.15.80.192 0.0.0.31 any
!
!
!
!
route-map PUSH_OVER_LINK2 permit 10
 match ip address LINK2_PREFERRED
 set ip next-hop verify-availability 12.78.45.49 1 track 1
!
!
end

Note: You may have to work with your ISP to accept smaller sized network advertisements. It may be beneficial to explain they only need to advertise the /24 out to the Internet and accept the smaller networks only within their topology.

Tuesday, February 4, 2014

Scenario from Puzzle #1 - Configured in a better way

Previously, I had posted puzzle #1, which had a network topology of two routers in the organization, R1 and R2, that connected via a tunnel over two serial connections using a statically routed transport network.  In the scenario from puzzle #1, the network administrator followed several back practices for the use of tunnels; some were pointed out and were part of the solution to the problem, some where not.

The bad habits that were pointed out where to make static routes for the tunnel destination that included more IP address space than needed and to include the network statements for the tunnel endpoints into the routing protocol that is used over the tunnel.  These bad habits often result into a recursive routing error like the one in the problem. 

There were some other bad habits throughout the configuration.  The mask on the loopback should have been a /32.  The /30 was really just wasted IP address space and because the transport network seemed to only use static routing there was really no benefit to use the loopback as a tunnel source except to have only a single tunnel that could be used for either interface, when, this would limit your ability to load balance across the two serial links.

My goal is to show a better configuration, although there are many more than just this one, that will allow the routers to load balance and retain a fairly simple tunneling configuration.  My first choice was to not use any loopback interfaces.  This allowed me to simplify the configuration.  The second is that I chose to use of only 2 tunnels rather than a full mesh of 4 tunnels.  While this also makes it easy to load balance over the two circuits, it does carry risk.  I will be using tunnels that go over R1's serial 0/0 interface to R2's serial0/0 interface and R1's serial 0/1 interface to R2's serial 0/1 interface (See the diagram below).  Redundancy will be offered, however, should one circuit for each tunnel, both tunnels could be inoperable even if there is a path that could exist (if R1's s0/0 fails and R2's s0/1 fails for example).  More tunnels could be created, or more advanced techniques could be used, to offer better redundancy, but I wanted an easier configuration.



The configurations below are for the described implementation of R1 and R2:


!!R1
hostname R1
!
logging buffered 4096 informational
!
interface Tunnel0
 description ***TUNNEL TO R2 OVER S0/0***
 ip address 172.18.1.1 255.255.255.252
 tunnel source Serial0/0
 tunnel destination 12.43.78.134
!
interface Tunnel1
 description ***TUNNEL TO R2 OVER S0/1***
 ip address 172.18.1.5 255.255.255.252
 tunnel source Serial0/1
 tunnel destination 12.43.78.138
!
interface FastEthernet0/0
 description ***USER NETWORK***
 ip address 172.17.51.1 255.255.255.0
 duplex auto
 speed auto
!
interface Serial0/0
 description ***TRANSPORT LINK1***
 ip address 12.43.78.122 255.255.255.252
 clock rate 2000000
!
interface Serial0/1
 description ***TRANSPORT LINK2***
 ip address 12.43.78.126 255.255.255.252
 clock rate 2000000
!
router ospf 1
 log-adjacency-changes
 passive-interface default
 no passive-interface Tunnel0
 no passive-interface Tunnel1
 network 172.16.0.0 0.15.255.255 area 0
!
ip route 12.43.78.134 255.255.255.255 12.43.78.121 name R2_S0/0_IP
ip route 12.43.78.138 255.255.255.255 12.43.78.125 name R2_S0/1_IP
!
end


!!R2
hostname R2
!
logging buffered 4096 informational
!
interface Tunnel0
 description ***TUNNEL TO R1 OVER S0/0***
 ip address 172.18.1.2 255.255.255.252
 tunnel source Serial0/0
 tunnel destination 12.43.78.122
!
interface Tunnel1
 description ***TUNNEL TO R1 OVER S0/1***
 ip address 172.18.1.6 255.255.255.252
 tunnel source Serial0/1
 tunnel destination 12.43.78.126
!
interface FastEthernet0/0
 description ***SERVER NETWORK***
 ip address 172.17.100.1 255.255.255.0
 duplex auto
 speed auto
!
interface Serial0/0
 description ***TRANSPORT LINK1***
 ip address 12.43.78.134 255.255.255.252
 clock rate 2000000
!
interface Serial0/1
 description ***TRANSPORT LINK2***
 ip address 12.43.78.138 255.255.255.252
 clock rate 2000000
!
router ospf 1
 log-adjacency-changes
 passive-interface default
 no passive-interface Tunnel0
 no passive-interface Tunnel1
 network 172.16.0.0 0.15.255.255 area 0
!
ip route 12.43.78.122 255.255.255.255 12.43.78.133 name R1_S0/0_IP
ip route 12.43.78.126 255.255.255.255 12.43.78.137 name R2_S0/1_IP
!
end

Once configured, you should verify that OSPF was able to perform a neighbor adjacency over the tunnels with "show ip ospf neighbor."

R1#sho ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
12.43.78.141      0   FULL/  -        00:00:30    172.18.1.6      Tunnel1
12.43.78.141      0   FULL/  -        00:00:30    172.18.1.2      Tunnel0

If successful, you can verify that load balancing is working by performing a "show ip route" and ensuring two routes for the server network on the other side.  Then, perform a traceroute to that network from your client network interface.  If the router is load balancing you will see two next hop routers in the traceroute.

R1#sho ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     172.17.0.0/24 is subnetted, 2 subnets
C       172.17.51.0 is directly connected, FastEthernet0/0
O       172.17.100.0 [110/11121] via 172.18.1.6, 1d03h, Tunnel1
                     [110/11121] via 172.18.1.2, 1d03h, Tunnel0
     172.18.0.0/30 is subnetted, 2 subnets
C       172.18.1.4 is directly connected, Tunnel1
C       172.18.1.0 is directly connected, Tunnel0
     12.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C       12.43.78.120/30 is directly connected, Serial0/0
C       12.43.78.124/30 is directly connected, Serial0/1
S       12.43.78.138/32 [1/0] via 12.43.78.125
S       12.43.78.134/32 [1/0] via 12.43.78.121
R1#
R1#traceroute 172.17.100.1 source fa0/0

Type escape sequence to abort.
Tracing the route to 172.17.100.1

  1 172.18.1.6 20 msec
    172.18.1.2 40 msec *



Sunday, February 2, 2014

Answer to Puzzle #1

Previously, I had posted a puzzle:
http://ephemeralportal.blogspot.jp/2014/02/tunnel-puzzle-find-what-is-broken.html

First the easier part, what is happening? what can you do to fix the issue?

In this example, the network administrator who configured used several bad practices.  The big one that hit him was that he included the tunnel endpoints in the routing process.  The network statement "network 12.0.0.0 0.255.255.255 area 0" allowed OSPF to advertise the loopback address to the router on the other side.  If you would have had access to the logs in R1.  You would have seen:

%OSPF-5-ADJCHG: Process 1, Nbr 12.43.78.141 on Tunnel0 from LOADING to FULL, Loading Done
%TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
%OSPF-5-ADJCHG: Process 1, Nbr 12.43.78.141 on Tunnel0 from FULL to DOWN, Neighbor Down: Interface down or detached

So as soon as the tunnel came up, OSPF formed an adjacency to the router on the other side of the tunnel.  It then advertised the loopback address to the other router.  This is a problem, because it is recursive routing.  The route for the other side of the tunnel must go over the transport network and not the tunnel or it will have no way to route the tunnel packets.  The router discovered this error and disabled the tunnel interface.

So our fix is to remove the network statement for the 12.0.0.0 network.

router ospf 1
  no network 12.0.0.0 0.255.255.255 area 0


In addition changing the static routes from a /30 to the /32 for the loopbacks would also fix the issue. This is a recommended practice along with the removal of the unnecessary network statement for the 12 network shown above.

The other part is a little more difficult, and is probably the question his boss will ask, why did this problem start when OSPF was introduced and not with EIGRP?  The answer lies in the mask used for the loopback.  Rather than using a /32, the network administrator used a /30, and made similar static routes over the transport network.  When EIGRP was implemented, EIGRP advertised the /30 network; the administrative distance of EIGRP, 90, was higher than the static routes created of 1 and 2 so the EIGRP advertisement was not put into the routing table.  With OSPF, all advertisements for loopback interfaces are always a /32, even if /30 is configured on the interface.  So it did not matter if the administrative distance of the static was lower, the OSPF route was most specific and the process would try to add the route to the routing table, creating a recursive routing error.

Additional:

OSPF loopback behavior can be changed:
http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a0080094704.shtml#qone

I have written a follow on article outlining a better way to configure the routers in this scenario.
http://ephemeralportal.blogspot.jp/2014/02/scenario-from-puzzle-1-configured-in.html

Saturday, February 1, 2014

Puzzle #1 - Find what is broken - Dealing with tunnels

It seems like everyone likes puzzles, so I thought I would make one.

The diagram below indicates a network where users on router 1 connect to the servers on router 2 via a transport network.


Router 1 and Router 2 had an EIGRP neighbor adjacency using EIGRP and everything was working fine, however, in an effort to move to open standards a similar configuration with OSPF was implemented.  Now, tunnel 0 will not stay up.

The current configurations for R1 and R2 are below.


!!!R1
!
hostname R1
!
!
logging buffered 4096 informational
!
interface Tunnel0
 description ***TUNNEL TO R2***
 ip address 172.18.1.1 255.255.255.252
 tunnel source Loopback0
 tunnel destination 12.43.78.141
!
interface Loopback0
 ip address 12.43.78.129 255.255.255.252
!
interface FastEthernet0/0
 description ***USER NETWORK***
 ip address 172.17.51.1 255.255.255.0
 duplex auto
 speed auto
!
interface Serial0/0
 description ***TRANSPORT LINK1***
 ip address 12.43.78.122 255.255.255.252
 clock rate 2000000
!
!
interface Serial0/1
 description ***TRANSPORT LINK2***
 ip address 12.43.78.126 255.255.255.252
 clock rate 2000000
!
router ospf 1
 log-adjacency-changes
 passive-interface default
 no passive-interface Tunnel0
 network 12.0.0.0 0.255.255.255 area 0
 network 172.16.0.0 0.15.255.255 area 0
!
ip route 12.43.78.140 255.255.255.252 12.43.78.121 name R2_LOOPBACK_NETWORK
ip route 12.43.78.140 255.255.255.252 12.43.78.125 2 name R2_LOOPBACK_NETWORK



!!R2
!
hostname R2
!
!
logging buffered 4096 informational
!
interface Tunnel0
 description ***TUNNEL TO R1***
 ip address 172.18.1.2 255.255.255.252
 tunnel source Loopback0
 tunnel destination 12.43.78.129
!
interface Loopback0
 ip address 12.43.78.141 255.255.255.252
!
interface FastEthernet0/0
 description ***SERVER NETWORK***
 ip address 172.17.100.1 255.255.255.0
 duplex auto
 speed auto
!
interface Serial0/0
 description ***TRANSPORT LINK1***
 ip address 12.43.78.134 255.255.255.252
 clock rate 2000000
!
!
interface Serial0/1
 description ***TRANSPORT LINK2***
 ip address 12.43.78.138 255.255.255.252
 clock rate 2000000
!
router ospf 1
 log-adjacency-changes
 passive-interface default
 no passive-interface Tunnel0
 network 12.0.0.0 0.255.255.255 area 0
 network 172.16.0.0 0.15.255.255 area 0
!
ip route 12.43.78.128 255.255.255.252 12.43.78.133 name R1_LOOPBACK_NETWORK
ip route 12.43.78.128 255.255.255.252 12.43.78.137 2 name R1_LOOPBACK_NETWORK

The EIGRP configuration that was working is below.

!old eigrp section
router eigrp 1
 passive-interface default
 no passive-interface Tunnel0
 network 12.0.0.0
 network 172.16.0.0 255.240.0.0
 no auto-summary

Additionally, the routers can easily ping each other via their loopback addresses that are used for the tunnels.


R1#ping 12.43.78.141 source 12.43.78.129

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.43.78.141, timeout is 2 seconds:
Packet sent with a source address of 12.43.78.129
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/43/76 ms

Why did this tunnel start failing when OSPF was introduced?  What can be done to fix the issue?