[j-nsp] status-vector in VPLS?

Fri Aug 1 01:10:46 EDT 2008

Hi,

You should be able to see it in BGP Update Message, a sub-tlv under
MP_REACH_NLRI -> NLRI. I don't think that it is decoded in Wireshark or
Ethreal. But you should be able to see at the Hex decimal values by
clicking above & below the NLRI tlv, there must be some missing Hex
values which are not encoded & shown in the Packet stack tree. :-)

Thanks

Munish Saini

________________________________

From: Marlon Duksa [mailto:mduksa at gmail.com] 
Sent: Thursday, July 31, 2008 6:20 PM
To: Munish Saini
Cc: juniper-nsp at puck.nether.net
Subject: Re: status-vector in VPLS?

Great. Thanks. Munish.

I've never be able to observe this status vector in Wireshark and I
captured l2vpn BGP updates many times. Does  Wireshark (Ethereal)
encoder support this status vector? Is there any extension or update
that I need to apply to the Wireshark to be able to see a complete
MP_REACH_NLRI?

Marlon 

On Wed, Jul 30, 2008 at 10:16 PM, Munish Saini <msaini at ixiacom.com>
wrote:

Hi,

Status vector means Bit vector advertising the state of local PE-CE
circuits to remote PE routers. A bit value of 0 indicates that the local
circuit and LSP tunnel to the remote PE router are up, whereas a value
of 1 indicates either one or both are down.

It is basically Layer 2 VPN and VPLS network layer reachability
information (NLRI).

RFC CUT Section 5.1.7 of "draft-kompella-ppvpn-l2vpn-03.txt"

Circuit Status Vector

  A new sub-TLV is introduced to carry the status of an L2VPN PVC
  between a pair of PEs.  This sub-TLV is a mandatory part of
  MP_REACH_NLRI.

  Note that an L2VPN PVC is bidirectional, composed of two simplex
  connection going in opposite directions.  A simplex connection
  consists of the 3 segments: 1) the local access circuit between the
  source CE and the ingress PE, 2) the tunnel LSP between the ingress
  and egress PEs, and 3) the access circuit between the egress PE and
  the destination CE.

  To monitor the status of a PVC, a PE needs to monitor the status of
  both simplex connections.  Since it knows that status of its access
  circuit, and the status of the tunnel towards the remote PE, it can
  inform the remote PE of these two.  Similarly, the remote PE can
  inform the status of its access circuit to its local CE and the
  status of the tunnel to the first PE.  Combining the local and the
  remote information, a PE can determine the status of a PVC.

  The basic unit of advertisement in L2VPN for a given CE is a label-
  block.  Each label within a label-block corresponds to a PVC on the
  CE.  So its natural to advertise the local status information for all
  PVCs corresponding to a label-block along with the label-block's
  NLRI.  This is done by introducing the circuit status vector TLV.
  The value field of this TLV is a bit-vector, each bit of which
  indicates the status of the PVC associated with the corresponding
  label in the label-block.  Bit value 0 indicates that the local
  circuit and the tunnel LSP to the remote PE is up, while a value of 1
  indicates that either or both of them are down.

  PE A, while selecting a label from a label-block (advertised by PE B,
  for remote CE m, and VPN X) for one of its local CE n (in VPN X) can
  also determine the status of the corresponding PVC (between CE n and
  CE m) by looking at the appropriate bit in the circuit status vector.

  Type field for the circuit status vector TLV is TBD.

  The length field of the TLV specifies the length of the value field
  in bits.  The value field is padded to the nearest octet boundary.

  Note that the length field corresponds to the number of labels in the
  label-block, i.e., the label-block range.  Label-block range enables
  a CE to select a label block (among several label-blocks advertised
  by a CE) when picking the VPN label for sending traffic destined to
  the CE this label-block corresponds to, such that : received
label-block
  offset <= local CE id < received label-block range.

Thanks

Munish Saini

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of
juniper-nsp-request at puck.nether.net
Sent: Thursday, July 31, 2008 9:13 AM
To: juniper-nsp at puck.nether.net
Subject: juniper-nsp Digest, Vol 68, Issue 59

Send juniper-nsp mailing list submissions to
       juniper-nsp at puck.nether.net

To subscribe or unsubscribe via the World Wide Web, visit
       https://puck.nether.net/mailman/listinfo/juniper-nsp
or, via email, send a message with subject or body 'help' to
       juniper-nsp-request at puck.nether.net

You can reach the person managing the list at
       juniper-nsp-owner at puck.nether.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of juniper-nsp digest..."

Today's Topics:

  1. status-vector in VPLS? (Marlon Duksa)
  2. vpls remote mac learning on M20 on Junos 9.1? (Marlon Duksa)
  3. Re: vpls remote mac learning on M20 on Junos 9.1? (Harry Reynolds)
  4. Re: vpls remote mac learning on M20 on Junos 9.1? (Marlon Duksa)

----------------------------------------------------------------------

Message: 1
Date: Wed, 30 Jul 2008 14:53:52 -0700
From: "Marlon Duksa" <mduksa at gmail.com>
Subject: [j-nsp] status-vector in VPLS?
To: "juniper-nsp at puck.nether.net" <juniper-nsp at puck.nether.net>
Message-ID:
       <a89d89ac0807301453j107848a3x5644fceadf3b440c at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Does anyone know what this status-vector below in 'show vpla connections
extensice' mean? It is in bold red below.
How can it be interpreted?
Thanks

admin at re-0# run show vpls connections extensive
Layer-2 VPN connections:

Legend for connection status (St)
EI -- encapsulation invalid      NC -- interface encapsulation not
CCC/TCC/VPLS
EM -- encapsulation mismatch     WE -- interface and instance encaps not
same
VC-Dn -- Virtual circuit down    NP -- interface hardware not present
CM -- control-word mismatch      -> -- only outbound connection is up
CN -- circuit not provisioned    <- -- only inbound connection is up
OR -- out of range               Up -- operational
OL -- no outgoing label          Dn -- down
LD -- local site signaled down   CF -- call admission control failure
RD -- remote site signaled down  SC -- local and remote site ID
collision
LN -- local site not designated  LM -- local site ID not minimum
designated
RN -- remote site not designated RM -- remote site ID not minimum
designated
XX -- unknown connection status  IL -- no incoming label
MM -- MTU mismatch               MI -- Mesh-Group ID not availble

Legend for interface status
Up -- operational
Dn -- down

Instance: vpls
 Local site: green (2)
 Number of local interfaces: 2
 Number of local interfaces up: 2
 IRB interface present: no
   ge-5/0/0.0
   ge-5/0/0.1
   lsi.1048576         1         Intf - vpls vpls local site 2 remote
site
1
   lsi.1048577         3         Intf - vpls vpls local site 2 remote
site
3
         262145           1         8       100
   *status-vector: 5F *
   connection-site           Type  St     Time last up          # Up
trans
   1                         rmt   Up     Jul 30 21:40:47 2008
1
     Local interface: lsi.1048576, Status: Up, Encapsulation: VPLS
       Description: Intf - vpls vpls local site 2 remote site 1
     Remote PE: 1.1.1.1, Negotiated control-word: No
     Incoming label: 262145, Outgoing label: 262146

   Connection History:
       Jul 30 21:40:47 2008  status update timer
       Jul 30 21:40:47 2008  PE route changed
       Jul 30 21:40:47 2008  Out lbl Update                    262146
       Jul 30 21:40:47 2008  In lbl Update                     262145
       Jul 30 21:40:47 2008  loc intf up                  lsi.1048576

------------------------------