ASR Pseudowire to remote physical interface vs loopback?

[malcolmsalmons]

Hi

We currently run a number or pseudo wires over our MPLS network with the targets for the pwire being the loopback of the remote router. This means that our pwires re-route in the event of a primary link failure as long as there is an alternative path to the remote routers loopback.

However, we now have a requirement where we don't want the pwire to reroute if the primary link fails. Therefore, I changed the neighbor address of a test pwire to be the remote end of the primary physical link as opposed to the loopback. However when I did this the pwire would not come up. The config is as shown:

ASR 9901 - PWIRE connectivity

mpls ldp
graceful-restart
router-id 1.1.1.1

l2vpn
xconnect group EOMPLS
p2p ptp_5000
interface GigabitEthernet0/0/0/1
neighbor ipv4 2.2.2.2 pw-id 5000

2.2.2.2 = peer router-id (loopback)

Point-to-point link = 10.0.0.0/30

Local p2p = 10.0.0.1
Remote p2p = 10.0.0.2

Convert the p2p to target the physical address from 2.2.2.2

p2p ptp_5000
interface GigabitEthernet0/0/0/1
neighbor ipv4 10.0.0.2 pw-id 5000

At this point the pwire is down and wont come up. If I revert it to the loopback then it comes up.

I couldn't see a command under the p2p to specify a source interface or similar. Therefore, I'm wondering if this is related to setting the router-id under the mpls config, i.e. does it only allow pwires to be built to the mpls router-id?

Any thoughts appreciated.

Thanks

Malc

[filopeter]

As far as I know the remote router ID must be the LDP router ID of the peer for a successful LDP session. To get rid of this LDP restriction, consider using Static Pseudowire Provisioning.
According the following document

https://www.cisco.com/c/en/us/td/docs/ios/12_2sr/12_2srb/feature/guide/srstatpw.html

the remote router ID can be any IP address, as long as it is reachable.

Best Regards, 

P.

[Harold Ritter]

Hi @malcolmsalmons ,

There are many reasons why it is not a good idea to establish any MPLS services using physical interfaces rather than a loopback interface. One of them is that it will break the end to end LSP between the 2 nodes.

There is another way you can achieve your requirement. You can setup an MPLS traffic engineering tunnel through the physical interface and use that tunnel in the l2vpn xconnect pw-class as follow:

l2vpn

pw-class to-other-pe

encapsulation mpls

preffered-path interface tunnel-te <x> fallback disable

This will cause the pseudowire to go down if the mpls traffic engineering tunnel going through the physical interface goes down.  

[Albertt]

Dear @malcolmsalmons ,

For your requirement, and your situation, I recommend you use Traffic Engineering with an Explicit Path, so the PW is forced to stay on the primary link and does not reroute. Just make sure RSVP is enabled across the core.

I also tested static labels, but the PW got stuck in ios xr, with ios or xe it worked for me in real practise.

If TE is too heavy for your setup, you also have two easier alternatives:

- L2TPv3 VPWS (no RSVP, no MPLS needed) - Easiest way

- SR-TE with preferred-path, if supported by your platform.

If you need sample configs, let me know.

Best Regards,

Albert.

[malcolmsalmons]

Hi

Thanks for the responses.

So as the network is currently deployed with MPLS it seems like RSVP-TE is worth exploring.

As a bit of background on the pseudowire I don't want to failover is on two directly connected PEs. Therefore, if I wanted to set up RSVP-TE would I need to deploy RSVP across the entire network or just for these two nodes so that I can use the LSP between them?

Additionally, does this have any impact upon other pwires that I do want to re-route or is it only the xconnect with the pw-class applied to it that would not re-route?

Thanks

Malc

[Harold Ritter]

Hi @malcolmsalmons ,

> Therefore, if I wanted to set up RSVP-TE would I need to deploy RSVP across the entire network or just for these two nodes so that > I can use the LSP between them?

Just deploying MPLS TE between the two directly connected nodes is sufficient.

> Additionally, does this have any impact upon other pwires that I do want to re-route or is it only the xconnect with the pw-class       > applied to it that would not re-route?

That does not have any impact on the other pseudo wires, just those with the pw-class.