Not sure of the design goals here, but these might be some potentially useful features.
If you need to influence the physical topology that TE considers when building tunnels without changing IGP metrics, set "mpls traffic-eng administrative-weight X" on the radio link. Auto-tunnel mesh group simplifies building all required PE-PE tunnels. If your loopbacks fall under some sensible addressing scheme, adding PE's in future won't require you to go back and touch every other PE. Possibly combine this with auto-tunnel backup, for FRR NNHOP protection and you should be away. Again, no need for any explicit paths, as protection will be provisioned automatically for each primary LSP. As the network changes, the backup LSP's will build around the primaries. Richard -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Shore Sent: 06 August 2007 22:43 To: 'Cisco-nsp' Subject: [c-nsp] TE design guidance I'm trying to come up with the best way to layout TE tunnels between a couple POPs. On one side I have a pair of 7600s with 3BXLs running SRB1; we'll call this A and B. On the other side I have a pair of ME6524s; we'll call these C and D. Each pair of routers serves are the core in their respective POP, with the edge devices dual-homing to each core router. The first router in each POP is connected via GigE over about 80 miles of fiber through numerous towns using media converters. The second router in each POP is connected in a similar fashion over another strand in the same fiber bundle. A 3rd connection is being made with radios and will terminate in the first router in each POP. At some point in the future the second fiber path will be broken in the middle to drop off services in that town. I anticipate either a 7201 or another 7600 depending on bandwidth needs vs costs; we'll call this future router E. My short term needs mainly involve FRR. However as our backbone bandwidth needs grow we'll likely need the full set of TE features in the not-too-distant long-term. Unfortunately we do not have 2 diverse fiber paths to work with at this point in time. My initial thought was that I should build tunnels for A-C, B-D, A-B-D-C, and B-A-C-D. However the radios complicate that design in my eyes. How do I indicate that the radio path is more costly than the fiber path for as far as MPLS TE is concerned? Do I need an explicit path defined for each possible combination of paths? Am I simply not looking at this in the right light? Thanks Justin _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ This email and any attachments may be confidential and/or legally privileged. If you have received this e-mail and you are not a named addressee, please inform the sender of this email by sending a return email to the address above and then delete the e-mail and your response from your system. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail. Any views or opinions presented are solely those of the author. Any statements made, or intentions expressed in this communication may not necessarily reflect the view of Easynet. No content herein will bind Easynet or any associated company unless confirmed by the execution of a formal contract by Easynet. Any figures or amounts given in this email are quotations only and are subject to change. Although Easynet routinely screens for viruses, addressees should scan this e-mail and any attachments for viruses. Easynet makes no representation or warranty as to the absence of virus! es in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our customers and business, we may monitor and read e-mails sent to and from our server(s). Easynet Limited a company incorporated and existing under the laws of England and Wales, with company number 2954343 and having its registered office at 44-46 Whitfield Street London, W1T 2RJ. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
