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.

[malcolmsalmons]

Hi Harold

Thanks for your help. So if I wanted to get this working from what you've added and from what I've read I think I'd need to add the following:

1) Enable TE and set TE router-id

router isis
address-family ipv4 unicast
mpls traffic-eng level-2
mpls traffic-eng router-id Loopback0

2) Enable RSVP and MPLS‑TE on the links that will carry the TE tunnel:

- RSVP (configure per core interface (so the P2P to the other router in this case))
rsvp
interface ten0/0/0/1
!bandwidth [optional sub-pool/global settings] - Do I need to add this?

- MPLS‑TE (enable TE on those interfaces)
mpls traffic-eng
interface ten0/0/0/1

3) Create the explicit-path

explicit-path name PRIMARY_PATH
index 10 next-address strict ipv4 unicast 10.0.0.1
index 20 next-address strict ipv4 unicast 10.0.0.2

4) Create TE tunnel (headend to remote loopback)

interface tunnel-te 100
ipv4 unnumbered Loopback0
destination 2.2.2.2
path-option 1 explicit name PRIMARY_PATH
autoroute announce

5) Create and pin the PW to the tunnel and disable fallback

l2vpn
pw-class PREFERRED_TE
encapsulation mpls
protocol ldp
preferred-path interface tunnel-te 100 fallback disable
!
xconnect group EOMPLS
p2p ptp_5000
interface GigabitEthernet0/0/0/1
neighbor ipv4 pw-id 5000
pw-class PREFERRED_TE

Hopefully this would create the tunnel (LSP) from A to B and then I'd need to go to B and reverse this. 

Thanks

Malc

[Harold Ritter]

Hi @malcolmsalmons ,

1) this part of the config looks good.

2) This part of the configuration looks good. You do not need to set the bandwidth for RSVP.

3) Why is there two next-address in the explicit path if the neighbor is directly connected? 

4) you do not need to configure "autoroute announce". You could use "path-option 1 dynamic" as there should be only one path to destination.

5) You are missing the neighbor address for the xconnect:

p2p ptp_5000
neighbor ipv4 x.x.x.x pw-id 5000
pw-class PREFERRED_TE

> Hopefully this would create the tunnel (LSP) from A to B and then I'd need to go to B and reverse this. 

Correct.

[malcolmsalmons]

Hi

Ah, for section 3 I'd just need a single entry for next hop? I wasn't sure if I needed to add the outgoing address and the next one. So assuming its just for next hops IP?

For point 4 is that a case of either config will work but "path-option 1 dynamic" is a better option?

Good spot on 5!

Thanks

[Harold Ritter]

Hi @malcolmsalmons ,

> So assuming its just for next hops IP?

That is correct.

> For point 4 is that a case of either config will work but "path-option 1 dynamic" is a better option?

The dynamic is easier to configure, but explicit is safer if you have redundant path that could be used if the direct link goes down.