I was wondering if anyone is out there with experience supporting a BGP based layer 2 VPLS\VPN environment using RSVP to signal pseudo-wire access. Below is an outline of the general P\PE core configuration.
· The core network comprised of P\PE LSR’s · BGP based RSVP based l2vpn signaling is fully meshed between all P\PE core nodes · IGP is ISIS with wide-metrics and traffic engineering enabled · Named CSPF based mesh of LSPs exist between all P\PE core nodes Goal is to deploy label switch routers specifically functioning only as PE (distribution) nodes with direct connectivity to the P\PE (core) nodes and avoid the configuration required for a full mesh of LSP’s and l2vpn signaling between the P\PE core nodes and the PE distribution nodes. Below is an outline of requirements. · Leave current P\PE LSR RSVP l2vpn signaling and LSP full mesh configuration intact · PE (distribution) node will utilize BGP\l2vpn route reflector architecture with P\PE routers act as BGP l2vpn signal route reflectors · IGP configured as ISIS with wide-metrics and traffic engineering enabled · Configure named LSP’s between the directly attached P\PE and PE LSR’s · Avoid enabling RSVP auto-mesh feature I am noticing the pseudo-wire is attempting to establish a session across a routed link (with RSVP and MPLS enabled) without a defined LSP path causing any pseudo-wires using that path to go down. The pseudo-wire re-establishes its connection when the IGP metric is modified and reroutes traffic or when then named LSP is created between the two PE nodes. Although this appears to be an issue regarding order of operations when deploying a new node(d) in this configuration, is there a mechanism in place to restrict pseudo-wires from trying to establish connections across a path without an established LSP path across the connection? Regards, Peter Kalogerakos _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
