Tuesday, November 5, 2013

OSPF Forwarding Address (FA) Part 1 - Is It All About Taking A Shortcut ?

OSPF Forwarding Address or FA is relatively less known as feature among network engineers. Okay I might be wrong... But as far I remember this feature was never been on CCNP Route/BSCI blueprint. So unless people are working on CCIE or reading through OSPF RFC, chances are quite slim they ever heard of it.

Anyways, lets start this series with Introduction of FA and later we see how it turns into good option or bad option to be enabled on network.

Now let's review our topology to begin with:


In this network we are running OSPF Area 0 between R2, R3 & R4 and their respective Loopback interfaces are advertised into OSPF. Now consider that it's a transition phase for this network where you are adding BGP IN but at the moment only R2 is capable of running BGP where as R3 requires some RAM upgrade or IOS Image upgrade to run BGP. So we have enabled EBGP between R1 & R2 at the moment which means R2 is currently Acting as OSPF ASBR. Also there is no OSPF running on 123.0.0.X/24 network at the moment.

Now lets review what CLI has to tell us:

Starting with R4's Routing Table:

R4#sh ip route ospf | begin ^Gateway
Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
O E2     1.1.1.1 [110/1] via 24.0.0.2, 00:00:48, Serial2/0
      2.0.0.0/32 is subnetted, 1 subnets
O        2.2.2.2 [110/65] via 24.0.0.2, 00:02:49, Serial2/0
      3.0.0.0/32 is subnetted, 1 subnets
O        3.3.3.3 [110/2] via 34.0.0.3, 00:02:49, GigabitEthernet1/0

So as we can see, R4 is pointing Route towards R2 (ASBR). Which of course seems to be okay as the only way to get out of this network to reach prefix 1.1.1.1/32 is that way only. But on the flip it doesn't seem to be most optimal path since link between R2 - R4 is a T1 connection Vs R3 - R4 as GigE connection. 

Let's verify the Data Plane from R4 prospective:

R4#traceroute 1.1.1.1 source loopback 0
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
  1 24.0.0.2 88 msec 80 msec 36 msec
  2 123.0.0.1 140 msec 120 msec 168 msec

Now let's take a quick look what network view R3 has:

R3#sh ip route ospf | begin ^G
Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
O E2     1.1.1.1 [110/1] via 34.0.0.4, 00:04:55, GigabitEthernet2/0
      2.0.0.0/32 is subnetted, 1 subnets
O        2.2.2.2 [110/66] via 34.0.0.4, 00:06:56, GigabitEthernet2/0
      4.0.0.0/32 is subnetted, 1 subnets
O        4.4.4.4 [110/2] via 34.0.0.4, 00:06:56, GigabitEthernet2/0
      24.0.0.0/24 is subnetted, 1 subnets
O        24.0.0.0 [110/65] via 34.0.0.4, 00:06:56, GigabitEthernet2/0

R3#traceroute 1.1.1.1 source loopback 0
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
  1 34.0.0.4 84 msec 76 msec 164 msec
  2 24.0.0.2 116 msec 64 msec 216 msec
  3 123.0.0.1 156 msec 140 msec 120 msec

Now this definitely doesn't look good even. Since we are following a longer path which also has a Poor Man's T1 connection in between.



Can we fix this design even without Running BGP on R3 ?



Of course....with FA :)

FA or Forwarding Address is a field we find under OSPF LSA Type-5. In most cases the FA is 0.0.0.0 which means "No" FA. In such case the traffic will be forwarded out to ASBR itself.

To include FA in OSPF LSA - 5, there are couple of conditions that needs to meet as follows:

"These conditions set the forwarding address field to a non-zero address:

OSPF is enabled on the ASBR's next hop interface AND

ASBR's next hop interface is non-passive under OSPF AND

ASBR's next hop interface is not point-to-point AND

ASBR's next hop interface is not point-to-multipoint AND

ASBR's next hop interface address falls under the network range specified in the router ospf command."

Okay let's cut the crap out spelled above and make it simple " The OSPF Network Type on ASBR External interface should be Broadcast while enabling OSPF and The Interface shouldn't be passive under OSPF Process"


Now let first review R4 and R3's LSA-5 before making any changes:

R4#sh ip ospf database external

            OSPF Router with ID (4.4.4.4) (Process ID 1)

                Type-5 AS External Link States

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 143
  Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 1.1.1.1 (External Network Number )
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000001
  Checksum: 0xCD75
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 1
        Forward Address: 0.0.0.0
        External Route Tag: 100


