Routing

hi experts

Can some one please explain to me in L2VPN

1-      how the L2VPN auto provision for the sites is work   in draft-kompella

2-      and what is the  “default site associations rule “  for the sites mapping ( without remote-site-id knob )

Thanks in advance

Hi,
    When you don't provide remote-site-id under L2VPN configs, the default behavior is to assign the remote-site-id as 1 and then increment by 1 accordingly based on the number of interfaces.

Let's say you network is as below and the requirement is to interconnect CE1, CE2 and CE3 (belonging to same VPN) in such a way that
IF1 connects to IF3
IF2 connects to IF4
                                                              IF3 +-----+
                                                              /---| CE2 |
                                                             /    +-----+
        +-----+   IF1    +-----+         (  )        +-----+/
        |     |----------|     |        (    )       |     |
        | CE1 |          | PE1 |-------( MPLS )------| PE2 |
        |     |----------|     |        (    )       |     |
        +-----+   IF2    +-----+         (  )        +-----+\
                                                             \    +-----+
                                                              \---| CE3 |
                                                             IF4  +-----+

In this case, on PE1 you assign a site-identifier as 1 for CE1 and include both the interface (in ascending order***) On PE2, you assign CE2 with site-identifer as 2 and CE3 with site-identifer as 3.

PE1:
====
routing-instances {
    VPNA {
        instance-type l2vpn;
        interface et-3/1/0.0;
        interface et-3/1/1.0;
        route-distinguisher 100:1;
        vrf-target target:100:100;
        protocols {
            l2vpn {
                encapsulation-type ethernet;
                site CE1 {
                    site-identifier 1;
                    interface et-3/1/1.0;   <<< IF1
                    interface et-3/1/0.0;   <<< IF2
                }
            }
        }
    }
}

PE2:
====
routing-instances {
    VPNA {
        instance-type l2vpn;
        interface xe-2/0/2.0;
        interface xe-2/0/3.0;
        route-distinguisher 100:3;
        vrf-target target:100:100;
        protocols {
            l2vpn {
                encapsulation-type ethernet;
                site CE2 {
                    site-identifier 2;
                    interface xe-2/0/3.0;      <<< IF3
                }
                site CE3 {
                    site-identifier 3;
                    interface xe-2/0/2.0;      <<< IF4
                }
            }
        }
    }
}

As you see in both PEs I have not configured remote-site-id. This is how it works.
When VPN signalling starts, PE1 takes the first interface (et-3/1/1) configured under the site CE1 stanza and starts with default remote-site-id which is 1.
Now since site-id 1 is local-site-identifer, it skips this value and increments by 1. This makes the expected remote-site-id as 2.
This matches with the CE2 site-id (IF3) and thus the l2vpn connection will come up. Now IF1 is connected to IF3

As PE1 moves to the next interface(et-3/1/0) under CE1, it is aware that site-id 1 and 2 are utilised for this VPN instance. It then picks up the next
available id which is 3, as the expected remote-site-id. Since this matches with CE3 site-id (IF4), the L2VPN would come up for this interface and connects IF3 and IF4

Just providing the show lvpn connection details for reference

[edit]
suryak@PE1# run show l2vpn connections
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 available
BK -- Backup connection          ST -- Standby connection
PF -- Profile parse failure      PB -- Profile busy
RS -- remote site standby        SN -- Static Neighbor

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

Instance: VPNA
  Local site: CE1 (1)
    connection-site           Type  St     Time last up          # Up trans
    2                         rmt   Up     May 24 00:07:25 2011           1
      Remote PE: 3.3.3.3, Negotiated control-word: Yes (Null)
      Incoming label: 800007, Outgoing label: 800004
      Local interface: et-3/1/1.0, Status: Up, Encapsulation: ETHERNET
    3                         rmt   Up     May 24 00:17:41 2011           1
      Remote PE: 3.3.3.3, Negotiated control-word: Yes (Null)
      Incoming label: 800008, Outgoing label: 800008
      Local interface: et-3/1/0.0, Status: Up, Encapsulation: ETHERNET



