ASD Junho Lee
23 May 2016
NSO Intro, Usecase, Demo
NSO 소개
NSO Intro
• CLI를 기반으로 하는 작업 – Router/Switch è 벤더/제품 마다 명령어
다름
• Web을 기반으로 하는 작업 – Firewall è 요청 때마다 Rule 추가만 함
• Business Agility 요구 증대로 클라우드/가상화의 등장 è 매우
복잡해짐에 따라 수 작업 중심의 관리의 한계
• 네트워크 관리자는
• 버전별 벤더 제품에 대한 전체적인 지식이 요구됨
• 네트워크 현황에 대한 전반적인 History를 파악하고 있어야 함
• 신속한 구성을 할 수 있는 역량이 요구됨
네트워크 관리의 현주소
• CLI를 기반으로 하는 작업 – Router/Switch è 버전별 스크립트를
미리 생성해 두고 활용
• Web을 기반으로 하는작업 – Firewall è 방화벽 처리 업무를
까다롭게 만들어서 시간을 확보
• Business Agility 요구 증대로 클라우드/가상화의 등장 è SDN/NFV의
검토
현행의 어떤 솔루션도 전반적인 해결책을 제공해주지는 못하는 상태임
현행 이슈의 극복 방안
• CLI를 기반으로
하는 작업 –
Router/Switch
Automation vs. Orchestration
• Web을 기반으로
하는작업 –
Firewall
• Business Agility
요구 증대로
클라우드/가상화
Automation Orchestration
• 벤더의 제품, 버전,
및 대수에 관계없이
동일하게 자동 설정
• 방화벽 장비 종류에
상관없이 동일하게
자동 설정
• 요구하는 서비스
형태에 따라
자동으로 설정
• 특정 업무를 위해
순차적으로 장비
자동 설정
• 특정 업무를 위해
순차적으로 장비
자동 설정
• 특정 업무를 위해
순차적으로 장비
설정(VM 생성 포함)
• Router/Switch 업무 è 더 이상 벤더별/버전별, 반복적인 작업을 할
필요가 없어짐
• Firewall 업무 è 방화벽 관리가 서비스에 Binding됨으로 히스토리
관리가 단순해 짐
• 클라우드/가상화 업무 è 서비스 중심으로 운영 업무 제공 가능하며
Under layer에서 일어나는 복잡한 작업에 관여 안해도 됨
Automation/Orchestration은 단순하고 반복적이고 때로는 복잡한
관리 업무를 완화시킬 수 있는 핵심 솔루션
네트워크 관리에 있어서 Automation/Orchestration 의미
jBPM
비즈니스 업무에 대한 순차 처리에 Focus가 되어 있는 관계로
네트워크 업무에 활용하기에는 적합하지 않음
Orchestration 솔루션 소개
Cloudify
TOSCA 기반으로 구현, 클라우드 관점의 순차 처리로 네트워크
업무는 보조적인 수준의 기능을 제공하고 있음
UCSD
Cloupia script 기반으로 구현, 네트워크 관점의 순차 처리로
네트워크 업무에 전문화되어 있으나 지원되는 장비 종류가
한정되어 있음
SNMP
널리 활용되고 있는 네트워크 설정 자동화 기술이나, 표준 규격
없는 MIB의 벤더 별 개별적인 제공으로 CLI에서 처리하는 만큼의
관리 노력이 필요함
Automation 솔루션 소개
Netconf
SNMP의 단점을 극복하기 위해 표준으로 제정하여 네트워크
벤더에서 공통적으로 제공하고 있으나 XML 규격의 복잡성으로
널리 활용되지는 못하고 있음
NSO
SNMP와 Netconf의 단점을 극복하기 위해 네트워크 구성 업무를
MVC 모델로 분리하여 MV는 Yang을 통한 추상화 C는 벤더
스펙에 따라 제공하여 PNF/VNF/VMM에 관계없이 관리 제공
NSO 소개
Network Equipment Drivers (NEDs)
Service Manager
Device Manager
Physical Networks Virtual Networks Network Apps
Service
Model
Device
Model
Applications
REST, NETCONF, Java, Python, Erlang, CLI, Web UI
Engineers
• NSO는 크게 Model과 View를
제공하는 Device
Manager/Service Manager와
Control을 제공하는 NED로
구성됨
• PNF, VNF, VNFM, EMS 등과
연계하여 네트워크 구성
제공함
• 네트워크 장비의 종류와
버전에 관계 없이 구성 제공이
가능함
• 이런 특성을 활용하여 End-
to-End 네트워크 구성을 위한
Orchestration이 가능함
• 구성에 대한 Transaction
기능을 제공함
VNFM
NETCONF, REST, SNMP, CLI, etc
• Controller Apps
• EMS and NMS
• Misc. (e.g. DNS)
“Network Service Orchestrator”
Declarative programming vs. Imperative programming
정의
Imperative
특정 정보를 제공하기 위해
절차적으로 처리하는 방식
일반적인 어플리케이션
개발에 활용됨
Fortran, Basic, C, C++,
Legacy .NET, Legacy Java
Declarative
동일한 구성을 제공하기
위해 상태를 기술하는 방식
서버 구성, 네트워크 구성,
병렬 처리에서 활용됨
Make, Autoconf, Ant, SQL,
Prolog, Scala, Puppet, Chef
용도
예시
Yang 소개 “Yet Another Next Generation”
YANG 은:
• 읽기 쉽고 배우기 쉬움(Java/C 형태의
문법 제공)
• 데이터 모델을 Tree 형태의 구조로
구성할 수 있음(OODB Schema와 유사)
• Struct/Union과 같은 타입 정의를 통한
재사용성
• Augmentation을 통한 모델의 확장 제공
• RPC를 통한 제어 기능 제공
• 데이터 모델의 검증이 가능하도록 제약
조건의 지정이 용이
• 모듈/서브 모듈 개념을 통한 모듈간
부모-자식 관계 설정 가능
• 모델별 버전 관리가 가능함
q 데이터 모델링 언어
§ 네트워크 디바이스의 설정 및 운영
데이터에 대한 모델 정의
§ 네트워크 디바이스에서 발생하는
이벤트에 대한 형식 정의
§ NETCONF 프로토콜의 데이터
모델을 기술하는데 활용
Yang 예시
Data Definitions
Lists with unique constraints
Mandatory constraints
Default values can be provided
NSO 동작 원리
네트워크
관리자
API
관리 웹 사이트
NSO
네트워크
구성 서비스
관리자
해당 서비스
Yang 모델
초기화
CISCO
Device
Template
Juniper
Device
Template
Neutron
Device
Template
etc.
Template
…
NED NED NED NED
Physical Networks Virtual Networks Network Apps
VNFM • Controller Apps
• EMS and NMS
• Misc. (e.g. DNS)
Device Template 예시
CISCO - IOSXR
Juniper - Junos
Mapping Logic
mgmt-fw
rule
source-ip-prefix 10.1.1.0/24
source-port 161 udp
protocol udp
filter
from
source-address
protocol
source port
firewall
then
Yang 모델 Device 템플릿
• Yang 모델을 통한 데이터 정의 è Device 별 Template에 매핑
• 현행 네트워크 관리에 있어서
Rollback 개념은 없음
• 기존 설정을 Backup하고 작업
후 문제 발생 시 전체 원복
실시
• 다수의 장비가 얽힌 경우
원복의 절차가 매우 중요하며
작업자 실수 확률이 매우 높음
1. 소스 관리의 Rollback에 준하는
기능 제공
2. 실 작업 시 Commit Dry-
run/Commit으로 진행하며
3. 문제 발생 시 Commit의
역순으로 Rollback 진행
4. 이전 단계로 모두 원복하는
방법과 특정 시점만 원복하는
방법 제공함
Rollback
NSO Rollback 기능
NSO 전체 아키텍처
Service Manager
Multi-Vendor Network
Network
Engineer
EMS/NMS
NETCONF REST CLI Web UI SNMP JAVA
OSS/BSS
NSO
AAA Core Engine
NETCON
F
SNMP REST CLI
Network Element Drivers
Mapping
Logic
Templates
Fast Map
Device ManagerNotification ReceiverAlarm Manager
Service
Models
Package
Manager
Script API
Device
Models
Developer
API
NSO 전체 아키텍처(NFV 관점)
NFV INFRASTRUCTURE
VNF
Manager(s)
NFVO
OSS (RFS Fulfillment and Service Assurance)
SDN
Controller
DC
Overlay
SDN
CTCM / ESC
VNF3 VNF2 VNF1
Virtualized
Infrastructure
Manager(s)
Openstack
• Generic Orchestration architecture that
spans physical and virtual domains and
migration
• Generic architecture for different use cases
including mobility, vCPE and virtual
Managed Services
PHYSICAL INFRASTRUCTURE
Hypervisor
EMS
BSS
Network Services Orchestrator
NSO Usecase
Customer Example: VPN Provisioning
Business Challenge:
Fast delivery of various types of VPNs (L2 and L3)
and Carrier Ethernet 2.0 services for traffic
separation in a dynamic, programmatic way.
Benefits with NSO:
• Provision complex VPNs spanning 50,000+
devices from multiple vendors using
network-wide, transaction-safe features
• Juniper MX series core routers
• Cisco for PE
• Overture, Adtran and ADVA for CE
• Develop VPN services using CLI templates
of Java
• Support for provisioning, updating and
removing VPNs using minimal diffs
• API integration with customer self-service
portal, OSS, and analytics systems
Customer Example: Firewall Rules Management
Business Challenge:
Automation of firewall provisioning and distributed
ACL rules management
Benefits with NSO:
• Manage ACL rules across multi-vendor
network (e.g. Cisco ASA and Juniper SRX)
• Easy migration for rip-and-replace
• Atomic change sets with full transaction
integrity and auto-rollback
• Model driven architecture allows for
optimization of rules
Juniper
SRX
NSO
Cisco ASA
VMWare
vShield
Rule	1:	SRC:	192.168.1.128/28	DST:	10.26.10.0/23	PROTO:	TCP	PORT:	80
..
Customer Example: British Telecom’s NFV project
NETCONF & YANG
interfaces
NSO
Customer Example: Nokia-Siemens Mobile Transport
NetAct Network
Engineer
NSO
Switches and Routers
• Cisco
• Juniper
• Etc.
Automation of IP service provisioning in mobile transportBusiness Driver:
Public References
85+ Customers Worldwide
§ Domain 2.0: Transformation to cloud-based network (NFV)
• http://www.att.com/gen/press-room?pid=25274&cdvn=news&newsarticleid=37439
§ TeraStream: Transformation to cloud-based network (NFV)
• http://www.tail-f.com/deutsche-telekom-selects-tail-f-as-provider-of-software-defined-
networking-sdn-in-terastream-project/
• http://newsroom.cisco.com/press-release-content?type=webcontent&articleId=1600834
§ Equinix Cloud Exchange: Automated network and service provisioning
• http://newsroom.cisco.com/press-release-content?type=webcontent&articleId=1601082
§ Multi-vendor NFV Trial for vEPC
• https://www.nttdocomo.co.jp/english/info/media_center/pr/2014/1014_00.html
NSO Demo
NSO simpleACL provisioning/Lab topology
Simulated IOS-XR
127.0.0.1:12001 - 4
NSO server
localhost:8080/login
Simulated JunOS
127.0.0.1:12205 - 8
1. 데모 목적
• NSO를 이용하여 IX계위에 존재하는 MX, XR 라우터들의 특정 인터페이스에 동일한 ACL을 동일 방향으로
적용/삭제.
2. 데모 대상 장비 선택
• Juniper MX router 4대 (simulator) : mx0 (=>hostname) ~mx3
• Cisco XR router 4대 (simulator) : pe0 (=>hostname), ~pe3
3. 적용할 ACL 정의
• 5 Tuple 사용
• source-ip
• source-port
• destination-ip
• destination-port
• protocol
NSO simpleACL provisioning/Test Scenario
고객별로 특정 장비, 특정 인터페이스에 적용 ACL이 적용되므로 pre-defined된 고객별 ACL
적용 profile을 서비스로 정의하고, 위에 정의된 ACL을 적용하도록 함.
NSO simpleACL provisioning/Yang model
Juniper Firewall Filter와 Cisco ACL 설정 비교
device junos0
config {
junos:configuration {
firewall {
+ filter acl {
+ term 10 {
+ from {
+ source-address 172.1.0.0/24;
+ destination-address 200.1.0.0/24;
+ protocol [ udp ];
+ source-port [ 1000 ];
+ destination-port [ 2000 ];
+ }
+ then {
+ accept;
+ }
+ }
+ term 20 {
+ from {
+ source-address 172.2.2.0/24;
+ source-address 172.2.1.0/24;
+ source-address 172.2.0.0/24;
+ }
+ then {
+ accept;
+ }
+ }
+ term 30 {
+ from {
+ destination-address 192.168.0.0/24;
+ destination-address 192.168.1.0/24;
+ destination-address 192.168.2.0/24;
+ }
+ then {
+ discard {
+ }
+ }
+ }
+ }
}
}
}
device xr0
config {
cisco-ios-xr:ipv4 {
access-list {
+ named-acl acl {
+ rule 10 {
+ line "permit udp 172.1.0.0/24 eq 1000 200.1.0.0/24 eq 2000";
+ }
+ rule 20 {
+ line "permit ipv4 172.2.2.0/24 any";
+ }
+ rule 30 {
+ line "permit ipv4 172.2.1.0/24 any";
+ }
+ rule 40 {
+ line "permit ipv4 172.2.0.0/24 any";
+ }
+ rule 50 {
+ line "deny ipv4 any 192.168.0.0/24";
+ }
+ rule 60 {
+ line "deny ipv4 any 192.168.1.0/24";
+ }
+ rule 70 {
+ line "deny ipv4 any 192.168.2.0/24";
+ }
+ }
}
}
}
ACL name
seq id
action
match condition
Source IP Dest IPProtocol Source Port Dest Port
Juniper Firewall Filter와 Cisco ACL 적용 비교
device xr0
config {
cisco-ios-xr:interface {
TenGigE 0/0/0/0 {
ipv4 {
+ access-group egress {
+ acl;
+ }
access-group ingress {
+ acl;
}
}
}
TenGigE 0/0/0/1 {
ipv4 {
access-group ingress {
+ acl;
}
}
}
}
}
device junos0
config {
junos:configuration {
interfaces {
interface xe-0/0/0 {
unit 0 {
filter {
+ input acl;
+ output acl
}
}
}
interface xe-0/0/1 {
unit 0 {
filter {
+ input acl;
}
}
}
}
}
}
ACL Interface
ACL name
ACL direction
적용 결과
적용 결과
적용 결과
NSO Introduction

