NLSR

What do you mean by inactive link?

I tried one test just right now with a triangle topology.
I just brought up two machines keeping one down. I saw
two machines picking up each other's prefix without any
problem/delay.

Obaid: can you check the logs to see if there's anything that might indicate the cause?

The conf file of Arizona node is given below. With this setting both Arizona and Caida cannot see each others name prefixes. However, when we commented out the section related to CSU, both nodes started to see each others name. I am also investigating the issue and will update you if something useful is found.

; the general section contains all the general settings for router

general
{
; mandatory configuration command section network, site and router

network /ndn                   ; name of the network the router belongs to in ndn URI format
site /arizona                   ; name of the site the router belongs to in ndn URI format
router /%C1.Router/router1      ; name of the router in ndn URI format

; lsa-refresh-time is the time in seconds, after which router will refresh its LSAs

lsa-refresh-time 1800           ; default value 1800. Valid values 240-7200

; log-level is to set the levels of log for NLSR

log-level  DEBUG                ; default value INFO, valid value DEBUG, INFO
log-dir /tmp/ls/faces-2          ; path for log directory (Absolute path)
seq-dir /tmp/ls/faces-2          ; path for sequence directory (Absolute path)

}

; the neighbors section contains the configuration for router's neighbors and hello's behavior

neighbors
{
; in case hello interest timed out, router will try 'hello-retries' times at 'hello-time-out'
; seconds interval before giving up for any neighbors (deciding link is down)

hello-retries 3 ; interest retries number in integer. Default value 3
; valid values 1-10

hello-timeout 1 ; interest time out value in integer. Default value 1
; Valid values 1-15

hello-interval 60 ; interest sending interval in seconds. Default value 60
; valid values 30-90
; neighbor command is used to configure router's neighbor. Each neighbor will need
; one block of neighbor command

; ARIZONA has 5 neighbors: CAIDA, CSU, MEMPHIS, UCLA, WUSTL (showing only 2 for now)

; CAIDA
neighbor
{
name /ndn/caida/%C1.Router/router1 ; name prefix of the neighbor router consists
; of network, site-name and router-name

   face-uri  udp://caida                  ; face uri of the face connected to the neighbor
   link-cost 18                           ; cost of the connecting link to neighbor

}

; CSU
neighbor
{
name /ndn/csu/%C1.Router/router1 ; name prefix of the neighbor router consists
; of network, site-name and router-name

   face-uri  udp://csu                    ; face uri of the face connected to the neighbor
   link-cost 18                           ; cost of the connecting link to neighbor

}
}

; the hyperbolic section contains the configuration settings of enabling a router to calculate
; routing table using hyperbolic routing table calculation method

hyperbolic
{
; commands in this section follows a strict order
; the switch is used to set hyperbolic routing calculation in NLSR

state off              ; default value 'off', set value 'on' to enable hyperbolic routing table
                       ; calculation which turns link state routing 'off'. set value to 'dry-run"
                       ; to test hyperbolic routing and compare with link state routing.


radius   16.230539         ; radius of the router in hyperbolic coordinate system
angle    2.970333          ; angle of the router in hyperbolic coordinate system

}

; the fib section is used to configure fib entry's type to ndn FIB updated by NLSR

fib
{
; the max-faces-per-prefix is used to limit the number of faces for each name prefixes
; by NLSR in ndn FIB

max-faces-per-prefix 2   ; default value 0. Valid value 0-60. By default (value 0) NLSR adds
                         ; all available faces for each reachable name prefixes in NDN FIB

}

; the advertising section contains the configuration settings of the name prefixes
; hosted by this router

advertising
{
; the ndnname is used to advertised name from the router. To advertise each name prefix
; configure one block of ndnname configuration command for every name prefix.

prefix /ndn/arizona/name1           ; name in ndn URI format
prefix /ndn/arizona/name2

}

security
{
validator
{
rule
{
id "NSLR Hello Rule"
for data
filter
{
type name
regex ^[]*<><>$
}
checker
{
type customized
sig-type rsa-sha256
key-locator
{
type name
hyper-relation
{
k-regex ^[]*$
k-expand \1
h-relation equal
p-regex ^[]*<><>$
p-expand \1
}
}
}
}

 rule
 {
   id "NSLR LSA Rule"
   for data
   filter
   {
     type name
     regex ^[^<NLSR><LSA>]*<NLSR><LSA>
   }
   checker
   {
     type customized
     sig-type rsa-sha256
     key-locator
     {
       type name
       hyper-relation
       {
         k-regex ^([^<KEY><NLSR>]*)<NLSR><KEY><ksk-.*><ID-CERT>$
         k-expand \\1
         h-relation equal
         p-regex ^([^<NLSR><LSA>]*)<NLSR><LSA>(<>*)<><><>$
         p-expand \\1\\2
       }
     }
   }
 }

 rule
 {
   id "NSLR Hierarchy Exception Rule"
   for data
   filter
   {
     type name
      regex ^[^<KEY><%C1.Router>]*<%C1.Router>[^<KEY><NLSR>]*<KEY><ksk-.*><ID-CERT><>$
    }
    checker
    {
      type customized
      sig-type rsa-sha256
      key-locator
      {
        type name
        hyper-relation
        {
          k-regex ^([^<KEY><%C1.Operator>]*)<%C1.Operator>[^<KEY>]*<KEY><ksk-.*><ID-CERT>$
          k-expand \\1
          h-relation equal
          p-regex ^([^<KEY><%C1.Router>]*)<%C1.Router>[^<KEY>]*<KEY><ksk-.*><ID-CERT><>$
          p-expand \\1
        }
      }
    }
  }

  rule
  {
    id "NSLR Hierarchical Rule"
    for data
    filter
    {
      type name
      regex ^[^<KEY>]*<KEY><ksk-.*><ID-CERT><>$
    }
    checker
    {
      type hierarchical
      sig-type rsa-sha256
    }
}

trust-anchor
{
  type any
}

}
;cert-to-publish "router.cert" ; required, a file containing the router certificate.
}

I investigated the issue a bit more and it looks like the problem happens only for unresolvable host names. If there is a single unresolvable hostname in the conf the advertised names are not reaching to FIB of the neighboring nodes. About your setup the third node might have a resolvable host name, therefore it worked. Just to check this can you please try by setting one of the neighbors to unresolvable hostname, for e.g. udp://myneighbor (assuming my neighbor doesn't have any entry in host files)

One clarification, names in face-uri like csu and caida are hostnames, which are set by emulab. If I do ping to caida from arizona I can simply type:

oamin@arizona:/tmp/ls/faces-2$ ping caida
PING caida-lan0 (10.1.1.3) 56(84) bytes of data.
64 bytes from caida-lan0 (10.1.1.3): icmp_req=1 ttl=64 time=39.1 ms
64 bytes from caida-lan0 (10.1.1.3): icmp_req=2 ttl=64 time=38.1 ms
.
.
.

In conf file, caida is a resolvable hostname but csu is not (as there were only two nodes for testing, arizona and caida) and that seems to be a problem. If there is one unresolvable host name in the conf the nodes stops seeing each others advertised names.

I think I found the reason why this is happening for unreachable host name. Will try to push commit to fix this issue

So what was the problem? can you explain briefly?

The problem is: in case of unreachable link nlsr can not send INFO interest as face creation gets error from NFD. Adjacency LSA is not built until it hears from its neighbors or INFO interest is timed out for neighbors. In the above case NLSR does not send info interest. So NLSR get stuck in a state where it waits for building adjacency LSA.