EoMPLS Testing

[Jon Berres]

Hello,

I am wondering if anyone is familar with a method for testing an EoMPLS L2VPN circuit built to a new router with no customer interfaces up yet.

For example if I have a PE ASR901 router and I build a L2VPN circuit to an interface that is not up/up yet the circuit will remain down until that segment is up. But if I want to test the circuit ahead of time before the customer connects that I would need someone to travel out to the remote ASR901 and plug a testset into the interface to activate the interface and loop any traffic back.

Is there a way to remotely enable an interface or build an EoMPLS circuit to a router that would simply loop the traffic back. In this test scenario I have an ethernet testset plugged into the aggregation router (ASR9010) which is the near side AC for the circuit.

[testset] -> [asr9010] -> ((mpls path)) -> [PE - asr901]

## ASR9010 ##

l2vpn

bridge group Test

!

  bridge-domain eompls-Test

   interface GigabitEthernet0/4/0/38.1018

   !

   neighbor 10.43.95.25 pw-id 10439525

    pw-class mpls_csr

   !

  !

## ASR901##

sho mpls l2trans vc det

interface GigabitEthernet0/0
description  EoMPLS Test
no negotiation auto
service instance 1018 ethernet
  encapsulation untagged
  xconnect 10.43.52.1 10439525 encapsulation mpls pw-class mpls_csr

asr901#sho mpls l2trans vc det
Local interface: Gi0/0 down, line protocol down, Ethernet:1018 down
  Destination address: 10.43.52.1, VC ID: 10439525, VC status: down
    Output interface: none, imposed label stack {}
    Preferred path: not configured 
    Default path: no route
    No adjacency
  Create time: 02:16:58, last status change time: 02:16:45
  Signaling protocol: LDP, peer 10.43.52.1:0 up
    Targeted Hello: 10.43.95.25(LDP Id) -> 10.43.52.1, LDP is UP

Any help is appreciated.

Thanks

Jon

[Vinit Jain]

Hello Jon

you will need to have something connected to that interface to bring that interface in up/up state. unless the state of the interface is up/up, its not possible to bring the pseudowire up.

Regards

Vinit

[Jon Berres]

Thank you for the reply Vinit.

I am looking into testing a type of EtherNID which can be plugged into a customer facing port and then 'looped up' by an Ethernet testset. I think this will provide a means to test an EoMPLS circuit for a customer before they actually plug their equipment into it.

I was looking for a built in Cisco function that could do something similar to the EtherNID.

b/r

Jon

[a-gould]

About what Dean suggested, looping a port on an ASR9000, I never saw this before that i can recall on the ASR901, but I just now saw this... I haven't tested it yet.  Actually, we are using ASR901's less and less.... we have been opt'ing more for the Accedian MetroNID cell backhaul device.

lab-2-901(config-if)#do sh ver | in IOS
Cisco IOS Software, 901 Software (ASR901-UNIVERSALK9-M), Version 15.4(3)S3, RELEASE SOFTWARE (fc1)
lab-2-901(config-if)#int g0/5
lab-2-901(config-if)#loop
lab-2-901(config-if)#loopback ?
  driver  Loopback at the transceiver level
  mac     Loopback at the MAC controller level

[a-gould]

Vinit/Jon, have you figured out how to do this yet?  If not, it seems that you could create an SVI interface within the 901 and xconnect from that SVI to the remote l2vpn endpoint and test pw that way.  i realize that won't test out the CE handoff gige connection nor will it test out the CE handoff 901 gige interface service instance config but at least it might prove to be useful for the PW mpls cloud test.

Hey i just thought of something else, what if you connect a cable from 901 g0/0 to g0/1 (xover if need be) and pretend g0/0 is the actual customer CE device (add an svi to, for instance, vlan 10 and service instance that vlan 10 via g0/0).....then config g0/1 as the actual way that you would rcv that traffic from a customer and then xconnect g0/1 to the remote end of the pw across the mpls cloud.

