* flush time -> 스위치에서 프레임이 들어오면 mac table에 learning을 실시한다. 이때 스위치 RAM을 사용하는데 mac table에 수많은 데이터가 쌓이면 과부하가 걸린다. 이를 위해 mac table을 초기화하는 시간이 flush time이다.
정해놓은 flush time 내에 새로운 데이터가 들어오면 갱신되지만, 그렇지 않으면 테이블을 초기화한다.
* transparent Bridge -> 스위치에 프레임이 들어오면 이 프레임은 vlan에 대한 정보가 없다.
스위치에 vlan이 설정되어있을 경우, 프레임이 들어오는 포트에 맞는 vlan에 대한 정보가 프레임 헤더에 추가된다.
스위치에서는 이 프레임의 MAC주소를 해당 vlan에 맞게 기록한 뒤 출구 포트로 나갈 때 vlan에 대한 정보를 떼버린다.
즉 들어올 때와 나갈 때의 상태를 똑같이 해주는 과정을 transparent 라 한다.
라우터에서는 transparent를 수행하지 않는다 (ttl처럼 들어올 때와 나갈 때의 상태가 다른 것, segment를 나누어 10000byte의 크기가 1500byte로 쪼개져 나가는 것 등)
서버 <-> host
/서버 <-> 스위치/
1. TCP / UDP를 선택한다.
2. 서버측에서 L3에 대한 (src IP, dst IP) 헤더를 붙인다.
3. L2에 대한 (src mac, dst mac) 헤더를 붙인다.
-> 여기서 자신의 arp table을 참조하는데, dst IP에 대한 mac 주소가 없으므로 1~3 단계에서의 데이터는 보류하고, arp request를 보내게 된다.
4. dst ip를 확인했더니 서브넷마스크를 통해 서로 다른 네트워크임을 확인하고, arp request안의 dst mac은 모르는 상태로 보내고, dst ip는 'gateway'이다. L2헤더로 붙은 dst mac은 '브로드캐스트'로 보낸다.
/스위치 <-> R1/
5. 스위치는 f0/1로 request를 받아 f0/1의 mac주소가 AA인 것을 확인하고 mac-table에 기록한다.
6. 여기서 스위치는 dst mac이 브로드캐스트이므로 나머지 포트들에 flooding 수행 (브로드캐스트는 mac-table에 src mac으로 들어갈 수 없다)
7. 라우터 f0/1로 해당 데이터를 받아 arp table에 10.1.1.10 - AA를 기록하고 arp request의 dst ip가 자기의 f0/1 주소임을 확인하고 arp reply를 서버로 전송한다.
8. 스위치는 f0/2로 들어온 포트의 mac 주소가 bb임을 mac-table에 기록하고, mac-table에는 AA에 대한 정보가 있으므로 f0/1을 거쳐 서버로 보낸다.
9. 서버의 arp table에는 reply를 확인하여 10.1.1.1 - BB 의 쌍을 기록하게 되고 dst ip를 192.168.1.10으로 하고 데이터 전송
10. 이 데이터는 스위치를 거치며 flush time을 초기화시키고 R1으로 도착
/R1 <-> R2/
11. R1 routing table에는 상대 host에 대한 static 주소가 등록되어 있으므로 라우터는 이 데이터가 static 등록된 주소로 보내는 것임을 확인하고 s2/0을 통해 보내게 된다.
12. 두 라우터 사이는 1:1 연결이기에 바로 R2로 가게 된다.
13. R2에서 받고 L2를 확인 후 L3의 정보를 확인한다. dst ip(192.168.1.10)를 봤더니 자신의 routing table에 C로 연결된 192.168.1.0/24의 정보가 있으므로 f0/1로 내보낸다.
14. 여기서 f0/1부터는 이더넷 구간이므로 L2헤더가 붙어 통신해야한다.
/R2 <-> 스위치/
15. R2의 src mac은 CC이지만, dst mac에 대한 정보를 arp table에서 가져와서 보내야 하는데 host에 대한 mac이 없으므로 arp request를 보내게 된다.
16. arp request는 src mac - CC, dst mac - ?인 상태, L2헤더의 dst mac - 브로드캐스트 인 상태로 스위치 f0/1로 가게 되며, 스위치는 f0/1에 대한 mac주소가 CC임을 mac-table에 기록한다.
17. arp request는 dst mac = 브로드캐스트 이므로 flooding 한다.
/스위치 <-> host/
18. host는 arp request를 받고 L2 헤더의 src mac = CC 임을 보고 192.168.1.1 - CC 의 쌍을 arp table에 기록한다.
19. L3로 올라가 arp request의 dst IP가 자신(192.168.1.10)임을 확인하고 arp reply를 R2의 gateway로 전송한다.
20. arp reply의 src IP = 192.168.1.10, dst IP = 192.168.1.1, src mac = DD, dst mac = CC
/host <-> 스위치/
21. 스위치는 arp reply를 받고 f0/2의 mac = DD임을 mac-table에 기록한다.
22. mac-table을 참고해 mac = CC 인 포트를 확인해 f0/1로 보내게 된다.
/스위치 <-> R2/
23. R2의 f0/1로 arp reply가 도착하고 arp table에 192.168.1.10 - CC 쌍을 저장한다.
24. 이제 src mac = CC, dst mac = DD, src ip = 192.168.1.1, dst ip = 192.168.1.10 의 정보로 보류해뒀던 L2~L4의 헤더와 데이터에 넣어 host로 보낸다.
/R2 <-> host/
25. 데이터가 host에 도착하면 데이터의 헤더를 L2부터 차례로 떼며 L4로 넘기며 TCP SYN을 확인한다.
26. 데이터를 성공적으로 받았으므로 TCP ACK을 헤더에 붙여 다시 L3~L2로 host 자신의 mac, ip 정보들을 차례로 헤더에 넣어 서버로 전송한다.
27. 이제는 스위치, 라우터들의 arp table과 routing table들에 통신에 필요한 ip, mac 주소들이 있으므로 추가의 arp request들이 발생하지 않는다.
* 스위치를 거칠때마다 flush time은 초기화
트렁크 tagging protocol
1. cisco -> isl (cisco 장비끼리만 호환)
2. 국제표준 -> dot1q (서로 다른 제조사끼리도 호환)
1. 각각 pc에 ip와 g/w를 부여한다.
2. 스위치에 vlan 생성 및 할당
3. 스위치에 trunk 포트 세팅
4. 라우터 세팅
5. PC에서 ping 으로 결과확인
* 스위치에서 라우터로 넘어갈 때 vlan tag정보는 없어지게 됨(transparent bridge)
* 스위치와 라우터의 encapsulation 방식은 동일해야 함
멀티레이어 스위치
1. ip routing 명령어로 router 기능을 하는지 확인
2. 인터페이스로 들어가 no switchport 명령어가 먹히면 ip address 기능을 할 수 있다는 뜻
3. 다시 스위치로 사용하기 위해 e0/0, e0/1에 switchport로 명령어 해준 뒤 vlan 할당 작업
4. vlan 10에서 vlan10 gateway 및 상대 vlan20의 gateway와의 ping test
'ㄴ CCNA' 카테고리의 다른 글
| 3월 25일 (서브넷팅, EVE-Ubuntu 연동) (0) | 2022.03.25 |
|---|---|
| 3월 24일 (네트워크 연습 토폴로지) (0) | 2022.03.24 |
| 3월 22일 (계층 네트워크, TCP/UDP, 패킷 전달과정) (0) | 2022.03.22 |
| 3월 11일 (서브넷팅) (0) | 2022.03.14 |
| 3월 10일 (Routing table, 스위치 및 라우터 포트) (0) | 2022.03.14 |