EoMPLS and Multicast

[galo]

Should I be able to pass multicast traffic over a L2 MPLS VPN? Any links?

Thanks In Advance!

[Harold Ritter]

It is certainly possible to pass multicast traffic over L2VPN as anything received from the attachment circuit will be forwarded to the pseudowire and vice versa.

Let me know if I answered your question,

[galo]

Hi h,

Thanks for your help! I'm still having problems. My configs are on gigabit ethernet interfaces. I'm not able to ping end to end. My lab consists of HOST-SWITCH-PE-PE-SWITCH-HOST. The PE hardware and software is identical:

IOS (tm) 7200 Software (C7200-JS-M), Version 12.2(15)T17, RELEASE SOFTWARE (fc

PE1#

!

interface GigabitEthernet1/0

description TEST Network

ip address 172.26.1.18 255.255.255.248

no ip redirects

no ip unreachables

no ip proxy-arp

negotiation auto

tag-switching mtu 1530

tag-switching ip

end

!

interface GigabitEthernet2/0.1

description TESTING_MULTICAST

encapsulation dot1Q 10

no cdp enable

mpls l2transport route 172.26.1.254 10

end

PE1#sh mpls l2transport summary

Destination address: 172.26.1.254, total number of vc: 1

0 unknown, 1 up, 0 down, 0 admin down

1 active vc on MPLS interface Gi1/0

PE1#sh mpls l2transport vc de

Local interface: Gi2/0.1 up, line protocol up, Eth VLAN 10 up

Destination address: 172.26.1.254, VC ID: 10, VC status: up

Tunnel label: imp-null, next hop 172.26.1.17

Output interface: Gi1/0, imposed label stack {16}

Create time: 01:00:23, last status change time: 00:59:07

Signaling protocol: LDP, peer 172.26.1.254:0 up

MPLS VC labels: local 16, remote 16

Group ID: local 3, remote 3

MTU: local 1500, remote 1500

Remote interface description: TESTING_MULTICAST

Sequencing: receive disabled, send disabled

VC statistics:

packet totals: receive 0, send 0

byte totals: receive 0, send 0

packet drops: receive 0, send 0

PE1#sh mpls forwarding-table

Local Outgoing Prefix Bytes tag Outgoing Next Hop

tag tag or VC or Tunnel Id switched interface

16 Untagged l2ckt(10) 0 Gi2/0.1 point2point

17 Pop tag 172.26.1.254/32 0 Gi1/0 172.26.1.17

PE2#

interface GigabitEthernet1/0

description TEST Network

ip address 172.26.1.17 255.255.255.248

no ip redirects

no ip unreachables

no ip proxy-arp

negotiation auto

tag-switching mtu 1530

tag-switching ip

end

!

interface GigabitEthernet2/0.1

description TESTING_MULTICAST

encapsulation dot1Q 10

no cdp enable

mpls l2transport route 172.26.1.253 10

end

PE2#sh mpls l2transport summary

Destination address: 172.26.1.253, total number of vc: 1

0 unknown, 1 up, 0 down, 0 admin down

1 active vc on MPLS interface Gi1/0

PE2#sh mpls l2transport vc de

Local interface: Gi2/0.1 up, line protocol up, Eth VLAN 10 up

Destination address: 172.26.1.253, VC ID: 10, VC status: up

Tunnel label: imp-null, next hop 172.26.1.18

Output interface: Gi1/0, imposed label stack {16}

Create time: 01:02:19, last status change time: 01:01:21

Signaling protocol: LDP, peer 172.26.1.253:0 up

MPLS VC labels: local 16, remote 16

Group ID: local 3, remote 3

MTU: local 1500, remote 1500

Remote interface description: TESTING_MULTICAST

Sequencing: receive disabled, send disabled

VC statistics:

packet totals: receive 0, send 0

byte totals: receive 0, send 0

packet drops: receive 0, send 0

PE2#sh mpls forwarding-table

Local Outgoing Prefix Bytes tag Outgoing Next Hop

tag tag or VC or Tunnel Id switched interface

16 Untagged l2ckt(10) 0 Gi2/0.1 point2point

17 Pop tag 172.26.1.253/32 0 Gi1/0 172.26.1.18

Am I missing anything?

[Harold Ritter]

The configs and the output from the show commands look good. Are you trying to ping a unicast or multicast address. Could you please post the CE configs and the output from your ping test.

Thanks,

[galo]

Hi H,

Good call! I checked my CE trunks and noted both had my vlan 10 as the native. After the native was changed on both sides the traffic started flowing and the multicast barely affected the router proc in comparison to when i tested the multicast vpn config.

Many Thanks!

[dknov]

Hi,

I wonder if that had happened because by default there is no tagging on native VLAN, so PE could not identify the traffic to be forwared via the pseudowire?

David

[attrgautam]

Yes ideally that should have been the issue. If the xconnect had been on the native ethernet , it would have worked right away i assume.