네트웍 노트

2012년 11월 27일 화요일

스위치

1. IOS 복구 작업
1) switch:  flash_init
2) switch:  load-helper
3) switch:  set 57600
->115200 은 종종 에러가 생김
4) console 프로그램 57600 bps로 설정후 재 접속
5) switch:  copy xmodem: flash:ios~~.bin
6) 전송 완료
7) switch: set 9600
8) console 프로그램 9600 bps로 설정후 재 접속
9) switch: boot flash:ios이름~.bin

2.스위치에서 IOS를 TFTP로 백업하기
1) # archive upload-sw tftp://1.1.1.1/ios이미지.tar
-> flash에 있는 ios 이미지를 tar로 압축해서 tftp로 올림

3.TFTP에서 스위치로 백업 IOS를 copy 하기
1) # archive download-sw tftp://1.1.1.1/ios이미지.tar /overwrite /reload
-> /overwrite 는 기존 ios 삭제후 copy
-> /reload 는 스위치 copy 완료후 재부팅

4.명령어

1) sh int status errdisable
2) sh int f0/0 counter errors

5.stp 장애 처리순서
1) 루핑 의심 장비 찾기
(1) 각 장비의 sh log 및 sh process cpu 확인
(a) log 의 flapping 포트 확인
(2) 루핑 있는 장비 확인후 루핑 포트 shut
(3) 원인 조사
(a) 하드웨어 조사(케이블링,gibc,spf 등등)
-> sh int, sh hardware, sh module, sh tech-support
(b) 소프트웨어 조사
-> sh spanning-tree vlan 1 detail ( stp tcn 조사)
-> sh spanning-tree int f0/0 detail (원인 포트 bpdu 수신여부 점검)

6.etherchannel 장애 처리
1) speed,duplex,trunk mode,native vlan 이 서로 같아야함
2) pagp 또는 lacp로 같아야함
3) s-mac, d-mac, ip-mac ~~~ 같은 분배 알고리즘을 사용해야함
4) sh etherchannel summary
5) sh etherchannel 1 detail

7.점포 스위치 장애 심각성

1) MS 다운
-> BS의 VPN간 링크가 UP될 동안 통신 불가,매장 전체 영업 장애
2) BS 다운
-> BS 에 연결되어 있는 단말들만 통신 불가
3) 1 다운
-> 3번 ,4번 50초 동안 통신 불가,유선 pos 장애
-> uplink fast 설정하면 block 포트를 즉각 forwarding 상태로 전환 -> ping 안 끊어짐
4) 3 과 4 다운
-> 매장 pos는 무선 ap로 연결 전환 됨, 전환 시간동안 통신 불가 발생

8.uplink fast

C에 uplink fast 설정(block 포트를 갖고 있는 sw에서만 설정해야 함)
2번 링크 장애->3번 링크의 block 포트 즉시 forwarding 전환->ping 안 빠짐

9.backbone fast

C에 backbone fast 설정(모든 sw에서 설정해야 함)
1번 링크 장애->c의 block 포트는 20초 동안의 max-age 없이 30초후 forwarding 전환
-> ping 빠짐

1) 작동원리
(1) 링크 장애가 생긴 B가 후순위 bpdu를 c에게 송신
(2) c는 root sw에게 RLQ 송신
(3) root sw는 c에게 RLQ Ack 송신
(4) c는 block 포트를 20초 max-age 없이 30초 후 forwarding 전환

10. pvst 와 mst
1) pvst
-> vlan 별로 stp가 개별로 돌아감, bpdu 증가
2) mst
-> vlan을 그룹화하여 그룹별로 stp를 돌림, bpdu 감소
A(config)# spanning-tree 15 vlan 1,3,5
A(config)# spanning-tree 15 priority 1
B(config)# spanning-tree 16 vlan 2,4,6
B(config)# spanning-tree 16 priority 1

