IPv6: Verwendung von /127er Prefixen

Unter IPv4 ist heutzutage die Verwendung von /30er oder /31er Netzen auf Point-to-Point-Links der Standard. Während früher Links noch häufig mit einer 30-bit Maske konfiguriert, und auch auf Point-to-Point-Links eine Netz- und Broadcast-Adresse vorsehen wurde, so verwendet man heute fast ausschließlich /31er Netze um keine Adressen zu verschwenden. Und besser rechnen lässt sich mit /31er Adressen auch.

Im IPv6 wurde die Verwendung von /127er Netzen lange Zeit sehr kontrovers diskutiert. Oftmals wurden diese mit Hinweis auf die nicht-Konformität mit den geltenden RFCs abgelehnt. Vielfach wurde es auch einfach damit begründet, dass man im IPv6 keine Adressen sparen müsse.

Jetzt haben die /127er Netze im IPv6 aber doch den offiziellen Segen des IETFs bekommen:

RFC 6164: Using 127-Bit IPv6 Prefixes on Inter-Router Links

Während ich mir des “Ping-Pong”-Problems bisher nicht bewusst war (Section 5.1), hat mich das Problem der Neighbor Cache Exhaustion (Section 5.2) auch schon beschäftigt und ich fand die Verwendung von /127er Netzen auch keine schlechte Idee.

Schön, das man diese Prefixe jetzt auch “offiziell” auf Inter-Router Links verwenden darf.

Advertisements
IPv6: Verwendung von /127er Prefixen

Ethernet-Bridging über MPLS

Der Cisco MPLS-Kurs ist zwar im großen und ganzen recht “rund”, beschränkt sich aber fast ausschließlich auf MPLS-VPNs für IPv4. Das man auch andere Protokolle transportieren kann ist nur am Rande erwähnt. Dafür habe ich hier ein kleines Beispiel wie man mit AToM (AnyTransport over MPLS) zwei Standorte per Bridging über das MPLS verbindet:

Als Router kommen mal wieder 7200er (im GNS3) mit IOS 15.0(1)M4 zum Einsatz:

Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), Version 15.0(1)M4, RELEASE SOFTWARE (fc1)

Die fa0/0-Interfaces der Router C1 und C2 sollen sich dabei in einem IP-Netz (hier in einem IPv6-Netz) befinden und sich ohne eine Routing-Instanz erreichen können.

hostname C1
!
interface FastEthernet0/0
 description Link zum CE1
 no ip address
 ipv6 address 2001:DB8:1111::1/64
hostname C2
!
interface FastEthernet0/0
 description Link zum CE2
 no ip address
 ipv6 address 2001:DB8:1111::2/64

Die CE-Router müssen dafür IPv6 transparent bridgen. Das kann über eine traditionelle Bridge-Group erreicht werden:

bridge irb
!         
interface FastEthernet0/0
 description Link zum C1
 no ip address
 bridge-group 1
!         
interface FastEthernet0/1
 description Link zum PE1
 no ip address
 bridge-group 1
!
bridge 1 protocol ieee

Die PE-Router haben eine normale MPLS-Konfiguration, verwenden aber für AToM keine MPLS-VPNs, sondern sogenannte “Pseudo-Wires“. Daher werden auch keine VRF- oder BGP-Instanzen benötigt. Das ist im einfachsten Fall wie ein virtuelles Kabel zwischen zwei PE-Routern zu verstehen. Die Pseudo-Wires werden mit dem Befehl xconnect zwischen den Loopback-Adressen der PE-Router konfiguriert:

hostname PE1
!
interface Loopback0
 ip address 10.10.10.1 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/1
 description Link zum CE1
 no ip address
 xconnect 10.10.10.2 100 encapsulation mpls
!

Auf dem PE 1 wird also ein Pseudowire mit der Virtual Circuit-ID von 100 vom aktuellen Router zur Loopback des PE2 (10.10.10.2) aufgebaut. Der Transport läuft über das schon vorhandene MPLS.
Da diese Pseudo-Wire unidirektional arbeiten, wird das gleiche auch auf dem PE2 konfiguriert:

hostname PE2
!
interface Loopback0
 ip address 10.10.10.2 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/1
 description Link zum CE2
 no ip address
 xconnect 10.10.10.1 100 encapsulation mpls
!

Die PE-Router verwenden für den Austausch des VC-Labels eine gerichtete LDP-Sitzung:

PE1#sh mpls ldp neighbor 10.10.10.2
    Peer LDP Ident: 10.10.10.2:0; Local LDP Ident 10.10.10.1:0
	TCP connection: 10.10.10.2.45592 - 10.10.10.1.646
	State: Oper; Msgs sent/rcvd: 117/118; Downstream
	Up time: 01:33:43
	LDP discovery sources:
	  Targeted Hello 10.10.10.1 -> 10.10.10.2, active, passive
        Addresses bound to peer LDP Ident:
          10.10.2.1       10.10.10.2      

