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:
- The tests against each of the attributes works, individually and jointly.
- 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:
- route generated form static, not imported, export allowed
- reconfig with static, import, and no export
- reconfig with static, import, and export
Route Passage
The test sequence needs to see what happens on other nodes if
- route not imported
- reconfig with route imported but not exported
- 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
- Test 1 - External peers, no route passage (restrict)
- Test 2 - External peers, all route passed (all)
- Test 3 - External peers, some route passed (nlri & all)
- Test 4 - External peers, selected route passed (nlri & all restrict)
External Peer Tests repeated with Rib Refresh
- Test 5 - (Test 1 with rib refresh)
- Test 6 - (Test 2 with rib refresh)
- Test 7 - (Test 3 with rib refresh)
- Test 8 - (Test 4 with rib refresh)
Internal Peer Tests with Delta routes
- Test 9 - Internal peers and no route passage
- Test 10 - Internal peers and all route passed
- Test 11 - Internal peers & some routes pass (nlri passed, all restricted )
- Test 12 - Internal peers and some selected route passed (nlri restricted)
Internal Peer Tests with Rib Refresh
- Test 13 - (Test 9 with rib refresh)
- Test 14 - (Test 10 with rib refresh)
- Test 15 - (Test 11 with rib refresh)
- Test 16 - (Test 12 with rib refresh)
Group 2
Basic RDI tests with gated preference set on import lines
Repeat tests 1-12 with
- gated-pref set on the import clause
- idrp_pref set on the import clause
- 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
- None of values-n for "gated-pref" should be equal to the default gated preference.
- None of the idrp-values-n "idrp-pref" values should be equal to the IDRP defaults.
- NO NLRI-specific preferences should be equal to any preferences set at the opening of the import stanza;
- not all NLRI should have a specific preference;
- import stanzas should be set up to allow at least one default value to be generated by a valid import() call.
- Vary the values in a manageable way.
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
- NONE of the "gated-pref" or "idrp-pref" values should be equal to the defaults;
- NO NLRI-specific preferences should be equal to any preferences set at the opening of the import stanza;
- not all NLRI should have a specific preference;
- import stanzas should be set up to allow at least one default value to be generated by a valid import() call.
- Vary the values in a manageable way.
Expected Results
Routing tables will be the same as in the original test; preferences should work in
this manner:
- all imported NLRI which have the given preference set on the NLRI line should have
the value shown on that line in the config file;
- all imported NLRI which have no specific preference set on the NLRI line should have
the value shown for the import stanza, if there is one;
- any imported NLRI which don't have a specific preference set on the NLRI line *and* which
are in an import stanza which has no specific preferences set should have the default
preferences.
Group 4"
Basic RDI (ADVFT_RDI) Multi-machine tests
- The tests under specified above can be repeated with following topological variants
listed in the Basic Testing " document.
- The tests for preference can be interesting in that a single machine can now receive the same
NLRI from various other machines and, based on policy, select one machine over another (e.g.,
internal peer over external, etc.).
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.
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.
- Allow via one 1 path, deny others
- Allow via one 2 paths, deny others
- Allow via one 3 paths, deny others
- Prefer 1 path over others (allow all)
- 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
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.
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;
}
}