11.전환 시간
1) forwarding -> block
-> 즉시
2) block -> forwarding
-> 50초
(1) uplink fast 적용 ->즉시
(2) backbone fast 적용 -> 30초후

12. BPDU
1) 일반 sw는 TCN 만 송신 가능
2) ROOT sw는 설정 BPDU 송신 가능, TCN 송신 불가
(1) 설정 BPDU
(a) TCN Ack
(b) TC
-> 일반 sw의 mac address table의 max-age를 15초로 변경 시킴

13. 링크 장애 발생시 작동 순서
1) 링크 장애 발생 sw는 root sw에게 tcn bpdu 송신
2) tcn bpdu 수신 root sw는 장애 sw 에게 tcn ack 송신
3) 동시에 root sw는 모든 sw에게 tc bpdu 송신하여 mac address table의 max-age값을 15초로 조정하게끔 함

14. 링크 장애시 스위치가 하는 일
1) 일반 sw는 장애 보고
2) root sw는 mac 테이블 max-age 값 15초로 조정 알림

15.TRUNK 포트
스위치에 등록된 vlan 1,2,3,4 등을 타 sw에 전달하는 기능을 함->
양단의 trunk 포트의 native vlan 이 같아야 함->다르면 스위칭 루프가 발생함
스패닝트리가 자동으로 해당 루핑 vlan 들을 block 시킴

예)
a,b 스위치 모두에 vlan 2,3 이 있어야 트렁크로 통신이 된다.
a 스위치의 native vlan = 2 이고 b 스위치의 native vlan = 3 일때
각 스위치의 스패닝 트리에서 vlan 2 와 vlan 3을 blocking 시킨다.
native vlan mismatch 는 cdp를 통해서 전달된다.

16.native vlan 의 필요성

1) 트렁크 포트 중간에 허브가 있을시 허브에 연결된 파란색 pc들은 vlan tag을 붙이지 않고 프레임 송신
2) untag 프레임을 수신한 스위치의 트렁크 포트는 미리 설정되어 있는 native vlan 2 로 생각하고 vlan 2로 프레임에 tag를 붙인후 해당 vlan 포트로 포워딩 시킴

17. switchport access vlan 10 명령어의 의미
해당 포트가 trunk로 작동 안할때에는 해당 포트에 vlan 10을 부여하라는 의미
trunk로 작동시에는 아무런 의미가 없음

예)
sw mode trunk
sw access vlan 10
sw voice vlan 11
sw trunk native vlan 10

해당 포트에 전화기가 연결되지 않고 pc만 연결되면 vlan 10이 할당된 access 포트로 작동
전화기와 pc가 연결되면 trunk 포트로 작동 됨
pc와 전화기가 연결된 trunk 포트까지 untag 프레임으로 왔다갔다 함
전화기 연결된 trunk포트에서 다른 trunk 포트로 프레임 이동시에는 vlan 10 tag를 프레임에 붙임

18. 스위치의 포트 동작 3가지 모드
1) access
sw mode access
-> dtp 송신,수신 전부 안함

2) trunk
sw mode trunk
-> 무조건 dtp 송신

3) dynamic
sw mode dynamic auto
->dtp 수신시에만 송신
sw mode dynamic desirable
-> 무조건 dtp 송신

access-trunk
-> 통신불가
trunk-auto
->통신가능
auto-auto
->통신불가

19.L3 스위치 동작 순서
1) vlan 10에서 vlan 20으로의 unknowning packet 송신

pc 자체 라우팅 비교 검색후 gateway를 목적지로 설정후 패킷 송신
라인카드의 ingress buffer에 저장
라인카드의 packet process로 이동
라인카드의 mac table 검색
라인카드의 mac table에 source mac 저장 안되어 있음 확인
컨트롤카드의 mac table 검색
컨트롤카드의 mac table에 source mac 저장 안되어 있음 확인
컨트롤카드의 mac table에 source mac 저장