PE2:
====
[edit]
suryak@PE2# run show l2vpn connections
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
BK -- Backup connection          ST -- Standby connection
PF -- Profile parse failure      PB -- Profile busy
RS -- remote site standby        SN -- Static Neighbor

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

Instance: VPNA
  Local site: CE2 (2)
    connection-site           Type  St     Time last up          # Up trans
    CE3 (3)                   loc   OR  
    1                         rmt   Up     May 24 00:07:26 2011           1
      Remote PE: 1.1.1.1, Negotiated control-word: Yes (Null)
      Incoming label: 800004, Outgoing label: 800007
      Local interface: xe-2/0/3.0, Status: Up, Encapsulation: ETHERNET
  Local site: CE3 (3)
    connection-site           Type  St     Time last up          # Up trans
    CE2 (2)                   loc   OR  
    1                         rmt   Up     May 24 00:17:40 2011           1
      Remote PE: 1.1.1.1, Negotiated control-word: Yes (Null)
      Incoming label: 800008, Outgoing label: 800008
      Local interface: xe-2/0/2.0, Status: Up, Encapsulation: ETHERNET

Thank you surya

just more questions , how is the VPN out going labe is calculated from both of the PE , and base on what the site lable rage is calculated

Hi,

    The label is calculated based on the below formula:

L2VPN label = Label-Base(remote) + Site-Id(Local) – Label-Offset(remote)



With above topology as reference, let's look at the L2VPN NLRI advertised by PE2 to PE1:

suryak@PE1# run show route receive-protocol bgp 3.3.3.3 detail table VPNA.l2vpn.0

VPNA.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
*  100:3:2:1/96 (1 entry, 1 announced)
     Import Accepted
     Route Distinguisher: 100:3
     Label-base: 800000, range: 2, status-vector: 0x0
     Nexthop: 3.3.3.3
     Localpref: 100
     AS path: I
     Communities: target:100:100 Layer2-info: encaps:ETHERNET, control flags:Control-Word, mtu: 0, site preference: 100

*  100:3:3:1/96 (1 entry, 1 announced)
     Import Accepted
     Route Distinguisher: 100:3
     Label-base: 800002, range: 2, status-vector: 0x0
     Nexthop: 3.3.3.3
     Localpref: 100
     AS path: I
     Communities: target:100:100 Layer2-info: encaps:ETHERNET, control flags:Control-Word, mtu: 0, site preference: 100


100:3:2:1/96 translates to RD:Remote-Site-ID:Remote-Label-Offset


So for Remote-Site 2 PE2 has advertised the Label-Base=800000, RD=100:3 and  Label-Offset=1
Similarly for Remote-Site 3 the Label-Base=800002, RD=100:3 and Label-Offset=1

On PE1, IF1(1)-IF3(2) L2VPN connection would have VPN label = 800000 + 1 - 1 = 800000
        IF2(1)-IF4(3) L2VPN connection would have VPN LAbel = 800002 + 1 - 1 = 800002




Below is L2VPN NLRI advertised by PE1 to PE2:

suryak@PE2# run show route receive-protocol bgp 1.1.1.1 table VPNA detail

VPNA.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 100:1:1:1/96 (1 entry, 1 announced)
     Import Accepted
     Route Distinguisher: 100:1
     Label-base: 800000, range: 2, status-vector: 0x0
     Nexthop: 1.1.1.1
     Localpref: 100
     AS path: I
     Communities: target:100:100 Layer2-info: encaps:ETHERNET, control flags:Control-Word, mtu: 0, site preference: 100

* 100:1:1:3/96 (1 entry, 1 announced)
     Import Accepted
     Route Distinguisher: 100:1
     Label-base: 800002, range: 2, status-vector: 0x0
     Nexthop: 1.1.1.1
     Localpref: 100
     AS path: I
     Communities: target:100:100 Layer2-info: encaps:ETHERNET, control flags:Control-Word, mtu: 0, site preference: 100


