[Ryu_OpenFlow 1.3]

스위칭 허브

김지은

yeswldms@gmail.com

Flooding

• 플러딩이란?

: 포트를 통해 들어온 하나의 패킷을 라우터에 접속된 다른 모든 포트로 보내는 것

: 대규모의 네트워크 환경에서 플러딩을 이용하여 수정된 라우팅 정보를 모든 포트로 빠르게 전달

• 플러딩이 발생하는 경우 브로드캐스트로 인한 네트워크 성능 우려

1) MAC 주소 테이블이 완전 비어있는 경우 - 모든 포트를 통해 패킷을 전송

2) MAC 주소 테이블이 가득 차 있는 경우 – 스피닝과 같은 공격을 통해 MAC주소 테이블이 가능차게 되는 경우 모든 포트를 통해 전송

3) 프레임의 목적지 MAC주소가 MAC주소 테이블에 없는 경우나 다른 경우 – 모든 포트로 전송

4) 보내고자하는 프레임의 목적지 MAC주소가 브로드캐스트인 경우 - 브로드캐스트니까 당연히 모든 포트로 전송

• 해결법 ? 라우터사용, VLAN 사용 등등

Switching HUB

• 스위칭 허브의 간단한 기본기능

프트에 연결되어있는 호스트의 MAC주소를 학습하고 MAC 주소 테이블을 유지이미 학습된 호스트에 대한 패킷을 수신하면 호스트에 연결된 포트로 전송알 수 없는 호스트에 대한 패킷을 수신하면, Flooding

• OpenFlow의한스위칭 허브: Ryu와 같은 OpenFlow 컨트롤러의 지시를 받고 다음을 수행

수신된 패킷의 주소를 rewrtie하거나 지정된 포트쪽으로부터 전송받은 패킷을 컨트롤러에 전송 (Packet-In)

컨트롤러에 의해 전달된 (forwarded) 패킷을 특정 포트쪽으로부터 전송(Packet-Out)

- Packet-In으로 MAC 주소를 학습가능

- 컨트롤러는 Packet-In 기능을 이용하여 스위치로부터 패킷을 받음

- 스위치에서 받은 패킷을 분석하고, 연결되어있는 포트에 대한 호스트의 MAC 주소 및 정보를 학습

- 학습된 호스트인 경우, Packet-Out기능으로연결된 포트쪽으로 패킷을 전송

- 알 수 없는 호스트인 경우, Packet-Out기능으로패킷을 플러딩

Switching HUB

Step1. 초기상태

TBL이비어있음

Step12. HostA HostB

: HostA에서 HostB로 패킷이 전송되면, Packet-In 메시지가 전송되고 HostA의 MAC주소가 포트1에 학습

: HostB의 포트는 아직 알지 못하여 패킷이 플러딩되고 브로드캐스트로 HostB, HostC에서 수신

Switching HUB

Step3. HostB HostA

: HostB에서 호스트A로 패킷이 리턴, 플로우 테이블에 항목을 추가ㅡ 팻킷은 포트1에 전송

Step4. HostA HostB

: HostA에서 HostB로 패킷이 전송되면, 플로우 테이블에 항목을 추가하고 패킷을 포트 4에 전송

Ryubook Practice

• 가상머신 생성

• Xwindows 환경이 필요함

• Ubuntu 14.04.2 LTS Server, id : user / pw : ryuc

• http://osrg.github.io/ryu/

• http://osrg.github.io/ryu-book/ko/html/switching_hub.html#id2

Ryubook Practice

• Version 1.3

• ryu/app/simple_switch_13.py

cf. $ find / -name ‘ryu’ 전체 하드디스크에서 해당 파일 찾기

• Ryu 응용 프로그램으로 구현을 위해 ryu.base.app_manager.RyuApp을상속

• OFP_VERSIOS OpenFlow 버전

• mac_to_port 맥주소테이블

• OpenFlow 프로토콜은 OpenFlow스위티와 컨트롤러가 통신을 위해 필요한 핸드쉐이크 등 몇 가지 단계가 정의

• 이벤트 처리기

• API 레퍼런스 참조 http://ryu.readthedocs.org/en/latest/

• Table-miss 플로우

: OpenFlow 스위치와 핸드셰이크가 완료 된 후,

Table-miss 플로우 항목이 플로우 테이블에 추가, Packet-In 메시지를 수신할 준비 Switch Features 메시지를 수신하자마자 Table-miss 플로우 항목을 추가

• Packet-in 메시지 : 알 수 없는 목적지를 가진 수신패킷을 허용하기 위해 Packet-In 이벤트 처리기를 생성

• MAC 주소 테이블 업데이트

TEST

• $ sudo mn –topo single,3 –mac –switch ovsk –controller remote -x

◀ 3개의 host, 1개의 controller, 1개의 switch

TEST

• 초기 생성정보 확인

Switch(britde) 1이 생성Host에 port 3개 생성

: 스위치에 OpenFlow 프로토콜 설정

: 플로우테이블 확인

TEST

• Ryu 용용프로그램 실행

: OVS와 연결, 핸드쉐이크가 이루어져 Table-miss 플로우 항목이 추가: 스위칭허브는 Packet-In을 기다리는 상태

Switch에 Table-miss 플로우 항목이 추가

TEST

• Understanding Packet Flows

• 시나리오

1) ARP request : H1에서 H2의 MAC주소를 모르기때문에 ICMP echo request 이전에 ARP request를브로드캐스팅

2) ARP reply : H2가 ARP에 응답

3) ICMP echo request : H1, H2의 MAC주소를 학습하였으므로, echo request를 H2에게 보냄

4) ICMP echo reply : H1에게 echo reply 반환

• H1,H2,H3 tcpdump 실행

• 미니넷을 실행한 HOST에서 h1h2로의 ping 실행

TEST

• Switch에서 플로우테이블확인

Table-miss 플로우항목이외에우선순위가 1인플로우항목이 2개 추가등록됨

1) 수신포트 (in_port):2, MAC 수신주소(dl_dst):호스트 1 동작(actions):포트1로전송

- H2에서 H1로의 통신이므로, ARP request 및 ICMP echo reply, 총 2번 reference(n_packets)

2) 수신포트(in_port):1, MAC 수신주소(dl_dst): 호스트3 동작(actions):포트2로전송

- H!에서 H2로의 통신, ARP request가브로드캐스트로 ICMP echo request

• Controller에서 simple_switch_13 로그 확인

1) Packet-In은 H1에서 발생한 ARP request이고, 브로드캐스트이므로플로우항목에등록되지않고 Packet-Out만처리

2) H2에서 반환된 ARP reply에서 목적지 MAC 주소가 H1이고 항목(1)이등록

3) H1에서 H2로 전송된 ICMP Request에서플로우항목 (2)가등록4) H2에서 H1에 반환된 ICMP echo reply는 등록된플로우항목 (1)에일치, Packet-In은발생하지않고 H1에 전송

TEST

• 각 Host에서 pack dump내용확인

-ARP request , broadcast-Apt reply, from H2-ICMP echo request-ICMP reply from H2

-ARP request from H1-Apt reply to H1-ICMP echo request from H1-ICMP reply to H1

-ARP request from H1

이상입니다.

2015.05.01