vlan mac 포트
10 x g1/1

모든 라인카드의 mac table에 source mac 저장
라인카드의 fib 검색
해당 interface의 arp 검색 진행
라인카드의 arp 검색
라인카드의 arp 에 일치하는 항목 없음 확인
컨트롤카드이 arp 검색
컨트롤카드의 arp 에 일치하는 항목 없음 확인
arp 송신 지시
vlan 테이블에서 vlan 20 에 해당하는 포트 검색
vlan 20에 해당하는 포트로만 arp 전송

요약)

라인카드 포트에서 패킷 수신->ingress buffer 저장->라인카드 mac table 검색->컨트롤 카드 mac table 검색->컨트롤카드 mac table 저장->라인카드 mac table 저장->스위칭 인지 라우팅인지 판단(목적지 mac이 L3 자신)->라인카드의 해당 interface를 fib에서 검색->라인카드의 해당 interface의 mac을 arp에서 검색->없음->컨트롤카드의 arp 검색->없음->컨트롤카드의 vlan table에서 vlan20 포트 검색->라인카드의 vlan table에서 vlan20 포트 검색->vlan 20 인 모든 포트로 arp 패킷 브로드캐스팅 함

6500

1.flash 메모리 명칭

1) active supervisor

(1) sup-bootflash: = sup-bootdisk:

-> supervisor 내장 flash 메모리

(2) disk0:

-> supervisor 외장 flash CF 메모리

(3) disk1:

-> supervisor 외장 flah CF 메모리

(4) bootflash:

-> MSFC 카드 내장 flash 메모리

2) standby supervisor

(1) slavesup-bootflash: = slavesup-bootdisk:

-> supervisor 내장 flash 메모리

(2) disk0:

-> supervisor 외장 flash CF 메모리

(3) disk1:

-> supervisor 외장 flah CF 메모리

(4) bootflash:

-> MSFC 카드 내장 flash 메모리

2.부팅 ios 지정 명령어

1) (config)# boot system flash sup-bootdisk:ios이름~~~.bin

3.IOS 업그레이드 작업 순서
1) 5번 shelf active supervisor module
-> copy tftp: sup-bootflash: 실행
2) 6번 shelf standby supervisor module
-> copy tftp: slavesup-bootflash: 실행
3) 5번 shelf active supervisor module
-> boot system flash sup-bootflash:ios명~.bin 실행
-> hw-module 6 reset 실행
5) 6번 shelf standby supervisor modle
-> sh module 실행 -> rpr ( cold ) 상태 확인
6) 5번 shelf active supervisor module
-> redundancy force-switchover 실행
-> standby 전환됨 확인 -> sh module -> sso 상태 확인
8) 6번 shelf supervisor
-> active 전환됨 확인 -> sh module -> sso 상태 확인

3. password 복구 작업
1) standby supervisor module 제거
2) 재부팅후 화면에 %CIR-6-console:chaning console ownership to route processor 메세지 출력된후 ctrl+break 를 누른다
->SP 부팅후 RP가 부팅하므로 sp 부팅중에 crtl+break 누르면 password 복구 못함
RP 부팅할때 ctrl+break 눌러야 함
3) rommon> confreg 0x2142
-> start-up config skip후 부팅됨
4) rommon> reset
5) switch# copy startup-config running-config
6) switch(config)# password xxxxx
7) switch# config-register 0x2102
8) switch# wr
9) standby supervisor module 장착
10) 1분후
11) switch# wr
-> active와 standby의 sync를 맞추기위해서 1분 기다린후
12) switch# reload

4.IOS 복구 방법

