Kategorie: wan

Veröffentlicht am

Cisco CSR1000v – additional Interfaces? vNIC Hot-Add!

My apprehension – a weird nightmare of having to shutdown the router, add the nic and boot the router again – proved wrong.
vNIC Hot-Add is supported for VMware ESXi, Citrix XenServer and KVM
Not for Hyper-V, Azure, AWS today.
Cisco: Virtual Machine Requirements
…up to 10 vNICs for ESXi btw.

  • Starting with three default-interfaces
IOS-RTR#show ip int brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet1       192.168.2.13    YES NVRAM  up                    up
GigabitEthernet2       unassigned      YES NVRAM  administratively down down
GigabitEthernet3       unassigned      YES NVRAM  administratively down down
  • select the VM
  • go to „Edit Settings“
vSphere Client: Add Hardware
vSphere Client: Add Hardware
Add Ethernet NIC
Select NIC-Type „VMXNET3“
  • Next, Next, Finish
  • be patient
Dec 16 14:56:10.165: %LINK-5-CHANGED: Interface GigabitEthernet4, changed state to administratively down
Dec 16 14:56:11.166: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet4, changed state to down

IOS-RTR#show ip int brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet1       192.168.2.13    YES NVRAM  up                    up
GigabitEthernet2       unassigned      YES NVRAM  administratively down down
GigabitEthernet3       unassigned      YES NVRAM  administratively down down
GigabitEthernet4       unassigned      YES unset  administratively down down

…Hot-Remove is supported only using a special „two-step“ strategy

Veröffentlicht am

WAN MACsec – Encrypting Ethernet-Frames in the WAN

Not talking about ATM, PPP, HDLC, Frame Relay WAN. Ethernet is the new WAN.

Sometimes you need an easy to use encryption, which is just added to a Link between two devices – and you don’t want to invent IPSec-VPNs which at least add complexity to the design.

MACsec solved this problem bringing absolutely transparent encryption, but – since MACsec-Sessions are sent to a „link-local“ ethernet destination address (01-80-c2-00-00-03) they aren’t allowed to be forwarded by any device. A typical „non-dark-fiber“ WAN-Link can’t be encrypted using MACsec.

http://www.ieee802.org/1/files/public/docs2013/ae-seaman-macsec-hops-0213-v02.pdf discussed years ago the elegant technical solution.

Years later these thoughts are moving into production: Cisco invented „WAN MACsec“:

  • simply allowing the network-designer to change destination-mac-address and the ethernet-frametype.

This makes it possible for active provider devices to forward MACsec-Sessions through the WAN so the WAN-Customers could create a virtual encrypted link between sites, completely transparent
https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/identity-based-networking-services/white-paper-c11-737544.html

This example shows the most simple suggestion:

  • change the destination-mac from link-local-multicast to broadcast 😉

Router A

key chain KC_WAN macsec
 key 1
   key-string PASSWORD
interface GigabitEthernet0/0/0
  ip address 10.0.0.1 255.255.255.252 
  eapol destination-address broadcast
  mka pre-shared-key key-chain KC_WAN
  macsec

Router B

key chain KC_WAN macsec
 key 1
   key-string PASSWORD
interface GigabitEthernet0/0/0
  ip address 10.0.0.2 255.255.255.252
  eapol destination-address broadcast 
  mka pre-shared-key key-chain KC_WAN
  macsec

Might make sense to change the cipher, increase the anti-reply-window etc…