messed up default in a vrf

Problem was that servers in a vrf that used a stub area could not reach outside the VRF. The default routes were messed up they were pointing not to the exit but to themselves. I knew this was an area 0 problem as you get a default route when you have a connection to area 0.

The flip side is that when you are setting up a VRF the box that you want to originate has to have 1 interface in area 0 to force the advertisement of a default route

Looking in one of the switches i see that there is an area 0 there. This is not correct there is not supposed to be one. 

 Routing Process 100 with ID 10.202.255.7 VRF up
Area BACKBONE(0.0.0.0) (Inactive)
        Area has existed for 1w0d
        Interfaces in this area: 1 Active interfaces: 1
        Passive interfaces: 1  Loopback interfaces: 0
        No authentication available
        SPF calculation has run 2 times
         Last SPF ran for 0.000125s
        Area ranges are
        Number of LSAs: 90, checksum sum 0x2e88fb
   Area (0.0.0.202)
        Area has existed for 2y9w
        Interfaces in this area: 22 Active interfaces: 21
        Passive interfaces: 19  Loopback interfaces: 1
        This area is a STUB area
        Generates stub default route with cost 1
        No authentication available
        SPF calculation has run 690 times
         Last SPF ran for 0.003378s
        Area ranges are
        Number of LSAs: 31, checksum sum 0xeb8bc

So now need to find the bad interface I just need to know which interface is in area 0 so I can fix it

sho ip ospf int vrf up | inc Vlan|area
 Vlan6626 is up, line protocol is up
    IP address 10.10.10.2/23, Process ID 100 VRF backup, area 0.0.0.0

so fixing the ospf area statement under the SVI (this was NX-OS) fixes the problem.

So what about applications specifically do network engineers need to know.

I was at Network Worlds ONX (SDN) conference and I heard for the nth time that network engineers need to learn how to communicate with our application developer partners. Learn WHAT, never seems to be answered. So I came to the conclusion I would need to figure this out myself. Clearly we are going to have to speak some common language and develop a way to map the design of an application into network characteristic we can provision (QoS, load balancing, security, traffic engineering etc.). I think the knowledge is there (and been there for a while) so looking at the ancient texts may give me some answers My first stop is the classic 8 myths of distributed computing The network is reliable. Latency is zero. Bandwidth is infinite. The network is secure. Topology doesn't change. There is one administrator. Transport cost is zero. The network is homogeneous See below for some links. We can now begin a discussion as to did the application developer make any of these assumptions and are any of these issues in your network. http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing http://java.sys-con.com/node/38665 http://www.rgoarchitects.com/Files/fallacies.pdf I also remembered that there are a number of different interaction models for applications RPC: Short message the application is waiting for a response so latency important Message queuing: I send a message and check back later, latency not as important File transfer: a 1 way transmission care about available bandwidth and is the application written to consume the bandwidth. Email? Streaming Not sure if data base calls are the same as RPC or different. The point is that the interaction model between application components is key to what demands the application will have upon the network. So understanding the interaction models and mapping them to the sorts of network services are required to make those applications work seems a good place to start. I am not sure if I need to go into the types of SOA, SOAP, XML etc. I am hoping that people smarter than me can begin to describe what the right information we need to have as network engineers.