1) rommon> dir bootflash:
-> ios 가 있는것 확인
2) rommon> dir slot:
-> ios가 있는것 확인
3) rommon> set
-> 설정 내용 확인
4) rommon> unset boot
-> 설정 내용 삭제
5) rommon> set interface fa1 1.1.1.2 255.255.255.0
-> mgmt 포트에 ip 입력
6) rommon> set ip route default 1.1.1.1
-> 게이트웨이 설정
7) rommon> set
-> 설정 내용 확인
8) rommon> ping 1.1.1.1
-> ping 확인
9) rommon> boot tftp://1.1.1.1/ios명~~.bin
-> tftp 서버에서 ios를 갖고와서 부팅시킴
10) switch> ping 1.1.1.1
-> ping 확인
11) switch> copy tftp: bootflash:
12) switch> copy tftp: slot0:
13) switch> dir bootflash:
-> ios 확인
14) switch> dir slot0:
-> ios 확인
15) switch> verify bootflash:ios이미지~bin
->ios 파일 에러 체크
16) switch> sh bootvar
-> boot 변수 확인
17) switch(config)#no boot system flash:ios이미지~.bin
->기존 boot 변수 삭제
18) switch(config)#boot system flash:ios이미지~.bin
->새 ios 이름으로 boot 변수 수정
19) switch# sh ver
-> config-register 가 0x2102 인지 확인 아니면
20) switch> config-register 0x2102
21) switch(config)# sh bootvar
22) switch# wr
23 switch# reload

4507R

1.Standby supervisor 모듈 교체시 인식 불량 일때
1) 발생 주 원인
(1) 카드 장착 불량
(2) active 와 standby supervisor의 ios 또는 netflow 카드가 서로 같지 않을때

2) 소프트웨어적으로 reload 시키는 방법
active supervisor 에서 명령어 입력
(1) (config)# redundancy reload peer
-> standby supervisor reload 시키는 명령어

참고)
#redundancy reload shelf
-> active 와 standby supervisor 둘다 reload 시키는 명령어

3) 하드웨어적으로 reset 시키는 방법
(1) (config)# hw-module #(shelf 번호) reset
(2) 인식불량 supervisor module을 뱄다가 꼽는다

4) module 정상 확인
(1) sh module 또는 sh environment status

2.Actvie 와 Standby module 강제 전환
1) (config)# sh redundancy status
-> redundancy 상태 확인
2) redundancy가 sso 상태면
3) (config)# redundancy force-switchover
-> standby가 hot상태(sso)일때만 사용가능
-> sso = hot, rpr+ = warm, rpr = cold
-> 모든 스위치 모듈의 전원이 off 된후 on 됨,통신 순단 발생함

참고 1) sso

참고 2)
(1) sso란?
supervisor active<->standby 전환동안 L2 트래픽을 중단을 최소화 하기위해 사용하는 프로토콜

참고 3)
sso 설정
(1) (config)#redundancy
(2) (config)#sso

참고4 )
Active<->standby 전환 요인
1) active supervisor의 rp 나 sp 모듈 장애시
2) 시간 동기화 장애시
3) 수동 전환시
4) supervisor module 제거시

3.부팅시 LED상태 점검
1) power good LED = green 이고 power fail LED = green
-> 정상
(1) power good LED = off 이고 power fail LED = on
-> 장애
(a) power supply를 재장착해보고
(b) 파워케이블 바꿔보고
(c) 파워 소스를 바꿔봐라

2) fan good LED
(1) good LED = green
-> 정상
(2) good LED = off
-> fan 장착불량
(3) good LED = red
- >fan 불량

3) supervisor status LED
(1) status LED = green
-> 정상
(2) status LED = orange,red
-> 장애
-> system software가 시작되지 못한 것 임
-> sh enviornment 명령어로 에러 확인

