Import Tests for IDRP in GateD


Sytnax and import processing

These test test the syntax and processing of routes via the import command.

Theory for these tests

Import testing is based upon these aspects:
  1. The tests against each of the attributes works, individually and jointly.
  2. The import() call returns the proper gated and IDRP preferences.

Physical Layouts

Layouts" for systems include connections between 2-6 systems.

Local Route Generation

The local route generation has three variables: generate from static, import, export.


Each has a place to filter. What happens if the route: 
  1. route generated form static, not imported, export allowed
  2. reconfig with static, import, and no export
  3. reconfig with static, import, and export

Route Passage


The test sequence needs to see what happens on other nodes if
  1. route not imported
  2. reconfig with route imported but not exported
  3. reconfig with route imported

Assumptions for Tests

All tests assume that routing tables are clean upon startup.

Import filter Tests - Top Level Match Conditions

Group 1 Basic RDI (ADVFT_RDI) 2 machine tests

The "top-level" match conditions (no ADVFT_PS tests; in the parser, this means that "idrp_import_optional_info" is empty):

External Peer Tests with Delta routes

External Peer Tests repeated with Rib Refresh

Internal Peer Tests with Delta routes

Internal Peer Tests with Rib Refresh

Group 2 Basic RDI tests with gated preference set on import lines

Repeat tests 1-12 with

  1. gated-pref set on the import clause
  2. idrp_pref set on the import clause
  3. gated-pref & idrp-pref set on import clause

(Example of configuration line are listed below.)



    import proto idrp rdi rdi-of-B  gated-pref value1 
	 { 
	    ...
	    };



    import proto idrp rdi rdi-of-A idrp-pref value3 gated-pref value2 
 	{
	    ...
	};

Expected Results

Routing tables as for original tests. Gated and/or IDRP preferences for *all* imported routes will be set as specified in the import stanza.

Basic RDI tests with gated preference set on NLRI lines

Repeat tests 1-16 with gated-pref and/or idrp-pref set on the NLRI lines:

    Machine A/B

    import proto idrp rdi rdi-of-B  {
		       ... ; ... 
		        gated-pref  value-i ;
		        gated-pref  value-j  idrp-pref  value-k  ;
		        idrp-pref  value-m ;
		    ...
		    };


Where 

Expected Results

Routing tables will be the same as in the original tests. Unlike Test Group 1, only the NLRI with the specific preference(s) set will have preferences which differ from the defaults.

Group 3" Basic RDI tests with gated preference set on NLRI lines


Repeat tests 3 thru 10  with both global import preferences in Test Group 2, 
and some per-NLRI preferences.  The global import preferences can either be  idrp-pref  or  
 gated-pref  on the  import  stanza.  The NLRI preferences 
are  idrp-pref  or  gated-pref  on the  nlri  lines. 
(Example of configuration line are listed below.)

    Machine A:

    import proto idrp rdi rdi-of-B gated-pref  value-1 idrp-pref  idrp-value1  {
		       ... ; ... 
		        gated-pref  value-i ;
		        gated-pref  value-j  idrp-pref  value-k  ;
		        idrp-pref  value-m ;
		    ...
		    };


Where 
Expected Results

Routing tables will be the same as in the original test; preferences should work in
this manner:


Group 4" Basic RDI (ADVFT_RDI) Multi-machine tests




RD_PATH" (ADVFT_RDPATH)


The RD_PATH tests need to test the setting of preference based on a RDPATH. Routes need
to be imported based on their RDPATH setting. 

RD_PATH 2 machine tests "


The 2-machine RD_PATH test include:

  • two internal peers - filters on the RD_PATH for another routing domain
  • two external peers - allowing both RD_PATH
  • two external peers - 1st RD allowing the RD_PATH in, 2nd RD deny
  • two external peers - 1 RD allowing RD_PATH switching to deny it
  • two external peers - 1st RD allow to Deny, 2nd RD Deny to Allow
    
    

    RD_PATH (ADVFT_RDPATH) multiple node tests

    
     3 Node tests 
    
    
    Try in all layouts of the 3 node. 
    

    1. Allow via one 1 path, deny others
    2. Allow via one 2 paths, deny others
    3. Allow via one 3 paths, deny others
    4. Prefer 1 path over others (allow all)
    5. Prefer 1 path over others, allow only some
    
     4 Node tests 
    
    
    Try in all layouts of the 4 node the same tests as in the 3 node tests 
    

    
    

    idrp-ps-policy-att"

     Extended match conditions (ADVFT_PS) Tests  
    
    
    The extended match condition tests are invoked by the idrp-ps-policy-att clauses in the import statement.
    
    import proto idrp rdi 0x490137 local-net 0x47000580ffff000000040000000000c66c3c5900
            idrp-ps-policy-atts
            {
    	 idrp pathway policy filter statements 
    	 }
    };
    import proto idrp rdi 0x490137 local-interface 192.48.60.1 
            idrp-ps-policy-atts
            {
    	 idrp pathway policy filter statements 
    	 }
    
    
    The extended match tests will involve testing each of the clauses below to see that static, or
    route imported from idrp can be imported or rejected based on the policy.
    

    idrp-ps-att"

    
    This clause modifies the idrp path attribute received to another
    attribute for export.  This is a  MERIT  function.  
    This cluause is defined for general use  on export. 
    

    Import example
    
    
    	import proto idrp rdi 0x490130   
    	idrp-ps-att
    	{
    	(policy-statments)
    	}
    
    
    Example on export 
    
    
    	export  proto idrp rdi 0x490130   
    	idrp-ps-att
    	{
    	(policy-statments)
    	}
    	{
    	proto idrp rdi 0x490129;
    		{
    		all;
    		}
    	}