NSO Introduction

  • 1.
    ASD Junho Lee 23May 2016 NSO Intro, Usecase, Demo NSO 소개
  • 2.
  • 3.
    • CLI를 기반으로하는 작업 – Router/Switch è 벤더/제품 마다 명령어 다름 • Web을 기반으로 하는 작업 – Firewall è 요청 때마다 Rule 추가만 함 • Business Agility 요구 증대로 클라우드/가상화의 등장 è 매우 복잡해짐에 따라 수 작업 중심의 관리의 한계 • 네트워크 관리자는 • 버전별 벤더 제품에 대한 전체적인 지식이 요구됨 • 네트워크 현황에 대한 전반적인 History를 파악하고 있어야 함 • 신속한 구성을 할 수 있는 역량이 요구됨 네트워크 관리의 현주소
  • 4.
    • CLI를 기반으로하는 작업 – Router/Switch è 버전별 스크립트를 미리 생성해 두고 활용 • Web을 기반으로 하는작업 – Firewall è 방화벽 처리 업무를 까다롭게 만들어서 시간을 확보 • Business Agility 요구 증대로 클라우드/가상화의 등장 è SDN/NFV의 검토 현행의 어떤 솔루션도 전반적인 해결책을 제공해주지는 못하는 상태임 현행 이슈의 극복 방안
  • 5.
    • CLI를 기반으로 하는작업 – Router/Switch Automation vs. Orchestration • Web을 기반으로 하는작업 – Firewall • Business Agility 요구 증대로 클라우드/가상화 Automation Orchestration • 벤더의 제품, 버전, 및 대수에 관계없이 동일하게 자동 설정 • 방화벽 장비 종류에 상관없이 동일하게 자동 설정 • 요구하는 서비스 형태에 따라 자동으로 설정 • 특정 업무를 위해 순차적으로 장비 자동 설정 • 특정 업무를 위해 순차적으로 장비 자동 설정 • 특정 업무를 위해 순차적으로 장비 설정(VM 생성 포함)
  • 6.
    • Router/Switch 업무è 더 이상 벤더별/버전별, 반복적인 작업을 할 필요가 없어짐 • Firewall 업무 è 방화벽 관리가 서비스에 Binding됨으로 히스토리 관리가 단순해 짐 • 클라우드/가상화 업무 è 서비스 중심으로 운영 업무 제공 가능하며 Under layer에서 일어나는 복잡한 작업에 관여 안해도 됨 Automation/Orchestration은 단순하고 반복적이고 때로는 복잡한 관리 업무를 완화시킬 수 있는 핵심 솔루션 네트워크 관리에 있어서 Automation/Orchestration 의미
  • 7.
    jBPM 비즈니스 업무에 대한순차 처리에 Focus가 되어 있는 관계로 네트워크 업무에 활용하기에는 적합하지 않음 Orchestration 솔루션 소개 Cloudify TOSCA 기반으로 구현, 클라우드 관점의 순차 처리로 네트워크 업무는 보조적인 수준의 기능을 제공하고 있음 UCSD Cloupia script 기반으로 구현, 네트워크 관점의 순차 처리로 네트워크 업무에 전문화되어 있으나 지원되는 장비 종류가 한정되어 있음
  • 8.
    SNMP 널리 활용되고 있는네트워크 설정 자동화 기술이나, 표준 규격 없는 MIB의 벤더 별 개별적인 제공으로 CLI에서 처리하는 만큼의 관리 노력이 필요함 Automation 솔루션 소개 Netconf SNMP의 단점을 극복하기 위해 표준으로 제정하여 네트워크 벤더에서 공통적으로 제공하고 있으나 XML 규격의 복잡성으로 널리 활용되지는 못하고 있음 NSO SNMP와 Netconf의 단점을 극복하기 위해 네트워크 구성 업무를 MVC 모델로 분리하여 MV는 Yang을 통한 추상화 C는 벤더 스펙에 따라 제공하여 PNF/VNF/VMM에 관계없이 관리 제공
  • 9.
    NSO 소개 Network EquipmentDrivers (NEDs) Service Manager Device Manager Physical Networks Virtual Networks Network Apps Service Model Device Model Applications REST, NETCONF, Java, Python, Erlang, CLI, Web UI Engineers • NSO는 크게 Model과 View를 제공하는 Device Manager/Service Manager와 Control을 제공하는 NED로 구성됨 • PNF, VNF, VNFM, EMS 등과 연계하여 네트워크 구성 제공함 • 네트워크 장비의 종류와 버전에 관계 없이 구성 제공이 가능함 • 이런 특성을 활용하여 End- to-End 네트워크 구성을 위한 Orchestration이 가능함 • 구성에 대한 Transaction 기능을 제공함 VNFM NETCONF, REST, SNMP, CLI, etc • Controller Apps • EMS and NMS • Misc. (e.g. DNS) “Network Service Orchestrator”
  • 10.
    Declarative programming vs.Imperative programming 정의 Imperative 특정 정보를 제공하기 위해 절차적으로 처리하는 방식 일반적인 어플리케이션 개발에 활용됨 Fortran, Basic, C, C++, Legacy .NET, Legacy Java Declarative 동일한 구성을 제공하기 위해 상태를 기술하는 방식 서버 구성, 네트워크 구성, 병렬 처리에서 활용됨 Make, Autoconf, Ant, SQL, Prolog, Scala, Puppet, Chef 용도 예시
  • 11.
    Yang 소개 “YetAnother Next Generation” YANG 은: • 읽기 쉽고 배우기 쉬움(Java/C 형태의 문법 제공) • 데이터 모델을 Tree 형태의 구조로 구성할 수 있음(OODB Schema와 유사) • Struct/Union과 같은 타입 정의를 통한 재사용성 • Augmentation을 통한 모델의 확장 제공 • RPC를 통한 제어 기능 제공 • 데이터 모델의 검증이 가능하도록 제약 조건의 지정이 용이 • 모듈/서브 모듈 개념을 통한 모듈간 부모-자식 관계 설정 가능 • 모델별 버전 관리가 가능함 q 데이터 모델링 언어 § 네트워크 디바이스의 설정 및 운영 데이터에 대한 모델 정의 § 네트워크 디바이스에서 발생하는 이벤트에 대한 형식 정의 § NETCONF 프로토콜의 데이터 모델을 기술하는데 활용
  • 12.
    Yang 예시 Data Definitions Listswith unique constraints Mandatory constraints Default values can be provided
  • 13.
    NSO 동작 원리 네트워크 관리자 API 관리웹 사이트 NSO 네트워크 구성 서비스 관리자 해당 서비스 Yang 모델 초기화 CISCO Device Template Juniper Device Template Neutron Device Template etc. Template … NED NED NED NED Physical Networks Virtual Networks Network Apps VNFM • Controller Apps • EMS and NMS • Misc. (e.g. DNS)
  • 14.
    Device Template 예시 CISCO- IOSXR Juniper - Junos
  • 15.
    Mapping Logic mgmt-fw rule source-ip-prefix 10.1.1.0/24 source-port161 udp protocol udp filter from source-address protocol source port firewall then Yang 모델 Device 템플릿 • Yang 모델을 통한 데이터 정의 è Device 별 Template에 매핑
  • 16.
    • 현행 네트워크관리에 있어서 Rollback 개념은 없음 • 기존 설정을 Backup하고 작업 후 문제 발생 시 전체 원복 실시 • 다수의 장비가 얽힌 경우 원복의 절차가 매우 중요하며 작업자 실수 확률이 매우 높음 1. 소스 관리의 Rollback에 준하는 기능 제공 2. 실 작업 시 Commit Dry- run/Commit으로 진행하며 3. 문제 발생 시 Commit의 역순으로 Rollback 진행 4. 이전 단계로 모두 원복하는 방법과 특정 시점만 원복하는 방법 제공함 Rollback NSO Rollback 기능
  • 17.
    NSO 전체 아키텍처 ServiceManager Multi-Vendor Network Network Engineer EMS/NMS NETCONF REST CLI Web UI SNMP JAVA OSS/BSS NSO AAA Core Engine NETCON F SNMP REST CLI Network Element Drivers Mapping Logic Templates Fast Map Device ManagerNotification ReceiverAlarm Manager Service Models Package Manager Script API Device Models Developer API
  • 18.
    NSO 전체 아키텍처(NFV관점) NFV INFRASTRUCTURE VNF Manager(s) NFVO OSS (RFS Fulfillment and Service Assurance) SDN Controller DC Overlay SDN CTCM / ESC VNF3 VNF2 VNF1 Virtualized Infrastructure Manager(s) Openstack • Generic Orchestration architecture that spans physical and virtual domains and migration • Generic architecture for different use cases including mobility, vCPE and virtual Managed Services PHYSICAL INFRASTRUCTURE Hypervisor EMS BSS Network Services Orchestrator
  • 19.
  • 20.
    Customer Example: VPNProvisioning Business Challenge: Fast delivery of various types of VPNs (L2 and L3) and Carrier Ethernet 2.0 services for traffic separation in a dynamic, programmatic way. Benefits with NSO: • Provision complex VPNs spanning 50,000+ devices from multiple vendors using network-wide, transaction-safe features • Juniper MX series core routers • Cisco for PE • Overture, Adtran and ADVA for CE • Develop VPN services using CLI templates of Java • Support for provisioning, updating and removing VPNs using minimal diffs • API integration with customer self-service portal, OSS, and analytics systems
  • 21.
    Customer Example: FirewallRules Management Business Challenge: Automation of firewall provisioning and distributed ACL rules management Benefits with NSO: • Manage ACL rules across multi-vendor network (e.g. Cisco ASA and Juniper SRX) • Easy migration for rip-and-replace • Atomic change sets with full transaction integrity and auto-rollback • Model driven architecture allows for optimization of rules Juniper SRX NSO Cisco ASA VMWare vShield Rule 1: SRC: 192.168.1.128/28 DST: 10.26.10.0/23 PROTO: TCP PORT: 80 ..
  • 22.
    Customer Example: BritishTelecom’s NFV project NETCONF & YANG interfaces NSO
  • 23.
    Customer Example: Nokia-SiemensMobile Transport NetAct Network Engineer NSO Switches and Routers • Cisco • Juniper • Etc. Automation of IP service provisioning in mobile transportBusiness Driver:
  • 24.
    Public References 85+ CustomersWorldwide § Domain 2.0: Transformation to cloud-based network (NFV) • http://www.att.com/gen/press-room?pid=25274&cdvn=news&newsarticleid=37439 § TeraStream: Transformation to cloud-based network (NFV) • http://www.tail-f.com/deutsche-telekom-selects-tail-f-as-provider-of-software-defined- networking-sdn-in-terastream-project/ • http://newsroom.cisco.com/press-release-content?type=webcontent&articleId=1600834 § Equinix Cloud Exchange: Automated network and service provisioning • http://newsroom.cisco.com/press-release-content?type=webcontent&articleId=1601082 § Multi-vendor NFV Trial for vEPC • https://www.nttdocomo.co.jp/english/info/media_center/pr/2014/1014_00.html
  • 25.
  • 26.
    NSO simpleACL provisioning/Labtopology Simulated IOS-XR 127.0.0.1:12001 - 4 NSO server localhost:8080/login Simulated JunOS 127.0.0.1:12205 - 8
  • 27.
    1. 데모 목적 •NSO를 이용하여 IX계위에 존재하는 MX, XR 라우터들의 특정 인터페이스에 동일한 ACL을 동일 방향으로 적용/삭제. 2. 데모 대상 장비 선택 • Juniper MX router 4대 (simulator) : mx0 (=>hostname) ~mx3 • Cisco XR router 4대 (simulator) : pe0 (=>hostname), ~pe3 3. 적용할 ACL 정의 • 5 Tuple 사용 • source-ip • source-port • destination-ip • destination-port • protocol NSO simpleACL provisioning/Test Scenario
  • 28.
    고객별로 특정 장비,특정 인터페이스에 적용 ACL이 적용되므로 pre-defined된 고객별 ACL 적용 profile을 서비스로 정의하고, 위에 정의된 ACL을 적용하도록 함. NSO simpleACL provisioning/Yang model
  • 29.
    Juniper Firewall Filter와Cisco ACL 설정 비교 device junos0 config { junos:configuration { firewall { + filter acl { + term 10 { + from { + source-address 172.1.0.0/24; + destination-address 200.1.0.0/24; + protocol [ udp ]; + source-port [ 1000 ]; + destination-port [ 2000 ]; + } + then { + accept; + } + } + term 20 { + from { + source-address 172.2.2.0/24; + source-address 172.2.1.0/24; + source-address 172.2.0.0/24; + } + then { + accept; + } + } + term 30 { + from { + destination-address 192.168.0.0/24; + destination-address 192.168.1.0/24; + destination-address 192.168.2.0/24; + } + then { + discard { + } + } + } + } } } } device xr0 config { cisco-ios-xr:ipv4 { access-list { + named-acl acl { + rule 10 { + line "permit udp 172.1.0.0/24 eq 1000 200.1.0.0/24 eq 2000"; + } + rule 20 { + line "permit ipv4 172.2.2.0/24 any"; + } + rule 30 { + line "permit ipv4 172.2.1.0/24 any"; + } + rule 40 { + line "permit ipv4 172.2.0.0/24 any"; + } + rule 50 { + line "deny ipv4 any 192.168.0.0/24"; + } + rule 60 { + line "deny ipv4 any 192.168.1.0/24"; + } + rule 70 { + line "deny ipv4 any 192.168.2.0/24"; + } + } } } } ACL name seq id action match condition Source IP Dest IPProtocol Source Port Dest Port
  • 30.
    Juniper Firewall Filter와Cisco ACL 적용 비교 device xr0 config { cisco-ios-xr:interface { TenGigE 0/0/0/0 { ipv4 { + access-group egress { + acl; + } access-group ingress { + acl; } } } TenGigE 0/0/0/1 { ipv4 { access-group ingress { + acl; } } } } } device junos0 config { junos:configuration { interfaces { interface xe-0/0/0 { unit 0 { filter { + input acl; + output acl } } } interface xe-0/0/1 { unit 0 { filter { + input acl; } } } } } } ACL Interface ACL name ACL direction
  • 31.
  • 32.
  • 33.