1. To protect your layer 2 ISIS adjacencies network from a configuration mistake and against malicious or accidental insertion of IS-IS routes into the ISIS database, You can use MD5 authentication on all ISIS enabled interfaces.
2. I don't think you need to have FCS enabled on ISIS interfaces, the default for STM/Ethernet would serve the purpose. But Im not sure someone might answer this. 3. Since the number of routers that will participate in the routing =30 and the number of routes are relatively small, there is no major benefit to creating Level 1 and Level 2 ISIS areas. A flat level 2 area would serve the purpose. Yea carrying loopback interfaces along with physical links addresses over ISIS is fine (some people just carrying loopback interfaces over IGP) and using IBGP is nice for customer routes or physical links. Cool.... 4. Yea correct, LDP synchronization add the maximum cost metric until LDP is operational on the link. Further LDP synchronization is supported only on point-to-point interfaces, In your case you can configure LAN interfaces as point-to-point under the IGP. 5. If you can configure bfd-liveness-detection under [ protocol isis interface] It's only the ISIS adjacency that is torne down. BFD becomes complex when you use this along with GRES, it can be harmful too, since a GRES event without BFD enabled would not otherwise cause the router to be removed from the routing topology and associated routing updates to be generated. Regards, Masood Blog: http://weblogs.com.pk/jahil/ -----Original Message----- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Net MailingList Sent: Tuesday, May 19, 2009 12:33 PM To: juniper-nsp@puck.nether.net Subject: [j-nsp] ISIS general questions Hi, I would like to ask some generic questions about ISIS configuration. 1. Is ISIS authentication part of good current practices in large backbone? 2. In the case of an Ethernet and STM backbone, that already has Frame Check Sequence functionality, is it still necessary to enable checksum for IS-IS packet? Is this option used only in case the L2 protocol does not provide any FCS? 3. Let's imagine a network of 30 routers, 100 IS-IS routes within 20 PoPs. Only the loopbacks, point-to-point links and backbone LAN will be advertised within ISIS. All the rest (Internet routes, Data centers'LAN, customers' pool of addresses, customers LAN and connections from PE to CE) will be advertised by iBGP with route-reflectors. My intention is to have a big flat network, within a single area where all the IS-IS enable interfaces will be Level2 only. Whould you see any practical issue in this design? 4. About LDP/ISIS synchronisation: Scenario1: we don't configure "ldp-synchronization {enable;}", my understanding is that: - 1. ISIS converges - 2. Some IP traffic can routed on the backbone (excluding MPLS VPN and Internet routes for example) - 3. LDP converges, LSP are established - 4. All Taffic is tagged switched Scenario2: we do configure "ldp-synchronization {enable;}", my understanding is that: - 1. ISIS converges - 2. No IP Traffic can be routed on the backbone as the links are advertised with the maximum metric - 3. LDP converges, LSP are established - 4. All Taffic is tagged switched Are those scenarii correct? 5. Concerning BFD (bidirectional forwarding detection), when Hellos are not received anymore, is the interface status declared down? Or is it only the ISIS adjacency that is torne down? What if the Hellos are blocked only in one direction? 6. Given that our backbone is build over Metro-Ethernet and STM, can I safely assume that the MTU can only be is symetrical? If not (why?) it becomes necessary to configure some padding (strict maybe) Thank you very much in advance for your time. Christophe _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp