|
|
The following review questions are based on the topology shown earlier in Figure 4.4.
1. | Will the following IS-IS configuration correctly configure interface fe-0/0/0 for IS-IS level 1 operation only? [edit protocols isis] lab@r5# show interface fe-0/0/0.0 { level 1 hello-interval 10; } interface all { level 2 disable; } | |
2. | The following configuration results in an IS-IS adjacency to r3 and r4, but no routes are installed and the LSDB contains no LSP from these routers. What is a likely cause for this symptom?
[edit protocols isis] lab@r5# show export summ; reference-bandwidth 500m; lsp-lifetime 3600; level 2 { authentication-key "$9$qP5FREy8X-"; # SECRET-DATA authentication-type simple; # SECRET-DATA } level 1 preference 155; interface fe-0/0/0.0 { level 2 disable; level 1 { hello-authentication-key "$9$H.fz1IcSeW"; # SECRET-DATA hello-authentication-type md5; # SECRET-DATA } } interface fe-0/0/1.0 { level 2 disable; level 1 { hello-authentication-key "$9$EORSlM2gJZjq"; # SECRET-DATA hello-authentication-type md5; # SECRET-DATA } } interface all { level 1 disable; level 2 { hello-authentication-key "$9$5znCyrvMX-"; # SECRET-DATA hello-authentication-type md5; # SECRET-DATA } } | |
3. | You have incorrectly specified the IP address for r5’s at-0/12/1.35 interface, as highlighted next. Will an IS-IS adjacency still be possible? [edit interfaces at-0/2/1] lab@r5# show atm-options { vpi 0 maximum-vcs 17; vpi 5 maximum-vcs 36; ilmi; } unit 35 { vci 5.35; shaping { cbr 50m; } oam-period 10; oam-liveness { up-count 2; down-count 2; } family inet { address 10.0.20.1/30; } family iso; } | |
4. | What is missing from the IS-IS configuration shown next?
[edit protocols isis] lab@r5# show export summ; reference-bandwidth 500m; lsp-lifetime 3600; level 2 { authentication-key "$9$jEkmTOBEhrv"; # SECRET-DATA authentication-type simple; # SECRET-DATA } level 1 preference 155; interface fe-0/0/0.0 { level 2 disable; level 1 { hello-authentication-key "$9$H.fz1IcSeW"; # SECRET-DATA hello-authentication-type md5; # SECRET-DATA } } interface fe-0/0/1.0 { level 2 disable; level 1 { hello-authentication-key "$9$EORSlM2gJZjq"; # SECRET-DATA hello-authentication-type md5; # SECRET-DATA } } interface at-0/2/1.35 { level 1 disable; level 2 { hello-authentication-key "$9$WcqXNbiHmPQn"; # SECRET-DATA hello-authentication-type md5; # SECRET-DATA } } interface as1.0 { level 2 { hello-authentication-key "$9$d7w2a5T3nCu"; # SECRET-DATA hello-authentication-type md5; # SECRET-DATA } level 1 disable; } | |
5. | Your goal is to advertise a 10.0.4/22 summary to level 2 areas only. Will the following policy achieve this requirement? [edit] lab@r3# show policy-options policy-statement summ { term 1 { from { route-filter 10.0.4.0/22 longer; } to level 2; then reject; } term 2 { from { protocol aggregate; route-filter 10.0.4.0/22 exact; } then accept; } } | |
6. | You have decided to save some time by using a configuration group intended to configure the iso family on your router’s interface with less typing. What could go wrong, based on the following configuration? [edit] lab@r2# show groups interfaces { <*> { unit <*> { family iso; } } } } [edit] lab@r2# show interfaces apply-groups apply-groups iso; [edit] lab@r2# show protocols isis export direct; reference-bandwidth 500m; lsp-lifetime 3600; level 1 wide-metrics-only; interface all { hello-authentication-key "$9$TF6ArlMWxd"; # SECRET-DATA hello-authentication-type md5; # SECRET-DATA level 2 disable; } | |
Answers
1. | No, this configuration will result in level 1 and level 2 operation on the fe-0/0/0 interface. The specific mention of interface fe-0/0/0 exempts it from the interface all level 2 disable statement. You will need to specifically disable level 2 operation on this interface. |
2. | The most likely cause is mismatched LSP authentication as configured under the level 2 stanza. Hello authentication must be properly configured for the adjacency to form. To test if this is the cause, you could delete backbone area authentication-related entries, perform protocol tracing, or configure the no-authentication-check option. |
3. | Depending on the JUNOS software version, the answer will be yes or no. The 5.2.x JUNOS software used in this test bed will permit the IS-IS adjacency to form. Unlike OSPF, the IS-IS protocol does not understand IP addressing, and can therefore allow an IS-IS adjacency when IP subnet parameters have been mismatched. This aspect of IS-IS is well worth noting, because troubleshooting issues that relate to simple IP addressing mistakes are made more difficult when the operator believes that the presence of an IS-IS adjacency provides vindication of the interface’s IP properties. |
4. | The lack of an interface all term, and specific mention of the router’s lo0 interface, means that the router will have no ISO NET (assuming you have correctly assigned the NET to the router’s lo0 interface). The IS-IS protocol will not function without a NET. In this case, protocol tracing will report errors as shown next:
May 29 04:42:41 task_receive_packet: task IS-IS I/O from index 5 addr 0.a0.c9.69.c5.27 socket 11 length 62 May 29 04:42:41 ERROR: received IIH but have no local sysid . |
5. | No. The lack of a to level 2 clause in term 2 will result in the summary route being advertised into all IS-IS levels. |
6. | Your configuration group’s wild-card syntax will match on all router interfaces and logical units, which includes the router’s fxp0 interface. The use of interface all in the IS-IS stanza will in turn enable IS-IS operation on all such ISO-capable interfaces. This can lead to the formation of IS-IS adjacencies over the OoB network, which has the potential of catastrophic disruption considering the black holes that will occur when a router forwards packets destined for a remote router over an fxp0 adjacency. To alleviate this problem, you could rewrite the wild-card expression to be more selective or you could specifically disable the router’s fxp0 interface under the IS-IS stanza. Both approaches are demonstrated next in the context of r2’s case study configuration. The first example has the wild-card expression carefully written such that it will match only on the correct router interfaces (fe-0/0/1 through fe-0/0/3): [edit groups iso] lab@r2# show iso { interfaces { "<fe-[1-3]>" { unit <*> { family iso; } } } } |
The second approach compensates for the use of a sloppy wild-card expression (<*>) by explicitly disabling interfaces that should not run IS-IS:
[edit] lab@r2# show protocols isis { export direct; reference-bandwidth 500m; lsp-lifetime 3600; level 1 wide-metrics-only; interface fe-0/0/0.0 { disable; } interface all { hello-authentication-key "$9$TF6ArlMWxd"; # SECRET-DATA hello-authentication-type md5; # SECRET-DATA level 2 disable; } interface fxp0.0 { disable; } }
|
|