EoMPLS Control Word Usage

[Deniz AYDIN]

Hi,

Is there documentation know why the source and destionation mac adress changes when the control word usage is off for P2P EoMPLS setup. I have tested this with Cisco ASR 1K and 7200 NPE-G2 and both have the same type of beaviour. When the control word is off, the packets transmitted over the pseudowire without the tagged information, instead the source and destination mac adress are changed by the ingress PE (the last 12 bit of the source mac adress equals the vlan and some bits shows the COS value) but I dont understand how the egress PE finds the original source/destination mac. Is there any documantetion about this method?

[Alessio Andreoli]

Hi Deniz,

this is why:

http://tools.ietf.org/html/rfc4448

Hope this helps

Alessio

PS: The MAC is kept (or emulated) in VPLS instead, where the STP needs this info to compute the loop-free tree between PEs

[Deniz AYDIN]

Hi Alessio,

This was the first doc I have read and no information about this method. It just call this as a NSP function and noting beyond this. Actually this is beyonde the scope of control world, but however related with it. 

[Sandip Rathod]

Hi Deniz,

Look at the c-bit handling in RFC 4447

http://tools.ietf.org/html/rfc4447#page-20

Regards,

Sandip

[Deniz AYDIN]

Hi Sandip,

I have read the RFC and could not find any information why the source and destination mac addresses change. Its all about the control word negotiation, or may be I am all missing something in the RFC:(

Here is the  wireshark capture (from ASR1K) with control word off. CPE's are sending traffic with vlan-id 400. But you can not see the vlan-id 400. Instead the last 12 bit of source mac address show the vlan-id (0x190 hexa decimal). And also the 16-15-14 bits shows the COS value of the packet.

This one is from same setup with control word on. You can see the vlan-id 400 and CPE's unchanged mac addresses. and vlan-id can be shown clearly.

[Adam Vitkovsky]

What interworking type are you using for this PW please?

adam

[Deniz AYDIN]

Actually there is no internetworking configured. I just add the pw-class for turning the control word on and remove for off. Below is the configurations of the routers.

CE-1 :
interface GigabitEthernet0/0/0
no ip address
negotiation auto
interface GigabitEthernet0/0/0.400
encapsulation dot1Q 400
ip address 5.5.5.5 255.255.255.0

PE-1
pseudowire-class test
encapsulation mpls

interface GigabitEthernet0/0/1
no ip address
negotiation auto
xconnect 192.168.126.4 1 encapsulation mpls pw-class test
end
PE-2
pseudowire-class test
encapsulation mpls
control-word

interface GigabitEthernet0/11
no switchport
no ip address
xconnect 192.168.126.219 1 encapsulation mpls pw-class test
end

CE-2 :
interface GigabitEthernet0/0/0
no ip address
negotiation auto
interface GigabitEthernet0/0/0.400
encapsulation dot1Q 400
ip address 5.5.5.6 255.255.255.0

PE-1 :

Local interface: Gi0/0/1 up, line protocol up, Ethernet up

Destination address: 192.168.126.4, VC ID: 1, VC status: up

Output interface: Gi0/0/0, imposed label stack {3324 191}

Preferred path: not configured

Default path: active

Next hop: 192.168.119.241

Create time: 00:03:55, last status change time: 00:03:19

Last label FSM state change time: 00:03:21

Signaling protocol: LDP, peer 192.168.126.4:0 up

Targeted Hello: 192.168.126.219(LDP Id) -> 192.168.126.4, LDP is UP

Graceful restart: not configured and not enabled

Non stop routing: not configured and not enabled

Status TLV support (local/remote) : enabled/supported

LDP route watch : enabled

Label/status state machine : established, LruRru

Last local dataplane status rcvd: No fault

Last BFD dataplane status rcvd: Not sent

Last BFD peer monitor status rcvd: No fault

Last local AC circuit status rcvd: No fault

Last local AC circuit status sent: No fault

Last local PW i/f circ status rcvd: No fault

Last local LDP TLV status sent: No fault

Last remote LDP TLV status rcvd: No fault

Last remote LDP ADJ status rcvd: No fault

MPLS VC labels: local 155, remote 191

Group ID: local 0, remote 0

MTU: local 1500, remote 1500

Remote interface description:

Sequencing: receive disabled, send disabled

Control Word: On

(configured: autosense)

SSO Descriptor: 192.168.126.4/1, local label: 155

Dataplane:

SSM segment/switch IDs: 4138/8232 (used), PWID: 1

VC statistics:

transit packet totals: receive 9, send 7

transit byte totals: receive 1192, send 859

transit packet drops: receive 0, seq error 0, send 0

[Adam Vitkovsky]

Can’t find what the default mode of operation is.

Only info I was able to dig out was that interworking is not enabled by default.

But the behavior implies  that the default mode of operation is “interworking ethernet” (VC type 5)

–and that’s what (without the control word) seems to cause the mac-addr to be used to carry the VLAN info.

Hidden VLAN (outside the allowed VLAN range) concept was used in 7600 and 6500 to carry the ingress port information for NP - so what you see might be a version of this.

What happens if you specifically configure “interworking ethernet” or “interworking vlan” in the pw-class please?

CISCO definition for XE:

interworking Ethernet:

Causes Ethernet frames to be extracted from the attachment circuit and sent over the pseudowire. Ethernet end-to-end transmission is assumed. Attachment circuit frames that do not contain Ethernet frames are dropped. In the case of VLAN, the VLAN tag is removed, which leaves a pure Ethernet frame.

interworking vlan:

Causes Ethernet frames and the VLAN tag to be sent over the pseudowire. Ethernet end-to-end transmission is assumed. Attachment circuit frames that do not contain Ethernet frames are dropped.

adam

[Deniz AYDIN]

I have two different PE'es, PE-1 is ASR1K and PE-2 is 3600X. With etnernet interworking ethernet, gives the same result, striping vlan info and using mac to carry this information. With interworing vlan, 3600X carries the vlan information but still changes source mac to 9b0081000000 and the ASR1K still hides the vlan.

[Adam Vitkovsky]

Hi,

What do the mac addresses mean anyway

The 9b:00:81:00:00:00 I have no clue where is that coming from

Or the destination mac ff:ff:00:07:7d:6a

Odd enough 00:07:7d:00:00:00 to 00:07:7d:ff:ff:ff belongs to cisco systems

I have checked and the L2PT uses different destination mac 01:00:0c:cd:cd:d0

adam