Load balancing VPLS traffic

Featured

Posted on by
Reply

In this post, we will demonstrate load balancing VPLS traffic using multiple LSP tunnels.

Topology

VPLS-VLAN-to-VLAN

Configuration


[edit]
lab@PE1# 

interfaces {

    ge-1/0/7 {
        description "LINK - PE2 ge-1/0/7";
        unit 0 {
            family inet {
                address 10.10.101.1/24;
            }
            family mpls;
        }
    }

    ge-1/1/7 {
        description "LINK - PE2 ge-1/1/7";
        unit 0 {
            family inet {
                address 10.10.102.1/24;
            }
            family mpls;
        }
    }

    ge-1/0/6 {
        vlan-tagging;
        encapsulation flexible-ethernet-services;
        /* VLPS Vlan */
        unit 600 {
            description "vpls interface to SW1";
            encapsulation vlan-vpls;
            vlan-id 600;                
            family vpls;
        }
    }
}

protocols {
    rsvp {
        load-balance bandwidth;
        interface all;
    }
    mpls {
        label-switched-path PE1-to-PE2-LSP1 {
            to 10.1.1.22;               
            bandwidth 200m;
            no-cspf;
            primary via-Ge1;
        }
        label-switched-path PE1-to-PE2-LSP2 {
            to 10.1.1.22;
            bandwidth 200m;
            no-cspf;
            primary via-Ge2;
        }
        path via-Ge1 {
            10.10.101.2;
        }
        path via-Ge2 {
            10.10.102.2;
        }
        interface ge-1/0/7.0;
        interface ge-1/1/7.0;
    }
    bgp {
        local-as 65000;
        group PEs {
            type internal;
            local-address 10.1.1.11;
            family inet {
                unicast;
            }
            family inet-vpn {
                unicast;
            }
            family l2vpn {
                signaling;
            }
            neighbor 10.1.1.22;
        }
    }
    ospf {
        traffic-engineering;
        area 0.0.0.0 {
            interface ge-1/0/7.0 {
                interface-type p2p;     
            }
            interface ge-1/1/7.0 {
                interface-type p2p;
            }
            interface lo0.0;
        }
    }
}

routing-instances {
    VPLS-1 {
        instance-type vpls;             
        interface ge-1/0/6.600;
        route-distinguisher 10.1.1.11:11;
        vrf-target target:65000:100;
        protocols {
            vpls {
                site-range 10;
                site Site1 {
                    site-identifier 1;
                }
            }
        }
    }
}

policy-options {
    policy-statement per-flow-load-balance {
        then {
            load-balance per-packet;
        }
    }
}

routing-options {
    forwarding-table {
        export per-flow-load-balance;
    }
}

Verification

Behaviour on different Junos version may be different. Note that on MX5, the load-balancing is supported under forwarding-options enhanced-hash-key configuration, rather than hash-key. In fact, we need to remove all the hash-key config, otherwise, the behaviour is not expected. By default load-balancing is already supported on MX5.

The following command is useful to confirm the hash key configuration:

lab@PE1> request pfe execute command "show jnh lb" target tfeb0 
SENT: Ukern command: show jnh lb
GOT:
GOT: Unilist Seed Configured 0x8bce4c39 System Mac address 00:00:00:00:00:00
GOT: Hash Key Configuration: 0x0000000000e00000 0xffffffffffffffff
GOT:            IIF-V4: No
GOT:          SPORT-V4: Yes
GOT:          DPORT-V4: Yes
GOT:               TOS: No
GOT:
GOT:            IIF-V6: No
GOT:          SPORT-V6: Yes
GOT:          DPORT-V6: Yes
GOT:     TRAFFIC_CLASS: No
GOT:
GOT:          IIF-MPLS: No
GOT:      MPLS_PAYLOAD: Yes
GOT:          MPLS_EXP: No
GOT:
GOT:       IIF-BRIDGED: No
GOT:     MAC ADDRESSES: Yes
GOT:     ETHER_PAYLOAD: Yes
GOT:      802.1P OUTER: No
GOT:
GOT: Services Hash Key Configuration:
GOT:          SADDR-V4: No
GOT:            IIF-V4: No
GOT:
LOCAL: End of file

lab@PE1> show mpls lsp statistics    
Ingress LSP: 3 sessions
To              From            State     Packets            Bytes LSPname
10.1.1.22       10.1.1.11       Up           1284           130968 PE1-to-PE2-LSP1
10.1.1.22       10.1.1.11       Up           1208           123216 PE1-to-PE2-LSP2
Total 3 displayed, Up 3, Down 0

Egress LSP: 3 sessions
To              From            State     Packets            Bytes LSPname
10.1.1.11       10.1.1.22       Up             NA               NA PE2-to-PE1-LSP1
10.1.1.11       10.1.1.22       Up             NA               NA PE2-to-PE1-LSP2
Total 3 displayed, Up 3, Down 0

Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

lab@PE1> monitor label-switched-path PE1-to-PE2-LSP2 

To 10.1.1.22, From 10.1.1.11, state: Up
  LSPname: PE1-to-PE2-LSP2, type: Ingress
  Label in: -, Label out: 3
  Port number: sender 4, receiver 7368, protocol 0
  Record Route:  10.10.102.2

  Traffic statistics:                      pps/bps
    Output packets:            38813             0
    Output bytes:            3958926             0

Tunnelling LDP over RSVP

Featured

Posted on by
Reply

Task

In this lab, we will demonstrate the configuration of tunnelling LDP over RSVP, and verification steps.

Topology

We use the standard topology (PE1, 6 x P routers and PE2). For simplicity, we only use the path between PE1 – P1 – P2 – P3 – PE2 by shutting down interfaces between PE1 and P4, and between P6 and PE2.

 

Configuration

The steps involved are:

On all P routers, we need Enable RSVP. We only need to enable interfaces between P routers. For convenience, it make no difference if we enable all interfaces because PE does not run RSVP.

p1@vr-device:p1> show configuration protocols rsvp 
interface all;

Enable ldp-tunneling for the RSVP LSP.

p1@vr-device:p1> show configuration protocols mpls 
no-cspf;
label-switched-path p1-to-p3 {
    from 192.168.5.1;
    to 192.168.5.3;
    ldp-tunneling;
}
interface all;

Enable LDP on interface(s) facing PE, AND the loopback address.

p1@vr-device:p1> show configuration protocols ldp 
interface em1.210;
interface lo0.1;

On PE router, we need to enable MPLS, and LDP on interfaces facing the P routers

 
lab@PE1> show configuration protocols mpls 
interface all;

lab@PE1> show configuration protocols ldp 
/* same as interface all */
interface em1.210;
interface em2.211;
interface lo0.0;

Verification

Verify LDP neighbor relationship on PE1

lab@PE1> show rsvp neighbor 
RSVP not configured

lab@PE1> show ldp neighbor 
Address            Interface          Label space ID         Hold time
172.22.210.2       em1.210            192.168.5.1:0            12

On P1, verify LDP neighbor relationship with PE1, and RSVP relationship with P2, and status of MPLS LSP

p1@vr-device:p1> show rsvp neighbor 
RSVP neighbor: 1 learned
Address            Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd
172.22.201.2         10  1/0       19:51        9   134/134  58

p1@vr-device:p1> show ldp neighbor 
Address            Interface          Label space ID         Hold time
192.168.5.3        lo0.1              192.168.5.3:0            41
172.22.210.1       em1.210            192.168.1.1:0            10

p1@vr-device:p1> show mpls lsp 
Ingress LSP: 1 sessions
To              From            State Rt P     ActivePath       LSPname
192.168.5.3     192.168.5.1     Up     0 *                      p1-to-p3
Total 1 displayed, Up 1, Down 0

Egress LSP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
192.168.5.1     192.168.5.3     Up       0  1 FF       3        - p3-to-p1
Total 1 displayed, Up 1, Down 0

Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

By default, only BGP traffic can use MPLS table to resolve the next hop. IGP can not. To be able to force tracing between PE1 and PE2 loopback via LSP path, we need to enable the following command.

lab@PE1# edit protocols mpls 
set traffic-engineering bgp-igp

Verify with ping and trace, and note the labels used by the packet. As P1 is the one that does the LDP over RSVP tunnelling, it does not only swap the incoming label 300912 with an outgoing label of 300704 (LDP LSP label) but also pushes another label of 300768 (RSVP LSP label) on top.

lab@PE1> traceroute 192.168.1.2 source 192.168.1.1 
traceroute to 192.168.1.2 (192.168.1.2) from 192.168.1.1, 30 hops max, 40 byte packets
 1  172.22.210.2 (172.22.210.2)  0.451 ms  0.328 ms  0.281 ms
     MPLS Label=300912 CoS=0 TTL=1 S=1
 2  172.22.201.2 (172.22.201.2)  0.448 ms  0.448 ms  0.496 ms
     MPLS Label=300768 CoS=0 TTL=1 S=0
     MPLS Label=300704 CoS=0 TTL=1 S=1
 3  172.22.206.2 (172.22.206.2)  0.634 ms  0.621 ms  0.808 ms
     MPLS Label=300704 CoS=0 TTL=1 S=1
 4  192.168.1.2 (192.168.1.2)  0.913 ms  0.898 ms  0.796 ms

lab@PE1> show route forwarding-table destination 192.168.1.2 
Routing table: default.inet
Internet:
Destination        Type RtRef Next hop           Type Index NhRef Netif
192.168.1.2/32     user     1 172.22.210.2      Push 300912   598     4 em1.210

p1@vr-device:p1> show route forwarding-table label 300912 
Logical system: p1
Routing table: default.mpls
MPLS:
Destination        Type RtRef Next hop           Type Index NhRef Netif
300912             user     0 172.22.201.2      Swap 300704, Push 300768(top)   974     2 em3.12

p2@vr-device:p2> show route forwarding-table label 300768 
Logical system: p2
Routing table: default.mpls
MPLS:
Destination        Type RtRef Next hop           Type Index NhRef Netif
300768             user     0 172.22.206.2      Pop     971     2 em3.23
300768(S=0)        user     0 172.22.206.2      Pop     972     2 em3.23

p3@vr-device:p3> show route forwarding-table label 300704 
Logical system: p3
Routing table: default.mpls
MPLS:
Destination        Type RtRef Next hop           Type Index NhRef Netif
300704             user     0 172.22.212.1      Pop     955     2 em2.212
300704(S=0)        user     0 172.22.212.1      Pop     956     2 em2.212

Verify that CE1 can ping CE2 and the path is via CE1 – PE1 – P1 – P2 – P3 – PE2. Note that in the trace output, we can not see the intermediate hops between PE1 and PE2 (i.e. P1, P2, P3) because these router do not run BGP and have no route back to the CE1.

lab@PE2> ping 192.168.11.1 source 192.168.11.2 routing-instance ce2 count 3    
PING 192.168.11.1 (192.168.11.1): 56 data bytes
64 bytes from 192.168.11.1: icmp_seq=0 ttl=59 time=1.694 ms
64 bytes from 192.168.11.1: icmp_seq=1 ttl=59 time=1.128 ms
64 bytes from 192.168.11.1: icmp_seq=2 ttl=59 time=1.106 ms

--- 192.168.11.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.106/1.309/1.694/0.272 ms

lab@PE2> trace 192.168.11.1 source 192.168.11.2 routing-instance ce2    
traceroute to 192.168.11.1 (192.168.11.1) from 192.168.11.2, 30 hops max, 40 byte packets
 1  10.0.11.1 (10.0.11.1)  0.969 ms  0.412 ms  0.471 ms
 2  * * *
 3  * * *
 4  * * *
 5  172.22.210.1 (172.22.210.1)  1.367 ms  1.358 ms  1.181 ms
 6  192.168.11.1 (192.168.11.1)  1.397 ms  1.468 ms  1.240 ms

Reference

http://www.juniper.net/techpubs/en_US/junos10.4/topics/example/vpn-ldp-over-rsvp-topology-configuring.html

MPLS LSP Protection Features

Featured

Posted on by
Reply

One of the key advantages of MPLS is the fast convergence after a link or node failure. In this post, I will go through various LSP protection features supported on Juniper router.

Secondary path protection

This following config creates a LSP path to 192.168.1.2 (other PE) that goes via first strict hop of 172.22.210.2 (the next hop have to be this IP), and via next loose hop of 192.168.5.6 (i.e. the path LSP takes travel via this loose hop, but this hop does not neccessarily follow immediately the previous strict hop). If this path is not available, LSP can go via a secondary path, which is any path.

lab@PE1# show 
label-switched-path pe1-to-pe2-1 {
    to 192.168.1.2;
    no-cspf;
    primary strict-first-hop;
    secondary any-path;
}
path strict-first-hop {
    172.22.210.2 strict;
    192.168.5.6 loose;
}
path any-path;

Verification

lab@PE1> show rsvp session ingress extensive    
Ingress RSVP: 1 sessions

192.168.1.2
  From: 192.168.1.1, LSPstate: Up, ActiveRoute: 0
  LSPname: pe1-to-pe2-1, LSPpath: Primary
  LSPtype: Static Configured
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 305376
  Resv style: 1 FF, Label in: -, Label out: 305376
  Time left:    -, Since: Mon Aug  6 18:16:45 2012
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 3 receiver 13826 protocol 0
  PATH rcvfrom: localclient 
  Adspec: sent MTU 1500
  Path MTU: received 1500
  PATH sentto: 172.22.210.2 (em1.210) 6 pkts
  RESV rcvfrom: 172.22.210.2 (em1.210) 6 pkts
  Explct route: 172.22.210.2 192.168.5.6 
  Record route: self 172.22.210.2 172.22.201.2 172.22.206.2 172.22.207.2 172.22.213.1  
Total 1 displayed, Up 1, Down 0

lab@PE1> show mpls lsp ingress extensive        
Ingress LSP: 1 sessions

192.168.1.2
  From: 192.168.1.1, State: Up, ActiveRoute: 0, LSPname: pe1-to-pe2-1
  ActivePath: strict-first-hop (primary)
  LSPtype: Static Configured
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary   strict-first-hop State: Up
    Priorities: 7 0
    SmartOptimizeTimer: 180
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          172.22.210.2 172.22.201.2 172.22.206.2 172.22.207.2 172.22.213.1
   15 Aug  6 18:16:45.128 Selected as active path
   14 Aug  6 18:16:45.126 Record Route:  172.22.210.2 172.22.201.2 172.22.206.2 172.22.207.2 172.22.213.1
   13 Aug  6 18:16:45.126 Up
   12 Aug  6 18:16:45.110 Originate Call
   11 Aug  6 18:16:45.109 Clear Call
   10 Aug  6 18:16:45.109 Deselected as active
    9 Aug  6 18:15:48.062 Selected as active path: due to 'primary'
    8 Aug  6 18:14:47.904 Record Route:  172.22.210.2 172.22.202.2 172.22.203.2 172.22.204.2 172.22.213.1
    7 Aug  6 18:14:47.904 Up
    6 Aug  6 18:14:47.896 ResvTear received
    5 Aug  6 18:14:47.896 172.22.210.1: Down
    4 Aug  6 18:14:45.946 Record Route:  172.22.210.2 172.22.202.2 172.22.203.2 172.22.204.2 172.22.207.1 172.22.212.1
    3 Aug  6 18:14:45.946 Up
    2 Aug  6 18:14:45.750 172.22.207.1: Routing loop detected
    1 Aug  6 18:14:45.741 Originate Call
  Secondary any-path         State: Dn
    Priorities: 7 0
    SmartOptimizeTimer: 180
   14 Aug  6 18:19:41.145 Clear Call
   13 Aug  6 18:19:40.483 Record Route:  172.22.211.2 172.22.203.2 172.22.204.2 172.22.213.1
   12 Aug  6 18:19:40.483 Up
   11 Aug  6 18:19:40.469 Originate Call
   10 Aug  6 18:19:40.467 Clear Call
    9 Aug  6 18:17:15.077 Record Route:  172.22.210.2 172.22.201.2 172.22.206.2 172.22.212.1
    8 Aug  6 18:17:15.077 Up
    7 Aug  6 18:17:15.062 Originate Call
    6 Aug  6 18:16:45.110 Clear Call
    5 Aug  6 18:15:48.062 Deselected as active: due to 'primary'
    4 Aug  6 18:14:45.930 Selected as active path
    3 Aug  6 18:14:45.928 Record Route:  172.22.210.2 172.22.201.2 172.22.206.2 172.22.212.1
    2 Aug  6 18:14:45.928 Up
    1 Aug  6 18:14:45.753 Originate Call
  Created: Mon Aug  6 18:14:45 2012