4.IOS 복구 방법
1) rommon> dir bootflash:
-> ios 가 있는것 확인
2) rommon> dir slot:
-> ios가 있는것 확인
3) rommon> set
-> 설정 내용 확인
4) rommon> unset boot
-> 설정 내용 삭제
5) rommon> set interface fa1 1.1.1.2 255.255.255.0
-> mgmt 포트에 ip 입력
6) rommon> set ip route default 1.1.1.1
-> 게이트웨이 설정
7) rommon> set
-> 설정 내용 확인
8) rommon> ping 1.1.1.1
-> ping 확인
9) rommon> boot tftp://1.1.1.1/ios명~~.bin
-> tftp 서버에서 ios를 갖고와서 부팅시킴
10) switch> ping 1.1.1.1
-> ping 확인
11) switch> copy tftp: bootflash:
12) switch> copy tftp: slot0:
13) switch> dir bootflash:
-> ios 확인
14) switch> dir slot0:
-> ios 확인
15) switch> verify bootflash:ios이미지~bin
->ios 파일 에러 체크
16) switch> sh bootvar
-> boot 변수 확인
17) switch(config)#no boot system flash:ios이미지~.bin
->기존 boot 변수 삭제
18) switch(config)#boot system flash:ios이미지~.bin
->새 ios 이름으로 boot 변수 수정
19) switch# sh ver
-> config-register 가 0x2102 인지 확인 아니면
20) switch> config-register 0x2102
21) switch(config)# sh bootvar
22) switch# wr
23 switch# reload

5. password 복구 작업
1) standby supervisor module 제거
2) 재부팅 하자마자 ctrl+break 입력
3) rommon> confreg 0x2142
-> start-up config skip후 부팅됨
4) rommon> reset
5) switch# copy startup-config running-config
6) switch(config)# password xxxxx
7) switch# config-register 0x2102
8) switch# wr
9) standby supervisor module 장착
10) 1분후
11) switch# wr
-> active와 standby의 sync를 맞추기위해서 1분 기다린후
12) switch# reload

2012년 11월 22일 목요일

OSPF

1.장점
1) Convergence 가 빠름
2) 큰 규모의 인터네트워크 지원
3) 잘못된 라우팅 정보에 덜 민감

2.작동원리
1) OSPF가 활성화된 모든 인터페이스에서 hello 전송
hello의 매개변수가 서로 맞으면 네이버 성립

2) Adjacency 성립

3) Adjacency 관계의 모든 네이버에게 LSA 전송

4) 각 라우터는 수신한 LSA를 LSA DATABASE에 기록하고 사본 LSA를 전송

5) 모든 라우터들의 DATABASE가 완성되면 SPF Algorithm을 이용하여 최단경로우선트리 계산(SPF Tree)

6) SPF Tree로부터 라우팅 테이블 생성

7) Keep alive 용도로 hello를 지속적으로 교환

8) LSA Refresh를 30분 마다 실행

3.LSA 종류
1) LSA 1 = Router

2) LSA 2 = Network

3) LSA 3 = summary

4) LSA 4 = asbr-summary

5) LSA 5 = External

6) LSA 7 = Nssa External

4.라우터 ID
OSPF 도메인 내부에서 유일하게 식별되도록 하는 IP주소

5.HELLO
1) 네이버 발견 수단

2) 네이버간의 Keep alive 역활

3) Broadcast/Nbma 네트워크에서 DR/BDR 선출

6.HELLO 내부 정보
1) 전송하는 라우터의 라우터 ID

2) 인터페이스의 Area ID

3) 인터페이스의 서브넷마스크

4) HELLO/DEAD 주기

5) Priority

6) DR/BDR

7) HELLO를 수신한 네이버 리스트

8) 인증정보

7.네이버 수립 조건
상대 라우터가 보낸 HELLO에 자신의 라우터 ID가 네이버 리스트에 있으면 서로 2-Way Communication이 성립되면서 네이버가 됨

8.Transit Network
연결된 라우터가 2대 이상
패킷을 단지 전달만 할뿐

9.Stub Network
연결된 라우터가 오직 1대 일뿐

10.다중접속네트워크에서의 LSA 전송 문제점
1) 모든 라우터 사이의 유대관계로 인한 많은 LSA 생성