R3#sh ip ospf database external
            OSPF Router with ID (3.3.3.3) (Process ID 1)

                Type-5 AS External Link States

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 367
  Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 1.1.1.1 (External Network Number )
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000001
  Checksum: 0xCD75
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 1
        Forward Address: 0.0.0.0
        External Route Tag: 100

Now let's first enable OSPF on R2 (ASBR) only on interface facing R1 to see if that helps with anything.

R2(config)#router ospf 1
R2(config-router)#network 123.0.0.2 0.0.0.0 area 0
R2(config-router)#end

Now let's review back the LSA-5 again on R3 & R4


R4#sh ip ospf database external

            OSPF Router with ID (4.4.4.4) (Process ID 1)

                Type-5 AS External Link States

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 183
  Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 1.1.1.1 (External Network Number )
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000002
  Checksum: 0x289D
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 1
        Forward Address: 123.0.0.1
        External Route Tag: 100

Let's verify the Data Plane:

R4#traceroute 1.1.1.1 source loopback 0
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
  1 24.0.0.2 56 msec 96 msec 36 msec
  2 123.0.0.1 160 msec 116 msec 156 msec



Seems like though R4 knows about FA now, it is not changing anything in Data Plane.


Now we need to take a Look at R3's LSA-5 :

R3#sh ip ospf database external

            OSPF Router with ID (3.3.3.3) (Process ID 1)

                Type-5 AS External Link States

  LS age: 49
  Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 1.1.1.1 (External Network Number )
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000002
  Checksum: 0x289D
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 1
        Forward Address: 123.0.0.1
        External Route Tag: 100


Again FA is set but let's verify Data Plane to see if it has some affect on traffic forwarding:

R3#traceroute 1.1.1.1 source loopback 0
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
  1  *  *  *
  2  *  *  *
  3  *  *  *
  4  *  *  *
  5  *  *  *

  6


R3#sh ip route ospf | b ^G
Gateway of last resort is not set

      2.0.0.0/32 is subnetted, 1 subnets
O        2.2.2.2 [110/66] via 34.0.0.4, 00:01:23, GigabitEthernet2/0
      4.0.0.0/32 is subnetted, 1 subnets
O        4.4.4.4 [110/2] via 34.0.0.4, 00:35:47, GigabitEthernet2/0
      24.0.0.0/24 is subnetted, 1 subnets
O        24.0.0.0 [110/65] via 34.0.0.4, 00:35:47, GigabitEthernet2/0

R3#sh ip route 123.0.0.1
Routing entry for 123.0.0.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via GigabitEthernet1/0
      Route metric is 0, traffic share count is 1


That's probably you don't want to see on a production network :)

We will return to details in next post talking about why R3 isn't able to reach 1.1.1.1/32 at the moment.



Let's Enable OSPF on R3's interface also facing 123.0.0.X/24 network.

R3(config)#router ospf 1
R3(config-router)#network 123.0.0.3 0.0.0.0 area 0
R3(config-router)#end


*Nov  5 14:27:11.195: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on GigabitEthernet1/0 from LOADING to FULL, Loading Done

Now Let's check our poor fellow R3 again to see if this helped:

R3#sh ip ospf database external

            OSPF Router with ID (3.3.3.3) (Process ID 1)

                Type-5 AS External Link States

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 314
  Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 1.1.1.1 (External Network Number )
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000002
  Checksum: 0x289D
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 1
        Forward Address: 123.0.0.1
        External Route Tag: 100


R3#sh ip ospf border-routers

            OSPF Router with ID (3.3.3.3) (Process ID 1)


                Base Topology (MTID 0)

Internal Router Routing Table
Codes: i - Intra-area route, I - Inter-area route

i 2.2.2.2 [1] via 123.0.0.2, GigabitEthernet1/0, ASBR, Area 0, SPF 5




R3#traceroute 1.1.1.1 source loopback 0
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
  1 123.0.0.1 64 msec 80 msec 108 msec


R3#sh ip route ospf | begin ^G
Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
O E2     1.1.1.1 [110/1] via 123.0.0.1, 00:01:50, GigabitEthernet1/0
      2.0.0.0/32 is subnetted, 1 subnets
O        2.2.2.2 [110/2] via 123.0.0.2, 00:01:50, GigabitEthernet1/0
      4.0.0.0/32 is subnetted, 1 subnets
