L2VPN broadcast traffic problem | docsis.org

You are here

L2VPN broadcast traffic problem

10 posts / 0 new
Last post
mbernardi
L2VPN broadcast traffic problem
AttachmentSize
Plain text icon CM cfg file1.03 KB
PDF icon very basic diagram49.29 KB

I am working on a L2VPN solution for one of our customers. I wanted to try to use the CM config file and put the VPN config in there. Our customer has 3 CMs off various nodes on our plant and a fiber connection using dot1q vlan trunks. Now I need to break the rules for networking, I need to get all of these modems and fiber vlan into a "broadcast domain". So I have the 3 modems in VLAN 100, 101 and 102. The modem config file is attached for VLAN 102 modem but they are all the same config(obviously except VLAN ID). The NSI port is configured and terminates into an EX4200, I also have a host in the EX as an access port(VLAN400) to simulate the fiber VLAN. All the VLANs get trunked into an MX5 and glued together with VPLS.

Now the problem. When I get the 3 modems online I can watch them register and using "debug cable l2vpn" and "show cab l2vpn xconn dot1q" see the config files work, and all MAC tables populate on the EX and MX with correct info. But when my host in vlan 400(fiber vlan) tries to ping any host behind a CM the ARP broadcast get flooded out each VLAN as it should because of VPLS but never makes it to the host behind the modem. But if I originate traffic from behind the modem to the host in vlan 400 things "work". Any traffic from modem host to modem host shows this same problem. It's almost like downstream ARP(most likely all broadcast; DHCP) traffic just will not work.

Oh, and, if I add static ARPs on the host behind the modem, pings will work.

I have a uBR7225VXR with SCG3, MC-88V. Using Arris 820 CMs. Could it have something to do with 802.1q=N, I didn't think so since the CMTS should strip the single dot1q tag before transmitting it back to the modem on the downstream.

MAC Version : DOC3.0
QoS Provisioned Mode : DOC1.1
Enable DOCSIS2.0 Mode : Y
Modem Status : {Modem= w-online(pt), Security=assign(tek)}
Capabilities : {Frag=N, Concat=N, PHS=Y}
Security Capabilities : {Priv=BPI+, EAE=Y, Key_len=56,40,128}
L2VPN Capabilities : {L2VPN=Y, eSAFE=N}
Sid/Said Limit : {Max US Sids=8, Max DS Saids=24}
Optional Filtering Support : {802.1P=N, 802.1Q=N, DUT=Y}

mbowe
L2VPN is a bit of a black art

L2VPN is a bit of a black art :-)

I have looked over your configs and I cant spot anything obviously wrong.

A few suggestions for you :

1) try temporarily removing the DUT stanza from the config file to see if ARP is then working. DUT is a good thing to have on L2VPN, but maybe something is going wrong there and causing your problems. If it starts working after the change at least that gives you somewhere to start looking.

2) In my experience it is not common to include the DUT CMIM in the config file. The system should work this out automatically. A quick glance at the docs show you seem to be specifying the default, but would be good to try removing it to see if it makes a difference.

3) Also I don't think this is causing a problem, but I would think its necessary to put the L2VPN CMIM in the config file. Again this is automatically calculated. Less stuff in the config file is always good!

4) If you cant get the L2VPN going via CM config file, you could try changing over to Cisco's proprietary CMTS style instead ("Cisco Transparent LAN Service"). If you have large numbers of L2VPN modems then yes, using the config file is probably best. But if you are only dealing with smaller number (eg less than 100) that don't really change all that often then I reckon the CMTS style is better. This eliminates the need to have custom config file per customer. Instead you can just make a handful of generic L2VPN config files that each have the DUT enabled plus the desired speed eg 1/1, 2/2, 4/4 etc. No need to nominate any VLAN info in the config file. More info here http://www.cisco.com/en/US/docs/ios/cable/configuration/guide/tspnt_lans.... This is the style we use on our CMTSes, and we do same as you sending them through a switch to a Juniper MX. We are using bridge-domains, but that is a legacy thing and basically the same as dumping them into a VPLS. I'd probably use VPLS instead if redoing our system from scratch.

mbernardi
Black art is an understatement... :)

I tried moving back to one of our generic boot files. Just a plain old 20x2 DOCSIS 1.1 QOS with SNMP strings no filtering or anything. Added the CLI commands to put the modems in their respected VLANs. I've tracked it down to the CM. While doing a debug "debug cable mac-address verbose" and "debug cable l2vpn conditional". I can see the packet the CMTS is sending to the CM. But my host behind the modem cannot see the packet. Where I am confused is the SRC part of the debug is wrong. The source VLAN of 001b.2187.e59b should've come from VLAN400. But all the DST information is correct.

Nov 5 00:58:42.431: DOWNSTREAM SZ 68 SRC GigabitEthernet0/1:[101]:[001b.2187.e59b] DST Cable1/0:[SID33]:[ffff.ffff.ffff] CM[cca4.6267.7ac7]

Nov 5 00:58:43.431: DOWNSTREAM SZ 68 SRC GigabitEthernet0/1:[101]:[001b.2187.e59b] DST Cable1/0:[SID33]:[ffff.ffff.ffff] CM[cca4.6267.7ac7]