2) LSA Flooding이 무질서해짐

3) 해결책은 DR/BDR 지정
DR은 전체 라우터가 아닌 라우터의 인터페이스 측면의 개념

예)
기본 Priority=1 -> ip ospf priority 10
Priority=0 -> DR/BDR 선출 거부

11.DR/BDR 선출 절차
1) 네이버끼리 HELLO 패킷내부의 Priority, DR/BDR 필드 검사

2) 라우터들은 DR/BDR 필드를 자신의 인터페이스 주소로 설정

3) Priority 값 비교후 DR/BDR 선출

네이버 발견시 DR/BDR 필드 검사후 설정값이 있으면 DR/BDR을 수용하고 BDR 필드에 설정 값이 없으면 새로 선출

12.OSPF 인터페이스
HELLO 전송전,Adjacency 수립전,LSA 전송전 라우터는 자신의 링크들(인터페이스)을 이해하고 있어야함

예)
show ip ospf int f0/0
transmit delay -> LSA의 경과시간 증가(s단위)

13.네이버 수립의 목적
라우팅 정보를 전달하기 위한 유대 관계를 형성하기 위해서

14.Adjacency 수립 4단계
1) 네이버 발견
2) 2-way communication 성립
3) database 동기화
4) 완전 유대관계 수립(full adjacency)

15.LSA Flooding

모든 라우터들이 서로 똑같은 Topology Database를 유지하기위해서 네트워크 전체로 LSA를 전송하는것

전체 OSPF Topology는 물리적 링크 연결이 아닌 논리적 Adjacency에 의해 서로 연결된 라우터 그룹이나 노드로써 표현됨
논리적인 Topology Database = Link state Database

16.LSA Flooding 패킷 종류
1) Link state Update
2) Linki state Acknowldge

여러개의 LSA를 전달할수 있다

라우팅

1. 정적 라우팅
Hub and Spoke 인터네트워크는 정적 라우팅의 이상적인 모델이다

1) physical,datalink layer
물리적 경로르 통해 통신
mac,arp table

2) network,transport layer
논리적 또는 가상 경로를 통해 통신
ip주소,routing table

3. 부하분산
1) equal-cost load balancing

2) unequal-cost load balancing

3) 목적지별 부하분산
fast switching에서 작동
ip route cache
routing table 검색->arp cache table 검색->캡슐화후 전송->검색된 경로와 arp 정보를 fast switching cache에 저장->동일 목적지로 향하는 packet은 fast switching cache 참조후 전송(routing table 참조 안함)

2) 패킷별 부하분산
process switching에서 작동
no ip route cache

경로의 cost가 동일하면 링크별 균등하게 부하분산 전송시킴
경로의 cost가 비동일하면 낮은 cost 링크에 packet 3개 전송,높은 cost 링크에 packet 1개 전송

4.순환테이블 참조
라우팅 테이블을 여러번 참조 하는것
process 점유시간 증가->바람직 하지 않음

5.부정확한 arp cache table의 원인
동일한 datalink를 공유하는 라우터의 인터페이스에 proxy arp가 설정되어서 발생

6. 동적 라우팅 프로토콜
라우팅 프로토콜은 라우터 사이의 언어다
경로결정,최적경로 사용 안할시 그 다음의 최적경로 결정
토폴로지 변화에 능동적으로 대응하기 위함->동적라우팅이 제공하는 가장 중요한 장점

7. 알고리즘 최소 만족 조건
1) 경로정보를 다른 라우터에게 전달

2) 경로정보를 다른 라우터에게서 수신

3) 최적경로 선택후 라우팅 테이블 기록

4) 토폴로지 변화 인식후 적절히 대응

8. 모든 라우팅 프로토콜에 적용되는 공통 이슈
1) 경로 선정

2) metric

3) convergence - 모든 라우팅 테이블을 일관된 상태로 만드는것

4) 부하균형관리