O        4.4.4.4 [110/2] via 34.0.0.4, 00:17:15, GigabitEthernet2/0
      24.0.0.0/24 is subnetted, 1 subnets
O        24.0.0.0 [110/65] via 123.0.0.2, 00:01:50, GigabitEthernet1/0
                  [110/65] via 34.0.0.4, 00:17:15, GigabitEthernet2/0


Now it looks much better.

But anything changed from R4 prospective ? ... Remember that Poor Man's T1 Link ? :)

R4#traceroute 1.1.1.1 source loopback 0
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
  1 34.0.0.3 52 msec 76 msec 48 msec
  2 123.0.0.1 120 msec 124 msec 168 msec








Now wait till 2nd Part to unfold some more details and Caveats of FA.

HTH...
Deepak Arora
Evil CCIE

In case you want to lab it up yourself, below are the initials:

Initials:

R1
++

!
en
!
conf t
!
ho R1
!
no ip do lo
!
line con 0
 no exec-time
 exit
!
int loop0
 ip add 1.1.1.1 255.255.255.255
 exit
!
int gi1/0
 ip add 123.0.0.1 255.255.255.0
 no sh
 exit
!
router bgp 100
 no auto
 no sync
 nei 123.0.0.2 remote 200
 net 1.1.1.1 mask 255.255.255.255
 exit
!
end
!

=================================

R2
++

!
en
!
conf t
!
ho R2
!
no ip do lo
!
line con 0
 no exec-time
 exit
!
int loop0
 ip add 2.2.2.2 255.255.255.255
 exit
!
int gi1/0
 ip add 123.0.0.2 255.255.255.0
 no sh
 exit
!
int s2/0
 ip add 24.0.0.2 255.255.255.0
 no sh
 exit
!
router bgp 200
 no auto
 no sync
 nei 123.0.0.1 remote 100
 redistribute ospf 1 match internal external 1 external 2
 exit
!
router ospf 1
 net 2.2.2.2 0.0.0.0 area 0
 net 24.0.0.2 0.0.0.0 area 0
 redistribute bgp 200 subnets
 exit
!
end
!

=================================

R3
++

!
en
!
conf t
!
ho R3
!
no ip do lo
!
line con 0
 no exec-time
 exit
!
int loop0
 ip add 3.3.3.3 255.255.255.255
 exit
!
int gi1/0
 ip add 123.0.0.3 255.255.255.0
 no sh
 exit
!
int gi2/0
 ip add 34.0.0.3 255.255.255.0
 no sh
 exit
!
router ospf 1
 net 3.3.3.3 0.0.0.0 area 0
 net 34.0.0.3 0.0.0.0 area 0
 exit
!
end
!

=================================

R4
++

!
en
!
conf t
!
ho R4
!
no ip do lo
!
line con 0
 no exec-time
 exit
!
int loop0
 ip add 4.4.4.4 255.255.255.255
 exit
!
int s2/0
 ip add 24.0.0.4 255.255.255.0
 no sh
 exit
!
int gi1/0
 ip add 34.0.0.4 255.255.255.0
 no sh
 exit
!
router ospf 1
 net 4.4.4.4 0.0.0.0 area 0
 net 34.0.0.4 0.0.0.0 area 0
 net 24.0.0.4 0.0.0.0 area 0
 exit
!
end
!

Sunday, October 20, 2013

The Side Effects Of Route Summarization

Most of Network Engineers are well aware about benefits of using Route Summarization. It's one of those tools which plays an important role in any modern network design specially EIGRP based large scale networks which are prone to old Evil known as Stuck In Active (SIA).

Now there are couple of benefits that Summarization offers like:

> Hiding More Specific Routes - Which Means If one or more networks becomes unreachable or are not stable, The Devices beyond summarization point won't notice this and hence will not cause network convergence

> Also the devices beyond summary point will have only summary route in their Routing Tables instead of more specific routes. Which means less memory utilization and less calculation over head on CPU.

Now what most documents and books doesn't talk about usually are side effects of summarization. 



Pick EIGRP for instance.

Let's first understand how EIGRP chose it's metric that it should advertise to EIGRP Peers for given summary route.

