1

I am observing 'PE route down message ' against LDP based VPLS connection on Juniper MX. The IGP protocol is IS-IS. LDP VPLS connectivity is point to point (having only two end points).

When I check status of LDP VPLS for some instance with the extensive knob , then its shows in connection history ' PE route down' along with 'status update timer'. Can someone please explain what does it mean? It is also observed in log messages that VPLS connection goes from up to down and then up again.

Below are some observations

When we check the route to LDP peer ip (targetted session) in routing table, in inet.0 route age is 'more' than in inet.3.

LDP session with targeted peer dont flap.

Below are configuration and logs .

R1> show configuration routing-instances 1784 
instance-type vpls;
interface ge-2/1/5.1784;
protocols {
    vpls {
        encapsulation-type ethernet-vlan;
        no-tunnel-services;
        vpls-id 1784;
        mtu 1500;
        neighbor 192.168.0.18;
    }
}



R1> show vpls connections instance 1784 extensive 
Instance: 1784
      VPLS-id: 1784
        Number of local interfaces: 1
        Number of local interfaces up: 1
        ge-2/1/5.1784      
        lsi.1097220                   Intf - vpls 1784 neighbor 192.168.0.18 vpls-id 1784
        Neighbor                  Type  St     Time last up          # Up trans
        192.168.0.18(vpls-id 1784) rmt  Up     May 14 11:14:20 2019        1196
          Remote PE: 192.168.0.18, Negotiated control-word: No
          Incoming label: 262190, Outgoing label: 153422
          Negotiated PW status TLV: No
          Local interface: lsi.1097220, Status: Up, Encapsulation: VLAN
            Description: Intf - vpls 1784 neighbor 192.168.0.18 vpls-id 1784
          Flow Label Transmit: No, Flow Label Receive: No
        Connection History:                 
            May 14 11:14:20 2019  status update timer  
            May 14 11:14:20 2019  PE route down        
            May 14 11:14:15 2019  status update timer  
            May 14 11:14:14 2019  PE route down        
            May 14 10:14:20 2019  status update timer  
            May 14 10:14:20 2019  PE route down        
            May 14 10:14:15 2019  status update timer  
            May 14 10:14:14 2019  PE route down        
            May 14 09:19:43 2019  status update timer  
            May 14 09:19:42 2019  PE route down        
            May 14 09:19:38 2019  status update timer  
            May 14 09:19:36 2019  PE route down        
            May 14 09:14:20 2019  status update timer  
            May 14 09:14:20 2019  PE route down        
            May 14 09:14:15 2019  status update timer  
            May 14 09:14:14 2019  PE route down        
            May 14 08:14:20 2019  status update timer  
            May 14 08:14:20 2019  PE route down        
            May 14 08:14:15 2019  status update timer  
            May 14 08:14:14 2019  PE route down 

R1> show route 192.168.0.18 

inet.0: 47621 destinations, 141466 routes (47621 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.0.18/32    *[IS-IS/18] 02:53:29, metric 149
                    > to 192.168.7.14 via ae0.3
                      to 192.168.7.18 via ae15.3

inet.3: 262 destinations, 262 routes (262 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.0.18/32    *[LDP/9] 00:58:42, metric 149
                    > to 192.168.7.14 via ae0.3, Push 50294
                      to 192.168.7.18 via ae15.3, Push 670023

R1> show ldp session 192.168.0.18 detail 
Address: 192.168.0.18, State: Operational, Connection: Open, Hold time: 29
  Session ID: 192.168.1.35:0--192.168.0.18:0
  Next keepalive in 9 seconds
  Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1
  Neighbor types: configured-layer2
  Keepalive interval: 10, Connect retry interval: 1
  Local address: 192.168.1.35, Remote address: 192.168.0.18
  Up for 3w4d 07:43:50

The log messages are shown below :-

May 14 11:14:14.419 2019  R1 rpd[9997]: %DAEMON-5-RPD_LAYER2_VC_DOWN: State of Layer 2 VC (Neighbor : 192.168.0.18, VC-ID : 1784) changed from UP to VC-Dn
May 14 11:14:15.891 2019  R1 rpd[9997]: %DAEMON-6-RPD_LAYER2_VC_UP: State of Layer 2 VC (Neighbor : 192.168.0.18, VC-ID : 1784) changed to UP
May 14 11:14:20.085 2019  R1 rpd[9997]: %DAEMON-5-RPD_LAYER2_VC_DOWN: State of Layer 2 VC (Neighbor : 192.168.0.18, VC-ID : 1784) changed from UP to VC-Dn
May 14 11:14:20.688 2019  R1 rpd[9997]: %DAEMON-6-RPD_LAYER2_VC_UP: State of Layer 2 VC (Neighbor : 192.168.0.18, VC-ID : 1784) changed to UP
Improve this question
1
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer.
    – Ron Maupin ♦
    Commented Dec 15, 2019 at 2:58

1 Answer 1

Reset to default
2

The VC will go down if the interface (in your case ge-2/1/5 goes down), so run show interfaces ge-2/1/5 and confirm the Last Flapped: time against your log entries.

Improve this answer
6
  • @BenjaminDale.I have already checked the attachment circuits at both ends of VPLS. The interface remains up (verified from interface flap date and also from log messages) while we still observe the PE route down message . In my case path is asymmetric i.e path from R1 to R2 (two VPLS endpoints) is different compared with in reverse direction.
    – Nabeel
    Commented May 16, 2019 at 6:19
  • @BenjaminDale.So is there possibility in the reverse direction i.e. from R2 to R1 there may some link flap due to which LDP reallocates label hence R1 when it receives new label it deletes the vpls connection associated with that label (top most label) and established new one.
    – Nabeel
    Commented May 16, 2019 at 6:19
  • @BenjaminDale.I have observed link flapping in reverse direction (from R2 to R1). This is just my thinking. Can you confirm that is this right?
    – Nabeel
    Commented May 16, 2019 at 6:22
  • I found answer to the question in 'MPLS Fundamentals' book by Luc De Ghein. When an LDP peer advertises a label binding, the receiving LDP peers keep it until the LDP session goes down or until the label is withdrawn. The label might be withdrawn if the local label changes. The local label might change if, for example, the interface with a certain prefix on it goes down, but another LSR still advertises the prefix. Therefore, the local label for that prefix changes from implicit NULL to a non-reserved label.
    – Nabeel
    Commented May 16, 2019 at 10:02
  • If this happens, the implicit NULL label is immediately withdrawn by sending a Label Withdraw message to the LDP peers. The new label is advertised in a Label Mapping message.
    – Nabeel
    Commented May 16, 2019 at 10:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.