cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1987
Views
0
Helpful
7
Replies

L2VPN + VLANS not passing traffic

Evan Roggenkamp
Level 1
Level 1

Hello Everyone.

I am working on getting L2VPN between two CE routers, which essentially need to have the equivalent of an 802.1q trunk between them. I have created a diagram to help illustrate my point. Right now I can not ping between the CE routers.

Here is the configuration:

CE ROUTER 1

interface GigabitEthernet0/1/1
 mtu 9216
 no ip address
 speed 1000
 no negotiation auto
 cdp enable
 service instance 1 ethernet
  encapsulation dot1q 72
  bridge-domain 72
 !
interface BDI72
 ip address 10.12.0.2 255.255.254.0
 standby 0 ip 10.12.0.1
 encapsulation dot1Q 72

PE ROUTER 1

interface GigabitEthernet0/1/0/3
 mtu 9216
 l2transport
  l2protocol cpsv tunnel

l2vpn
 xconnect-group SITE-TO-SITE
  p2p POINT-TO-POINT
   interface GigabitEthernet0/1/0/3
    neighbor 10.208.255.5 pw-id 8

Configuration is mirrored across the 2nd PE & CE routers

Digram:

http://i.imgur.com/wvQLAD3.png

What am I missing?

 

7 Replies 7

Rivalino Tamaela
Cisco Employee
Cisco Employee

Have you checked if PW or AC is up? You can see from following command:

- show l2vpn xconnect neighbor 10.208.255.5 pw-id 8 detail

 

thanks,

rivalino

Hello Rivalino and thank you for taking a look.

 

Below is the output. As you can see, I have modified my attachment circuit a bit in the process of troubleshooting, but the problem remains the same regardless of configuring the interface as I have above, or using vlan subinterfaces as shown here.

 

Group SITE-TO-SITE, XC POINT-TO-POINT, state is up; Interworking none
  AC: GigabitEthernet0/1/0/24.72, state is up
    Type VLAN; Num Ranges: 1
    VLAN ranges: [72, 72]
    MTU 9086; XC ID 0x440077; interworking none
    Statistics:
      packets: received 20831, sent 0
      bytes: received 1372386, sent 0
      drops: illegal VLAN 0, illegal length 0
  PW: neighbor 10.208.255.5, PW ID 8, state is up ( established )
    PW class VLAN-TEST, XC ID 0xc000006f
    Encapsulation MPLS, protocol LDP
    Source address 10.80.255.1
    PW type Ethernet, control word disabled, interworking none
    PW backup disable delay 0 sec
    Sequencing not set

    PW Status TLV in use
      MPLS         Local                          Remote                        
      ------------ ------------------------------ -----------------------------
      Label        289941                         16011                         
      Group ID     0x20006c0                      0x2000300                     
      Interface    GigabitEthernet0/1/0/24.72     GigabitEthernet0/1/0/3.72     
      MTU          9086                           9086                          
      Control word disabled                       disabled                      
      PW type      Ethernet                       Ethernet                      
      VCCV CV type 0x2                            0x2                           
                   (LSP ping verification)        (LSP ping verification)       
      VCCV CC type 0x6                            0x6                           
                   (router alert label)           (router alert label)          
                   (TTL expiry)                   (TTL expiry)                  
      ------------ ------------------------------ -----------------------------
    Incoming Status (PW Status TLV):
      Status code: 0x0 (Up) in Notification message
    Outgoing Status (PW Status TLV):
      Status code: 0x0 (Up) in Notification message
    MIB cpwVcIndex: 3221225583
    Create time: 10/04/2014 21:57:03 (11:58:02 ago)
    Last time status changed: 10/04/2014 21:57:03 (11:58:02 ago)
    Statistics:
      packets: received 0, sent 20831
      bytes: received 0, sent 1372386

 

Something to note is we have other pseudowires of this nature functioning, but none facing an EVC-based interface as in this example, simply IOS 802.1q trunks - and they work well. 

On AC counter we can see that it detects incoming packets from CE:

AC: GigabitEthernet0/1/0/24.72, state is up
    Type VLAN; Num Ranges: 1
    VLAN ranges: [72, 72]
    MTU 9086; XC ID 0x440077; interworking none
    Statistics:
      packets: received 20831, sent 0
      bytes: received 1372386, sent 0

 