In meinem Setup hat der PE1 dem PE2 ein VC-Label von 1100 angekündigt, und ein VC-Label von 1200 erhalten:

PE1#sh mpls l2transport binding 
  Destination Address: 10.10.10.2,  VC ID: 100
    Local Label:  1100
        Cbit: 1,    VC Type: Ethernet,    GroupID: 0
        MTU: 1500,   Interface Desc: Link zum CE1
        VCCV: CC Type: CW [1], RA [2]
              CV Type: LSPV [2]
    Remote Label: 1200
        Cbit: 1,    VC Type: Ethernet,    GroupID: 0
        MTU: 1500,   Interface Desc: Link zum CE2
        VCCV: CC Type: CW [1], RA [2]
              CV Type: LSPV [2]

Die Eigenschaften des Virtual Circuits:

PE1#sh mpls l2transport vc 

Local intf     Local circuit              Dest address    VC ID      Status    
-------------  -------------------------- --------------- ---------- ----------
Fa0/1          Ethernet                   10.10.10.2      100        UP        

PE1#
PE1#
PE1#sh mpls l2transport vc 100 detail       
Local interface: Fa0/1 up, line protocol up, Ethernet up
  Destination address: 10.10.10.2, VC ID: 100, VC status: up
    Output interface: Se1/0, imposed label stack {1000 1200}
    Preferred path: not configured  
    Default path: active
    Next hop: point2point
  Create time: 00:10:27, last status change time: 00:09:58
  Signaling protocol: LDP, peer 10.10.10.2:0 up
    Targeted Hello: 10.10.10.1(LDP Id) -> 10.10.10.2
    Status TLV support (local/remote)   : enabled/supported
      Label/status state machine        : established, LruRru
      Last local dataplane   status rcvd: no fault
      Last local SSS circuit status rcvd: no fault
      Last local SSS circuit status sent: no fault
      Last local  LDP TLV    status sent: no fault
      Last remote LDP TLV    status rcvd: no fault
    MPLS VC labels: local 1100, remote 1200 
    Group ID: local 0, remote 0
    MTU: local 1500, remote 1500
    Remote interface description: Link zum CE2
  Sequencing: receive disabled, send disabled
  VC statistics:
    packet totals: receive 377, send 76
    byte totals:   receive 25754, send 8835
    packet drops:  receive 0, seq error 0, send 0

Nachdem alles konfiguriert wurde kann die Verbindung getestet werden:

C1#ping ipv6 2001:DB8:1111::2 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2001:DB8:1111::2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 36/36/36 ms
C1#
C2#
*Apr 12 14:59:25.659: ICMPv6: Received echo request, Src=2001:DB8:1111::1, Dst=2001:DB8:1111::2
*Apr 12 14:59:25.663: ICMPv6: Sent echo reply, Src=2001:DB8:1111::2, Dst=2001:DB8:1111::1
C2#

Im Capture auf dem Link zwischen PE1 und PE kann man die zwei Label und den darüber transportierten Ethernet-Frame sehen:

No.     Time        Source                Destination           Protocol Info
    299 146.171341  2001:db8:1111::1      2001:db8:1111::2      ICMPv6   Echo (ping) request id=0x0fc4, seq=0

Frame 299: 130 bytes on wire (1040 bits), 130 bytes captured (1040 bits)
Cisco HDLC
MultiProtocol Label Switching Header, Label: 1000, Exp: 0, S: 0, TTL: 255
MultiProtocol Label Switching Header, Label: 1200, Exp: 0, S: 1, TTL: 255
PW Ethernet Control Word
Ethernet II, Src: ca:05:ac:17:00:08 (ca:05:ac:17:00:08), Dst: ca:06:ac:18:00:08 (ca:06:ac:18:00:08)
Internet Protocol Version 6, Src: 2001:db8:1111::1 (2001:db8:1111::1), Dst: 2001:db8:1111::2 (2001:db8:1111::2)
Internet Control Message Protocol v6

Das äußere Label (1000) ist das vom P-Router generierte Transport-Label zum PE2, das innere Label (1200) ist das vom PE2 generierte VC-Label.

Bleibt zu klären, warum ich bei diesem Beispiel entgegen meiner früheren Ankündigung das SP-Netz mit IPv4 anstelle IPv6 aufgebaut habe. Das liegt daran, das LDP noch nicht über IPv6 laufen kann.

Ethernet-Bridging über MPLS