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 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”
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 소개 “Yet Another Next Generation”
YANG 은:
• 읽기 쉽고 배우기 쉬움(Java/C 형태의
문법 제공)
• 데이터 모델을 Tree 형태의 구조로
구성할 수 있음(OODB Schema와 유사)
• Struct/Union과 같은 타입 정의를 통한
재사용성
• Augmentation을 통한 모델의 확장 제공
• RPC를 통한 제어 기능 제공
• 데이터 모델의 검증이 가능하도록 제약
조건의 지정이 용이
• 모듈/서브 모듈 개념을 통한 모듈간
부모-자식 관계 설정 가능
• 모델별 버전 관리가 가능함
q 데이터 모델링 언어
§ 네트워크 디바이스의 설정 및 운영
데이터에 대한 모델 정의
§ 네트워크 디바이스에서 발생하는
이벤트에 대한 형식 정의
§ NETCONF 프로토콜의 데이터
모델을 기술하는데 활용
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)
16. • 현행 네트워크 관리에 있어서
Rollback 개념은 없음
• 기존 설정을 Backup하고 작업
후 문제 발생 시 전체 원복
실시
• 다수의 장비가 얽힌 경우
원복의 절차가 매우 중요하며
작업자 실수 확률이 매우 높음
1. 소스 관리의 Rollback에 준하는
기능 제공
2. 실 작업 시 Commit Dry-
run/Commit으로 진행하며
3. 문제 발생 시 Commit의
역순으로 Rollback 진행
4. 이전 단계로 모두 원복하는
방법과 특정 시점만 원복하는
방법 제공함
Rollback
NSO Rollback 기능
17. 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
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
20. 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
21. 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
..
23. 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:
24. 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
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