On PW statistics, we can see that those packets were forwarded to remote PE:

 Statistics:
      packets: received 0, sent 20831
      bytes: received 0, sent 1372386

 

However, we do not see received packets from remote PE to this PE:

 Statistics:
      packets: received 0, sent 20831   <-- received counter is zero
      bytes: received 0, sent 1372386 

 

The next troubleshooting step is to take a look remote PE and doing the same command. Check the statistics for AC and PW. If AC's statistics in zero, so troubleshoot the link between PE and CE.

 

thanks,

rivalino

 

Ah, yes. These are the statistics from the remote end:

Group SITE-TO-SITE, XC POINT-TO-POINT, state is up; Interworking none
  AC: GigabitEthernet0/1/0/3.72, state is up
    Type VLAN; Num Ranges: 1
    VLAN ranges: [72, 72]
    MTU 9086; XC ID 0x88001c; interworking none
    Statistics:
      packets: received 0, sent 26091
      bytes: received 0, sent 2013691

Pseudowire:

    Statistics:

      packets: received 26091, sent 0
      bytes: received 2013691, sent 0

 

I cleared the counters on both ends of this circuit and did a few pings

CE FACING PE

GigabitEthernet1/3/0 is up, line protocol is up 
  Hardware is SPA-2X1GE-V2, address is 88f0.774a.8170 (bia 88f0.774a.8170)
  Description: *** L2 LINK FACING PE FOR PSEUDOWIRE ***
  MTU 9100 bytes, BW 1000000 Kbit/sec, DLY 10 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive not supported 
  Full Duplex, 1000Mbps, link type is force-up, media type is LX
  output flow-control is on, input flow-control is on
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:25, output 00:00:08, output hang never
  Last clearing of "show interface" counters 00:16:35
  Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     450 packets input, 39525 bytes, 0 no buffer
     Received 21 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 429 multicast, 0 pause input
     23 packets output, 8987 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out

PE FACING CE:

GigabitEthernet0/1/0/3 is up, line protocol is up 
  Interface state transitions: 17
  Hardware is GigabitEthernet, address is 6c9c.ed0a.3f09 (bia 6c9c.ed0a.3f09)
  Description: Uplink to CE ROUTER FOR PSEUDOWIRE
  Internet address is Unknown
  MTU 9100 bytes, BW 1000000 Kbit (Max: 1000000 Kbit)
     reliability 255/255, txload 0/255, rxload 0/255
  Encapsulation ARPA,
  Full-duplex, 1000Mb/s, LXFDX, link type is force-up
  output flow control is off, input flow control is off
  loopback not set,
  Last input 00:00:30, output 00:00:00
  Last clearing of "show interface" counters 00:14:04
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     19 packets input, 7367 bytes, 0 total input drops
     19 drops for unrecognized upper-level protocol
     Received 0 broadcast packets, 19 multicast packets
              0 runts, 0 giants, 0 throttles, 0 parity
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     377 packets output, 33266 bytes, 0 total output drops
     Output 14 broadcast packets, 363 multicast packets
     0 output errors, 0 underruns, 0 applique, 0 resets
     0 output buffer failures, 0 output buffers swapped out
     2 carrier transitions

I wonder what could be causing the problem here? Bad SFP???

 

We need to troubleshoot further on PE-CE link. Does number of packets sent by CE matches with number of packets received by PE? Or, you can try to configure subinterface on PE into layer 3 subinterface (removing from PE), and then ping from directly connected CE to that ip address.

 

thanks,

Rivalino

Rivalino I do thank you for your assistance. You have helped me narrow it down, and you are correct. I have done as you say, and the link in question is not passing traffic. Why this is still eludes me, as the configurations are the same, and the links are up! Do you have any theories?

I've attached the configuration comparison.

 

EDIT:

 

Today I removed the EVC and the sub-interface from the CE to PE configuration that was giving trouble and just added ipv4 address there.

It pings fine! So something is wrong with the L3 sub-interface or the EVC configuration? Since it is the same on the other side, what could it be?? Is this a bug?

Strange messages in my logs as well. Attached as they do not fit on the page.

When you change the config to L3 and it worked fine, this rules out hardware issue including the SFP. Then we need to take a look at the software in ASR1k. Unfortunately, I do not have expertise in CE's platform (i guess the image is IOS-XE). You might try to upgrade the image in CE router to latest release and see if this solve the problem.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: