[j-nsp] L2circuit martini issue....!

[Alex]

Fahad,
BFD probes directly connected IP neighbors (since it is run over IP) , in case of L2circuit it will be CE-CE.
803.2ah is scheduled in  future JUNOS releases, AFAIK.
I'm still not clear why you need to probe CE-PE link. If BFD/IP SLA probes would indicate CE-CE connectivity problem on IP level then surely the CE should be able to take a remedy action: switch to backup link/protect-interface which should be by that time enabled by PE.
Rgds
Alex
  ----- Original Message ----- 
  From: FAHAD ALI KHAN 
  To: Alex ; juniper-nsp 
  Sent: Thursday, January 25, 2007 4:24 AM
  Subject: Re: [j-nsp] L2circuit martini issue....!


  Alex.....Clear me in one thing....does BFD can probe L2circuit...and this probing is done from CE to PE?

  This is confusing. and if it can probe L2circuit.....L2circuit will remain UP...it didn't depend on the failure of Lastmile of client (when CE connects to FR Switch/L2 Switch and NNI/Trunk to PE) as i discuss in my previous mail. FR DLCI goes down but its FR-CCC link never. and this cause L2circuit to remain UP. 

  Also Does Juniper M10i/M7i/J-Series Routers supports Ethernet OAM (802.3ah)....if yes than sample configuration will be reuired....!

  Regards

  Fahad

   
  On 1/24/07, Alex <alex.arseniev at gmail.com> wrote: 
    Fahad,
    In absense of Ethernet OAM you can still use BFD/IP SLA to constantly probe the L2circuit and tear down IGP adjacencies/sink static routes/disable PBR.
    BTW, you can also use RPM+event/commit scripts on Junipe boxes to accomplish the same thing as Cisco IP SLA does.
    Cheers
    Alex

      ----- Original Message ----- 
      From: FAHAD ALI KHAN 
      To: Alex ; juniper-nsp 
      Sent: Wednesday, January 24, 2007 11:42 AM
      Subject: Re: [j-nsp] L2circuit martini issue....!

       
      Your understanding is correct but let me clear some background issues that i discuss few days ago......!

      Most of our client termination are in a manner that Ethernet clients are terminated over switch and than truncked to Juniper..and FR clients are terminated over NNI between FR switch and Juniper.,....and than they transported over Martini...but the issue is that..when the lastmile of client goes down....Juniper didnt down its CCC state....means....DLCI shows down but not FR-CCC similarly VLAN-CCC is not down. 

      here are the interface stats when Client lastmile goes down.....

      show interfaces ds-1/1/2:1.0 



       Logical interface ds-1/1/2:1.0 (Index 121) (SNMP ifIndex 156) 

          Description: *** Client X SITE B ***

          Flags: Point-To-Point SNMP-Traps Encapsulation: FR-CCC 

        Input packets : 47743200 

        Output packets: 43623195

          Protocol ccc, MTU: 1504

            Flags: None

          DLCI 152

            Flags: Down, DCE-Configured

            Total down time: 53:49:06 sec, Last down: 01:34:06 ago 

            Input packets : 47743200 

            Output packets: 43623195





      And DLCI flag DOWN will not cause FR-CCC to down.....and this will cause L2circuit to remain UP. and if the primary link FR-CCC is not down client cann't use the protected interface. 

        


      show l2circuit connections



      Neighbor: A.B.C.D

      Interface                 Type  St     Time last up          # Up trans

      ds-1/1/2:1.0{vc 152)      rmt   Up     Dec 26 08:32:09 2006           1

      Local interface: ds-1/1/2:1.0, Status: Up , Encapsulation: FRAME RELAY

      Remote PE: W.X.Y.Z, Negotiated control-word: Yes (Null)

      Incoming label: 102320, Outgoing label: 155888



      Similar is the case with VLAN transport over Martini....!



      And this is causing us alot of problem....!






      On 1/24/07, Alex <alex.arseniev at gmail.com > wrote: 
        Fahad,
        My understnding of "protect-interface" feature is that as long as Primary interface is UP then protect-interface is DOWN, the protect-interface is activated when Primary fails:
        "primary interface has priority over the protect interface and carries network traffic as long as it is functional. If the primary interface fails, the protect interface is activated"
        http://www.juniper.net/techpubs/software/junos/junos81/swconfig81-vpns/html/l2circuits-examples.html#1018999 
        Sort-of "backup-interface" in Cisco speak.
        So when PE-A client has 2 last-mile interfaces, one of then Primary and second one as protect-interface, then in normal conditions the Primary is UP and protect os DOWN. When primary fails and goes DOWN, protect is activated and goes UP. Client should be able to recognise the failure if it is DIRECTLY connected to PE-A and fail over the traffic to protect-interface. If there is a L2 switch in between then the whole process should be transparent to the client and it should not even notice the failover. 
        Is my understanding of your scenario correct?
        Cheers
        Alex
          ----- Original Message ----- 
          From: FAHAD ALI KHAN 
          To: Alex 
          Cc: juniper-nsp 
          Sent: Wednesday, January 24, 2007 10:16 AM
          Subject: Re: [j-nsp] L2circuit martini issue....!

           
          Well Alex it will help in CE-CE link tracking.....and PE will never know any thing.....!
          But consider a scenario, On PE-A clinet hav two last miles, one primary and other backup. We configure L2Circuit and set Pri lastmile as primary link and secondary lastmile as protected one (under the protocol l2circuit hierarchy). So If PE didnt know abt it and put down Primary link's CCC/TCC, client cannot use secondary Lastmile. 

          In this case use of every CE-CE link tracking methodologies will fail.....?

          Regards

          Fahad Ali Khan

           
          On 1/24/07, Alex <alex.arseniev at gmail.com > wrote: 
            Fahad,
            If you are looking for End-to-End failure detection for L2VPN where PE-CE links are Ethernet then You can do it either with BFD or IP SLA Cisco feature. Please be aware than BFD/IP SLA do not actually bring down the interface/subinterface, they either tear down IGP adjacencies (BFD), remove static routes (BFD/IP SLA) or disable PBR (IP SLA). 
            HTH
            Cheers
            Alex