Total 1 displayed, Up 1, Down 0

In this config, the secondary path is not up. It is only signalled, after the primary path is down.

Secondary Standby protection

[edit protocols mpls]
lab@PE1# set label-switched-path pe1-to-pe2-1 secondary any-path standby

The full MPLS protocol config is

[edit protocols mpls]
lab@PE1# show                                                               
label-switched-path pe1-to-pe2-1 {
    to 192.168.1.2;
    no-cspf;
    primary strict-first-hop;
    secondary any-path {
        standby;
    }
}
path strict-first-hop {
    172.22.210.2 strict;
    192.168.5.6 loose;
}
path any-path;
interface em1.210;
interface em2.211;

Note that with this config, the Secondary LSP is also up even when the Primary is up, which will help with convergence.

lab@PE1> show rsvp session ingress extensive 
Ingress RSVP: 2 sessions

192.168.1.2
  From: 192.168.1.1, LSPstate: Up, ActiveRoute: 0
  LSPname: pe1-to-pe2-1, LSPpath: Primary
  LSPtype: Static Configured
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 305376
  Resv style: 1 FF, Label in: -, Label out: 305376
  Time left:    -, Since: Mon Aug  6 18:16:45 2012
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 3 receiver 13826 protocol 0
  PATH rcvfrom: localclient 
  Adspec: sent MTU 1500
  Path MTU: received 1500
  PATH sentto: 172.22.210.2 (em1.210) 23 pkts
  RESV rcvfrom: 172.22.210.2 (em1.210) 21 pkts
  Explct route: 172.22.210.2 192.168.5.6 
  Record route:  172.22.210.2 172.22.201.2 172.22.206.2 172.22.207.2 172.22.213.1  

192.168.1.2
  From: 192.168.1.1, LSPstate: Up, ActiveRoute: 0
  LSPname: pe1-to-pe2-1, LSPpath: Secondary
  LSPtype: Static Configured
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 305408
  Resv style: 1 FF, Label in: -, Label out: 305408
  Time left:    -, Since: Mon Aug  6 18:29:26 2012
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 6 receiver 13827 protocol 0
  PATH rcvfrom: localclient 
  Adspec: sent MTU 1500
  Path MTU: received 1500
  PATH sentto: 172.22.210.2 (em1.210) 4 pkts
  RESV rcvfrom: 172.22.210.2 (em1.210) 4 pkts
  Record route:  172.22.210.2 172.22.201.2 172.22.206.2 172.22.212.1  
Total 2 displayed, Up 2, Down 0

lab@PE1> show mpls lsp ingress extensive        
Ingress LSP: 1 sessions

192.168.1.2
  From: 192.168.1.1, State: Up, ActiveRoute: 0, LSPname: pe1-to-pe2-1
  ActivePath: strict-first-hop (primary)
  LSPtype: Static Configured
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary   strict-first-hop State: Up
    Priorities: 7 0
    SmartOptimizeTimer: 180
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          172.22.210.2 172.22.201.2 172.22.206.2 172.22.207.2 172.22.213.1
   15 Aug  6 18:16:45.128 Selected as active path
   14 Aug  6 18:16:45.126 Record Route:  172.22.210.2 172.22.201.2 172.22.206.2 172.22.207.2 172.22.213.1
   13 Aug  6 18:16:45.126 Up
   12 Aug  6 18:16:45.110 Originate Call
   11 Aug  6 18:16:45.109 Clear Call
   10 Aug  6 18:16:45.109 Deselected as active
    9 Aug  6 18:15:48.062 Selected as active path: due to 'primary'
    8 Aug  6 18:14:47.904 Record Route:  172.22.210.2 172.22.202.2 172.22.203.2 172.22.204.2 172.22.213.1
    7 Aug  6 18:14:47.904 Up
    6 Aug  6 18:14:47.896 ResvTear received
    5 Aug  6 18:14:47.896 172.22.210.1: Down
    4 Aug  6 18:14:45.946 Record Route:  172.22.210.2 172.22.202.2 172.22.203.2 172.22.204.2 172.22.207.1 172.22.212.1
    3 Aug  6 18:14:45.946 Up
    2 Aug  6 18:14:45.750 172.22.207.1: Routing loop detected
    1 Aug  6 18:14:45.741 Originate Call
  Standby   any-path         State: Up
    Priorities: 7 0
    SmartOptimizeTimer: 180
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          172.22.210.2 172.22.201.2 172.22.206.2 172.22.212.1
   17 Aug  6 18:29:26.285 Record Route:  172.22.210.2 172.22.201.2 172.22.206.2 172.22.212.1
   16 Aug  6 18:29:26.285 Up            
   15 Aug  6 18:29:26.270 Originate Call
   14 Aug  6 18:19:41.145 Clear Call
   13 Aug  6 18:19:40.483 Record Route:  172.22.211.2 172.22.203.2 172.22.204.2 172.22.213.1
   12 Aug  6 18:19:40.483 Up
   11 Aug  6 18:19:40.469 Originate Call
   10 Aug  6 18:19:40.467 Clear Call
    9 Aug  6 18:17:15.077 Record Route:  172.22.210.2 172.22.201.2 172.22.206.2 172.22.212.1
    8 Aug  6 18:17:15.077 Up
    7 Aug  6 18:17:15.062 Originate Call
    6 Aug  6 18:16:45.110 Clear Call
    5 Aug  6 18:15:48.062 Deselected as active: due to 'primary'
    4 Aug  6 18:14:45.930 Selected as active path
    3 Aug  6 18:14:45.928 Record Route:  172.22.210.2 172.22.201.2 172.22.206.2 172.22.212.1
    2 Aug  6 18:14:45.928 Up
    1 Aug  6 18:14:45.753 Originate Call
  Created: Mon Aug  6 18:14:45 2012
Total 1 displayed, Up 1, Down 0

Secondary/Secondary protection

With Primary/Secondary protection option, when the Primary is up after a failure, it resumes its primary role. This behaviour is similar to a Preempt option in HSRP. We can config LSP with 2 secondary path, without a Primary one. In this case, the LSP will not revert back to the first secondary, once it comes back from a failure.

Configuration is as follow:

[edit protocols mpls]
lab@PE1# show 
label-switched-path pe1-to-pe2-1 {
    to 192.168.1.2;
    no-cspf;
    secondary strict-first-hop;
    secondary any-path;
}
path strict-first-hop {
    172.22.210.2 strict;
    192.168.5.6 loose;
}
path any-path;
interface em1.210;
interface em2.211;

Fast-Reroute Protected LSP

Fast reroute attempt to protect the entire LSP. Every intermediate downstream router creates a backup detour path to the next downstream router. 

[edit protocols mpls]
lab@PE1# show 
no-cspf;
label-switched-path pe1-to-pe2-1 {
    to 192.168.1.2;
    no-cspf;
    fast-reroute;
    primary strict-first-hop;
}
path strict-first-hop {
    172.22.210.2 strict;
    192.168.5.6 loose;
}

lab@PE1> show rsvp session ingress extensive    
Ingress RSVP: 1 sessions

192.168.1.2
  From: 192.168.1.1, LSPstate: Up, ActiveRoute: 0
  LSPname: pe1-to-pe2-1, LSPpath: Primary
  LSPtype: Static Configured
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 305504
  Resv style: 1 FF, Label in: -, Label out: 305504
  Time left:    -, Since: Mon Aug  6 18:44:34 2012
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 8 receiver 13826 protocol 0
  FastReroute desired
  PATH rcvfrom: localclient 
  Adspec: sent MTU 1500
  Path MTU: received 1500
  PATH sentto: 172.22.210.2 (em1.210) 7 pkts
  RESV rcvfrom: 172.22.210.2 (em1.210) 10 pkts
  Explct route: 172.22.210.2 192.168.5.6 
  Record route: self 172.22.210.2 172.22.201.2 172.22.205.2 172.22.204.2 172.22.213.1  
    Detour is Up
    Detour Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
    Detour adspec: sent MTU 1500
    Path MTU: received 1500
    Detour PATH sentto: 172.22.211.2 (em2.211) 4 pkts
    Detour RESV rcvfrom: 172.22.211.2 (em2.211) 2 pkts
    Detour Explct route: 172.22.211.2 172.22.203.2 172.22.204.2 172.22.213.1 
    Detour Record route: self 172.22.211.2 172.22.203.2 172.22.204.2 172.22.213.1  
    Detour Label out: 305968
Total 1 displayed, Up 1, Down 0

Link Protected LSPs

While fast reroute attempts to protect the entire path of a given LSP, you can apply link protection on a per-interface basis as needed.

Configuration:

lab@PE1> show configuration protocols mpls 
no-cspf;
label-switched-path pe1-to-pe2-1 {
    to 192.168.1.2;
    no-cspf;
    link-protection;
    primary strict-first-hop;
}
path strict-first-hop {
    172.22.210.2 strict;
    192.168.5.6 loose;
}

Verification:

lab@PE1> show rsvp session ingress extensive 
Ingress RSVP: 2 sessions

192.168.1.2
  From: 192.168.1.1, LSPstate: Up, ActiveRoute: 0
  LSPname: pe1-to-pe2-1, LSPpath: Primary
  LSPtype: Static Configured
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 305520
  Resv style: 1 SE, Label in: -, Label out: 305520
  Time left:    -, Since: Mon Aug  6 18:47:35 2012
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 1 receiver 13829 protocol 0
  Link protection desired
  Type: Link protected LSP, using Bypass->172.22.210.2
      2 Aug  6 18:48:29 Link protection up, using Bypass->172.22.210.2
      1 Aug  6 18:47:44 New bypass Bypass->172.22.210.2
  PATH rcvfrom: localclient 
  Adspec: sent MTU 1500
  Path MTU: received 1500
  PATH sentto: 172.22.210.2 (em1.210) 6 pkts
  RESV rcvfrom: 172.22.210.2 (em1.210) 4 pkts
  Explct route: 172.22.210.2 192.168.5.6 
  Record route:  192.168.5.1 (node-id) 172.22.210.2 192.168.5.2 (node-id) 172.22.201.2 192.168.5.3 (node-id)
  172.22.206.2 192.168.5.6 (node-id) 172.22.207.2 192.168.1.2 (node-id) 172.22.213.1  

192.168.5.1
  From: 192.168.1.1, LSPstate: Up, ActiveRoute: 0
  LSPname: Bypass->172.22.210.2
  LSPtype: Static Configured
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 306016
  Resv style: 1 SE, Label in: -, Label out: 306016
  Time left:    -, Since: Mon Aug  6 18:47:46 2012
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 1 receiver 13830 protocol 0
  Type: Bypass LSP
    Number of data route tunnel through: 1
    Number of RSVP session tunnel through: 0
  PATH rcvfrom: localclient 
  Adspec: sent MTU 1500
  Path MTU: received 1500
  PATH sentto: 172.22.211.2 (em2.211) 4 pkts
  RESV rcvfrom: 172.22.211.2 (em2.211) 4 pkts
  Explct route: 172.22.211.2 172.22.202.1 
  Record route:  172.22.211.2 172.22.202.1  
Total 2 displayed, Up 2, Down 0

Node-Link Protected LSPs

Similarly to link protection, we can enable protection for a selected node rather than for an entire LSP. The ingress router will set up a bypass LSP around the first downstream node.

[edit protocols mpls]
lab@PE1# show 
no-cspf;
label-switched-path pe1-to-pe2-1 {
    to 192.168.1.2;
    no-cspf;
    node-link-protection;
    primary strict-first-hop;
}
path strict-first-hop {
    172.22.210.2 strict;
    192.168.5.6 loose;
}

Verification

lab@R1> show rsvp session ingress    
Ingress RSVP: 2 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
192.168.1.2     192.168.1.1     Up       0  1 SE       -   302912 pe1-to-pe2-1
192.168.5.4     192.168.1.1     Up       0  1 SE       -        3 Bypass->172.22.210.2->172.22.202.2
Total 2 displayed, Up 2, Down 0

lab@R1> show rsvp session ingress extensive 
Ingress RSVP: 2 sessions

192.168.1.2
  From: 192.168.1.1, LSPstate: Up, ActiveRoute: 0
  LSPname: pe1-to-pe2-1, LSPpath: Primary
  LSPtype: Static Configured
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 302912
  Resv style: 1 SE, Label in: -, Label out: 302912
  Time left:    -, Since: Thu Aug  9 02:24:34 2012
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 12 receiver 13924 protocol 0
  Node/Link protection desired
  Type: Node/Link protected LSP, using Bypass->172.22.210.2->172.22.202.2
      2 Aug  9 02:25:28 Node protection up, using Bypass->172.22.210.2->172.22.202.2
      1 Aug  9 02:24:43 New bypass Bypass->172.22.210.2
  PATH rcvfrom: localclient 
  Adspec: sent MTU 1500
  Path MTU: received 1500
  PATH sentto: 172.22.210.2 (em1.210) 14 pkts
  RESV rcvfrom: 172.22.210.2 (em1.210) 12 pkts
  Explct route: 172.22.210.2 192.168.5.6 
  Record route:  192.168.5.1 (node-id) 172.22.210.2 192.168.5.4 (node-id) 172.22.202.2
  192.168.5.5 (node-id) 172.22.203.2 192.168.5.6 (node-id) 172.22.204.2 192.168.1.2 (node-id) 172.22.213.1  

192.168.5.4
  From: 192.168.1.1, LSPstate: Up, ActiveRoute: 0
  LSPname: Bypass->172.22.210.2->172.22.202.2     <<<< This is node/link protection LSP
  LSPtype: Static Configured
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 3
  Resv style: 1 SE, Label in: -, Label out: 3
  Time left:    -, Since: Thu Aug  9 02:25:11 2012
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 1 receiver 13941 protocol 0
  Type: Bypass LSP                      
    Number of data route tunnel through: 1
    Number of RSVP session tunnel through: 0
  PATH rcvfrom: localclient 
  Adspec: sent MTU 1500
  Path MTU: received 1500
  PATH sentto: 172.22.211.2 (em2.211) 11 pkts
  RESV rcvfrom: 172.22.211.2 (em2.211) 11 pkts
  Explct route: 172.22.211.2 
  Record route:  172.22.211.2  
Total 2 displayed, Up 2, Down 0

These two RSVP sessions (primary and bypass) are permanently up in normal network condition.

Constrained Shortest Path First (CSPF)

Featured

Posted on by

In this lab, I will practice configuration and verification of a networking running Traffic Engineering with RSVP and CSPF.

Part 1: Basic routing verification, and enabling MPLS & RSVP

Bellow are various verification steps to confirm basic routing functionality before starting the RSVP, CSPF configuration.

OSPF between PE and the P routers:

lab@PE1> show ospf neighbor 
Address          Interface              State     ID               Pri  Dead
172.22.210.2     em1.210                Full      192.168.5.1      128    38
172.22.211.2     em2.211                Full      192.168.5.4      128    33

BGP between PE and the P routers:

lab@PE1> show bgp summary    
Groups: 3 Peers: 3 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0                 0          0          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.0.10.1             65512         34         33       0       7       14:06 Establ
  ce1.inet.0: 0/0/0/0
10.0.10.2             65101        991       1033       0       7       14:06 Establ
  inet.0: 0/0/0/0
192.168.1.2           65512        201        203       0       4     1:29:17 Establ
  inet.0: 0/0/0/0

Enabling MPLS family on core facing interfaces:

lab@PE1# show interfaces | display set | match mpls 
set interfaces em1 unit 210 family mpls
set interfaces em2 unit 211 family mpls

Configuring MPLS and RSVP protocol on core facing interfaces

lab@PE1# show | display set | match mpls      
set protocols mpls interface em1.210
set protocols mpls interface em2.211

[edit protocols]
lab@PE1# show | display set | match rsvp    
set protocols rsvp interface em1.210
set protocols rsvp interface em2.211

Quick verification

lab@PE1> show mpls interface 
Interface        State       Administrative groups (x: extended)
em1.210          Up         
em2.211          Up         

lab@PE1> show rsvp interface 
RSVP interface: 2 active
                  Active Subscr- Static      Available   Reserved    Highwater
Interface   State resv   iption  BW          BW          BW          mark
em1.210     Up         0   100%  1000Mbps    1000Mbps    0bps        0bps       
em2.211     Up         0   100%  1000Mbps    1000Mbps    0bps        0bps

Part 2: Enabling the TED

By default OSPF does not have Traffic Engineering Database (TED) enabled. In other words, the routers do not flood the Opaque LSAs. Note the default OSPF database:

lab@PE1> show ospf database 

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Router  *192.168.1.1      192.168.1.1      0x8000009f  1779  0x22 0x19ba  60
Router   192.168.1.2      192.168.1.2      0x80000098  1653  0x22 0xc10e  60
Router   192.168.5.1      192.168.5.1      0x800000cc  1785  0x22 0x6f10  72
Router   192.168.5.2      192.168.5.2      0x8000009f   248  0x22 0x1a91  72
Router   192.168.5.3      192.168.5.3      0x800000b3  1657  0x22 0x5e1b  72
Router   192.168.5.4      192.168.5.4      0x800000bc   217  0x22 0x82fc  72
Router   192.168.5.5      192.168.5.5      0x80000085  2236  0x22 0x2398  72
Router   192.168.5.6      192.168.5.6      0x800000b4  1653  0x22 0x5a16  72
Network  172.22.201.2     192.168.5.2      0x80000019   248  0x22 0xf151  32
Network  172.22.202.2     192.168.5.4      0x80000019  1415  0x22 0xee4f  32
Network  172.22.203.2     192.168.5.5      0x80000017  1242  0x22 0x1624  32
Network  172.22.204.2     192.168.5.6      0x80000018  1279  0x22 0x1b1a  32
Network  172.22.205.2     192.168.5.5      0x80000016   248  0x22 0xe555  32
Network  172.22.206.2     192.168.5.3      0x80000019  1147  0x22 0xcc6e  32
Network  172.22.207.2     192.168.5.6      0x8000001b   404  0x22 0xd759  32
Network  172.22.210.2     192.168.5.1      0x80000004  1785  0x22 0x80d4  32
Network  172.22.211.2     192.168.5.4      0x80000006  1780  0x22 0x7dce  32
Network  172.22.212.2     192.168.5.3      0x80000004  1657  0x22 0x80cd  32
Network  172.22.213.2     192.168.5.6      0x80000004  1653  0x22 0x81c5  32

Following command enable Traffic Engineering under OSPF protocol of PE, and P routers (same need to be applied on every routers).

lab@PE1# show | display set | match traffic-engineering 
set protocols ospf traffic-engineering

Note the new OpaqArea database

lab@PE1> show ospf database opaque-area 

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
OpaqArea*1.0.0.1          192.168.1.1      0x80000001   279  0x22 0xb0a7  28
OpaqArea 1.0.0.1          192.168.1.2      0x80000001   285  0x22 0xb4a1  28
OpaqArea 1.0.0.1          192.168.5.1      0x80000006   221  0x22 0xae9c  28
OpaqArea 1.0.0.1          192.168.5.2      0x80000005   226  0x22 0xb495  28
OpaqArea 1.0.0.1          192.168.5.3      0x80000004   224  0x22 0xba8e  28
OpaqArea 1.0.0.1          192.168.5.4      0x80000003   221  0x22 0xc087  28
OpaqArea 1.0.0.1          192.168.5.5      0x80000002   223  0x22 0xc680  28
OpaqArea 1.0.0.1          192.168.5.6      0x80000001   226  0x22 0xcc79  28
OpaqArea*1.0.0.3          192.168.1.1      0x80000005   207  0x22 0x34a  124
OpaqArea 1.0.0.3          192.168.1.2      0x80000005   220  0x22 0x61e6 124
OpaqArea 1.0.0.3          192.168.5.1      0x80000002   208  0x22 0xb40  124
OpaqArea 1.0.0.3          192.168.5.2      0x80000001   182  0x22 0x361d 124
OpaqArea 1.0.0.3          192.168.5.3      0x80000001   219  0x22 0x65e0 124
OpaqArea 1.0.0.3          192.168.5.4      0x80000001   181  0x22 0x7fd8 124
OpaqArea 1.0.0.3          192.168.5.5      0x80000001   182  0x22 0xaba9 124
OpaqArea 1.0.0.3          192.168.5.6      0x80000001   183  0x22 0x6edd 124
OpaqArea*1.0.0.4          192.168.1.1      0x80000006   216  0x22 0x2920 124
OpaqArea 1.0.0.4          192.168.1.2      0x80000005   224  0x22 0x89bb 124
OpaqArea 1.0.0.4          192.168.5.1      0x80000001   181  0x22 0x69f1 124
OpaqArea 1.0.0.4          192.168.5.2      0x80000001   182  0x22 0x4f0c 124
OpaqArea 1.0.0.4          192.168.5.3      0x80000001   184  0x22 0x58f6 124
OpaqArea 1.0.0.4          192.168.5.4      0x80000001   181  0x22 0x89cc 124
OpaqArea 1.0.0.4          192.168.5.5      0x80000001   182  0x22 0x64a  124
OpaqArea 1.0.0.4          192.168.5.6      0x80000001   225  0x22 0x7bc4 124
OpaqArea 1.0.0.5          192.168.5.1      0x80000001   181  0x22 0x2d2f 124
OpaqArea 1.0.0.5          192.168.5.2      0x80000001   182  0x22 0xef63 124
OpaqArea 1.0.0.5          192.168.5.3      0x80000001   184  0x22 0x3a15 124
OpaqArea 1.0.0.5          192.168.5.4      0x80000001   217  0x22 0x192c 124
OpaqArea 1.0.0.5          192.168.5.5      0x80000001   182  0x22 0xaba6 124
OpaqArea 1.0.0.5          192.168.5.6      0x80000001   183  0x22 0xc38c 124

lab@PE1> show ted database 
TED database: 0 ISIS nodes 19 INET nodes
ID                            Type Age(s) LnkIn LnkOut Protocol
192.168.1.1                   Rtr     256     2      2 OSPF(0.0.0.0)
    To: 172.22.211.1-1, Local: 172.22.211.1, Remote: 0.0.0.0
      Local interface index: 0, Remote interface index: 0
    To: 172.22.210.1-1, Local: 172.22.210.1, Remote: 0.0.0.0
      Local interface index: 0, Remote interface index: 0
ID                            Type Age(s) LnkIn LnkOut Protocol
192.168.5.1                   Rtr     229     3      3 OSPF(0.0.0.0)
    To: 172.22.210.1-1, Local: 172.22.210.2, Remote: 0.0.0.0
      Local interface index: 0, Remote interface index: 0
    To: 172.22.202.2-1, Local: 172.22.202.1, Remote: 0.0.0.0
      Local interface index: 0, Remote interface index: 0
    To: 172.22.201.2-1, Local: 172.22.201.1, Remote: 0.0.0.0
      Local interface index: 0, Remote interface index: 0
ID                            Type Age(s) LnkIn LnkOut Protocol
172.22.210.1-1                Net     256     2      2 OSPF(0.0.0.0)
    To: 192.168.5.1, Local: 0.0.0.0, Remote: 0.0.0.0
      Local interface index: 0, Remote interface index: 0
    To: 192.168.1.1, Local: 0.0.0.0, Remote: 0.0.0.0
      Local interface index: 0, Remote interface index: 0

...

Note that by default, NO Color (administrative groups) is assigned to any links. This could be seen reflected in the TE database:

lab@PE1> show ted database 192.168.1.1 extensive 
TED database: 0 ISIS nodes 19 INET nodes
NodeID: 192.168.1.1
  Type: Rtr, Age: 525 secs, LinkIn: 2, LinkOut: 2
  Protocol: OSPF(0.0.0.0)
    To: 172.22.211.1-1, Local: 172.22.211.1, Remote: 0.0.0.0
      Local interface index: 0, Remote interface index: 0
      Color: 0 
      Metric: 1
      Static BW: 1000Mbps
      Reservable BW: 1000Mbps
      Available BW [priority] bps:
          [0] 1000Mbps     [1] 1000Mbps    [2] 1000Mbps    [3] 1000Mbps    
          [4] 1000Mbps     [5] 1000Mbps    [6] 1000Mbps    [7] 1000Mbps    
      Interface Switching Capability Descriptor(1):
        Switching type: Packet
        Encoding type: Packet
        Maximum LSP BW [priority] bps:
          [0] 1000Mbps     [1] 1000Mbps    [2] 1000Mbps    [3] 1000Mbps    
          [4] 1000Mbps     [5] 1000Mbps    [6] 1000Mbps    [7] 1000Mbps    
    To: 172.22.210.1-1, Local: 172.22.210.1, Remote: 0.0.0.0
      Local interface index: 0, Remote interface index: 0
      Color: 0 
      Metric: 1
      Static BW: 1000Mbps
      Reservable BW: 1000Mbps
      Available BW [priority] bps:
          [0] 1000Mbps     [1] 1000Mbps    [2] 1000Mbps    [3] 1000Mbps    
          [4] 1000Mbps     [5] 1000Mbps    [6] 1000Mbps    [7] 1000Mbps    
      Interface Switching Capability Descriptor(1):
        Switching type: Packet
        Encoding type: Packet
        Maximum LSP BW [priority] bps:
          [0] 1000Mbps     [1] 1000Mbps    [2] 1000Mbps    [3] 1000Mbps    
          [4] 1000Mbps     [5] 1000Mbps    [6] 1000Mbps    [7] 1000Mbps

Part 3: Configuring RSVP-Signaled LSPs

[edit protocols mpls]
lab@PE1# show | display set 
# Configure a loose path option
set protocols mpls path loose-via-p2 192.168.5.2 loose

# Configure LSPs
set protocols mpls label-switched-path lsp-gold-pe1-to-pe2-1 to 192.168.1.2
set protocols mpls label-switched-path lsp-gold-pe1-to-pe2-1 primary loose-via-p2
set protocols mpls label-switched-path lsp-silver-pe1-to-pe2-1 to 192.168.1.2
set protocols mpls label-switched-path lsp-silver-pe1-to-pe2-1 primary loose-via-p2
set protocols mpls label-switched-path lsp-bronze-pe1-to-pe2-1 to 192.168.1.2
set protocols mpls label-switched-path lsp-bronze-pe1-to-pe2-1 primary loose-via-p2

LSP Verification

lab@PE1> show rsvp session 
Ingress RSVP: 3 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
192.168.1.2     192.168.1.1     Up       0  1 FF       -   300160 lsp-gold-pe1-to-pe2-1
192.168.1.2     192.168.1.1     Up       0  1 FF       -   300176 lsp-bronze-pe1-to-pe2-1
192.168.1.2     192.168.1.1     Up       0  1 FF       -   300192 lsp-silver-pe1-to-pe2-1
Total 3 displayed, Up 3, Down 0

Egress RSVP: 3 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
192.168.1.1     192.168.1.2     Up       0  1 FF       3        - lsp-bronze-pe2-to-pe1-1
192.168.1.1     192.168.1.2     Up       0  1 FF       3        - lsp-gold-pe2-to-pe1-1
192.168.1.1     192.168.1.2     Up       0  1 FF       3        - lsp-silver-pe2-to-pe1-1
Total 3 displayed, Up 3, Down 0

Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

lab@PE1> show rsvp session extensive 
Ingress RSVP: 3 sessions

192.168.1.2
  From: 192.168.1.1, LSPstate: Up, ActiveRoute: 0
  LSPname: lsp-gold-pe1-to-pe2-1, LSPpath: Primary
  LSPtype: Static Configured
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 300160
  Resv style: 1 FF, Label in: -, Label out: 300160
  Time left:    -, Since: Sat Aug  4 18:16:55 2012
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 1 receiver 13800 protocol 0
  PATH rcvfrom: localclient 
  Adspec: sent MTU 1500
  Path MTU: received 1500
  PATH sentto: 172.22.210.2 (em1.210) 21 pkts
  RESV rcvfrom: 172.22.210.2 (em1.210) 20 pkts
  Explct route: 172.22.210.2 172.22.201.2 172.22.206.2 172.22.212.1 
  Record route:  172.22.210.2 172.22.201.2 172.22.206.2 172.22.212.1  

192.168.1.2
  From: 192.168.1.1, LSPstate: Up, ActiveRoute: 0
  LSPname: lsp-bronze-pe1-to-pe2-1, LSPpath: Primary
  LSPtype: Static Configured
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 300176
  Resv style: 1 FF, Label in: -, Label out: 300176
  Time left:    -, Since: Sat Aug  4 18:25:38 2012
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 1 receiver 13803 protocol 0
  PATH rcvfrom: localclient 
  Adspec: sent MTU 1500
  Path MTU: received 1500
---(more)---

Part4: Adding Administrative Groups (Colors) to the core facing interfaces

[edit protocols mpls]
lab@PE1# show | display set | match admin 
set protocols mpls admin-groups gold 1
set protocols mpls admin-groups silver 2
set protocols mpls admin-groups bronze 3

set protocols mpls interface em1.210 admin-group silver
set protocols mpls interface em1.210 admin-group bronze
set protocols mpls interface em2.211 admin-group gold

lab@PE1> show mpls interface  
Interface        State       Administrative groups (x: extended)
em1.210          Up          bronze
                             silver
em2.211          Up          gold

lab@PE2> show ted database 192.168.1.1 extensive    
TED database: 0 ISIS nodes 19 INET nodes
NodeID: 192.168.1.1
  Type: Rtr, Age: 234 secs, LinkIn: 2, LinkOut: 2
  Protocol: OSPF(0.0.0.0)
    To: 172.22.210.1-1, Local: 172.22.210.1, Remote: 0.0.0.0
      Local interface index: 0, Remote interface index: 0
      Color: 0xc bronze silver
      Metric: 1
      Static BW: 1000Mbps
      Reservable BW: 1000Mbps
      Available BW [priority] bps:
          [0] 1000Mbps     [1] 1000Mbps    [2] 1000Mbps    [3] 1000Mbps    
          [4] 1000Mbps     [5] 1000Mbps    [6] 1000Mbps    [7] 1000Mbps    
      Interface Switching Capability Descriptor(1):
        Switching type: Packet
        Encoding type: Packet
        Maximum LSP BW [priority] bps:
          [0] 1000Mbps     [1] 1000Mbps    [2] 1000Mbps    [3] 1000Mbps    
          [4] 1000Mbps     [5] 1000Mbps    [6] 1000Mbps    [7] 1000Mbps    
    To: 172.22.211.1-1, Local: 172.22.211.1, Remote: 0.0.0.0
      Local interface index: 0, Remote interface index: 0
      Color: 0x2 gold
      Metric: 1
      Static BW: 1000Mbps
      Reservable BW: 1000Mbps
      Available BW [priority] bps:
          [0] 1000Mbps     [1] 1000Mbps    [2] 1000Mbps    [3] 1000Mbps    
          [4] 1000Mbps     [5] 1000Mbps    [6] 1000Mbps    [7] 1000Mbps    
      Interface Switching Capability Descriptor(1):
        Switching type: Packet
        Encoding type: Packet
        Maximum LSP BW [priority] bps:
          [0] 1000Mbps     [1] 1000Mbps    [2] 1000Mbps    [3] 1000Mbps    
---(more)---

Similarly, we  need to assign administrative colours to all interfaces of the P routers.

Below is the TED database for P2 router, which show all its connected interfaces and the administrative colours:

lab@PE1> show ted database 192.168.5.2 extensive | no-more 
TED database: 0 ISIS nodes 19 INET nodes
NodeID: 192.168.5.2
  Type: Rtr, Age: 114 secs, LinkIn: 3, LinkOut: 3
  Protocol: OSPF(0.0.0.0)
    To: 172.22.201.2-1, Local: 172.22.201.2, Remote: 0.0.0.0
      Local interface index: 0, Remote interface index: 0
      Color: 0xa bronze gold
      Metric: 1
      Static BW: 1000Mbps
      Reservable BW: 1000Mbps
      Available BW [priority] bps:
          [0] 1000Mbps     [1] 1000Mbps    [2] 1000Mbps    [3] 1000Mbps    
          [4] 1000Mbps     [5] 1000Mbps    [6] 1000Mbps    [7] 1000Mbps    
      Interface Switching Capability Descriptor(1):
        Switching type: Packet
        Encoding type: Packet
        Maximum LSP BW [priority] bps:
          [0] 1000Mbps     [1] 1000Mbps    [2] 1000Mbps    [3] 1000Mbps    
          [4] 1000Mbps     [5] 1000Mbps    [6] 1000Mbps    [7] 1000Mbps    
    To: 172.22.206.2-1, Local: 172.22.206.1, Remote: 0.0.0.0
      Local interface index: 0, Remote interface index: 0
      Color: 0x4 silver
      Metric: 1
      Static BW: 1000Mbps
      Reservable BW: 1000Mbps
      Available BW [priority] bps:
          [0] 1000Mbps     [1] 1000Mbps    [2] 1000Mbps    [3] 1000Mbps    
          [4] 1000Mbps     [5] 1000Mbps    [6] 1000Mbps    [7] 1000Mbps    
      Interface Switching Capability Descriptor(1):
        Switching type: Packet
        Encoding type: Packet
        Maximum LSP BW [priority] bps:
          [0] 1000Mbps     [1] 1000Mbps    [2] 1000Mbps    [3] 1000Mbps    
          [4] 1000Mbps     [5] 1000Mbps    [6] 1000Mbps    [7] 1000Mbps    
    To: 172.22.205.2-1, Local: 172.22.205.1, Remote: 0.0.0.0
      Local interface index: 0, Remote interface index: 0
      Color: 0xe bronze silver gold
      Metric: 1
      Static BW: 1000Mbps
      Reservable BW: 1000Mbps
      Available BW [priority] bps:
          [0] 1000Mbps     [1] 1000Mbps    [2] 1000Mbps    [3] 1000Mbps    
          [4] 1000Mbps     [5] 1000Mbps    [6] 1000Mbps    [7] 1000Mbps    
      Interface Switching Capability Descriptor(1):
        Switching type: Packet
        Encoding type: Packet
        Maximum LSP BW [priority] bps:
          [0] 1000Mbps     [1] 1000Mbps    [2] 1000Mbps    [3] 1000Mbps    
          [4] 1000Mbps     [5] 1000Mbps    [6] 1000Mbps    [7] 1000Mbps

Part 5: Configuring LSPs to take Gold, Silver, and Bronze paths using CSPF

[edit protocols mpls]
set label-switched-path lsp-gold-pe1-to-pe2-1 admin-group include-any gold    
set label-switched-path lsp-silver-pe1-to-pe2-1 admin-group include-any silver
set label-switched-path lsp-bronze-pe1-to-pe2-1 admin-group include-any bronze

Verification

lab@PE1> show rsvp session                                         
Ingress RSVP: 3 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
192.168.1.2     192.168.1.1     Up       0  1 FF       -   301648 lsp-bronze-pe1-to-pe2-1
192.168.1.2     192.168.1.1     Up       0  1 FF       -   300976 lsp-gold-pe1-to-pe2-1
192.168.1.2     192.168.1.1     Up       0  1 FF       -   301680 lsp-silver-pe1-to-pe2-1
Total 3 displayed, Up 3, Down 0

Egress RSVP: 3 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
192.168.1.1     192.168.1.2     Up       0  1 FF       3        - lsp-bronze-pe2-to-pe1-1
192.168.1.1     192.168.1.2     Up       0  1 FF       3        - lsp-gold-pe2-to-pe1-1
192.168.1.1     192.168.1.2     Up       0  1 FF       3        - lsp-silver-pe2-to-pe1-1
Total 3 displayed, Up 3, Down 0

Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

lab@PE1> show rsvp session name lsp-gold-pe1-to-pe2-1 detail    
Ingress RSVP: 3 sessions

192.168.1.2
  From: 192.168.1.1, LSPstate: Up, ActiveRoute: 0
  LSPname: lsp-gold-pe1-to-pe2-1, LSPpath: Primary
  LSPtype: Static Configured
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 300976
  Resv style: 1 FF, Label in: -, Label out: 300976
  Time left:    -, Since: Sun Aug  5 03:37:12 2012
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 1 receiver 13808 protocol 0
  PATH rcvfrom: localclient 
  Adspec: sent MTU 1500
  Path MTU: received 1500
  PATH sentto: 172.22.211.2 (em2.211) 13 pkts
  RESV rcvfrom: 172.22.211.2 (em2.211) 13 pkts
  Explct route: 172.22.211.2 172.22.202.1 172.22.201.2 172.22.205.2 172.22.204.2 172.22.213.1 
  Record route:  self 172.22.211.2 172.22.202.1 172.22.201.2 172.22.205.2 172.22.204.2 172.22.213.1  
Total 1 displayed, Up 1, Down 0

Egress RSVP: 3 sessions
Total 0 displayed, Up 0, Down 0

Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

lab@PE1> show mpls lsp name lsp-gold-pe1-to-pe2-1 extensive 
Ingress LSP: 3 sessions

192.168.1.2
  From: 192.168.1.1, State: Up, ActiveRoute: 0, LSPname: lsp-gold-pe1-to-pe2-1
  ActivePath: loose-via-p2 (primary)
  LSPtype: Static Configured
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary   loose-via-p2     State: Up
    Priorities: 7 0
    SmartOptimizeTimer: 180
          Include Any: gold
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 6)
 172.22.211.2 S 172.22.202.1 S 172.22.201.2 S 172.22.205.2 S 172.22.204.2 S 172.22.213.1 S 
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          172.22.211.2 172.22.202.1 172.22.201.2 172.22.205.2 172.22.204.2 172.22.213.1
    5 Aug  5 03:37:12.846 Selected as active path
    4 Aug  5 03:37:12.845 Record Route:  172.22.211.2 172.22.202.1 172.22.201.2 172.22.205.2 172.22.204.2 172.22.213.1
    3 Aug  5 03:37:12.845 Up
    2 Aug  5 03:37:12.721 Originate Call
    1 Aug  5 03:37:12.721 CSPF: computation result accepted  172.22.211.2 172.22.202.1 172.22.201.2 172.22.205.2 172.22.204.2 172.22.213.1
  Created: Sun Aug  5 03:37:12 2012
Total 1 displayed, Up 1, Down 0

Egress LSP: 3 sessions
Total 0 displayed, Up 0, Down 0

Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Note that the LSP path traverses via all routers along the Gold colour path, including P2. This satisfies the 2 constrained requirements:

  • Gold colour (an administrative attribute) and
  • Loose path via P2

Using RPM to generate traffic on a Junos device

Posted on by
Reply

RPM (Realtime Probe Monitoring) on a Junos device (similar to IP SLA feature on IOS) is used to monitor network performance between the two end points in a network. In a lab environment, we can use this feature to generate “real” traffic for testing QoS, or security policies, without having to have a real traffic generator, which is very handy. RPM can generate TCP and UDP traffic, in addition to ICMP (which can be easily done with the ping command.

The following are config to simulate ICMP/UDP/TCP traffic from R1 (simulating a Client machine) to R2 (Server).

Configuration

lab@R1> show configuration services   
rpm {
    probe ICMP_Probe {
        test Generate_ICMP_Ping {
            probe-type icmp-ping;
            target address 2.2.2.2;
            probe-count 10;
            probe-interval 1;
            test-interval 1;
            source-address 1.1.1.1;
            dscp-code-points cs1;
            data-size 100;
        }
    }
    probe IP_Phone {
        test Voice_RTP {
            probe-type udp-ping;
            target address 100.1.2.3;
            probe-count 10;
            probe-interval 1;
            test-interval 1;
            destination-port 51000;
            source-address 100.1.1.1;
            dscp-code-points ef;
            data-size 100;
        }
    }
    probe TCP_Probe {
        test Generate_TCP_Ping {
            probe-type tcp-ping;
            target address 2.2.2.2;
            probe-count 10;
            probe-interval 1;
            test-interval 1;
            destination-port 50000;
            source-address 1.1.1.1;
            dscp-code-points be;
            data-size 100;
        }
    }                                   
    probe-limit 500;                    
} 


lab@R2> show configuration services 
rpm {
    probe-server {
        tcp {
            port 50000;
            # destination-interface lo0.0;
        }
        udp {
            port 51000;
            # destination-interface ge-0/0/1.0;
        }
    }
}

Verification

lab@R1> show services rpm probe-results 
 Owner: IP_Phone, Test: Voice_RTP
 Target address: 100.1.2.3, Source address: 100.1.1.1, Probe type: udp-ping, Test size: 10 probes
 Probe results:
 Response received, Sat Aug 9 20:41:56 2014, No hardware timestamps
 Rtt: 2593 usec
 Results over current test:
 Probes sent: 7, Probes received: 7, Loss percentage: 0
 Measurement: Round trip time
 Samples: 7, Minimum: 666 usec, Maximum: 4624 usec, Average: 3008 usec, Peak to peak: 3958 usec, Stddev: 1370 usec,
 Sum: 21053 usec
 Results over last test:
 Probes sent: 10, Probes received: 10, Loss percentage: 0
 Test completed on Sat Aug 9 20:41:49 2014
 Measurement: Round trip time
 Samples: 10, Minimum: 623 usec, Maximum: 4110 usec, Average: 1485 usec, Peak to peak: 3487 usec, Stddev: 1156 usec,
 Sum: 14846 usec
 Results over all tests:
 Probes sent: 107, Probes received: 107, Loss percentage: 0
 Measurement: Round trip time
 Samples: 107, Minimum: 422 usec, Maximum: 4684 usec, Average: 1019 usec, Peak to peak: 4262 usec, Stddev: 981 usec,
 Sum: 109060 usec

 Owner: TCP_Probe, Test: Generate_TCP_Ping
 Target address: 2.2.2.2, Source address: 1.1.1.1, Probe type: tcp-ping, Test size: 10 probes
 Probe results:
 Response received, Sat Aug 9 20:41:55 2014
 Rtt: 940 usec
 Results over current test:
 Probes sent: 6, Probes received: 6, Loss percentage: 0
 Measurement: Round trip time
 Samples: 6, Minimum: 940 usec, Maximum: 1153 usec, Average: 1053 usec, Peak to peak: 213 usec, Stddev: 65 usec,
 Sum: 6318 usec 
 Results over last test:
 Probes sent: 10, Probes received: 10, Loss percentage: 0
 Test completed on Sat Aug 9 20:41:49 2014
 Measurement: Round trip time
 Samples: 10, Minimum: 952 usec, Maximum: 1179 usec, Average: 1044 usec, Peak to peak: 227 usec, Stddev: 72 usec,
 Sum: 10444 usec
 Results over all tests:
 Probes sent: 106, Probes received: 106, Loss percentage: 0
 Measurement: Round trip time
 Samples: 106, Minimum: 762 usec, Maximum: 1803 usec, Average: 1039 usec, Peak to peak: 1041 usec, Stddev: 134 usec,
 Sum: 110160 usec

 Owner: ICMP_Probe, Test: Generate_ICMP_Ping
 Target address: 2.2.2.2, Source address: 1.1.1.1, Probe type: icmp-ping, Test size: 10 probes
 Probe results:
 Response received, Sat Aug 9 20:41:56 2014, No hardware timestamps
 Rtt: 449 usec
 Results over current test:
 Probes sent: 7, Probes received: 7, Loss percentage: 0
 Measurement: Round trip time
 Samples: 7, Minimum: 360 usec, Maximum: 449 usec, Average: 401 usec, Peak to peak: 89 usec, Stddev: 33 usec, Sum: 2810 usec
 Results over last test:
 Probes sent: 10, Probes received: 10, Loss percentage: 0
 Test completed on Sat Aug 9 20:41:49 2014
 Measurement: Round trip time
 Samples: 10, Minimum: 306 usec, Maximum: 454 usec, Average: 381 usec, Peak to peak: 148 usec, Stddev: 37 usec,
 Sum: 3805 usec
 Results over all tests:
 Probes sent: 117, Probes received: 117, Loss percentage: 0
 Measurement: Round trip time
 Samples: 117, Minimum: 214 usec, Maximum: 531 usec, Average: 357 usec, Peak to peak: 317 usec, Stddev: 72 usec,
 Sum: 41719 usec


lab@R2# run show services rpm active-servers 
 Protocol: TCP, Port: 50000

 Protocol: UDP, Port: 51000

Circuit Cross Connect (RSVP-based CCC)

Posted on by
Reply

Configuration

PE1#

/* If logical systems are used for the lab, then 
 * The physical interface encapsulation (ethernet-ccc) is configured 
 * at the global level - NOT at logical system level
 */
 interface {
    ge-1/1/0 {
        encapsulation ethernet-ccc;
        unit 0 {
            description "PE1->CE1 | Physical interface";
        }    
    }
}

protocols {
    rsvp {
        /* PE1->P1 */
        interface lt-0/0/10.1101;
    }
    mpls {
        label-switched-path PE1-to-PE2 {
            to 12.12.12.12;
            no-cspf;
        }
        /* PE1->P1 */
        interface lt-0/0/10.1101;
    }
    ospf {
        area 0.0.0.0 {
            /* PE1 Loopback */
            interface lo0.11;
            /* PE1->P1 */
            interface lt-0/0/10.1101;
        }
    }
    connections {
        remote-interface-switch CE1-to-CE2 {
            interface ge-1/1/0.0;
            transmit-lsp PE1-to-PE2;
            receive-lsp PE2-to-PE1;
        }
    }
}



PE2#

interface {
    ge-1/1/1 {
        encapsulation ethernet-ccc;
        unit 0 {
            description "PE2->CE2 | Physical interface";
        }    
    }
}

protocols {
    rsvp {
        /* PE2->P3 */
        interface lt-0/0/10.123;
    }
    mpls {
        label-switched-path PE2-to-PE1 {
            to 11.11.11.11;             
            no-cspf;
        }
        /* PE2->P3 */
        interface lt-0/0/10.123;
    }
    ospf {
        area 0.0.0.0 {
            /* PE2->P3 */
            interface lt-0/0/10.123;
            /* PE2 Loopback */
            interface lo0.12;
        }
    }
    connections {
        remote-interface-switch CE2-to-CE1 {
            interface ge-1/1/1.0;
            transmit-lsp PE2-to-PE1;
            receive-lsp PE1-to-PE2;
        }
    }
}

Verification

pe1@MX:PE1> show connections | find Connection/Circuit 
Connection/Circuit                Type        St      Time last up     # Up trans
CE1-to-CE2                        rmt-if      Up      Jul 20 07:08:43           1
  ge-1/1/0.0                        intf  Up
  PE1-to-PE2                        tlsp  Up
  PE2-to-PE1                        rlsp  Up
  
pe1@MX:PE1> show connections labels 
Connection/Circuit                Type        St      Time last up     # Up trans
CE1-to-CE2                        rmt-if      Up      Jul 20 07:08:43           1
  Incoming labels: 300512
  Outgoing labels: Push 300144

The above labels (incoming of 300512, and outgoing of 300144) are exchanged via RSVP

pe1@MX:PE1> show rsvp session 
Ingress RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
12.12.12.12     11.11.11.11     Up       0  1 FF       -   300144 PE1-to-PE2
Total 1 displayed, Up 1, Down 0

Egress RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
11.11.11.11     12.12.12.12     Up       0  1 FF  300512        - PE2-to-PE1
Total 1 displayed, Up 1, Down 0

Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0


pe1@MX:PE1> show route table mpls.0  

mpls.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0                  *[MPLS/0] 01:38:01, metric 1
                      Receive
1                  *[MPLS/0] 01:38:01, metric 1
                      Receive
2                  *[MPLS/0] 01:38:01, metric 1
                      Receive
300512             *[CCC/7] 01:28:45
                    > via ge-1/1/0.0, Pop      
ge-1/1/0.0         *[CCC/7/1] 01:28:45, metric 4
                    > to 100.1.11.1 via lt-0/0/10.1101, label-switched-path PE1-to-PE2

Note one big difference of CCC compared to BGP/LDP based VPLS, BGP based L2VPN, LDP based L2CKT is that CCC does not support tunnel stacking. There is only one label used to encapsulate CCC traffic. For the other L2 technologies, there are two labels in use: one transport label (outer), and another inner one, which is VPN or CKT label.

BGP based L2VPN

Posted on by
Reply

Configuration

PE1#

/* If logical systems are used for the lab, then 
 * The physical interface encapsulation (ethernet-ccc) is configured 
 * at the global level - NOT at logical system level
 */
interface {
    ge-1/1/0 {
        encapsulation ethernet-ccc;
        unit 0 {
            description "PE1->CE1 | Physical interface";
        }    
    }
}

protocols {
    mpls {
        /* PE1->P1 */
        interface lt-0/0/10.1101;
    }
    bgp {
        group PE2 {                     
            type internal;
            local-address 11.11.11.11;
            family l2vpn {
                signaling;
            }
            neighbor 12.12.12.12;
        }
    }
    ospf {
        area 0.0.0.0 {
            /* PE1->P1 */
            interface lt-0/0/10.1101;
            /* PE1 Loopback */
            interface lo0.11;
        }
    }
    ldp {
        /* PE1->P1 */
        interface lt-0/0/10.1101;
        /* PE1 Loopback */
        interface lo0.11;
    }
}
routing-instances {
    L2VPN_1 {
        instance-type l2vpn;            
        interface ge-1/1/0.0;
        route-distinguisher 11.11.11.11:1001;
        vrf-target target:100:1001;
        protocols {
            l2vpn {
                encapsulation-type ethernet;
                interface ge-1/1/0.0;
                site CE1 {
                    site-identifier 1;
                    interface ge-1/1/0.0;
                }
            }
        }
    }
}



PE2#

/* If logical systems are used for the lab, then 
 * The physical interface encapsulation (ethernet-ccc) is configured 
 * at the global level - NOT at logical system level
 */
interface {
    ge-1/1/1 {
        encapsulation ethernet-ccc;
        unit 0 {
            description "PE2->CE2 | Physical interface";
        }    
    }
}


protocols {
    mpls {
        /* PE2->P3 */
        interface lt-0/0/10.123;
    }
    bgp {
        group PE1 {
            type internal;              
            local-address 12.12.12.12;
            family l2vpn {
                signaling;
            }
            neighbor 11.11.11.11;
        }
    }
    ospf {
        area 0.0.0.0 {
            /* PE2->P3 */
            interface lt-0/0/10.123;
            /* PE2 Loopback */
            interface lo0.12;
        }
    }
    ldp {
        /* PE2->P3 */
        interface lt-0/0/10.123;
        /* PE2 Loopback */
        interface lo0.12;
    }
}
routing-instances {
    L2VPN_1 {
        instance-type l2vpn;
        interface ge-1/1/1.0;           
        route-distinguisher 12.12.12.12:1001;
        vrf-target target:100:1001;
        protocols {
            l2vpn {
                encapsulation-type ethernet;
                site CE2 {
                    site-identifier 2;
                    interface ge-1/1/1.0 {
                        remote-site-id 1;
                    }
                }
            }
        }
    }
}

Verification

pe1@MX:PE1> show bgp summary          
Groups: 1 Peers: 1 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
bgp.l2vpn.0          
                       1          1          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
12.12.12.12             100         63         64       0       0       26:27 Establ
  bgp.l2vpn.0: 1/1/1/0
  L2VPN_1.l2vpn.0: 1/1/1/0

pe1@MX:PE1> show route receive-protocol bgp 12.12.12.12 detail 

inet.0: 24 destinations, 25 routes (24 active, 0 holddown, 0 hidden)

inet.3: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)

mpls.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)

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

L2VPN_1.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

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

pe1@MX:PE1> show route table l2vpn    

L2VPN_1.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

11.11.11.11:1001:1:1/96                
                   *[L2VPN/170/-101] 00:08:09, metric2 1
                      Indirect
12.12.12.12:1001:2:1/96                
                   *[BGP/170] 00:08:09, localpref 100, from 12.12.12.12
                      AS path: I
                    > to 100.1.11.1 via lt-0/0/10.1101, Push 300016

pe1@MX:PE1> show l2vpn connections | find L2VPN_1     

Instance: L2VPN_1
  Local site: CE1 (1)
    connection-site           Type  St     Time last up          # Up trans
    2                         rmt   Up     Jul 20 06:13:15 2014           1
      Remote PE: 12.12.12.12, Negotiated control-word: Yes (Null)
      Incoming label: 800001, Outgoing label: 800000
      Local interface: ge-1/1/0.0, Status: Up, Encapsulation: ETHERNET

LDP based L2CKT

Posted on by
Reply

Configuration

PE1#

/* If logical systems are used for the lab, then 
 * The physical interface encapsulation (ethernet-ccc) is configured 
 * at the global level - NOT at logical system level
 */
 interface {
    ge-1/1/0 {
        encapsulation ethernet-ccc;
        unit 0 {
            description "PE1->CE1 | Physical interface";
        }    
    }
}

protocols {
    mpls {
        /* PE1->P1 */
        interface lt-0/0/10.1101;
    }
    ospf {
        area 0.0.0.0 {                  
            /* PE1 Loopback */
            interface lo0.11;
            /* PE1->P1 */
            interface lt-0/0/10.1101;
        }
    }
    ldp {
        /* PE1->P1 */
        interface lt-0/0/10.1101;
        /* PE1 Loopback */
        interface lo0.11;
    }
    l2circuit {
        neighbor 12.12.12.12 {
            interface ge-1/1/0.0 {
                virtual-circuit-id 1;
                no-control-word;
                ignore-mtu-mismatch;
            }
        }
    }
}



PE2#

 interface {
    ge-1/1/1 {
        encapsulation ethernet-ccc;
        unit 0 {
            description "PE2->CE2 | Physical interface";
        }    
    }
}


protocols {
    mpls {
        /* PE2->P3 */
        interface lt-0/0/10.123;
    }
    ospf {
        area 0.0.0.0 {
            /* PE2->P3 */               
            interface lt-0/0/10.123;
            /* PE2 Loopback */
            interface lo0.12;
        }
    }
    ldp {
        /* PE2->P3 */
        interface lt-0/0/10.123;
        /* PE2 Loopback */
        interface lo0.12;
    }
    l2circuit {
        neighbor 11.11.11.11 {
            interface ge-1/1/1.0 {
                virtual-circuit-id 1;
                no-control-word;
                ignore-mtu-mismatch;
            }
        }
    }
}

Verification

Confirm that LDP sessions are up not only between local routers PE1-P1, but also via remote targeted LDP session PE1–PE2

pe1@MX:PE1> show ldp neighbor    
Address            Interface          Label space ID         Hold time
12.12.12.12        lo0.11             12.12.12.12:0            42
100.1.11.1         lt-0/0/10.1101     1.1.1.1:0                14


pe1@MX:PE1> show ldp database 
Input label database, 11.11.11.11:0--1.1.1.1:0
  Label     Prefix
      3     1.1.1.1/32
 299776     2.2.2.2/32
 299792     3.3.3.3/32
 299840     4.4.4.4/32
 299808     5.5.5.5/32
 299824     6.6.6.6/32
 299952     11.11.11.11/32
 299968     12.12.12.12/32

Output label database, 11.11.11.11:0--1.1.1.1:0
  Label     Prefix
 300112     1.1.1.1/32
 300128     2.2.2.2/32
 300144     3.3.3.3/32
 300192     4.4.4.4/32
 300160     5.5.5.5/32
 300176     6.6.6.6/32
      3     11.11.11.11/32
 300224     12.12.12.12/32

Input label database, 11.11.11.11:0--12.12.12.12:0
  Label     Prefix
 300160     1.1.1.1/32
 300144     2.2.2.2/32
 300128     3.3.3.3/32                  
 300208     4.4.4.4/32
 300176     5.5.5.5/32
 300192     6.6.6.6/32
 300224     11.11.11.11/32
      3     12.12.12.12/32
 300112     L2CKT NoCtrlWord ETHERNET VC 1

Output label database, 11.11.11.11:0--12.12.12.12:0
  Label     Prefix
 300112     1.1.1.1/32
 300128     2.2.2.2/32
 300144     3.3.3.3/32
 300192     4.4.4.4/32
 300160     5.5.5.5/32
 300176     6.6.6.6/32
      3     11.11.11.11/32
 300224     12.12.12.12/32
 300208     L2CKT NoCtrlWord ETHERNET VC 1

Confirm that the L2CKT is up for the P2P connection between PE1–PE2. If the session is not up, then we may need to check MTU, encapsulation, VC ID.

pe1@MX:PE1> show l2circuit connections | find Neighbor       
Neighbor: 12.12.12.12 
    Interface                 Type  St     Time last up          # Up trans
    ge-1/1/0.0(vc 1)          rmt   Up     Jul 20 05:27:32 2014           1
      Remote PE: 12.12.12.12, Negotiated control-word: No
      Incoming label: 300208, Outgoing label: 300112
      Negotiated PW status TLV: No
      Local interface: ge-1/1/0.0, Status: Up, Encapsulation: ETHERNET

BGP based VPLS

Posted on by
Reply

Configuration

PE1#

/* If Logical Systems are used for the lab
 * Note that the physical interface encapsulation of ethernet-vpls
 * is configured at the global level - Not at logical system level
 */
interface {
    ge-1/1/0 {
        encapsulation ethernet-vpls;
        unit 0 {
            description "PE1->CE1 | Physical interface";
        }    
    }
}

protocols {
    mpls {
        /* PE1->P1 */
        interface lt-0/0/10.1101;
    }
    bgp {
        group PE2 {                     
            type internal;
            local-address 11.11.11.11;
            family l2vpn {
                signaling;
            }
            neighbor 12.12.12.12;
        }
    }
    ospf {
        area 0.0.0.0 {
            /* PE1->P1 */
            interface lt-0/0/10.1101;
            /* PE1 Loopback */
            interface lo0.11;
        }
    }
    ldp {
        /* PE1->P1 */
        interface lt-0/0/10.1101;
        /* PE1 Loopback */
        interface lo0.11;
    }
}
routing-instances {
    VPLS_1 {
        instance-type vpls;             
        interface ge-1/1/0.0;
        route-distinguisher 11.11.11.11:1001;
        vrf-target target:100:1001;
        protocols {
            vpls {
                site-range 10;
                site CE1 {
                    site-identifier 1;
                    interface ge-1/1/0.0;
                }
            }
        }
    }
}



PE2#

interface {
    ge-1/1/1 {
        encapsulation ethernet-vpls;
        unit 0 {
            description "PE2->CE2 | Physical interface";
        }    
    }
}
protocols {
    mpls {
        /* PE2->P3 */
        interface lt-0/0/10.123;
    }
    bgp {
        family l2vpn {
            signaling;                  
        }
        group PE1 {
            type internal;
            local-address 12.12.12.12;
            neighbor 11.11.11.11;
        }
    }
    ospf {
        area 0.0.0.0 {
            /* PE2->P3 */
            interface lt-0/0/10.123;
            /* PE2 Loopback */
            interface lo0.12;
        }
    }
    ldp {
        /* PE2->P3 */
        interface lt-0/0/10.123;
        /* PE2 Loopback */
        interface lo0.12;
    }
}
routing-instances {
    VPLS_1 {
        instance-type vpls;
        interface ge-1/1/1.0;           
        route-distinguisher 12.12.12.12:1001;
        vrf-target target:100:1001;
        protocols {
            vpls {
                site-range 10;
                site CE2 {
                    site-identifier 2;
                    interface ge-1/1/1.0;
                }
            }
        }
    }
}

Verification

Verify that BGP is up, and exchange routes.

pe1@MX:PE1> show route receive-protocol bgp 12.12.12.12 
...
bgp.l2vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  12.12.12.12:1001:2:1/96                    
*                         12.12.12.12                  100        I

VPLS_1.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  12.12.12.12:1001:2:1/96                    
*                         12.12.12.12                  100        I

pe1@MX:PE1> show route advertising-protocol bgp 12.12.12.12 

VPLS_1.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  11.11.11.11:1001:1:1/96                    
*                         Self                         100        I

pe1@MX:PE1> show route table VPLS_1 extensive 

VPLS_1.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
 11.11.11.11:1001:1:1/96 (1 entry, 1 announced)
TSI:
Page 0 idx 0 Type 1 val 27912b4
    Flags: Nexthop Change
    Nexthop: Self
    Localpref: 100
    AS path: [100] I
    Communities: target:100:1001 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 100
Path 11.11.11.11:1001:1:1 Vector len 4.  Val: 0
        *L2VPN  Preference: 170/-101
                Next hop type: Indirect
                Address: 0x28183ec
                Next-hop reference count: 2
                Protocol next hop: 11.11.11.11
                Indirect next hop: 0 -
                State: 
                Age: 14:33      Metric2: 1 
                Task: VPLS_1-l2vpn
                Announcement bits (1): 1-BGP_RT_Background 
                AS path: I
                Communities: Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 100
                Label-base: 800008, range: 8, status-vector: 0x3F 

 12.12.12.12:1001:2:1/96 (1 entry, 1 announced)
        *BGP    Preference: 170/-101    
                Route Distinguisher: 12.12.12.12:1001
                Next hop type: Indirect
                Address: 0x281935c
                Next-hop reference count: 5
                Source: 12.12.12.12
                Protocol next hop: 12.12.12.12
                Indirect next hop: 2 no-forward
                State: 
                Local AS:   100 Peer AS:   100
                Age: 14:10      Metric2: 1 
                Task: BGP_100.12.12.12.12+65086
                Announcement bits (1): 0-VPLS_1-l2vpn 
                AS path: I
                Communities: target:100:1001 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 100
                Import Accepted
                Label-base: 800008, range: 8
                Localpref: 100
                Router ID: 12.12.12.12
                Primary Routing Table bgp.l2vpn.0
                Indirect next hops: 1
                        Protocol next hop: 12.12.12.12 Metric: 1
                        Indirect next hop: 2 no-forward
                        Indirect path forwarding next hops: 1
                                Next hop type: Router
                                Next hop: 100.1.11.1 via lt-0/0/10.1101
                        12.12.12.12/32 Originating RIB: inet.3
                          Metric: 1                       Node path count: 1
                          Forwarding nexthops: 1
                                Nexthop: 100.1.11.1 via lt-0/0/10.1101

Verify VPLS connections

pe1@MX:PE1> show vpls connections | find VPLS_1              

Instance: VPLS_1
  Local site: CE1 (1)
    connection-site           Type  St     Time last up          # Up trans
    2                         rmt   Up     Jul 20 03:06:23 2014           1
      Remote PE: 12.12.12.12, Negotiated control-word: No
      Incoming label: 800009, Outgoing label: 800008
      Local interface: vt-1/0/10.168821250, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls VPLS_1 local site 1 remote site 2

pe1@MX:PE1> show vpls connections extensive | find VPLS_1    

Instance: VPLS_1
  Local site: CE1 (1)
    Number of local interfaces: 1
    Number of local interfaces up: 1
    IRB interface present: no
    ge-1/1/0.0         
    vt-1/0/10.168821250 2         Intf - vpls VPLS_1 local site 1 remote site 2
    Label-base        Offset     Size  Range     Preference
    800008            1          8      8         100   
    connection-site           Type  St     Time last up          # Up trans
    2                         rmt   Up     Jul 20 03:06:23 2014           1
      Remote PE: 12.12.12.12, Negotiated control-word: No
      Incoming label: 800009, Outgoing label: 800008
      Local interface: vt-1/0/10.168821250, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls VPLS_1 local site 1 remote site 2
    Connection History:
        Jul 20 03:06:23 2014  status update timer  
        Jul 20 03:06:23 2014  loc intf up           vt-1/0/10.168821250
        Jul 20 03:06:23 2014  PE route changed     
        Jul 20 03:06:23 2014  Out lbl Update                    800008
        Jul 20 03:06:23 2014  In lbl Update                     800009
        Jul 20 03:06:23 2014  loc intf down

Check VPLS MAC table, and statistics

pe1@MX:PE1> show vpls mac-table    

MAC flags (S -static MAC, D -dynamic MAC, L -locally learned
           SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)

Logical system   : PE1
Routing instance : VPLS_1
 Bridging domain : __VPLS_1__, VLAN : NA
   MAC                 MAC      Logical
   address             flags    interface 
   a8:d0:e5:55:26:50   D        ge-1/1/0.0           
   a8:d0:e5:55:26:51   D        vt-1/0/10.168821250  

pe1@MX:PE1> show vpls statistics 
VPLS statistics:

Instance: VPLS_1
   Local interface: ge-1/1/0.0, Index: 330
     Broadcast packets:                     5
     Broadcast bytes  :                   300
     Multicast packets:                     0
     Multicast bytes  :                     0
     Flooded packets  :                     1
     Flooded bytes    :                    98
     Unicast packets  :                  1010
     Unicast bytes    :                 98942
     Current MAC count:                     1 (Limit 1024)
   Local interface: vt-1/0/10.168821250, Index: 334
   Remote PE: 12.12.12.12
     Broadcast packets:                     2
     Broadcast bytes  :                   120
     Multicast packets:                     0
     Multicast bytes  :                     0
     Flooded packets  :                     0
     Flooded bytes    :                     0
     Unicast packets  :                  1006
     Unicast bytes    :                 98588
     Current MAC count:                     1

LDP based VPLS

Posted on by
Reply

Configuration

PE1#

/* If Logical Systems are used for the lab
 * Note that the physical interface encapsulation of ethernet-vpls
 * is configured at the global level - Not at logical system level
 */
interface {
    ge-1/1/0 {
        encapsulation ethernet-vpls;
        unit 0 {
            description "PE1->CE1 | Physical interface";
        }    
    }
}


protocols {
    mpls {
        /* PE1->P1 */
        interface lt-0/0/10.1101;
    }
    ospf {
        area 0.0.0.0 {                  
            /* PE1->P1 */
            interface lt-0/0/10.1101;
            /* PE1 Loopback */
            interface lo0.11;
        }
    }
    ldp {
        /* PE1->P1 */
        interface lt-0/0/10.1101;
        /* PE1 Loopback */
        interface lo0.11;
    }
}
routing-instances {
    VPLS_1 {
        instance-type vpls;
        /* PE1->CE1 */
        interface ge-1/1/0.0;
        protocols {
            vpls {
                vpls-id 1001;
                neighbor 12.12.12.12;
            }
        }
    }
}


PE2#

interface {
    ge-1/1/1 {
        encapsulation ethernet-vpls;
        unit 0 {
            description "PE2->CE2 | Physical interface";
        }    
    }
}
protocols {
    mpls {
        /* PE2->P3 */
        interface lt-0/0/10.123;
    }
    ospf {
        area 0.0.0.0 {
            /* PE2->P3 */               
            interface lt-0/0/10.123;
            /* PE2 Loopback */
            interface lo0.12;
        }
    }
    ldp {
        /* PE2->P3 */
        interface lt-0/0/10.123;
        /* PE2 Loopback */
        interface lo0.12;
    }
}
routing-instances {
    VPLS_1 {
        instance-type vpls;
        /* PE2->CE2 */
        interface ge-1/1/1.0;
        protocols {
            vpls {
                vpls-id 1001;
                neighbor 11.11.11.11;
            }
        }
    }
}

Verification

Check LDP database, note there are local LDP session between PE1–P1, as well as targeted LDP session between PE1–PE2

pe1@MX:PE1> show ldp database 
Input label database, 11.11.11.11:0--1.1.1.1:0
  Label     Prefix
      3     1.1.1.1/32
 299776     2.2.2.2/32
 299792     3.3.3.3/32
 299840     4.4.4.4/32
 299808     5.5.5.5/32
 299824     6.6.6.6/32
 299888     11.11.11.11/32
 299904     12.12.12.12/32

Output label database, 11.11.11.11:0--1.1.1.1:0
  Label     Prefix
 299888     1.1.1.1/32
 299904     2.2.2.2/32
 299920     3.3.3.3/32
 299968     4.4.4.4/32
 299936     5.5.5.5/32
 299952     6.6.6.6/32
      3     11.11.11.11/32
 299984     12.12.12.12/32

Input label database, 11.11.11.11:0--12.12.12.12:0
  Label     Prefix
 299920     1.1.1.1/32
 299904     2.2.2.2/32
 299888     3.3.3.3/32                  
 299968     4.4.4.4/32
 299936     5.5.5.5/32
 299952     6.6.6.6/32
 299984     11.11.11.11/32
      3     12.12.12.12/32 
 800000 L2CKT NoCtrlWord ETHERNET VC 1001


Output label database, 11.11.11.11:0--12.12.12.12:0
  Label     Prefix
 299888     1.1.1.1/32
 299904     2.2.2.2/32
 299920     3.3.3.3/32
 299968     4.4.4.4/32
 299936     5.5.5.5/32
 299952     6.6.6.6/32
      3     11.11.11.11/32
 299984     12.12.12.12/32
 800000     L2CKT NoCtrlWord ETHERNET VC 1001

Check the status of VPLS connections

pe1@MX:PE1> show vpls connections | find VPLS_1      

Instance: VPLS_1
  VPLS-id: 1001
    Neighbor                  Type  St     Time last up          # Up trans
    12.12.12.12(vpls-id 1001) rmt   Up     Jul 20 01:36:58 2014           1
      Remote PE: 12.12.12.12, Negotiated control-word: No
      Incoming label: 800000, Outgoing label: 800000
      Negotiated PW status TLV: No
      Local interface: vt-1/0/10.168820992, Status: Up, Encapsulation: ETHERNET
        Description: Intf - vpls VPLS_1 neighbor 12.12.12.12 vpls-id 1001


pe1@MX:PE1> show vpls connections extensive | find VPLS_1 

Instance: VPLS_1
  VPLS-id: 1001
    Number of local interfaces: 1
    Number of local interfaces up: 1
    ge-1/1/0.0         
    vt-1/0/10.168820992           Intf - vpls VPLS_1 neighbor 12.12.12.12 vpls-id 1001
    Neighbor                  Type  St     Time last up          # Up trans
    12.12.12.12(vpls-id 1001) rmt   Up     Jul 20 01:36:58 2014           1
      Remote PE: 12.12.12.12, Negotiated control-word: No
      Incoming label: 800000, Outgoing label: 800000
      Negotiated PW status TLV: No
      Local interface: vt-1/0/10.168820992, Status: Up, Encapsulation: ETHERNET
        Description: Intf - vpls VPLS_1 neighbor 12.12.12.12 vpls-id 1001
    Connection History:
        Jul 20 01:36:58 2014  status update timer  
        Jul 20 01:36:58 2014  PE route changed     
        Jul 20 01:36:58 2014  Out lbl Update                    800000
        Jul 20 01:36:58 2014  In lbl Update                     800000
        Jul 20 01:36:58 2014  loc intf up           vt-1/0/10.168820992

And check the VPLS statistics, MAC table

        
        
pe1@MX:PE1> show vpls statistics 
VPLS statistics:

Instance: VPLS_1
   Local interface: ge-1/1/0.0, Index: 326
     Broadcast packets:                     3
     Broadcast bytes  :                   180
     Multicast packets:                     0
     Multicast bytes  :                     0
     Flooded packets  :                     0
     Flooded bytes    :                     0
     Unicast packets  :                  1001
     Unicast bytes    :                 98098
     Current MAC count:                     0 (Limit 1024)
   Local interface: vt-1/0/10.168820992, Index: 333
   Remote PE: 12.12.12.12
     Broadcast packets:                     1
     Broadcast bytes  :                    60
     Multicast packets:                     0
     Multicast bytes  :                     0
     Flooded packets  :                     0
     Flooded bytes    :                     0
     Unicast packets  :                  1003
     Unicast bytes    :                 98218
     Current MAC count:                     0
     
pe1@MX:PE1> show vpls mac-table    

MAC flags (S -static MAC, D -dynamic MAC, L -locally learned
           SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)

Logical system   : PE1
Routing instance : VPLS_1
 Bridging domain : __VPLS_1__, VLAN : NA
   MAC                 MAC      Logical
   address             flags    interface 
   a8:d0:e5:55:26:50   D        ge-1/1/0.0           
   a8:d0:e5:55:26:51   D        vt-1/0/10.168820992

Also, we may want to check the route table, and note the LDP, VPLS label entries in inet.3, mpls.0 & l2circuit.0

pe1@MX:PE1> show route | find inet.3         

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

1.1.1.1/32         *[LDP/9] 00:25:10, metric 1
                    > to 100.1.11.1 via lt-0/0/10.1101
...
12.12.12.12/32     *[LDP/9] 00:25:10, metric 1
                    > to 100.1.11.1 via lt-0/0/10.1101, Push 299904

mpls.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0                  *[MPLS/0] 00:50:01, metric 1
                      Receive
1                  *[MPLS/0] 00:50:01, metric 1
                      Receive
2                  *[MPLS/0] 00:50:01, metric 1
                      Receive
299888             *[LDP/9] 00:25:10, metric 1
                    > to 100.1.11.1 via lt-0/0/10.1101, Pop      
299888(S=0)        *[LDP/9] 00:25:10, metric 1
                    > to 100.1.11.1 via lt-0/0/10.1101, Pop      
299904             *[LDP/9] 00:25:10, metric 1
                    > to 100.1.11.1 via lt-0/0/10.1101, Swap 299776
...
800000             *[VPLS/7] 00:35:29
                    > via vt-1/0/10.168820992, Pop      
vt-1/0/10.168820992*[VPLS/7] 00:35:29, metric2 1
                    > to 100.1.11.1 via lt-0/0/10.1101, Push 800000, Push 299904(top)

l2circuit.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

12.12.12.12:NoCtrlWord:5:1001:Local/96                
                   *[VPLS/7] 00:35:34, metric2 1
                    > to 100.1.11.1 via lt-0/0/10.1101, Push 299904
12.12.12.12:NoCtrlWord:5:1001:Remote/96                
                   *[LDP/9] 00:35:34
                      Discard

Encapsulated Remote SPAN (ERSPAN)

Posted on by
Reply

There are three types of Switch Port Analyser (SPAN) supported on Cisco routers and switches:

Local SPAN: Mirrors traffic from one or more interface on the switch to one or more interfaces on the same switch.

Remote SPAN (RSPAN): An extension of SPAN called remote SPAN or RSPAN which allows to capture traffic and send it to a remote switch via a Layer 2 network.

Encapsulated Remote SPAN (ERSPAN): as the name indicates, ERSPAN encapsulates capture traffic in GRE and allows it to be transported to a remote port across a Layer 3 network.

ERSPAN is a Cisco proprietary feature and is available only to Catalyst 6500, 7600, Nexus, and ASR 1000 platforms to date. The ASR 1000 supports ERSPAN source (monitoring) only on Fast Ethernet, Gigabit Ethernet, and port-channel interfaces.

Firstly we will go through a typical scenario, in which traffic on port Gi1.23 of Router R2 is captured, and sent to interface Gi2 of R1 traffic using ERSPAN.

Topology

ERSPAN Topology

Configuration

ERSPAN Source Router

CSR2# 

monitor session 10 type erspan-source
 source interface GigabitEthernet1
 filter vlan 23    ! Specify Sub-interface
 destination
 erspan-id 100
 ip address 1.1.1.1
 origin ip address 2.2.2.2
 no shutdown   !   Default is shutdown

ERSPAN Destination Router

CSR1#
 
monitor session 10 type erspan-destination
 destination interface GigabitEthernet2
 source
  erspan-id 100
  ip address 1.1.1.1
 no shutdown   !   Default is shutdown

Verification

CSR2#show monitor session all
Session 10
----------
Type                   : ERSPAN Source Session
Status                 : Admin Enabled
Source Ports           : 
    Both               : Gi1
Filter VLANs           : 23
Destination IP Address : 1.1.1.1
MTU                    : 1464
Destination ERSPAN ID  : 100
Origin IP Address      : 2.2.2.2


CSR1#show monitor session all
Session 10
----------
Type                   : ERSPAN Destination Session
Status                 : Admin Enabled
Destination Ports      : Gi2
Source IP Address      : 1.1.1.1
Source ERSPAN ID       : 100

CSR1#show interface gi2 stats 
GigabitEthernet2
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor          1         77          4        308
             Route cache          0          0          0          0
       Distributed cache         47       7745        112      31780
                   Total         48       7822        116      32088

Capture files:

ERSPAN transport traffic, encapsulated within a GRE tunnel, as seen on R1 interface Gi1.12
https://www.cloudshark.org/captures/19b7c6b1c70b

ERSPAN capture result – on R1 Gi2
https://www.cloudshark.org/captures/00c5e863ecfe

ERSPAN without the destination router

Since ERSPAN is a Cisco proprietary protocol supported on a limited number of platforms, one may ask if we can capture traffic and send it via GRE to a remote laptop without having a destination ERSPAN router. We might run into this situation if the destination router does not support ERSPAN, or the PC is not connected directly to a physical port of the ERSPAN destination router (e.g. via a LAN switch, or via an Wireless AP).

The answer is, yes we can do this without the ERSPAN destination router!

The ERSPAN destination router is not a critical requirement. GRE/ERSPAN protocol in this case is not equipped with a reliable transmission mechanism. Nor it has a mechanism to verify the status of the ERSPAN session destination, before sending the capture traffic. Unlike ERSPAN, in the general GRE tunnel interface configuration on IOS (similarly in Juniper JUNOS) we can enable the “keep-alive” function under the GRE tunnel interface, and routers at both ends of the tunnel can check the status of the other end, and can bring down the interface if the keep-alive is not received within a configurable period, and can bring the interface up once the keep-alive messages are received again. The ERSPAN implementation of GRE does not have this feature.

ERSPAN destination router is needed if we want the traffic send to the destination interface appear in the same format as the one captured from the source, i.e. without it being encapsulated in GRE/ERSPAN headers.

If the remote PC is reachable via an IP address (connected to the network via a LAN switch or Wireless AP) the ERSPAN source router can send encapsulated traffic directly to this IP address. The PC does not need to have an GRE tunnel nor ERSPAN session configured . PC can not run ERSPAN anyway, because it is a Cisco proprietary protocol, and there is no “ERSPAN client” software released for PC.

If the remote PC does not have a reachable IP address (quite typical usage case) but connect physically to a router interface, we can still force the ERSPAN traffic to the interface assigned to this PC, by implementing a static route and static ARP. In this example below, 1.1.1.1 is the destination ERSPAN address (configured on R2), and R1 does not support ERSPAN.

ERSPAN without Dest Router

Configuration

ERSPAN Source router (2.2.2.2)
CRS2#
! Configuration is unchanged from the previous case
monitor session 10 type erspan-source
 source interface GigabitEthernet1
 filter vlan 23    ! Specify Sub-interface
 destination
 erspan-id 100
 ip address 1.1.1.1
 origin ip address 2.2.2.2
 no shutdown   !   Default is shutdown



CSR1#
! Destination router does not support ERSPAN. 
! The destination IP address 1.1.1.1 is now NOT a real IP "behind" the monitoring PC.

! Remove ERSPAN session
no monitor session 10

! Remove 1.1.1.1 from Loopback interface.
no interface Loopback0

! Configure a dummy "transit" IP address on Gi2 
! And add a static route for destination 1.1.1.1 to force ERSPAN traffic out this way.

interface GigabitEthernet2
 ip address 10.1.1.1 255.255.255.0
!
ip route 1.1.1.1 255.255.255.255 10.1.1.2 name Force_Traffic_Out_Gi2

! Note that we need static ARP for the dummy next hop IP. 
! Otherwise, router will keep ARPing, without sending the actual ERSPAN traffic out Gi2
 
arp 10.1.1.2 6400.f1e2.0112 ARPA

Capture file:

ERSPAN capture result – as seen on on R1 Gi2. Note that the captured traffic is now encapsulated within GRE/ERSPAN header, similar to the transit traffic captured on R1 Gi1.12 in the previous example.

