Hi Akhmedd, On Dec 24, 2010, at 4:58 AM, Akhmedd Aly wrote: > is it mistake about IS-IS default policy - that IS-IS rejected by default > learned routes from direct protocol? > Check this link > http://img843.imageshack.us/img843/3264/isisdefaultpolicy.png > > I think its must be accepted, and also in the next term we have the same > reject action...
This image seems to be taken from page 6-20 of the Juniper Networks Educations Services Advanced Policy course. A few notes about this slide: - There is an error, and the slide would be more correct if the action for the "accept-local-subnets" term was "then accept", rather than "then reject". It seems the student that posted this image was correctly informed of this error in the slide by his/her instructor because you will note that they have underlined the "reject" and written "accept" next to it. - The implicit default policies for each protocol can not necessarily be easily documented using the policy configuration syntax, and this is especially true for the default IS-IS export policy. So, the policy on this slide is not the actual policy. - This slide is trying to illustrate a difference between the default OSPF and IS-IS export policies. This difference is further documented in the "Default Export Policy for IS-IS" paragraph in the notes at the bottom of the page. Let me try to explain the difference: - In both IS-IS and OSPF, the subnets for directly connected interfaces that are running the IGP, those that are part of an 'interface' statement under [edit protocols ospf] or [edit protocols isis], are advertised in LSAs/LSPs. Note that 'passive' interfaces are also included in this. - In both IS-IS and OSPF, the subnets for directly connected intefaces that are not running the IGP, not configured under [edit protocols ospf] or [edit protocols isis], are NOT advertised in LSAs/LSPs, and are NOT advertised as 'external' routes in the IGP. In both IS-IS and OSPF, these directly routes can be advertised as 'external' routes by matching them in policy. - The difference is for the subnets for directly connected interfaces that are running the IGP. In OSPF, there is no way to write a policy to block these subnets from being advertised in the LSAs. In IS-IS, however, you can create an export policy that DOES block these subnets from being advertised in LSPs. > 2009/12/4 Akhmedd Aly <akhmed....@gmail.com> > >> Hi, >> >> can someone explain this difference between this 1-12 steps order in case >> of internal/external metric >> >> Each IS-IS router translates the information in the database into usable >> routes by implementing the >> Shortest Path First (SPF) algorithm. This computation is performed >> separately within each IS-IS >> level, and the results are compiled together and presented to the routing >> table on the router. The >> algorithm locates the metrically shortest path to each unique destination >> in the network. On occasion, >> the result of the calculation encounters multiple paths to the same >> destination learned through >> different means. To decide which path to use, the protocol has some >> tie-breaking rules to follow. The >> order of precedence for using a route is: >> 1. Level 1 intra-area routes with an internal metric >> 2. Level 1 external routes with an internal metric >> 3. Level 2 intra-area routes with an internal metric >> 4. Level 2 external routes with an internal metric >> 5. Inter-area routes (Level 1 to Level 2) with an internal metric >> 6. Inter-area external routes (Level 1 to Level 2) with an internal metric >> 7. Inter-area routes (Level 2 to Level 1) with an internal metric >> 8. Inter-area external routes (Level 2 to Level 1) with an internal metric >> 9. Level 1 external routes with an external metric >> 10. Level 2 external routes with an external metric >> 11. Inter-area external routes (Level 1 to Level 2) with an external metric >> 12. Inter-area external routes (Level 2 to Level 1) with an external metric >> >> >> Is it just meaning that ISIS protocol has two different preferences for >> each level: >> IS-IS Level 1 Internal Intermediate System to Intermediate System Level 1 >> internal routes 15 >> IS-IS Level 2 Internal Intermediate System to Intermediate System Level 2 >> internal routes 18 >> IS-IS Level 1 External Intermediate System to Intermediate System Level 1 >> external routes 160 >> IS-IS Level 2 External Intermediate System to Intermediate System Level 2 >> external routes 165 These tie breaking rules are not the same as the preference values. The tie breaking rules come into play when the SPF algorithm is being run. Remember, the SPF algorithm is run for each Level that the router is in. During the SPF, if there are two IS-IS learned routes to the same destination, these rules are followed to see which route(s) will be selected and installed in the routing table. Depending on the type of IS-IS route(s) selected by the SPF algorithm, the routes are installed into the routing table using the preference values you mention. If the same prefix was also learned from some other source, the preferences values are then used to choose the which route will become the active route in the routing table. Yes, the routing table preferences mimic the SPF tie breaking rules, but they are really two separate things. Also, note that only the "old-style" TLVs make a distinction between internal/external reachability and internal/external metrics. Those "old-style" TLVs are: IS reachbility (TLV 2), IP internal reachability (TLV 128), and IP external reachability (TLV 130). The "new-style" or "wide-metric" TLVs treat everything as internal reachability and internal metric. The "new-style" TLVs are: Extended IS reachability (TLV 22) and Extended IP reachability (TLV135). --Stacy _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