Nov 5 00:58:44.431: DOWNSTREAM SZ 68 SRC GigabitEthernet0/1:[101]:[001b.2187.e59b] DST Cable1/0:[SID33]:[ffff.ffff.ffff] CM[cca4.6267.7ac7]

cmts1-hsdlab#sh cab l2-vpn xconnect dot1q-vc-map cca4.6267.7ac7
MAC Address Ethernet Interface VLAN ID Cable Intf SID Customer Name/VPNID
cca4.6267.7ac7 GigabitEthernet0/1 101 Cable1/0 33

cmts1-hsdlab#

Now when I ping from inside to outside the CMTS I can see the ARP request, ARP response, ICMP echo request and echo response on the debug, but still no packets at the host behind the modem. I'll keep testing but boy am I confused.

Nov 5 01:14:13.245: UPSTREAM SZ 60 SRC Cable1/0:[SID33]:[0019.b9f9.1a53] CM[cca4.6267.7ac7] DST GigabitEthernet0/1:[101]:[ffff.ffff.ffff]

Nov 5 01:14:13.245: DOWNSTREAM SZ 68 SRC GigabitEthernet0/1:[101]:[001b.2187.e59b] DST Cable1/0:[SID33]:[0019.b9f9.1a53] CM[cca4.6267.7ac7]

Nov 5 01:14:13.261: UPSTREAM SZ 98 SRC Cable1/0:[SID33]:[0019.b9f9.1a53] CM[cca4.6267.7ac7] DST GigabitEthernet0/1:[101]:[001b.2187.e59b]

Nov 5 01:14:13.261: DOWNSTREAM SZ 106 SRC GigabitEthernet0/1:[101]:[001b.2187.e59b] DST Cable1/0:[SID33]:[0019.b9f9.1a52] CM[cca4.6267.7ac7]

Nov 5 01:14:14.253: UPSTREAM SZ 98 SRC Cable1/0:[SID33]:[0019.b9f9.1a53] CM[cca4.6267.7ac7] DST GigabitEthernet0/1:[101]:[001b.2187.e59b]

Nov 5 01:14:14.253: DOWNSTREAM SZ 106 SRC GigabitEthernet0/1:[101]:[001b.2187.e59b] DST Cable1/0:[SID33]:[0019.b9f9.1a52] CM[cca4.6267.7ac7]

Nov 5 01:14:15.261: UPSTREAM SZ 98 SRC Cable1/0:[SID33]:[0019.b9f9.1a53] CM[cca4.6267.7ac7] DST GigabitEthernet0/1:[101]:[001b.2187.e59b]

Nov 5 01:14:15.261: DOWNSTREAM SZ 106 SRC GigabitEthernet0/1:[101]:[001b.2187.e59b] DST Cable1/0:[SID33]:[0019.b9f9.1a52] CM[cca4.6267.7ac7]

Nov 5 01:14:16.269: UPSTREAM SZ 98 SRC Cable1/0:[SID33]:[0019.b9f9.1a53] CM[cca4.6267.7ac7] DST GigabitEthernet0/1:[101]:[001b.2187.e59b]

Nov 5 01:14:16.269: DOWNSTREAM SZ 106 SRC GigabitEthernet0/1:[101]:[001b.2187.e59b] DST Cable1/0:[SID33]:[0019.b9f9.1a52] CM[cca4.6267.7ac7]

mbernardi
SRC is correct

The ARP response should be tagged with VLAN 101 since it needs to get to the modem that has VLAN 101 configured, sorry for the confusion.

mbernardi
Got it working

I swapped out my Arris 820s for a Moto SB6180 and everything started working. I am going to contact Arris to see if it is maybe the firmware.

Capm
?

What version are you running?

mbernardi
Arris CM820A

SNMPv2-MIB::sysDescr.0 = STRING: ARRIS DOCSIS 3.0 Touchstone WideBand Cable Modem HW_REV: 1; VENDOR: Arris Interactive, L.L.C.; BOOTR: 1.2.1.61; SW_REV: 7.3.123; MODEL: CM820A

mbowe
Yeah that is too old.

Yeah that is too old.

You need to go to latest 7.5.93

There are fixes along the way like this :

"The following issues were resolved in release 7.5.32
[..]
2.3.75 BSOD Functionality
Tracking No.
PROD00177558, PROD00177557, PROD00177010
Description
The following BSOD related issues have been corrected:
* Multicast and broadcast traffic cannot properly traverse the L2VPN in the downstream.
* Traffic cannot reach an unknown Destination MAC address behind a BSoD enabled CM820A.
* When provisioned, the downstream traffic does not work, non-BSOD(traffic to CM) nor BSOD(traffic to CPE). But Upstream traffic works for both non-BSOD and BSOD packets.
"

mbernardi
That's it!

I upgraded to 7.5.93, and everything is working flawlessly. Thanks everyone!

henryoscar (not verified)
CMTS

I can see the package sent to the CMTS cm. But the hosts behind the modem could not see the package. Since I am at a loss is part of SRC to correct a mistake. VLAN source 001b.2187.e59b should have come from VLAN400. But all the information daylight saving time is right. https://www.examsbuzz.com/200-310-exam.html

Log in or register to post comments