[j-nsp] ISIS general questions

[masood at nexlinx.net.pk]

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 I’m 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-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Net MailingList
Sent: Tuesday, May 19, 2009 12:33 PM
To: juniper-nsp at 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 at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp