17/02/2017

Cisco – ASR 920 EoMPLS

Quick and dirty ein 10mbit L2VPN aka VLL aka E-Line aka EVPL aka VPWS aka pseudo-wire oder wie auch immer man sagen mag zwischen zwei Cisco ASR 920.

ASR 920 – 1:

policy-map 10m
 class class-default
  police 10000000

interface GigabitEthernet0/0/0
 mtu 1540
 no ip address
 negotiation auto
 no keepalive
 service instance 1 ethernet
  encapsulation default
  l2protocol forward
  service-policy input 10m
  service-policy output 10m
  xconnect 10.1.1.2 1 encapsulation mpls

 

ASR 920 – 2:

policy-map 10m
 class class-default
  police 10000000

interface GigabitEthernet0/0/0
 mtu 1540
 no ip address
 negotiation auto
 no keepalive
 service instance 1 ethernet
  encapsulation default
  l2protocol forward
  service-policy input 10m
  service-policy output 10m
  xconnect 10.1.1.1 1 encapsulation mpls

 

Schaut dann zB so aus:

Router#sh mpls l2transport vc 1 detail
Local interface: Gi0/0/0 up, line protocol up, Ethernet:1 up
  Destination address: 10.1.1.2, VC ID: 1, VC status: up
    Output interface: Te0/0/26, imposed label stack {19}
    Preferred path: not configured
    Default path: active
    Next hop: 10.100.1.2
  Create time: 00:52:42, last status change time: 00:23:50
    Last label FSM state change time: 00:27:24
  Signaling protocol: LDP, peer 10.1.1.2:0 up
    Targeted Hello: 10.1.1.1(LDP Id) -> 10.1.1.2, LDP is UP
    Graceful restart: not configured and not enabled
    Non stop routing: not configured and not enabled
    Status TLV support (local/remote)   : enabled/supported
      LDP route watch                   : enabled
      Label/status state machine        : established, LruRru
      Last local dataplane   status rcvd: No fault
      Last BFD dataplane     status rcvd: Not sent
      Last BFD peer monitor  status rcvd: No fault
      Last local AC  circuit status rcvd: No fault
      Last local AC  circuit status sent: No fault
      Last local PW i/f circ status rcvd: No fault
      Last local LDP TLV     status sent: No fault
      Last remote LDP TLV    status rcvd: No fault
      Last remote LDP ADJ    status rcvd: No fault
    MPLS VC labels: local 18, remote 19
    Group ID: local 6, remote 6
    MTU: local 1540, remote 1540
    Remote interface description:
  Sequencing: receive disabled, send disabled
  Control Word: On (configured: autosense)
  SSO Descriptor: 10.1.1.2/1, local label: 18
  Dataplane:
    SSM segment/switch IDs: 4101/4098 (used), PWID: 1
  VC statistics:
    transit packet totals: receive 66256, send 780668
    transit byte totals:   receive 98696217, send 1182578416
    transit packet drops:  receive 0, seq error 0, send 0


Router#

 
bzw so:

Router#sh ethernet service instance detail
Service Instance ID: 1
Service Instance Type: Static
Associated Interface: GigabitEthernet0/0/0
Associated EVC:
L2protocol forward
CE-Vlans:
Encapsulation: default
Interface Dot1q Tunnel Ethertype: 0x8100
State: Up
EFP Statistics:
   Pkts In   Bytes In   Pkts Out  Bytes Out
    805908 1220567334      41307   60820702

Router#

Es wuerde natuerlich reichen, wenn wir die service-policy jeweils nur eingehend montieren, aber als Test (fuer mich) und weil man ja nie weiss, was in welcher Richtung auf welcher Plattform unterstuetzt ist habe ich es mal in jeweils beide Richtungen probiert. Wenn ich input und output nur auf einem der beiden Router mache, dann funktioniert das trotzdem perfekt (auch wenn in der Praxis wahrscheinlich 2x input besser waere).

 

So sieht das aus:

Ich habe einen Bandwidth Test mit 20mbit gestartet, dieser wurde aber vom ASR bzw seiner service-policy sauber auf 10mbit geschraepft. Ausserdem gingen auch doppelt getaggte Frames (von VLAN 20 auf VLAN 20 am gegenueberliegenden MikroTik) durch (mit entsprechender MTU). Den gegenueberliegenden MikroTik sahen wir auch als Neighbor, aufgrund des l2protocol forward in der service-instance.

Die MTU muss uebrigens natuerlich auch am Link zwischen den ASRs und auf den MikroTiks selbst stimmen bzw der Praxis entsprechen.