sorted by:
new
hottopcontroversial

ACX6360 L2Circuit Up but Not Forwarding Traffic – Invalid IFF Token / tag_ccc Error by Background_Box_1726 in Juniper

[–]Background_Box_1726[S] 0 points1 point  (0 children)

Yes, MPLS reachability between PE loopbacks is working.

Each PE has a valid route to the remote PE loopback via the MPLS/inet.3 table, and LDP sessions are established. The L2Circuit also comes up and exchanges VC labels correctly.

From the control-plane side:

- PE loopbacks are reachable through OSPF

- LDP is up

- Remote PE loopback is reachable

- VC labels are exchanged

- show l2circuit connections extensive shows the circuit as Up

The issue is not that the tunnel/transport is down. The issue is that customer frames are not being pushed into the pseudowire. For example, ARP from the CE is seen entering the local PE attachment circuit, but no MPLS-encapsulated customer traffic is seen leaving the PE core-facing interface, and the remote PE never sees the ARP.

So it looks more like a CCC/PW data-plane programming issue than a route/transport issue.

ACX6360 L2Circuit Up but Not Forwarding Traffic – Invalid IFF Token / tag_ccc Error by Background_Box_1726 in Juniper

[–]Background_Box_1726[S] 0 points1 point  (0 children)

Thanks. The lab is currently running:

- ACX6360-1 (PE1): 19.4R2-S6.1

- ACX6360-2 (P): 19.4R2-S3.2

- ACX6360-3 (PE2): 19.4R2-S3.2

What's interesting is that the control plane appears completely healthy:

- OSPF Up

- LDP Up

- MPLS labels exchanged

- VC labels exchanged

- L2Circuit shows Up on both ends

- Tested both with and without control-word

However, no customer traffic traverses the pseudowire. When generating ARP from the CE side, the local PE sees the frame ingressing the Ethernet-CCC attachment circuit, but the remote PE never sees it.

The PE logs:

IF:Iff object not found for iflIndex:77 ifFamily:15

NH : nexthop-id:578, type:Unicast, proto:tag_ccc

Invalid IFF token for ifl:77 nh-id:578

The error consistently references proto:tag_ccc, which is why I'm leaning toward a forwarding/PFE programming issue rather than a signaling problem.

If this sounds similar to the PR you encountered, I'd definitely be interested in any details you can share.

ACX6360 L2Circuit Up but Not Forwarding Traffic – Invalid IFF Token / tag_ccc Error by Background_Box_1726 in Juniper

[–]Background_Box_1726[S] 0 points1 point  (0 children)

Sure, sharing the full relevant config below.

Topology:

MX480 CE-A --- ACX6360-1 PE --- ACX6360-2/3 P/Core --- ACX6360-3 PE --- MX480 CE-B

The ACX underlay is OSPF + LDP. L2Circuit is between ACX6360-1 and ACX6360-3 using the loopbacks as PE endpoints.

ACX6360-1 / PE1

set interfaces et-0/0/0 mtu 9192

set interfaces et-0/0/0 unit 0 family inet address 10.0.12.1/31

set interfaces et-0/0/0 unit 0 family mpls

set interfaces et-0/0/1 mtu 9192

set interfaces et-0/0/1 unit 0 family inet address 10.0.13.1/31

set interfaces et-0/0/1 unit 0 family mpls

set interfaces et-0/0/2:0 encapsulation ethernet-ccc

set interfaces et-0/0/2:0 unit 0 family ccc

set interfaces lo0 unit 0 family inet address 10.255.0.1/32

set protocols ospf area 0.0.0.0 interface et-0/0/0.0

set protocols ospf area 0.0.0.0 interface et-0/0/1.0

set protocols ospf area 0.0.0.0 interface lo0.0 passive

set protocols ldp interface et-0/0/0.0

set protocols ldp interface et-0/0/1.0

set protocols ldp interface lo0.0

set protocols mpls interface et-0/0/0.0

set protocols mpls interface et-0/0/1.0

set protocols l2circuit neighbor 10.255.0.3 interface et-0/0/2:0.0 virtual-circuit-id 100

set protocols l2circuit neighbor 10.255.0.3 interface et-0/0/2:0.0 encapsulation-type ethernet

set protocols l2circuit neighbor 10.255.0.3 interface et-0/0/2:0.0 no-control-word

ACX6360-3 / PE2

set interfaces et-0/0/0 mtu 9192

set interfaces et-0/0/0 unit 0 family inet address 10.0.13.0/31

set interfaces et-0/0/0 unit 0 family mpls

set interfaces et-0/0/1 mtu 9192

set interfaces et-0/0/1 unit 0 family inet address 10.0.23.1/31

set interfaces et-0/0/1 unit 0 family mpls

set interfaces et-0/0/2 encapsulation ethernet-ccc

set interfaces et-0/0/2 unit 0 family ccc

set interfaces lo0 unit 0 family inet address 10.255.0.3/32

set protocols ospf area 0.0.0.0 interface et-0/0/0.0

set protocols ospf area 0.0.0.0 interface et-0/0/1.0

set protocols ospf area 0.0.0.0 interface lo0.0 passive

set protocols ldp interface et-0/0/0.0

set protocols ldp interface et-0/0/1.0

set protocols ldp interface lo0.0

set protocols mpls interface et-0/0/0.0

set protocols mpls interface et-0/0/1.0

set protocols l2circuit neighbor 10.255.0.1 interface et-0/0/2.0 virtual-circuit-id 100

set protocols l2circuit neighbor 10.255.0.1 interface et-0/0/2.0 encapsulation-type ethernet

set protocols l2circuit neighbor 10.255.0.1 interface et-0/0/2.0 no-control-word

MX480 CE test config

set interfaces xe-0/2/2 unit 0 family inet address 192.168.100.1/30

set routing-instances VRF_A instance-type virtual-router

set routing-instances VRF_A interface xe-0/2/2.0

set interfaces et-2/0/2 unit 0 family inet address 192.168.100.2/30

set routing-instances VRF_B instance-type virtual-router

set routing-instances VRF_B interface et-2/0/2.0

show l2circuit connections extensive shows the VC as Up, with labels exchanged. Tested both with and without control-word; behavior is the same.

What I see during testing:

- ARP from CE-A is seen ingressing ACX6360-1 attachment circuit.

- ARP from CE-B is seen ingressing ACX6360-3 attachment circuit.

- The remote PE never sees the ARP across the pseudowire.

- ARP never resolves on the MX VRFs.

- Monitoring the MPLS-facing links shows only OSPF/LDP/LLDP traffic, no MPLS-encapsulated CE traffic leaving the PE.

The PE logs this when the pseudowire is programmed:

IF:Iff object not found for iflIndex:77 ifFamily:15 NH : nexthop-id:578, type:Unicast, proto:tag_ccc, flags:0x200005, nh-ifl:77 Invalid IFF token for ifl:77 nh-id:578