The metric of a summary is based on the metrics of its components where EIGRP chooses the metric of the lowest cost component route as the metric of the summary. When EIGRP creates a summary route, it has to determine the metric to include with the route advertisement—EIGRP examines every entry in the database (topology table) looking for components of the summary that will be suppressed (thus represented by) the summary; EIGRP finds the component with the best composite metric and then copies the metric details from it (bandwidth, delay, etc.) into the summary topology table entry.

Now this technique works well for most of the time except if the component the metric was derived from flaps, the summary flaps as well.

Though we are using the summary to hide reachability information, yet changes to the metric information causes the routers beyond the summary to perform work to keep up with the metric changes. Also there is processing overhead for EIGRP to recalculate the summary metric each time a component changes.

Another Issue With Summarization is as shown below:




It's a typical Hub and Spoke Network where Spokes (R4/R5) are advertising specific subnets to Hub Routers (R2/R3) which are summarizing the Spoke Networks and advertising summary towards the Core Network.

Now as we know that CEF decisions are flow based usually. Which means although R1 will have two Next Hops in routing table for any given spoke subnet. It will still use one particular next hop to specific flow based on CEF Hash. Let's assume it chose R2 for that flow as shown below:




Now everything works well until the Link Between R2-R4 goes down.




Now from R1's prospective nothing has changed since it was receiving summary route from R2 and R3. Since it's just a specific route that has failed, nothing will change from summary standpoint. So our friend R1 never notice any network change and keep forwarding . Where as R2 has no physical connectivity to R4 any longer and effectively black hole the traffic.



Though this design can be fixed easily by introducing a link between R2 & R3:




But this remind us important role of Network Testing Phase as part of your network design and understanding Network Failure Domains well.

Further Readings:


Load Balancing With CEF


EIGRP for IP: Basic Operation and Configuration (The Addison-Wesley Networking Basics Series)




HTH...
Deepak Arora
Evil CCIE

Saturday, October 12, 2013

Network Designer/Architect Vs Network Engineer...Theory Vs Real Life - Part 2

Now let's proceed further with our discussion from where we left it last time. I strongly believe that in Network Engineering field lots of gaps can be filled out with study. There might be a network engineer which could have spent 10 years into industry working on a flat network. If I compare his skill set to a fresher CCIE Lab certified person, our CCIE is most likely a way ahead in terms of skills. Of course people may argue about Experience and all, which I am not saying isn't important. But similarly something like CCIE not only teaches candidates in depth look at technologies but also prepare them to handle mental & physical stress along with importance of strategy.

Now one important thing that also CCIE taught me was - "In the end of day it's just a Technology and as long as we can break it into different pieces , you can see simplicity within complexity".

I remember couple of years back someone during an interview asked me " How much MPLS do you know ? " And I started explaining that I know MPLS quite a bit and have good understanding about how Layer 3 Intra AS MPLS VPNs works but of course since I mostly work for Enterprise customers. So CE is pretty much that defines my reach into SP-MPLS. 

The guy immediately replied back - "Knowing MPLS is far different from working on MPLS"

Wow....

I asked him back if MPLS in real life works much differently from what I know from theory and practice and if he knows something about MPLS which is not documented in any good MPLS book. Also if there is any voodoo magic about MPLS ?

of course I didn't get that job as a result :) hehehe...

But that was necessary to ask. Because when I am interviewing anyone, I always try to find how good he/she is with fundamentals about that particular technology (Of course not expecting bits and bytes info) and if he is good than how much willing that person really is to play the role we are offering. Of course that doesn't mean that I am gonna offer Level 3 Engineer position to him but still perhaps recommend him for Level 2 to give him chance to learn and explore.

Now coming back to idea of using Learning as technique to fill technology understanding gaps. If we talk about CCDE recommended books list (More accurate version), I don't think it's fair that none of those is actually available in India and I must buy US editions. US edition is always a choice and perhaps only choice but one must understand the economical differences we have. 

BGP Design & Implementation - Not Available in India
End To End QOS Network Design - Not Available in India
Definitive MPLS Network Designs - Not Available in India
Optimal Routing Design - Not Available in India
CCDE Quick Reference - Not Available in India
EIGRP For IP - Not Available in India
Comparing, Designing & Deploying VPNs - Not Available in India

CCDE Bootcamp Status:

Vendor - INE - Only run CCDE bootcamps in US
Vendor - Jeremy Filliben - Don't run bootcamps in India

So this is first reason I wanted to highlight in this series to Cisco CCDE Program Manager and CCDE Community.


HTH...

Deepak Arora
Evil CCIE