[j-nsp] Ethernet OAM on MX

[David Ball]

  Hi there.  MX480 running 10.0R3.10 and am trying to get 802.1ag and
Y.1731 delay measurement working on it, speaking to a non-juniper
device (MRV).  Given the config and results below, I'm guessing the MX
doesn't think all is well, as it thinks the remote MEP's mac is all
f's.  The funny thing is the MRV thinks everything is fine.....it
learned the MX's MAC in the CCM messages, and as such, even the
bidirectional delay/jitter/PL testing (Y.1731) is successful if
initiated from the MRV.  Naturally, due to the MX not learning the
MRV's mac, the delay/jitter/PL test fails if initiated from the MX.
The frames are traversing an MPLS network (L2vpn), PPM delegation to
PFE is 'not' disabled (ie. [edit protocols ppm] lists nothing).
Nothing jumped out at me in a defect search for 'OAM'.  I've tried
setting the remote-mep to 'auto-discovery' instead of manually naming
it, with similar result.

  Does anyone have this working between dis-similar devices, and if
so, did you have to fudge with anything in particular?  Again, the MRV
thinks everything is great (sending and receiving CCMs, and
successfully doing delay/jitter/PL measurements bidirectionally).

topology (with MEP endpoints being the LAN-facing ports on the MRV and MX480):

MRVswitch--(gig SMF)--MX80--(10Gig SMF)---L2VPN---MX480


MX config:

me at router-re0> show configuration protocols oam ethernet
connectivity-fault-management {
    performance-monitoring {
        hardware-assisted-timestamping;
    }
    traceoptions {
        file oamtrace.txt size 2m files 2 world-readable;
        flag all;
    }
    maintenance-domain oamtest {
        level 0;
        maintenance-association oamtest {
            continuity-check {
                interval 1s;
            }
            mep 1 {
                interface ge-1/0/0.10;
                direction up;
                remote-mep 2;
            }
        }
    }
}

results from 'show oam ethernet connectivity-fault-management
maintenance-domain oamtest maintenance-association oamtest':

Maintenance domain name: oamtest, Format: string, Level: 0
  Maintenance association name: oamtest, Format: string
  Continuity-check status: enabled, Interval: 1s, Loss-threshold: 3 frames
  MEP identifier: 1, Direction: up, MAC address: 00:22:83:75:69:4a
  Auto-discovery: disabled, Priority: 0
  Interface status TLV: none, Port status TLV: none
  Interface name: ge-1/0/0.10, Interface status: Active, Link status: Up
  Defects:
    Remote MEP not receiving CCM                  : no
    Erroneous CCM received                        : no
    Cross-connect CCM received                    : no
    RDI sent by some MEP                          : no
    Some remote MEP's MAC in error state          : no
  Statistics:
    CCMs sent                                     : 512954
    CCMs received out of sequence                 : 0

<snipping other entries whose counters were all 0s>

  Remote MEP count: 1
    Identifier    MAC address        State    Interface
        2     ff:ff:ff:ff:ff:ff    start


I don't see the PFE doing much about it:

me at router-re0> show pfe statistics traffic | match OAM
    ATM OAM                    :                    0
    ETHER OAM                  :                    0


I've tried using domain level 0 and level 1, both of which seem to add
some kind of 'filter' for which I can't find much info.  The default
for all levels seems to be 'Accept', but as soon as I configure that
level, it changes the action to 'Drop':

me at router-re0> sho oam ethernet connectivity-fault-management
forwarding-state interface extensive interface-name ge-1/0/0.10
Interface name: ge-1/0/0.10

  Level: 0
  Filter action: Drop
  Nexthop type: none

  Level: 1
  Direction: up
  Filter action: Drop
  Nexthop type: none
<snip>


Not much other than this in the oamtrace.txt log, looking as though
it's timing out waiting for something (other than when I restart CFM,
in which case it logs thousands of entries):

Mar 21 09:37:52 RTSOCK:Received async msg for ifl ge-1/0/0
Mar 21 09:37:52 RTSOCK:IFL handler: name=ge-1/0/0 index=91 op=change
flags=0xd000 sid:182
Mar 21 09:37:52 RTSOCK:name=ge-1/0/0.10 index=91 flags=0xd000, anydown=0
Mar 21 09:37:52 CFM-Session:cfmd_handle_ifl_flagchange: Process IFL(ge-1/0/0.10)
Mar 21 09:37:52 CFM-Session:CFM is enabled on IFL(ge-1/0/0.10), so
process flag change
Mar 21 09:38:03 CONN:cfmd_ltr_entry_flush_timer_expiry: timer expired
Mar 21 09:39:21 RTSOCK:Received async msg for ifl ge-1/0/0
Mar 21 09:39:21 RTSOCK:IFL handler: name=ge-1/0/0 index=91 op=change
flags=0xc000 sid:182
Mar 21 09:39:21 RTSOCK:name=ge-1/0/0.10 index=91 flags=0xc000, anydown=0
Mar 21 09:39:21 CFM-Session:cfmd_handle_ifl_flagchange: Process IFL(ge-1/0/0.10)
Mar 21 09:39:21 CFM-Session:CFM is enabled on IFL(ge-1/0/0.10), so
process flag change
Mar 21 09:48:03 CONN:cfmd_ltr_entry_flush_timer_expiry: timer expired