Spot the Issues: Review Questions

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; }

no, this configuration will result in level 1 and level 2 operation on the fe-0/0/0 interface. thespecific 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 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     } }

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 thecause, you could delete backbone area authentication-related entries, perform protocol tracing,or configure the no-authentication-check option.

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; }

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 protocoldoes not understand ip addressing, and can therefore allow an is-is adjacency when ip subnetparameters 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 theoperator believes that the presence of an is-is adjacency provides vindication of the interface sip properties.

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; }

the lack of an interface all term, and specific mention of the router s lo0 interface, meansthat the router will have no iso net (assuming you have correctly assigned the net to therouter s lo0 interface). the is-is protocol will not function without a net. in this case, protocoltracing will report errors as shown next: may 29 04:42:41 task_receive_packet: task is-is i/o from index 5 addr0.a0.c9.69.c5.27 socket 11 length 62 may 29 04:42:41 error: received iih but have no local sysid .

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;      } } 

no. the lack of a to level 2 clause in term 2 will result in the summary route being advertisedinto all is-is levels.

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; }

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 inturn enable is-is operation on all such iso-capable interfaces. this can lead to the formation ofis-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 remoterouter 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 theis-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 matchonly 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; } }}}

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;      } }




JNCIP. Juniper Networks Certified Internet Professional Study Guide Exam CERT-JNCIP-M
JNCIP: Juniper Networks Certified Internet Professional Study Guide
ISBN: 0782140734
EAN: 2147483647
Year: 2003
Pages: 132

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net