9. distance vector routing protocol
1) distance vector
경로가 거리와 방향으로써 광고
-> 목적지가 5 홉 거리에 있고 A 라우터 방향이다

각 라우터는 네이버 라우터의 관점에서 경로를 수신한 후 자신의 관점에 따라 경로정보를 저장하기 때문에 소문에 의한 라우팅이라고도 함

2) 일반적 특징
전체 라우팅 테이블을 네이버에게 주기적으로 전송
(1) 네이버
공통의 datalink를 공유하고 있는 라우터
(2) broadcast update
(3) 라우팅 테이블 전체 update
update 정보를 수신한 네이버는 관심있는 정보만 기록하고 나머지 부분은 폐기
(4) 소문에 의한 라우팅

10.경로 유효 타이머(route invalidation timer)
A-B-C-D
D라우터가 죽으면 A,B,C 라우터는 이 사실을 모른채 패킷을 전송->블랙홀 발생
대책->해당 경로를 수신시마다 타이머를 재설정
해당경로에 대한 updata 미수신->네이버 라우터는 해당경로에 도달할수 없다는 flag를 달아서 다음 update 전송시에 전송->해당경로는 도달할수 없다는것으로 됨

timer out의 범위
3~6 update

11. split horizon
A-B-C-D
B라우터로부터 수신한 경로를 A라우터가 다시 B라우터로 전달하는것은 상식적으로 낭비다
두 라우터 사이의 역경로(reverse route) 발생 방지 기능->라우팅 루트 발생 방지

12.split horizon 종류
1) simple split horizon
특정 인터페이스로 update 전송시 해당 인터페이스에서 수신한 경로를 포함하지 않고 송신

2) split horizon with poision reverse
특정 인터페이스로 update 전송시 해당 인터페이스에서 수신한 update로부터 학습한 경로를 도달 불가능으로 지정하여 송신
모르는것보다 나쁘다고 아는것이 낳다

13. convergence time 단축 방법
triggered update
1) triggered update
metric이 변하는 경우 즉시 updat 전송

14. hold down timer
부정확한 경로 정보의 승인을 줄임
심사숙고의 시간을 가짐
목적지까지의 거리가 2홉에서 4홉으로 증가
라우터는 해당 경로에 대해 hold down timer 설정
timer 만료전까지 해당경로에 대한 새로운 정보를 받아들이지 않음
단점은 convergence 시간이 늘어남

2012년 11월 21일 수요일

기본 개념

1.LAN
모든 장비가 인터페이스를 통해 데이타링크에 붙어있어야 함
매체 공유외에 공유방법 규정 필요->프로토콜->MAC
각 장비는 유일한 존재로 식별될수 있는 주소가 필요

2.라우터
공통 데이타링크를 공유하는 두 장비간 통신경로는 물리적 통로
서로 다른 네트워크에 속한 라우터 사이에서 제공하는 경로는 논리적 통로

1) 물리적 통로를 통과 하기 위해서는 Frame으로 캡슐화 해야함
2) 논리적 통로를 통과 하기 위해서는 Packet으로 캡슐화 해야함

Frame은 데이타링크를 거치면서 변하지만 Packet은 변하지 않음

3.인터네트워크에서 라우팅 할때의 기본 전제
모든 네트워크와 데이타링크는 유일하게 식별 되어야함->Network주소 필요

4.모든 라우터의 진짜 관심사는 Network의 위치
라우터는 Packet을 목적지 Network에 전달하기만 하면 됨
최종 목적지 Network에 도착하면 Mac주소로 해당 단말장비로 Frame 전달

5.라우터의 관심은 다른 라우터들 뿐이다.

6. TCP/IP
1) physical layer
물리적 매체와 관련
전기적,광학적,기계적,기능적,절차적

2) datalink layer
physical layer 제어
매체 접속 및 공유제어
MAC 주소
Frame 작성

3) internet layer
패킷과 주소 설정을 정의하여 논리적인 인터네트워크를 통해 data를 라우팅

4) host to host layer
internet layer 제어(흐름제어,오류제어)
논리적 링크 제어(end to end connection)
서로 다른 network에 존재하는 두 host 사이의 모든 논리적 경로에 대해 책임을 짐

7. 계층들 사이에서의 다중처리
많은 application들에게 host to host layer 계층의 한 서비스 이용 가능하게 함
host to host layer의 많은 서비스가 internet layer 이용 가능

8.IP 패킷
1) 헤더크기
20byte <= 24byte
패킷 전체 길이 = 최대 65,535byte

9.Identifier
datalink의 MTU를 넘으면 작은 packet으로 나눔
예) MTU=1500, data=5000 -> packet=1500 으로 나누고
나누어진 모든 패킷에 Identifier 1번을 부여함으로써 같은 data라는 표식이 되며 수신장비에서 조립시 참조함

10.flag
장애처리시 datalink의 MTU를 알아보기 위해 DF=1 세팅후 extended ping 시험
1) MF(more fragment)=1
뒤에 조각난 packet이 더 있음
2) MF(more fragment)=0
뒤에 조각난 packet이 없음

11.TTL
trace 명령어는 TTL 이용
처음 TTL=1 세팅후 ping ->1 hop 라우터는 TTL=0 세팅하고 packet을 폐기->발신지로 icmp 오류 메시지 송신->라우터는 icmp 오류 메시지로 송신지 라우터의 주소를 파악

12. Protocol 번호
상위 host to host layer의 프토토콜 번호
TCP,IGMP,ICMP,UDP,GRE,NHRP,IGRP,OSPF등....

13. option
1) loose source routing
지정한 라우터의 주소를 지나가면 ok
중간에 다른 라우터가 있어도 ok

2) strict source routing
지정한 라우터의 주소만 지나가야함
중간에 다른 라우터가 있으면 source route failed 에러 메시지 전송

14.ARP
datalink layer에서 host ip에 해당하는 mac 주소를 찾기위해 이용
목적지 mac주소는 broadcast 주소로 지정

15. clear arp-cache
동적으로 알게된 항목 삭제

16. proxy arp
라우터가 자신을 host에게 인식시키는 용도로 사용

예)
host(192.168.1.1)가 다른 네트워크(192.168.10.1)로 보내는 packet을 송신하려함->host에 gateway가 설정되어 있지 않음->목적지(192.168.10.1)에 대한 arp 패킷 전송->헤당 경로를 알고 있는 라우터가 자신의 mac주소로 arp 응답->host는 192.168.10.1을 목적지로 하는 frame의 목적지 주소를 라우터의 mac주소로 설정하여 전송
* 라우터가 자신의 인터페이스가 192.168.10.1인 것처럼 속임

17. ICMP
1) echo/echo reply
2) 경로 재설정 메시지
A 라우터가 같은 datalink에 있는 다른 B 라우터가 특정 목적지에 대해 더 적합한 라우터이므로 B라우터를 사용해야 한다는 사실을 자신에게 연결된 host들에게 통지

18. ICMP Redirect를 사용 하지말라
1) host에서 gateway를 설정 안했을떄->다른 네트워크를 목적지로 하는 ip에 대한 arp 전송->해당 경로를 알고 있는 라우터가 arp reply(단 proxy arp 설정된 라우터)

단점- 불필요한 arp traffic 발생
no ip redirects 설정하면 해제됨

19.TCP
연결지향 서비스 제공
1) sequence number
적절한 순서대로 패킷을 정렬하여 응용계층으로 전달

2) ack,검사합,timer
오류제어,신뢰성 있는 전달

3) window
흐름제어

flag - URG,ACK,PSH,SYN,RST,FIN

20. UDP
비연결 서비스 제공
응용서비스가 작고 폭증하는 data를 보낼때 유리