https://www.cloudshark.org/captures/76ce4261df29

Local ERSPAN

In this example, we’d like to mirror traffic from interface Gi1 to Gi2 on a local router R1. As traffic is copied from one interface to other on the same router, we wont be able to capture the actual transport traffic encapsulated within GRE/ERSPAN.

Below is the configuration & verification steps.

CSR1#

monitor session 10 type erspan-source
 source interface GigabitEthernet1
 destination
 erspan-id 100
 ip address 1.1.1.1
 origin ip address 1.1.1.1
 shutdown   !   Default
 
monitor session 20 type erspan-destination
 destination interface GigabitEthernet2
 source
  erspan-id 100
  ip address 1.1.1.1
 shutdown   !   Default
 

CSR1#! Before turning montor session ON
CSR1#
CSR1#
CSR1#show interfaces gigabitEthernet 1 stats 
GigabitEthernet1
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor          0          0          0          0
             Route cache          0          0          0          0
       Distributed cache         17       1540         15       1268
                   Total         17       1540         15       1268
CSR1#show interfaces gigabitEthernet 2 stats 
GigabitEthernet2
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor          0          0          0          0
             Route cache          0          0          0          0
       Distributed cache          0          0          0          0
                   Total          0          0          0          0
                   
                   
Note that there is no traffic sent to Gi2  


CSR1#
config t
monitor session 10
 no shutdown
monitor session 20
 no shutdown


CSR1#! After turning montor session ON


CSR1#show interfaces gigabitEthernet 1 stats 
GigabitEthernet1
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor          0          0          0          0
             Route cache          0          0          0          0
       Distributed cache         48       4264         45       3782
                   Total         48       4264         45       3782
CSR1#show interfaces gigabitEthernet 2 stats 
GigabitEthernet2
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor          0          0          0          0
             Route cache          0          0          0          0
       Distributed cache          0          0         14       1192
                   Total          0          0         14       1192

References

Configuring ERSPAN

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/lanswitch/configuration/xe-3s/lanswitch-xe-3s-book/lnsw-conf-erspan.html#GUID-152D9875-169B-461F-A34B-ABAABD0C1FF8

Understanding SPAN, RSPAN, and ERSPAN

https://supportforums.cisco.com/document/139236/understanding-spanrspanand-erspan

Inter-AS L3VPN Option B

Posted on by
Reply

In this post, we are going to go through the implementation and verification steps of Inter-AS Option B (defined in RFC4364 http://tools.ietf.org/html/rfc4364#page-32 ). Please refer to previous post Inter-AS Options to for the definitions, and differences of the three.

In option B implementation, ASBRs themselves are PE routers. They learn VPN-IPv4 routes from other PEs from the same AS via MP-iBGP (either directly or via Route Reflectors). The ASBR from one AS then have an eBGP session(s) with other AS ASBR to redistribute the VPN-IPv4 routes to the other AS. The later ASBR then redistributes those VPN-IPv4 labeled routes to the rest of the PEs belonging to that AS.

Topology

inter-as

In this topology, we use Cisco IOS routers (R1 – R3) in AS100, as well as Juniper routers (R4 – R6) in AS200, just for demonstration of configuration and verification on both platforms. Typically for connectivity beween ASes, one eBGP session between ASBRs is sufficient. In this example, however, we set up two eBGP sessions between ASBR R3 and R4 to demonstrate VPN-based policy routing, by route filtering based on VPN route targets. We would like to route traffic for VPN1 via the first connection, and VPN2 via the other.

Configuration

R3-ASBR#

interface Loopback0
 description Management Loopback
 ip address 3.3.3.3 255.255.255.255
!
interface GigabitEthernet1.23
 description R3 -> R2-P
 encapsulation dot1Q 23
 ip address 20.2.3.3 255.255.255.0
 mpls ip
!
interface GigabitEthernet1.34
 description R3 -> R4 | First eBGP
 encapsulation dot1Q 34
 ip address 20.3.4.3 255.255.255.0
 mpls bgp forwarding
!
interface GigabitEthernet1.342
 description R3 -> R4 | Second eBGP
 encapsulation dot1Q 342
 ip address 20.3.42.3 255.255.255.0
 mpls bgp forwarding


! Enable OSPF
 
router ospf 1
 network 3.3.3.3 0.0.0.0 area 0
 network 20.2.3.3 0.0.0.0 area 0
!

! Enable MP-iBGP to other PE, and MP-eBGP to other ASBR
router bgp 100
 bgp log-neighbor-changes
 ! By default, PE do not accept VPNv4 routes 
 ! that do not belong to one of its VRF
 ! This command force it to learn & propagate all routes to other PEs.
 no bgp default route-target filter
 neighbor 1.1.1.1 remote-as 100
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 20.3.4.4 remote-as 200
 neighbor 20.3.42.4 remote-as 200
 !
 address-family ipv4
  no neighbor 1.1.1.1 activate
  no neighbor 20.3.4.4 activate
  no neighbor 20.3.42.4 activate
 exit-address-family
 !
 address-family vpnv4
  neighbor 1.1.1.1 activate
  neighbor 1.1.1.1 send-community extended
  neighbor 1.1.1.1 next-hop-self
  neighbor 20.3.4.4 activate
  neighbor 20.3.4.4 send-community extended
  neighbor 20.3.42.4 activate
  neighbor 20.3.42.4 send-community extended
 exit-address-family
 

! Policy to only import and export VPN2 routes via the second eBGP connection
! We can apply a similar policy on the first eBGP connection on R3
! But for demonstration purpose, we choose to apply that policy on R4 (Junos)

ip extcommunity-list standard Community_VPN2 permit rt 100:2
ip extcommunity-list standard Community_VPN2 permit rt 200:2
!
route-map VPN2-EXPORT-ONLY permit 10
 match extcommunity Community_VPN2
!
route-map VPN2-EXPORT-ONLY deny 1000
 description Deny all else
!
route-map VPN2-IMPORT-ONLY permit 10
 match extcommunity Community_VPN2
 set local-preference 200
!
route-map VPN2-IMPORT-ONLY deny 1000
 description Deny all else
!
router bgp 100 
 address-family vpnv4
  neighbor 20.3.42.4 route-map VPN2-IMPORT-ONLY in
  neighbor 20.3.42.4 route-map VPN2-EXPORT-ONLY out
 exit-address-family 
 
  


R4-ASBR# 

interfaces {
    ge-0/0/1 {
        vlan-tagging;
        unit 34 {
            description "R4 -> R3 | First eBGP";
            vlan-id 34;
            family inet {
                address 20.3.4.4/24;
            }                           
            family mpls;
        }
        unit 45 {
            description "R4 -> R5";
            vlan-id 45;
            family inet {
                address 20.4.5.4/24;
            }
            family mpls;
        }
        unit 342 {
            description "R4 -> R3 | Second eBGP";
            vlan-id 342;
            family inet {
                address 20.3.42.4/24;
            }
            family mpls;
        }
    }
    lo0 {
        unit 0 {
            description "Management Loopback";
            family inet {
                address 4.4.4.4/32;     
            }
            family mpls;
        }
    }
}


routing-options {
    router-id 4.4.4.4;
    autonomous-system 200;
}
protocols {
    mpls {
        interface ge-0/0/1.45;
        interface ge-0/0/1.34;
        interface ge-0/0/1.342;
    }
    bgp {
        group IBGP {
            type internal;
            local-address 4.4.4.4;
            family inet-vpn {
                unicast;
            }
            export next-hop-self;
            neighbor 6.6.6.6;           
        }
        group EBGP1 {
            type external;
            description "L3VPN Inter-AS";
            import VPN1-IMPORT-ONLY;
            family inet-vpn {
                unicast;
            }
            export VPN1-EXPORT-ONLY;
            neighbor 20.3.4.3 {
                peer-as 100;
            }
        }
        group EBGP2 {
            type external;
            description "2nd L3VPN Inter-AS";
            family inet-vpn {
                unicast;
            }
            neighbor 20.3.42.3 {
                peer-as 100;
            }
        }
    }                                   
    ospf {
        area 0.0.0.0 {
            interface ge-0/0/1.45;
            interface lo0.0;
        }
    }
    ldp {
        interface ge-0/0/1.45;
        interface lo0.0;
    }
}



policy-options {
    policy-statement VPN1-EXPORT-ONLY {
        term VPN1 {
            from community [ Community_100_1 Community_200_1 ];
            then accept;
        }
        term Reject-All {
            then reject;
        }
    }
    policy-statement VPN1-IMPORT-ONLY {
        term VPN1 {
            from community Community_100_1;
            then {                      
                local-preference 200;   
                accept;                 
            }
        }
        term Reject-All {
            then reject;
        }
    }
    policy-statement next-hop-self {
        then {
            next-hop self;
        }
    }
    community Community_100_1 members target:100:1;
    community Community_100_2 members target:100:2;
    community Community_200_1 members target:200:1;
    community Community_200_2 members target:200:2;
}





/// Other router configuration

R1-PE#
!
hostname R1-PE
!
ip vrf VPN1
 rd 1.1.1.1:1
 route-target export 100:1
 route-target import 100:1
 route-target import 200:1
!
ip vrf VPN2
 rd 1.1.1.1:2
 route-target export 100:2
 route-target import 100:2
 route-target import 200:2

interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
 ip vrf forwarding VPN1
 ip address 10.1.1.1 255.255.255.0
!
interface Loopback2
 ip vrf forwarding VPN2
 ip address 10.1.2.1 255.255.255.0
!
interface GigabitEthernet1.12
 encapsulation dot1Q 12
 ip address 20.1.2.1 255.255.255.0
 mpls ip
!
router ospf 1
 network 1.1.1.1 0.0.0.0 area 0
 network 20.1.2.1 0.0.0.0 area 0
!
router bgp 100
 bgp log-neighbor-changes
 neighbor 3.3.3.3 remote-as 100
 neighbor 3.3.3.3 update-source Loopback0
 !
 address-family vpnv4
  neighbor 3.3.3.3 activate
  neighbor 3.3.3.3 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf VPN1
  redistribute connected
 exit-address-family
 !
 address-family ipv4 vrf VPN2
  redistribute connected
 exit-address-family
!


R2-P#

interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface GigabitEthernet1.12
 encapsulation dot1Q 12
 ip address 20.1.2.2 255.255.255.0
 mpls ip
!
interface GigabitEthernet1.23
 encapsulation dot1Q 23
 ip address 20.2.3.2 255.255.255.0
 mpls ip
!
router ospf 1
 network 2.2.2.2 0.0.0.0 area 0
 network 20.1.2.2 0.0.0.0 area 0
 network 20.2.3.2 0.0.0.0 area 0
 
 





lab@R5-P> show configuration

interfaces {
    ge-0/0/1 {
        vlan-tagging;
        unit 45 {
            vlan-id 45;
            family inet {
                address 20.4.5.5/24;
            }
            family mpls;                
        }
        unit 56 {
            vlan-id 56;
            family inet {
                address 20.5.6.5/24;
            }
            family mpls;
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 5.5.5.5/32;
            }
            family mpls;
        }
    }
}
routing-options {
    router-id 5.5.5.5;
    autonomous-system 200;
}
protocols {
    mpls {                              
        interface ge-0/0/1.45;
        interface ge-0/0/1.56;
    }
    ospf {
        area 0.0.0.0 {
            interface lo0.0;
            interface ge-0/0/1.45;
            interface ge-0/0/1.56;
        }
    }
    ldp {
        interface ge-0/0/1.45;
        interface ge-0/0/1.56;
        interface lo0.0;
    }
}



lab@R6-PE> show configuration 

interfaces {
    ge-0/0/1 {
        vlan-tagging;
        unit 56 {
            vlan-id 56;
            family inet {
                address 20.5.6.6/24;
            }
            family mpls;                
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 6.6.6.6/32;
            }
            family mpls;
        }
        unit 1 {
            family inet {
                address 10.6.1.1/24;
            }
        }
        unit 2 {
            family inet {
                address 10.6.2.1/24;
            }
        }
    }
}
routing-options {
    router-id 6.6.6.6;
    autonomous-system 200;              
}
protocols {
    mpls {
        interface ge-0/0/1.56;
    }
    bgp {
        group IBGP {
            type internal;
            local-address 6.6.6.6;
            family inet-vpn {
                unicast;
            }
            neighbor 4.4.4.4;
        }
    }
    ospf {
        area 0.0.0.0 {
            interface lo0.0;
            interface ge-0/0/1.56;
        }
    }
    ldp {
        interface ge-0/0/1.56;
        interface lo0.0;                
    }
}
policy-options {
    policy-statement VPN1-EXPORT {
        then {
            community add Community_200_1;
            accept;
        }
    }
    policy-statement VPN1-IMPORT {
        term Import {
            from community [ Community_200_1 Community_100_1 ];
            then accept;
        }
    }
    policy-statement VPN2-EXPORT {
        then {
            community add Community_200_2;
            accept;
        }
    }
    policy-statement VPN2-IMPORT {
        term Import {
            from community [ Community_200_2 Community_100_2 ];
            then accept;
        }
    }
    community Community_100_1 members target:100:1;
    community Community_100_2 members target:100:2;
    community Community_200_1 members target:200:1;
    community Community_200_2 members target:200:2;
}

routing-instances { 
    VPN1 {
        instance-type vrf;
        interface lo0.1;
        route-distinguisher 6.6.6.6:1;
        vrf-import VPN1-IMPORT;
        vrf-export VPN1-EXPORT;
    }
    VPN2 {
        instance-type vrf;
        interface lo0.2;
        route-distinguisher 6.6.6.6:2;
        vrf-import VPN2-IMPORT;
        vrf-export VPN2-EXPORT;
    }
}

Verification

R3-ASBR#show ip bgp vpnv4 all         
BGP table version is 31, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1.1.1.1:1
 *>i 10.1.1.0/24      1.1.1.1                  0    100      0 ?
Route Distinguisher: 1.1.1.1:2
 *>i 10.1.2.0/24      1.1.1.1                  0    100      0 ?
Route Distinguisher: 6.6.6.6:1
 *>  10.6.1.0/24      20.3.4.4                               0 200 i
 *>  10.6.1.1/32      20.3.4.4                               0 200 i
Route Distinguisher: 6.6.6.6:2
 *>  10.6.2.0/24      20.3.42.4                     200      0 200 i
 *>  10.6.2.1/32      20.3.42.4                     200      0 200 i
 
 
R3-ASBR#show mpls forwarding-table 
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop    
Label      Label      or Tunnel Id     Switched      interface              
16         Pop Label  20.3.4.4/32      0             Gi1.34     20.3.4.4    
17         Pop Label  20.3.42.4/32     0             Gi1.342    20.3.42.4   
18         Pop Label  2.2.2.2/32       0             Gi1.23     20.2.3.2    
19         Pop Label  20.1.2.0/24      0             Gi1.23     20.2.3.2    
20         16         1.1.1.1/32       0             Gi1.23     20.2.3.2    
27         300976     6.6.6.6:1:10.6.1.0/24   \
                                       0             Gi1.34     20.3.4.4    
28         300992     6.6.6.6:1:10.6.1.1/32   \
                                       0             Gi1.34     20.3.4.4    
29         301008     6.6.6.6:2:10.6.2.0/24   \
                                       0             Gi1.342    20.3.42.4   
30         301024     6.6.6.6:2:10.6.2.1/32   \
                                       0             Gi1.342    20.3.42.4   
31         18         1.1.1.1:1:10.1.1.0/24   \
                                       0             Gi1.23     20.2.3.2    
32         19         1.1.1.1:2:10.1.2.0/24   \
                                       0             Gi1.23     20.2.3.2  



lab@R4-ASBR> show route                 

inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
...

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

5.5.5.5/32         *[LDP/9] 02:27:16, metric 1
                    > to 20.4.5.5 via ge-0/0/1.45
6.6.6.6/32         *[LDP/9] 02:27:16, metric 1
                    > to 20.4.5.5 via ge-0/0/1.45, Push 301040

mpls.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0                  *[MPLS/0] 06:09:45, metric 1
                      Receive
1                  *[MPLS/0] 06:09:45, metric 1
                      Receive