On PE2, IF1(1)-IF3(2) L2VPN connection would have VPN label = 800000 + 2 - 1 = 800001
        IF2(1)-IF4(3) L2VPN connection would have VPN LAbel = 800002 + 3 - 3 = 800002



PE1:
====
suryak@PE1# run show l2vpn connections
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 available
BK -- Backup connection          ST -- Standby connection
PF -- Profile parse failure      PB -- Profile busy
RS -- remote site standby        SN -- Static Neighbor

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

Instance: VPNA
  Local site: CE1 (1)
    connection-site           Type  St     Time last up          # Up trans
    2                         rmt   Up     May 24 20:34:21 2011           1
      Remote PE: 3.3.3.3, Negotiated control-word: Yes (Null)
      Incoming label: 800001, Outgoing label: 800000
      Local interface: et-3/1/1.0, Status: Up, Encapsulation: ETHERNET
    3                         rmt   Up     May 24 20:34:19 2011           1
      Remote PE: 3.3.3.3, Negotiated control-word: Yes (Null)
      Incoming label: 800002, Outgoing label: 800002
      Local interface: et-3/1/0.0, Status: Up, Encapsulation: ETH


PE2:
====

suryak@PE2# run show l2vpn connections
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
BK -- Backup connection          ST -- Standby connection
PF -- Profile parse failure      PB -- Profile busy
RS -- remote site standby        SN -- Static Neighbor

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

Instance: VPNA
  Local site: CE2 (2)
    connection-site           Type  St     Time last up          # Up trans
    CE3 (3)                   loc   OR  
    1                         rmt   Up     May 24 20:34:22 2011           2
      Remote PE: 1.1.1.1, Negotiated control-word: Yes (Null)
      Incoming label: 800000, Outgoing label: 800001
      Local interface: xe-2/0/3.0, Status: Up, Encapsulation: ETHERNET
  Local site: CE3 (3)
    connection-site           Type  St     Time last up          # Up trans
    CE2 (2)                   loc   OR  
    1                         rmt   Up     May 24 20:34:19 2011           1
      Remote PE: 1.1.1.1, Negotiated control-word: Yes (Null)
      Incoming label: 800002, Outgoing label: 800002
      Local interface: xe-2/0/2.0, Status: Up, Encapsulation: ETHERNET



Hope this helps

Regards
Surya Prakash

Please aceept this Solution, if I have answered your query
If you like this, Kudos would be appreciated.

hi,

   my question is that where can find the "label-offset-remote"?

Hi,

You would find the answer in the above post. I am pasting the snippet here fyi... (look out for the last line)

Regards

Surya Prakash

I would like to make a correction to this post

The correct formula to calculate the inner MPLS label that will be used from a PE wanting to send L2 VPN information to a remote PE is:

L2VPN label = Site ID (local) - Label offset (remote) + Label base (remote)

Example

PEs R2 and R3 are connected over an MPLS network and their CEs (sites 2 and 3) want to communicate over a L2 VPN.

Topology

 R2 --- MPLS network --- R3

 |                        |

CE-X (SITE 2)            CE-Y (SITE 3)

site ID 2                Site ID 3

As you can see I have assigned a site ID of 2 for SITE 2 and a site ID of 3 for SITE 3.

>>> Lets calculate the label that R2 will push in order for Layer 2 VPN information from SITE 2 to reach SITE 3:

root@R2> show l2vpn connections extensive | match "Label-base|800"
    Label-base        Offset     Size  Range     Preference
    800004            3          2      1         100
      Incoming label: 800004, Outgoing label: 800001

root@R3> show l2vpn connections extensive | match "Label-base|800"
    Label-base        Offset     Size  Range     Preference
    800000            1          2      2         100
      Incoming label: 800001, Outgoing label: 800004

L2VPN label = Site ID (local) - Label offset (remote) + Label base (remote) = 2 (local site ID) - 1 (remote label offset) + 800000 (remote label base) = 800001

>>> Similarly for R3, in order for SITE 3 to reach SITE 2:

root@R2> show l2vpn connections extensive | match "Label-base|800"
    Label-base        Offset     Size  Range     Preference
    800004            3          2      1         100
      Incoming label: 800004, Outgoing label: 800001

root@R3> show l2vpn connections extensive | match "Label-base|800"
    Label-base        Offset     Size  Range     Preference
    800000            1          2      2         100
      Incoming label: 800001, Outgoing label: 800004

L2VPN label = Site ID (local) - Label offset (remote) + Label base (remote) = 3 (local site ID) - 3 (remote label offset) + 800004 (label base remote) = 800004

>>> Further verifications:

root@R2> show route table mpls.0
...
800004          *[L2VPN/7] 01:33:04  <- incoming label
                 > via ge-0/0/2.0, Pop       Offset: 4
ge-0/0/2.0      *[L2VPN/7] 01:33:04, metric2 1
                 > to 12.0.0.10 via ge-0/0/0.0, Push 800001, Push 299792(top) Offset: 252

                                                        |

                                                  outgoing label

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

My configuration:

root@R2# show routing-instances
vpn2 {
    instance-type l2vpn;
    interface ge-0/0/2.0;
    route-distinguisher 2:2;
    vrf-target target:2:3;
    protocols {
        l2vpn {
            encapsulation-type ethernet;
            site CE-R5 {
                site-identifier 2;
                interface ge-0/0/2.0 {
                    remote-site-id 3;
                }
            }
        }
    }
}

root@R3# show routing-instances
vpn3 {
    instance-type l2vpn;
    interface ge-0/0/2.0;
    route-distinguisher 3:3;
    vrf-target target:2:3;
    protocols {
        l2vpn {
            encapsulation-type ethernet;
            site CE-R4 {
                site-identifier 3;
                interface ge-0/0/2.0 {
                    remote-site-id 2;
                }
            }
        }
    }
}

root@R2# show interfaces ge-0/0/2
encapsulation ethernet-ccc;
unit 0;

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

By the way, can we set the label offset or label base values manually in a layer 2 vpn?

Kind Regards,

George Servetas

No Junos does not support manul configuration of label offset and label base values for BGP l2vpn and vpls

Thanks

Suresh

Hi George,

It took me few minutes of head-scratching to realise that your method is exactly the same as Surya's. The difference is that you're looking at the output of the "show l2vpn conn extensive" on the remote PE and look for label-base field there to calculate the outgoing label on the local PE, while Surya relied on the "show route receive-protocol bgp .." command on the local PE to do the same.

So there is no difference in formula here; Surya's method gets all info required for label calculation from one router rather than two in this example.

Thanks both Surya and George for your efforts.

Cheers,

Mina

Thanks Mina. Neither I do find the difference in formula 

 Surya = A + B - C

         L2VPN label = Label-Base(remote) + Site-Id(Local) – Label-Offset(remote)

George = B - C + A

         L2VPN label = Site ID (local) - Label offset (remote) + Label base (remote)

Regards

Surya

Would someone be kind enough to explain what's the role of 'offset' in Kompella VPN? I have a few questions about it:

      - what drives the selection of 'offset' on a PE. i.e. am I right in understanding that when the site-id on a PE is less than or equal to 8 label offset =1 when the site-id is between 9 and 16 label offset #2 and so forth?

    - why is it necessary to have this 'offset' number incorporated in label calculation formula? would the label mapping not work without offset and if so then why is that?

    - with or without the use of 'remote-site-id' is it possible to connect site 1 to site 9 (they are in two different label offsets in my understanding). I ask this since it does not satisfy the Kompella Draft stipulation LOm <= k < LOm + LRm (where m is site 1 and K is site 9 and LOm=1). what changes if 'remote-site-id' is used?

    - In what situations Label offset can be greater than remote site-ID and what is the implication?

thank you very much.

Hi

What is the encapsulation type in Kompella in dataplane? it uses its own or martini encapsulation?

I'm pretty sure that all l2vpn types use same forwarding/data plane encapsulation which is "Martini" RFC4448 encapsulation