Some Branch SRX devices have the capability to support a VDSL link. However, it is reported that the VDSL link will not train up with some ISPs, while an ADSL link on the same card will work without any problems with the same ISPs.
Note : This article deals with a specific issue related to the implementation of VDSL on Branch SRX devices. For general VDSL related information and for configuration examples, please use this link .
At the time of writing of this article, the following Branch SRX platforms have either the capability to support a VDSL mini-PIM or have an integrated VDSL card:
It is observed that the VDSL link fails to come up with some ISPs while an ADSL link trains up without any issues. It is also noted that other vendor VDSL modems train up successfully with the same ISPs. On such devices, when the monitor traffic command is executed on the logical VDSL interface, i.e., the pt interface, it seems like the PPPoE negotiation commences but the LCP packets never make it to the ISP:
pt
root# run monitor traffic interface pt-2/0/0 verbose output suppressed, use <detail> or <extensive> for full protocol decode Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay. Address resolution timeout is 4s. Listening on pt-2/0/0, capture size 96 bytes 10:29:53.074007 Out PPPoE [ses 4230]LCP, Conf-Reques t (0x01), id 68, length 16 10:29:53.618794 In PPPoE [ses 4230]LCP, Conf-Request (0x01), id 36, length 20 10:29:53.619949 Out PPPoE [ses 4230]LCP, Conf-Ack (0x02), id 36, length 20 10:29:55.963432 Out PPPoE [ses 4230]LCP, Conf-Request (0x01), id 69, length 16 10:29:56.718290 In PPPoE [ses 4230]LCP, Conf-Request (0x01), id 36, length 20 10:29:56.719528 Out PPPoE [ses 4230]LCP, Conf-Ack (0x02), id 36, length 20 10:29:58.939040 Out PPPoE [ses 4230]LCP, Conf-Request (0x01), id 70, length 16 10:29:59.819201 In PPPoE [ses 4230]LCP, Conf-Request (0x01), id 36, length 20 10:29:59.820439 Out PPPoE [ses 4230]LCP, Conf-Ack (0x02), id 36, length 20 10:30:01.848902 Out PPPoE [ses 4230]LCP, Conf-Request (0x01), id 71, length 16 10:30:02.909497 In PPPoE [ses 4230]LCP, Conf-Request (0x01), id 36, length 20 10:30:02.910846 Out PPPoE [ses 4230]LCP, Conf-Ack (0x02), id 36, length 20 10:30:04.782562 Out PPPoE [ses 4230]LCP, Conf-Request (0x01), id 72, length 16
From this, it can be seen that the SRX sends a Conf-Request packet but the ISP does not seem to receive the packet and responds with a Conf-Request as well. The SRX then sends a Conf-Ack to the Conf-Request by the ISP but there is no response from the ISP.
Conf-Request
Conf-Ack
This behavior repeats until the PPPoE negotiation times out, restarts and loops through the same steps.
According to Junos OS' implementation of VDSL on the SRX platforms, the IEEE802.1p field in the VLAN header of the LCP packets is set to a priority of 6 (internetwork-control). However, not all ISPs accept high-priority LCP packets and drop them at the edge of their network. This is why the LCP packets seem to never make it to the ISP.
When running the monitor traffic command on the pt interface with the extensive keyword, the differences in the priority bits can be easily seen:
monitor traffic
extensive
10:44:46.520712 In <
Juniper PCAP Flags [Ext, In], PCAP Extension(s) total length 16 Device Media Type Extension TLV #3, length 1, value: Ethernet (1) Logical Interface Encapsulation Extension TLV #6, length 1, value: PPPoE over Ethernet (62) Device Interface Index Extension TLV #1, length 2, value: 38144 Logical Interface Index Extension TLV #4, length 4, value: 74 -----original packet----- 00:30:88:15:f8:fd > 64:87:88:52:98:d4, ethertype 802.1Q (0x8100), length 60: vlan 600, p 0 , ethertype PPPoE S, PPPoE [ses 6600]LCP (0xc021), length 20: LCP, Conf-Request (0x01), id 156, length 20
10:44:46.345574
Out
Juniper PCAP Flags [Ext], PCAP Extension(s) total length 16 Device Media Type Extension TLV #3, length 1, value: Ethernet (1) Logical Interface Encapsulation Extension TLV #6, length 1, value: PPPoE over Ethernet (62) Device Interface Index Extension TLV #1, length 2, value: 38144 Logical Interface Index Extension TLV #4, length 4, value: 74 -----original packet----- 64:87:88:52:98:d4 > 00:30:88:15:f8:fd, ethertype 802.1Q (0x8100), length 40: vlan 600, p 6 , ethertype PPPoE S, PPPoE [ses 6600]LCP (0xc021), length 16: LCP, Conf-Request (0x01), id 11, length 16
When faced with a similar issue, run the following command from operational mode :
operational mode
monitor traffic interface pt- <fpc/pic/port> extensive
If the outgoing LCP packets show the priority-bit set to 6, then configure the following under edit mode and commit:
edit mode
set class-of-service host-outbound-traffic ieee-802.1 default be
The above command should enable the PPPoE negotiations to complete successfully and the VDSL link to come up.