2                  *[MPLS/0] 06:09:45, metric 1
                      Receive
13                 *[MPLS/0] 06:09:45, metric 1
                      Receive
300944             *[LDP/9] 02:27:16, metric 1
                    > to 20.4.5.5 via ge-0/0/1.45, Pop      
300944(S=0)        *[LDP/9] 02:27:16, metric 1
                    > to 20.4.5.5 via ge-0/0/1.45, Pop      
300960             *[LDP/9] 02:27:16, metric 1
                    > to 20.4.5.5 via ge-0/0/1.45, Swap 301040
300976             *[VPN/170] 02:27:08, metric2 1, from 6.6.6.6
                    > to 20.4.5.5 via ge-0/0/1.45, Swap 300080, Push 301040(top)
300992             *[VPN/170] 02:27:08, metric2 1, from 6.6.6.6
                    > to 20.4.5.5 via ge-0/0/1.45, Swap 300096, Push 301040(top)
301008             *[VPN/170] 02:27:08, metric2 1, from 6.6.6.6
                    > to 20.4.5.5 via ge-0/0/1.45, Swap 300112, Push 301040(top)
301024             *[VPN/170] 02:27:08, metric2 1, from 6.6.6.6
                    > to 20.4.5.5 via ge-0/0/1.45, Swap 300128, Push 301040(top)
301040             *[VPN/170] 02:26:38
                    > to 20.3.4.3 via ge-0/0/1.34, Swap 31
301056             *[VPN/170] 02:26:38
                    > to 20.3.42.3 via ge-0/0/1.342, Swap 32
                                        
bgp.l3vpn.0: 6 destinations, 7 routes (6 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

1.1.1.1:1:10.1.1.0/24                
                   *[BGP/170] 02:26:38, localpref 200
                      AS path: 100 ?
                    > to 20.3.4.3 via ge-0/0/1.34, Push 31
1.1.1.1:2:10.1.2.0/24                
                   *[BGP/170] 02:26:38, localpref 100
                      AS path: 100 ?
                    > to 20.3.42.3 via ge-0/0/1.342, Push 32
6.6.6.6:1:10.6.1.0/24                
                   *[BGP/170] 02:27:08, localpref 100, from 6.6.6.6
                      AS path: I
                    > to 20.4.5.5 via ge-0/0/1.45, Push 300080, Push 301040(top)
6.6.6.6:1:10.6.1.1/32                
                   *[BGP/170] 02:27:08, localpref 100, from 6.6.6.6
                      AS path: I
                    > to 20.4.5.5 via ge-0/0/1.45, Push 300096, Push 301040(top)
6.6.6.6:2:10.6.2.0/24                
                   *[BGP/170] 02:27:08, localpref 100, from 6.6.6.6
                      AS path: I
                    > to 20.4.5.5 via ge-0/0/1.45, Push 300112, Push 301040(top)
6.6.6.6:2:10.6.2.1/32                   
                   *[BGP/170] 02:27:08, localpref 100, from 6.6.6.6
                      AS path: I
                    > to 20.4.5.5 via ge-0/0/1.45, Push 300128, Push 301040(top)
                    
                    




Verification on PE routers


R1-PE#sh ip route vrf VPN1

      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C        10.1.1.0/24 is directly connected, Loopback1
L        10.1.1.1/32 is directly connected, Loopback1
B        10.6.1.0/24 [200/0] via 3.3.3.3, 02:30:47
B        10.6.1.1/32 [200/0] via 3.3.3.3, 02:30:47


R1-PE#sh ip bgp vpnv4 vrf VPN1 10.6.1.0/24
BGP routing table entry for 1.1.1.1:1:10.6.1.0/24, version 20
Paths: (1 available, best #1, table VPN1)
  Not advertised to any peer
  Refresh Epoch 1
  200, imported path from 6.6.6.6:1:10.6.1.0/24 (global)
    3.3.3.3 (metric 3) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:200:1
      mpls labels in/out nolabel/27
      rx pathid: 0, tx pathid: 0x0
      
lab@R6-PE> show route 

inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
...

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

4.4.4.4/32         *[LDP/9] 02:33:44, metric 1
                    > to 20.5.6.5 via ge-0/0/1.56, Push 301056
5.5.5.5/32         *[LDP/9] 02:33:46, metric 1
                    > to 20.5.6.5 via ge-0/0/1.56

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

10.1.1.0/24        *[BGP/170] 02:33:06, localpref 200, from 4.4.4.4
                      AS path: 100 ?
                    > to 20.5.6.5 via ge-0/0/1.56, Push 301040, Push 301056(top)
10.6.1.0/24        *[Direct/0] 03:58:06
                    > via lo0.1
10.6.1.1/32        *[Local/0] 03:58:06
                      Local via lo0.1

VPN2.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
                                        
10.1.2.0/24        *[BGP/170] 02:33:06, localpref 100, from 4.4.4.4
                      AS path: 100 ?
                    > to 20.5.6.5 via ge-0/0/1.56, Push 301056, Push 301056(top)
10.6.2.0/24        *[Direct/0] 03:58:06
                    > via lo0.2
10.6.2.1/32        *[Local/0] 03:58:06
                      Local via lo0.2

mpls.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0                  *[MPLS/0] 04:35:27, metric 1
                      Receive
1                  *[MPLS/0] 04:35:27, metric 1
                      Receive
2                  *[MPLS/0] 04:35:27, metric 1
                      Receive
13                 *[MPLS/0] 04:35:27, metric 1
                      Receive
300048             *[LDP/9] 02:33:46, metric 1
                    > to 20.5.6.5 via ge-0/0/1.56, Pop      
300048(S=0)        *[LDP/9] 02:33:46, metric 1
                    > to 20.5.6.5 via ge-0/0/1.56, Pop      
300064             *[LDP/9] 02:33:44, metric 1
                    > to 20.5.6.5 via ge-0/0/1.56, Swap 301056
300080             *[VPN/170] 02:33:36
                      receive table VPN1.inet.0, Pop      
300096             *[VPN/170] 02:33:36
                      receive table VPN1.inet.0, Pop      
300112             *[VPN/170] 02:33:36
                      receive table VPN2.inet.0, Pop      
300128             *[VPN/170] 02:33:36
                      receive table VPN2.inet.0, Pop      

bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.1.1.1:1:10.1.1.0/24                
                   *[BGP/170] 02:33:06, localpref 200, from 4.4.4.4
                      AS path: 100 ?
                    > to 20.5.6.5 via ge-0/0/1.56, Push 301040, Push 301056(top)
1.1.1.1:2:10.1.2.0/24                
                   *[BGP/170] 02:33:06, localpref 100, from 4.4.4.4
                      AS path: 100 ?
                    > to 20.5.6.5 via ge-0/0/1.56, Push 301056, Push 301056(top)

Inter-AS L3VPN Options

Posted on by
Reply

In certain cases, we need to connect L3VPN sites across multiple ASes, e.g. to join VPN sites provided by multiple ISPs. In this post, we are going to discuss three main options to deliver L3VPN across multiple ASes defined in RFC4364 ( http://tools.ietf.org/html/rfc4364#page-32 ). They are options A, B, C, also known as options 10A, 10B, 10C, because they are defined in section 10 – Multi-AS Backbones in RFC4364. The complexity increasing from A to B to C.

Option A: VRF-to-VRF connections at ASBR routers

This option is also referred to as “back-to-back” VRF, where at least one connection (typically one VLAN) is required to connect one VPN from one AS to the corresponding VPN in the other AS. Multiple eBGP peering sessions are used to exchange no-labeled IPv4 routes between ASes. There are no MPLS labels exchanged between ASBRs at all, and each ASBR will treat the other as if it were a CE router. This option is simple, but not scalable because a new sub-interface and new a new eBGP peering is required for each new VPN.

Option B: eBGP redistribution of labeled VPN-IPv4 routes from one AS to the other

In this option, iBGP is used to redistribute VPN-IPv4 routes between their PEs within an AS. The ASBR then uses eBGP to redistribute those labeled VPN-IPv4 routes to the ASBR in the other AS. The later ASBR then redistributes those VPN-IPv4 labeled routes to the rest of the PEs (via a direct iBGP peering session, or via Route Reflectors).

Typically one eBGP peering session is required between a pair of ASBRs, as compared to multiple ones (one per VPN) in option A. As the result Option B is more scalable than Option A. To make the memory usage more scalable, when there are multiple Inter-AS connections via multiple ASBRs, then ASBRs do not need to hold all routes from all VPNs. One ASBR can hold routes for a set of VPNs, and other ASBR can hold different sets of routes. This can be done by RT filters when the routes are exchanged via eBGP.

Option C: Multi-hop eBGP redistribution of labeled VPN VPN-IPv4 routes between PEs of source & destination ASes, with eBGP redistribution of labeled IPv4 routes (the PE loopbacks) between ASBRs

The difference between this option and option B is that ASes now exchange the loopbacks of the PEs (source and destination) via eBGP sessions between ASBRs. This creates an end to end labeled switch path between source and destination PEs. The source and destination PEs then can set up multi-hop eBGP (directly, or via RR) to exchange VPN-IPv4 labeled routes . The ASBRs do not need to hold the VPN-IPv4 routes. This make the option most scalable.

Circuit Cross Connect (CCC)

Posted on by
Reply

In this lab, we will demonstrate CCC configuration between similar type interfaces.
– CCC to connect VLAN to VLAN
– CCC to connect VLAN at one end, and the whole physical Ethernet port at the other end.

CCC Topology – VLAN to VLAN

CCC-VLAN-to-VLAN

Configuration

lab@PE1# show

interfaces {
    ge-1/0/6 {
        vlan-tagging;
        encapsulation flexible-ethernet-services;
        /* CCC Vlan */
        unit 500 {
            description "ccc interface to SW1";
            encapsulation vlan-ccc;
            vlan-id 500;
        }
        /* VLPS Vlan can co-exist on the same physical */
        unit 600 {
            description "vpls interface to SW1";
            encapsulation vlan-vpls;
            vlan-id 600;
            family vpls;
        }
    }
}

protocols {
    rsvp {
        load-balance bandwidth;
        interface all;
    }
    mpls {
        label-switched-path PE1-to-PE2-LSP1 {
            to 10.1.1.22;
            bandwidth 200m;
            no-cspf;
            primary via-Ge1;
        }
        label-switched-path PE1-to-PE2-LSP2 {
            to 10.1.1.22;
            bandwidth 200m;
            no-cspf;
            primary via-Ge2;
        }
        label-switched-path CCC-PE1-to-PE2 {
            to 10.1.1.22;
            no-cspf;
            primary via-Ge1;
        }
        path via-Ge1 {
            10.10.101.2;
        }
        path via-Ge2 {
            10.10.102.2;
        }
        interface ge-1/0/7.0;
        interface ge-1/1/7.0;
    }
    bgp {
        local-as 65000;
        group PEs {
            type internal;
            local-address 10.1.1.11;
            family inet {
                unicast;
            }
            family inet-vpn {
                unicast;
            }
            family l2vpn {
                signaling;
            }
            neighbor 10.1.1.22;         
        }                               
    }                                   
    ospf {                              
        traffic-engineering;
        area 0.0.0.0 {
            interface ge-1/0/7.0 {
                interface-type p2p;
            }
            interface ge-1/1/7.0 {
                interface-type p2p;
            }
            interface lo0.0;
        }
    }
    connections {
        remote-interface-switch CCC-500 {
            interface ge-1/0/6.500;
            transmit-lsp CCC-PE1-to-PE2;
            receive-lsp CCC-PE2-to-PE1;
        }
    }
}

Verification

lab@PE1> show connections  
CCC and TCC connections [Link Monitoring On]
Legend for status (St)              Legend for connection types
UN -- uninitialized                 if-sw:  interface switching
NP -- not present                   rmt-if: remote interface switching
WE -- wrong encapsulation           lsp-sw: LSP switching
DS -- disabled                      tx-p2mp-sw: transmit P2MP switching
Dn -- down                          rx-p2mp-sw: receive P2MP switching
-> -- only outbound conn is up
 ping 10.50.50.21 source 10.50.50.1 rapid count 5  
PING 10.50.50.21 (10.50.50.21): 56 data bytes
!!!!!
--- 10.50.50.21 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.534/2.228/3.721/0.794 ms

lab@PE1> show mpls lsp statistics     
Ingress LSP: 3 sessions
To              From            State     Packets            Bytes LSPname
10.1.1.22       10.1.1.11       Up              0                0 PE1-to-PE2-LSP1
10.1.1.22       10.1.1.11       Up              0                0 PE1-to-PE2-LSP2
10.1.1.22       10.1.1.11       Up              5              510 CCC-PE1-to-PE2
Total 3 displayed, Up 3, Down 0

Egress LSP: 3 sessions
To              From            State     Packets            Bytes LSPname
10.1.1.11       10.1.1.22       Up             NA               NA PE2-to-PE1-LSP1
10.1.1.11       10.1.1.22       Up             NA               NA PE2-to-PE1-LSP2
10.1.1.11       10.1.1.22       Up              0                0 CCC-PE2-to-PE1
Total 3 displayed, Up 3, Down 0

Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

CCC Topology – VLAN to Port

CCC-VLAN-to-Port

Configuration

[edit]
lab@PE1# show interfaces ge-1/0/8                                                       
description "CCC Ethernet interface to SW1 ge-0/0/0";
encapsulation ethernet-ccc;
unit 0 {
    input-vlan-map {
        push;
        vlan-id 500;
    }
    output-vlan-map pop;
}

[edit]
lab@PE1# show protocols connections 
remote-interface-switch CCC-500 {
    interface ge-1/0/8.0;
    transmit-lsp CCC-PE1-to-PE2;
    receive-lsp CCC-PE2-to-PE1;
}

[edit]
lab@PE2# show interfaces ge-1/0/6        
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
/* CCC Vlan */
unit 500 {
    description "ccc vlan interface to SW2";
    encapsulation vlan-ccc;
    vlan-id 500;
}

[edit]
lab@PE2# show protocols connections 
remote-interface-switch CCC-500 {
    interface ge-1/0/6.500;
    transmit-lsp CCC-PE2-to-PE1;
    receive-lsp CCC-PE1-to-PE2;
}

Verification

lab@PE1> show connections 
CCC and TCC connections [Link Monitoring On]
Legend for status (St)              Legend for connection types
UN -- uninitialized                 if-sw:  interface switching
NP -- not present                   rmt-if: remote interface switching
WE -- wrong encapsulation           lsp-sw: LSP switching
DS -- disabled                      tx-p2mp-sw: transmit P2MP switching
Dn -- down                          rx-p2mp-sw: receive P2MP switching
-> -- only outbound conn is up
 show interfaces ge-1/0/8.0  
  Logical interface ge-1/0/8.0 (Index 355) (SNMP ifIndex 560)
    Flags: SNMP-Traps 0x0 VLAN-Tag In(push 0x8100.500) Out(pop)  Encapsulation: Ethernet-CCC
    Input packets : 6760 
    Output packets: 6866
    Protocol ccc, MTU: 1514
      Flags: Is-Primary

lab@SW1> ping 10.50.50.21 source 10.50.50.1 rapid count 5    
PING 10.50.50.21 (10.50.50.21): 56 data bytes
.....
--- 10.50.50.21 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

{master:0}
lab@SW1> clear arp 
10.50.50.21      deleted
10.50.50.22      deleted

{master:0}
lab@SW1> ping 10.50.50.21 source 10.50.50.1 rapid count 5    
PING 10.50.50.21 (10.50.50.21): 56 data bytes
.!!!!
--- 10.50.50.21 ping statistics ---
5 packets transmitted, 4 packets received, 20% packet loss
round-trip min/avg/max/stddev = 1.964/2.908/5.001/1.224 ms

lab@PE1> show mpls lsp statistics     
Ingress LSP: 3 sessions
To              From            State     Packets            Bytes LSPname
10.1.1.22       10.1.1.11       Up              0                0 PE1-to-PE2-LSP1
10.1.1.22       10.1.1.11       Up              0                0 PE1-to-PE2-LSP2
10.1.1.22       10.1.1.11       Up              5              510 CCC-PE1-to-PE2
Total 3 displayed, Up 3, Down 0