If that works then this might be a good way to roll-out your 901's in test mode....pre-turnup...staging.... then when it's time to connect the customer to g0/1 you have your field tech/eng go out there and simple unplug g0/0 and g0/1 and then you remove previous test configs on g0/0 and svi and connect customer to g0/1.

Aaron

P.S.  Also, incase you weren't aware, I have seen that even though the L2VPN stays down while the AC is down on the ends of the complete l2vpn, you still will see some progress/status on the establishment of the intermediary pw.  this doesn't seem to be shown with the "brief" output since the pw "segment 2" shows down, BUT, with "detail" output you can see some of the negotiated or discovered setting from end to end....MTU seen, etc.

[dean holroyd]

Hello Jon

The ASR9000 allows you to internally loop an ethernet interface, which will allow you to bring it up without a cable connected. With the interface up, you can then ping the pseudowire. Perhaps it is the same for the 901

Hope that helps

RP/0/RSP0/CPU0:ASR1#sh run int Gi0/1/0/19

Tue Apr 10 16:49:38.949 bst

interface GigabitEthernet0/1/0/19

loopback internal

l2transport

RP/0/RSP0/CPU0:ASR1#sh l2vpn xconnect   

Tue Apr 10 16:49:45.180 bst

Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,

        SB = Standby, SR = Standby Ready

XConnect                   Segment 1                   Segment 2               

Group      Name       ST   Description            ST   Description            ST

------------------------   -------------------------   -------------------------

test       test       UP   Gi0/1/0/19             UP   10.11.11.2      19     UP

--------------------------------------------------------------------------------

RP/0/RSP0/CPU0:ASR1#ping mpls pseudowire 10.11.11.2 19 repeat 500

Tue Apr 10 16:50:22.796 bst

Sending 500, 100-byte MPLS Echos to 10.11.11.2 VC: 19,

      timeout is 2 seconds, send interval is 0 msec:

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

  'L' - labeled output interface, 'B' - unlabeled output interface,

  'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,

  'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,

  'P' - no rx intf label prot, 'p' - premature termination of LSP,

  'R' - transit router, 'I' - unknown upstream index,

  'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!

Success rate is 99 percent (497/500), round-trip min/avg/max = 2/2/6 ms

[a-gould]

Thanks Dean, good thinking, I do see ethernet oam on 901 supports loopback.  I want to try to make this work. I tried this....I must not be doing something right.

interface GigabitEthernet0/11

load-interval 30

no negotiation auto

ethernet oam remote-loopback supported

ethernet oam

service instance 1 ethernet

  encapsulation dot1q 11

  xconnect 10.1.0.3 1 encapsulation mpls

   mtu 9004

901#ethernet oam remote-loopback start interface g0/11

%Ethernet OAM client on Gi0/11 hasn't found its remote peer.

Aaron

[Jon Berres]

Thanks for the reply's. The problem with building an SVI on the ASR901 for running L2 traffic to is that it is not supported in the 901. I can only provision an xconnect from within a service instance on an interface. I tried to create a bridge domain and then xconnect from within the associated SVI, but it doesn't work. I know that this method does work on the MWR2941 routers, but they are an older platform.

I think that running a crossover between two ports on the 901 may work. If the l2vpn terminates at g0/0 and then is crossconnected to g0/1 with a bridge-domain built on it. The MAC address of the SVI associated with the g0/1 bridge domain could be put into the testset and traffic ran to it. I will have to try that out.

Aaron - I have not been able to get the OAM loopback to work either. I think it may just be for a OAM  loopback which basically sends ping type packets to the interface which then responds back. I guess this would be a possible solution for testing layer 2 circuits, but it doesn't work with our JDSU ethernet testsets. I wish that it worked similar to the ASR9000 loopback where is it an actual Layer 2 loop. But from my understanding the OAM loop is similar to an ICMP ping response.

Thanks again for the help.

Jon