route-map

1.정의
패킷을 허용,거부할 수 있다는 점에서 access-list 와 비슷하지만 패킷을 변경하거나 경로정보를 변경하는 match 와 set 을 추가할 수 있음

2.기본 용도
 1) qos
 2) policy route
 3) redistribute

3.policy route
 1) 단지 복잡한 static route 일뿐 임
 2) static route는 목적지 주소로 netxt-hop을 결정
 3) policy route는 송신지 주소로 next-hop을 결정
 4) extended access-list 의 protocol 과 포트 번호를 사용할 수 있음

4.설정
 1) 라우터로 들어온 패킷을 route-map으로 전송
 2) 재분배 패킷의 경로정보를 rotue-map으로 전송

5.deny 동작 방법
 1) policy route
  (1) deny 선언과 일치하면 policy route를 수행하지 않고 라우팅 프로세스를 이용하여 전송
 2) 재분배
  (1) deny 선언과 일치하면 경로를 재분배 하지 않음
  (2) 어떤 조건과도 일치하지 않으면 재분배 하지 않음
  (3) 조건에 맞지 않는 경로를 재분배 하려면 마지막줄에 permit 항 추가해야 함
 3) 마지막 줄에는 기본값으로 deny로 선언 되어 있음

6.활성화
route-map은 호출되어야만 동작 함

(config)# int f0/0
(config-if)# ip policy route-map (route-map 이름)
-> 들어오는 패킷에 대해서만 동작 함

8.라우터 스스로가 생성한 패킷에 대해서 policy route 적용하려면?
 (config-if)# ip local policy route-map (route-map 이름)

9.사례연구

패킷 length 1000 ~ 1600 은 b로 policy route 시킴
패킷 length 0 ~ 400은 c로 policy route 시킴
ospf 패킷 length 는 44 이다

 1) route a
  (config)# int e0
  (config-if)# ip add 172.16.1.4 255.255.255.0
  (config-if)# ip policy route-map woodstock
  (config)# ip local policy route-map woodstock
  (config)# access-list 120 permit ip any 172.16.1.0 0.0.0.255
  (config)# access-list 120 permit opf any any
  (config)# route-map woodstock permit 10
  (config-route-map)# match ip address 120
  (config)# route-map woodstock permit 20
  (config-route-map)# match length 1000 1600
  (config-route-map)# set ip netxt-hop b
  (config)# route-map woodstock permit 30
  (config-route-map)# match length 0 400
  (config-route-map)# set ip netxt-hop c

10.route-map 과 재분배
 (config)# route-map A deny 10
 (config-route-map)# match ip address 1
 (config)# route-map A permit 20
 (config-route-map)#exit
  -> 10항에 해당하는 경로는 재분배 거부
  -> 나머지 경로는 모두 허용

11.재분배에서 route-map 과 distribute-list의 차이점
 1) route-map
  (1) 경로의 값을 수정하여 재분배 가능함
   -> set metric,set metric-type,set next-hop,set tag 등등
  (2) routing protocol 수준에서만 사용 가능
 2) distribute-list
  (1) 경로의 허용 또는 거부만 가능함
  (2) interface 수준에서는 in/out 가능
  (3) routing protocol 수준에서는 out 만 가능

12.tag을 사용하여 경로 재분배시에는 route-map만 사용 가능

13.route tagging

14.라우팅 경로 선택 순위
1) longest match roule
2) AD 값
3) cost 값

OSPF

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

2.작동원리
 1) ospf가 활성화 된 모든 interface로 hello로 전송
    hello의매개변수가 일치하면 네이버 성립
 2) adjacency 성립
 3) adjacency 관계의 모든 네이버에게 LSA 전송

참고) LSA 종류
OSPF는 라우터가 여려 형태로 있으므로 LSA도 여려형태가 있다

 1) LSA 1 -> router

2) LSA 2 -> network

 3) LSA 3 -> summary

Area 내부에서는 link state protocol로 작동
Area 간 경로 발견에는 distance vector 알고리즘 이용해서 작동
distance vector 알고리즘 이용은 백본 영역의 존재와 모든 영역간 트래픽이 백본을 통과하도록 만들기 위해서 수행됨
Area를 허브앤스포크 구조로 만들면 distance vector 알고리즘에서 생기기 쉬운 라우팅 루프를 피할 수 있다.

 4) LSA 4 -> asbr-summary
 5) LSA 5 -> external
 6) LSA 7 -> nssa external

 4) 각 라우터는 수신한 LSA를 LSA database에 기록하고 복사된 LSA 사본을 전송
 5) 모든 라우터들은 데이타베이스가 완성되면 SPF 알고리즘을 이용하여 최단경로우선트리   계산을 수행
 6) SPF로 부터 라우팅 테이블 생성
 7) keep alive 용도로 hello 교환
 8) LSA Refresh 주기는 30분마다

3. router-id
ospf 도메인 내부에서 유일하게 식별되도록 하는 ip주소

4.hello
 1) 네이버 발견 수단
 2) 네이버간의 keep alive 수단
 3) 브로드캐스트/NBMA에서 DR/BDR 선출 수단

참고) hello 패킷의 내부 정보
 1) hello 전송 라우터의 router-id
 2) 인터페이스의 area id
 3) 인터페이스의 서브넷마스크
 4) hello/dead 주기
 5) priority
 6) DR/BDR
 7) hello를 수신한 네이버 리스트
  -> 상대방이 보낸 hello의 네이버 리스트에 자신의 router-id가 있으면 2-way 네이버 관계성립
 8) 인증정보

4.네트워크 종류
 1) transit network
  -> 연결된 라우터가 2대 이상이며 패킷을 단지 전달만 하는 것
 2) stub network
 -> 연결된 라우터가 오직 1개만 있는 것

5.다중접속네트워크에서의 LSA 전송 문제점
 1) 모든 라우터 사이의 유대관계로 인해 많은 LSA 생성되어 전송 됨
 2) LSA flooding 으로 네트워크가 무질서해 짐
 3) DR/BDR을 선출함으로써 해결됨
  -> DR/BDR은 라우터 인터페이스 측면의 개념임
  -> 기본 priority = 1 -> ip ospf priority 1
  -> priority = 0 -> DR/BDR 선출 거부

6.DR/BDR 선출 절차
 1) 네이버끼리 hello 패킷내의 DR/BDR 필드 검사후 설정 값 있으면 DR/BDR을 수용하고 없으면 새로 선출 절차 진행
 2) DR/BDR 필드에 자신의 인터페이스 주소를 입력함
 3)  priority 값 비교후 DR/BDR 선출

7.OSPF 인터페이스
OSPF가 작동되는 동시에 라우터는 자신의 인터페이스들을 이해하고 있어야 함
인터페이스는 OSPF가 링크를 해석하는 수단이기 때문임

 1) # sh ip ospf int f0/0
        ~~~~~~~~~
       transmit delay -> LSA의 경과시간 증가, 초 단위

8.네이버 관계의 궁극적인 목적
 라우팅 정보를 전달하기 위한 Adjacency 형성

9.Adjacency 관계 설정 단계
 1) 네이버 발견
 2) 2-way 네이버 관계 수립
 3) 데이타베이스 동기화
 4) 완전 유대관계 수립(full Adjacency)

10.논리적 TOPOLOGY DATABASE = LINK STATE DATABASE
 전체 OSPF TOPOLOGY는 물리적 링크 연결이 아닌 논리적 Adjacency에 의해 서로 연결된 라우터 그룹이나 노드로써 표현된다.

11.LSA 플러딩
 모든 라우터들이 서로 똑같은 LINK STATE TOPOLOGY를 유지하기 위해서 네트워크 전체로 LSA를 전송 하는 것

12.LSA 플러딩 패킷 종류
 1) update
 2) ack

13.LSA 플러딩의 신뢰성
모든 라우터는 동일한 LINK STATE DATABASE 유지가 중요 함
그러므로 LSA 플러딩의 신뢰성이 중요 함
전송 라우터는 LSA 수신을 확인 해아야 함
수신 라우터는 정확하게 LSA를 수신 했다는것을 알아야 함
LSA ack 1개로 여러 LSA 의 수신 확인이 가능 함(여러 LSA르 수신했다고 확인할수 있게 LSA 헤더를 전송해야 함)

 1) 수신확인 방식
  (1) 지연확인
   여러개의 LSA를 수신후 1개의 LSA Ack로 수신확인
  (2) 즉시확인
   네이버로부터 중복된 LSA 수신시

 2) 경과시간
  maxage(1시간)에 도달하면 LSA는 다시 플러딩 되고 해당 LSA는 LINK STATE DATABASE에서 삭제 됨

 3) 동일한 LSA를 여러개 수신했을때 선택법
  (1) 높은 순서번호
  (2) 높은 검사합
  (3) 낮은 age
  (4) 위의 모든 값이 동일하다면 LSA는 동일하다고 간주

14.AREA의 필요성
 CPU에 부담을 주는것은 spf 알고리즘보다 LSA 플러딩이나 데이타베이스 유지이다.
이런 단점을 해결하기 위해서 AREA를 이용한다.
 1) 장점
  (1) LSA 플러딩의 최대범위가 AREA 내부로 한정 됨
  (2) 고유 AREA에 대한 데이타베이스만 관리하므로 크기가 작아짐
  (3) 처리할 LSA양  줄어듬

15.AREA와 관련된 트래픽
 1) 내부 영역 트래픽
 2) 영역간 트래픽
 3) 외부 트래픽

16.Backbone area 의 역활
 1) 각 영역의 토폴로지를 요약하는 역할 수행
 2) 백본이 아닌 영역은 타 영역으로 트래픽 전송이 불가

17.LSA Refresh
1) LSA가 MaxAge(1시간)에 도달하여 삭제 되는 것을 예방하기 위하여 LSA Refresh 작동
2) 30분마다 증가된 sequnence number 와 0 의 age 값을 가지는 LSA 복사본을 flooding 함
3) LSA 수신 라우터는 sequence number 등을 비교하여 구 LSA를 대체하여 저장 함

CSU 회선 시험

1.라우터와 자국 CSU 구간 시험

 1)FUNC 키->LLB 선택->TPG 선택 (CSU에서 ERROR 값 0 이 정상임,0 아닌 값이면 이상 의심)
 2)라우터 시리얼포트 line protocol is up(looped) 상태 변함
 3)자신의 ip로 ping test
 4)정상이면 csu와 라우터 구간 이상없음,자국csu와 대국 csu(전화국)간의 DLB 테스트  및
    RDLB 테스트 시행
 5)ping이 안되거나 line protocol is down 이면
 6)CSU,V35,라우터 모듈 불량 의심

# 참고)
 1) DCD = UP
     DCE로 부터 수신된 반송파 유무
 2) DSR = UP
     DCE 동작 완료
 3) DTR = UP
     DTE 동작 완료
 4) RTS = UP
     DTE가 DCE에 데이타 송신 요구 준비 완료
 5) CTS = UP
     DTE가 상대 DTE에 데이타 송신이 가능함

2.자국 CSU 와 대국 CSU(전화국) 구간 시험

 1)자국 CSU->FUNC 키->TPG 선택->전화국 시험실에선 DLB를 건 상태임
 2)자국 CSU 화면상에 ERROR 값이 0이 아니면 이상 의심
 3)전화국 시험실에서 고칠때까지 대기


3.용어 정리

 1)TPG(TEST PATTERN GENERATOR)
   패턴 신호 발생

 2)DLB(DIGITAL LOOPBACK)
  대국 CSU 방향으로 LOOPBACK 걸어주는 것
  대국 CSU 에서는 TPG 선택후 ERROR 값 확인

 3)LLB(LOCAL LOOPBACK)
  자국 ROUTER 방향으로 LOOPBACK 걸어주는 것
  라우터쪽으로 TPG를 송신후 돌아오는 ERROR 값 확인
  LLB 선택후 TPG 선택해야 하는 이유 임

 4)RDLB(REMOTO DIGITAL LOOPBACK)
  대국 CSU쪽에 사람이 없을때 시행
  자국 CSU에서 RDLB 선택 하면 자동으로 TPG까지 선택되어 ERROR 값 보임
  대국 CSU는 자동으로 DLB 상태로 전환됨
  RDLB 지원 안되는 CSU는 DLB 시험 해야함

AP

1.장애 처리 순서
1) RF 신호 강도 측정
-> 스펙트럼 분석기로 측정
2) RF 신호 간섭 측정
-> 스펙트럼 분석기로 측정
3) 이상 없으면
4) 패킷 캡쳐후 client server 간 통신 이상유무 확인

라우터

1.모니터링
1) # sh process cpu
   # cpu utilization for five seconds : 45%/40%
 (1) 45%
  -> 메인 cpu 사용율 = 라우팅
 (2) 40%
  -> cache 사용율 = cef 스위칭

2) 메인 cpu 사용율 > cache 사용율
 -> 공격 의심
 (1) # sh process cpu sorted | ex 0.00
  ->점유율 높은 process 조사
 (2) ARP process 점유율 높으면
  -> arp spoofing 의심
  (a) # sh arp
      ->중복 mac 주소를 갖고 있는 ip 주소 확인
  (b) # sh mac add add mac주소
   ->포트 위치 파악 후 해당 포트 shut
 (3) IP process 점유율 높으면
  -> 바이러스 감염 의심
  (a) # sh ip cache flow | i  k 로 packet양 높은 ip 확인
  (b) # sh arp
    ->중복 mac 주소를 갖고 있는 ip 주소 확인
  (c) # sh mac add add mac주소
   ->포트 위치 파악 후 해당 포트 shut

3) ip spoofing 공격
 -> mac 주소 1개에 ip 주소 여러개 사용
 -> 대개 DOS 공격인 경우 많음
 -> RPF 기능 on 하면 차단 가능함
 (1) sh ip cache flow | i 96.70(ip spoofing 의심 ip)
  -> 유입되는 interface 확인
 (2) sh ip cef f0/0
  -> 유입되는 netxt hop ip 주소 확인
 (3) 외부 isp 이면 해당 isp에 ip 차단 요청
 (4) 메인 cpu 사용율 = cache 사용율
  -> 패킷 유입량 많음

2.명령어
 1) clear ip accounting
  -> ip accounting-output 초기화

 2) clear ip flow stats
  -> cache flow 초기화

 3) clear ip route
  -> routing table 초기화

 4) clear cdp table
  -> cdp table 초기화

 5) clear ip nat translation *
  -> nat table 초기화

 6) sh ip nat translation
  -> nat된 ip 주소 확인

 7) sh ip nat statistics
  -> nat 변환 통계 보기

 8) sh int status errdisable

 9) sh int f0/0 counter errors

3.access-list 수정
 1) access-list 10 deny 1.1.1.1
  (1) 1.1.1.2 추가
   (a) # sh ip access-list
        # standard ip access-list 10
        #  10 deny 1.1.1.1
   (b) (config)# ip access-list standard 10
   (c) (config)# 15 permit 1.1.1.2
  (2) 1.1.1.2 삭제
   (a) # ip access-list standard 10
   (b) (config)# ip access-list standard 10
   (c) (config)# no 15

 2) 이름을 갖는 standard access-list 추가
 (1) (config)# ip access-list standard abc
 (2) (config)# 10 permit 1.1.1.3

4.access-list 명령어
 1) sh access-list
  -> 전체 access-list 목록 보기

 2) sh ip access-list 100
  -> 특정 번호 access-list 목록 보기

 3) sh ip accounting access-violations
  -> access-list 위반 패킷 확인

5.HSRP 장애 처리
 1) sh standby f0/0
  -> 가상 mac 주소 확인
 2) 각 단말에서 gateway의 mac 주소가 가상 mac 주소와 같은지 비교
 3) 같지 않으면 arp spooping 의심

6.crash 발생
 1) crashinfo 파일이 flash에 저장 됨
 2) 재부팅 되면 지워지므로 반드시 저장해야 함

7.IOS 복구
 1) tftpdnld 가 있을때
  (1) rommon> set
   -> 환경변수 확인
  (2) rommon> IP_ADDRESS=1.1.1.1
  (3) rommon> IP_SUBNET_MASK=255.255.255.0
  (4) rommon> DEFAULT_GATEWAY=1.1.1.2
  (5) rommon> TFTP_SERVER=1.1.1.2
  (6) rommon> TFTP_FILE=ios이미지.bin
  (7) rommon> tftpdnld
  (8) 파일 업로드 시작됨
  (9) rommon> unset
   -> 환경변수 삭제
  (10) rommon> ios 복사 완료
  (11) rommon> reset

 2) tftpnld 가 없을때
  (1) rommon> confreg
  (2) rommon> do you wish to change the configuration? y
  (3) rommon> ~~~~~~~~~~~~~~~~~~~~~~~~ ? n
  (4) rommon> change console baud rate ? y
  (5) rommon> ~~~~~7=115200,[7]=7
  (6) rommon> ~~~~~~~~~~~~~~~~~~~~~~~~? n
  (7) console speed 115200으로 수정후 콘솔 접속
  (8) rommon> xmodem ios이름~.bin
  (9) 자동 재부팅
  (10) router# config-register 0x2102

스위치

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

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를 전달할수 있다

Link state routing protocol

Distance vector protocol은 이정표
Link state protocol은 지도

1.각 라우터는 자체정보,직접 연결된 링크 정보와 상태를 수집->이 정보는 네이버에게 송신->각 네이버는 사본을 만들어 저장후 정보 전달->모든 라우터와 동일한 정보를 가지면 각자 최상의 경로를 계산

2. 기본기능
1) 모든 네이버와 adjacency를 맺음

2) 각 라우터는 네이버에게 LSA를 전송
라우터의 각 링크에 대해 한개의 LSA 생성
LSA를 수신한 네이버는 수신한 LSA를 Flooding 함

3) 수신한 LSA 복사본을 Topology database에 저장

3.네이버
Hello를 통해 맺어짐
Keep alive 기능
Adjacency 기능

4.LSA Flooding
Adjacency가 맺어진후 LSA 전송
LSA를 전달한 네이버를 제외한 모든 네이버에게 전달

5.Distance vector 보다 convergence time이 빠르다
->distance vector는 update 전달전에 routing table을 먼저 update 해야 하기 때문에

6.Flooding 과정의 신뢰성과 효율성
1) LSA의 순서번호
TTL값이 만료될때까지 LSA가 네트워크를 돌아다니는것은 비효율적
수신한 LSA의 내용은 같지만 순서번호가 더 높은 경우 수신한 LSA의 순서번호를 Database에 기록한후 해당 LSA를 Flooding 함
수신한 LSA의 내용이 같고 순서번호가 같은 경우 수신한 LSA는 폐기함

2) LSA 수명
LSA에는 수명시간을 나타내는 필드가 있음
Maxage에 도달하면 해당 LSA를 삭제
삭제를 방지하려면 LSA를 주기적으로 검증해야함
LS Refresh=30분
Maxage=1시간

7.Link state database
LSA를 일련의 레코드로 저장

8.LSA에 포함된 2가지 정보
1) 라우터 링크 정보(라우터에 인접한 네이버를 광고)
라우터 ID, 네이버 ID, Cost

2) 스텁네트워크 정보(라우터에 직접 연결된 스텁네트워크를 광고)
라우터 ID, 네트워크 ID, Cost

9.SPF의 경로계산
각 라우터까지의 최단거리 계산시 라우터 링크 정보를 이용하고 그후에 스텁네트워크 정보를 가지고 라우터에 연결된 네트워크까지의 최단거리 계산

10.Area를 나누는 이유
Database가 Distance vector 보다 더 많은 메모리를 필요
CPU 점유시간 증가->복잡한 SPF 계산
LSA Flooding으로 인한 대역폭 낭비
LSA Flooding 영역을 줄임->LS Database 크기가 작아짐

11.ABR
각 영역에 대한 별도의 Database를 관리
1번 Area의 라우터가 2번 Area로 패킷을 전송 하려고 할때 1번 Area 라우터는 local ABR을 찾는 방법만 알면됨

영역내부 라우터와 ABR간이 관계는 호스트와 라우터간의 관계와 동일

라우팅

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 시간이 늘어남

기본 개념

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를 보낼때 유리

EIGRP

EIGRP
Link state protocol 처럼 작동하는 Distance vector protocol

1.Distance vector protocol
직접 연결된 네이버를 제외한 알고 있는 모든것을 공유

2.Link state protocol
직접 연결된 링크의 정보만 공유

3.Distance vector protocol은 routing loop을 유발하는 경향 있음
대책 = split horizon,route poisioning,holddown timer

4.Convergence 가 늦을수 있음
수신한 경로를 라우팅 알고리즘으로 계산후 네이버에게 전달해야 하므로
주요링크가 변경되면 변경된 수 많은 경로를 전파해야함->경로 자체를 전파하기 때문에

5.Update
비주기적-메트릭,토폴로지 변화시에만 전송
부분적-변경된 부분만 전송
제한적-연관된 라우터에게만 전송

6.Metric * 256

7.IP와 IPX,Appletalk도 라우팅 가능

8.EIGRP의 4가지 구성요소
1) protocol 종속모듈
ip,ipx,appletalk를 라우팅 시켜줌

2) 신뢰성 전송 프로토콜(RTP,Reliable transport protocol)
패킷 전달 보장 - multicast(224.0.0.10) 전송,unicast ack 송신
패킷 sequence number - 패킷 전송시마다 +1 증가 시킴

특별한경우 RTP를 사용 안하고 전송하는 경우가 있음

9.패킷 종류
1) hello - 비신뢰성 방식,multicast 사용
2) update - RTP방식,muliticast,unicast 사용
3) ack - 비신뢰성,unicast 사용
4) query - RTP방식,multicast,unicast 사용
5) reply - RTP방식,unicast 사용

10.ack 미수신시 작동순서
 eigrp 패킷 송신->ack 수신 실패->multicast flow timer 경과후 unicast 16번까지 송신->ack 수신실패->네이버 down 처리

11.ack을 수신해야 하는 패킷 종류
query,reply,update

12.SRTT
네이버에게 패킷 전송후 ack 수신까지 걸린 시간

13.RTO(retransmission time out)
multicast 전송에 대한 ack 수신 실패후 unicast 전송시 ack 수신을 기다리는 시간
단위 - ms
unicast 전송 주기 시간

14.DUAL(diffusion update algorithm)
업데이트 확산 알고리즘
일시적인 라우팅 루프조차 허용치 않겠다는 생각이 바탕이 됨

hello 송신->hello 수신->네이버 수립(adjacency)->update전송

수신되는 update에는 경로와 메트릭값이 들어있음
해당 목적지에 대해 네이버가 보낸 경로가 FC조건(AD<자신의 FD)을 만족하면 수신한 경로값을 선택함
해당 경로를 전송한 네이버는 feasible successor로 지정됨
수신한 경로의 메트릭 값과 네이버까지의 경로 메트릭 값 합산후 전체 메트릭 값 계산
경로를 토폴로지 테이블에 저장

15.네이버 수립조건
동일한 서브넷 - hello 송신자의 서브넷 주소가 수신자 인터페이스의 서브넷과 일치
AS번호,K 상수,인증

16.라우팅 루프를 막는 핵심 개념
feasible successor 와 feasible condition
feasible distance가 항상 기존 feasible distance보다 작기 때문에 라우터는 자신에게 돌아오는 경로를 결코 선택할 수 없다.

17.feasible successor 존재 이점
dual 계산 부하 감소
빠른 convergence 시간
라우터는 경로 변경시 먼저 topology table에서 해당 경로에 대한 feasible successor가 있는지 확인후 없으면 dual 시작

18.DUAL 작동 방식
1) input event 발생
직접 연결된 링크의 다운 또는 업
cost 값 변경
update,reply 수신

2) 모든 successor에 대해 지역계산(local computation) 실행
실행중 모든 경로는 passive 상태 유지
적당한 successor 발견시 update 패킷 전송

3) feasible successor가 토폴리지 테이블에 없을때 dual 시작
실행중 모든 경로는 active 상태 유지
dual 완료후 passive 상태 될때까지 또 다른 dual 계산 금지,FD 변경 금지,successor 변경 금지

4) query를 수신한 네이버가 적정 successor가 있다면 query를 전송한 네이버에게 reply 전송

5) 적정 succesor가 없다면 해당 경로를 active 상태로 변경후 dual 시작
query 전송->active timer 시작->query를 전송한 모든 네이버 항목에 reply status flag를 설정->query를 전송한 모든 네이버에게서 reply를 수신하면 dual 완료->active timer 종료시까지 reply를 받지 못했다면 해당 경로 SIA 선언->SIA 상태 경로 와 네이버는 삭제

19.FC(feasible condition)조건
FD>AD 이면 토폴로지 테이블에 저장
FD<AD 이면 토폴로지 테이블에서 삭제

20.특정 경로 장애시(link down시)
해당 경로에 대해 feasible successor를 발견 할수 없는 라우터->장애 경로에 대한 메트릭 값을 무한대로 설정한후 update를 네이버에게 전송->네이버에게 query를 전송->update를 수신한 네이버는 지역계산 수행

21. EIGRP 와 IGRP가 같은 process id 라면 재분배가 자동으로 이루어진다.

22. passive interface s0
s0 인터페이스로 hello 송신 안함->네이버 수립 안함->eigrp 패킷 전송 안함

23. eigrp는 네트워크 경계에서 address summarization 수행
#(config) int e0
#(config-if) ip summary-address eigrp 15 172.20.15.0 255.255.0.0

24. eigrp 장애처리

RIP 나 IGRP 에서는 라우팅의 부재 또는 부정확성만 체크 하면 됨

EIGRP에서는 4가지를 체크 해야함

1) 네이버 테이블

2) adjacency 관계

3) DUAL 과정

4) 자동요약

25. 네이버 사자지는 현상

1) 각 라우터의 라우팅 테이블 조사

2) 라우팅 테이블에서 이상한 라우터 발견

3) EIGRP 설정 확인

4) 네이버 테이블 확인

26. 반복되는 query 는 dual을 확장하는 원인

reply는 dual을 축소하는 원인

dual의 반경이 지나치게 크면 active timer가 모든 reply를 수신하기전에 종료될수 있음

26. 사용자가 간헐적으로 목적지에 연결 할수가 없다고 불평할때

네이버가 사라졌다가 나타났다가 반복->SIA 일경우 높음->라우터의 log 확인->%DUAL-3-SIA~~~~....라는 에러가 있으면 SIA가 확실

27. SIA 현상 해결책

주소를 주의해서 할당

경로 필터링,디폴트 경로,경로 요약을  결합하여 DUAL 계산의 범위를 적절히 조정

자투리 정보

1. gratuious arp
자신의 ip 주소를 목적지로 설정하여 arp 요청
1) ip 충돌감지 - 누가 내 ip 쓰는지 체크
2) arp cache 갱신 - 사용중 ip 변경되었을때 계속적인 통신을 위하여 변경된 ip/mac으로 변
                             경 시킴
3) vrrp/hsrp에서 사용

2. no ip redirect
hsrp/vrrp등 이중화 프로토콜 사용시 꼭 설정
라우터가 더 좋은 경로를 가진 라우터의 경로를 pc에게 redirect 메세지를 전송
두 라우터중 한개가 다운되면 pc는 저장된 라우팅 테이블을 지우기 위해서 재부팅 되야함

3. 이기종 장비에서 광모듈이 인식 안될떄
cisco 광 =  speed auto negotiate
알테온 광 = speed no negotiate

4. t1 회선 2개를 로드발란싱 하고 회선 백업구성을 하여 mrtg에서 3m로 보이게 할려면?
(config)#int s0
(config)#encap ppp
(config)#ppp multilink group 1
(config)#int s1
(config)#encap ppp
(config)#ppp multilink group 1
(config)#int multilink 1
(config)#ip add 1.1.1.1 255.255.255.252
(config)#ppp multilink group 1

5.종단간 연결성 원리
tcp/ip는 종단간 연결성의 원리로 구현
중간 네트워크 장비의 도움없이 종단끼리 패킷을 송수신 한다는 의미

nat는 종단간 연결성 원리를 지키지 않음
nat 아래의 단말들은 종단간 연결성을 위하여 nat 장치에 의존해야함
nat 단말 client로 동작->nat 장치가 nat table 항목 작성->통신 가능
nat 다말 server로 동작->nat 장치에 nat table 항목이 없음->통신 불가

1) 대책
nat-traversal 기술 이용

VPN

1.기능
1) 인증 - psk(preshare key)
           - 디지털인증서

2) 기밀성 유지
- des,3des,aes,rc4

3) 데이타 무결성 보장
- 데이타를 공격자가 변조하는것을 방지
diffie-hellman 으로 암호화 및 해싱을 위한 대칭키 생성->md5,sha->encrypt->해시코드  생성->패킷에 첨부->상대방 전송->decrypt->변조되지 않음 확인

4) 재생방지
- 공격자가 데이타를 중간에 끼워넣는 행위 방지
- 패킷의 순서번호 또는 도착시간을 확인하여 방지

2.종류
1) 순수 ipsec vpn - 기본 ipsec
2) gre ipsec vpn - gre를 통한 라우팅 해결
3) dmvpn - 대규모 vpn
4) ipsec vti - vpn 설정 간편
5) easy vpn - 외부사원의 내부망 접속허용
6) get vpn - 대규모 vpn, 멀티캐스트,qos지원
7) ssl vpn - 전자상거래 용도
8) pptp vpn - 외부사원의 내부망 접속허용
9) l2tp vpn - 외부사원의 내부망 접속허용
10) mpls vpn

3. 암호의 구분
1) 대칭키 - 양측에서 사용하는 암호가 같음
* psk - 미리설정된 암호키
* diffie-hellman - 알고리즘에 의해 생성된 암호키,대칭키 생성시의 알고리즘은 비대칭키 사용

2) 비대칭키 - 양측에서 사용하는 암호가 다름,암호화,복호화키가 상이함
* rsa
* 공개키(암호화,타인에게 공개),개인키(복호화,개인이 비밀스럽게 보관)

3) 동작
(1) 인증
r1->psk,인증서->r2
(2) 임시대칭키 생성
r1->diffie-hellman->r2
(3) 데이타 무결성 확인
r1->sha,md5->r2
(4) 재생방지
r1->순서번호,도착시간->r2

4.isakmp(internet security association key management protocol)
- 두개의 장비가 보안통신을 하기위한 절차를 명시한 프로토콜

1) ike(internet key exchange)
- isakmp가 명시한 각 절차에서 필요한 구체적인 프로토콜의 종류와 절차를 정의

2) ike 1단계(main mode)
(1) isakmp sa 제안
r1-->인증=psk,암호화=3des,해싱=sha,dh=2,isakmp=유효기간-->r2
(2) isakmp sa 선택=r2에 같은 isakmp sa가 있으면 r1에게 송신
r1<--인증=psk,암호화=3des,해싱=sha,dh=2,isakmp=유효기간<--r2
(3) diffie-hellman 키 교환=암호화 및 해싱에 사용할 대칭키 생성
r1-->r1의 공개키와 임의의 수-->r2=r1의 대칭키 계산 완료
(4) diffie-hellman 키 교환=암호화 및 해싱에 사용할 대칭키 생성
r2의 대칭키 계산 완료=r1<--r2의 공개키와 임의의 수<--r2
(5) 인증=psk 이용시는 자신의 id와 암호를 해시코드로 생성하여 전송
r1-->r1의 id와 암호에대한 해시코드-->r2
(6)인증=psk 이용시는 자신의 id와 암호를 해시코드로 생성하여 전송
r1<--r2의 id와 암호에대한 해시코드<--r2

3) ike 2단계(quick mode)

(1) ipsec sa 제안
r1-->암호화=3des,해싱=sha,보호대상 네트워크,동작모드(transport,tunnel),encapsulation(eps/ah)-->r2
(2) ipsec sa 선택
r1<--암호화=3des,해싱=sha,보호대상 네트워크,동작모드(transport,tunnel),encapsulation(eps/ah)<--r2
(3) 수신확인

r1-->수신확인-->r2

ike 는 총9단계를 거쳐서 세션이 완료
1단계(6)+2단계(3)

isakmp 세션에서 송수신되는 모든 패킷들은 udp 500포트 사용

ike 1단계->ike 2단계->esp 또는 ah로 encapsulation 된 데이타 송신


5.diffie-hellman 알고리즘
공개키/개인키 알고리즘을 사용하여 대칭키 생성

1) 동작방식
(1)
대칭키
   I
데이타-->암호화된 데이타
   I
3des

(2)

대칭키
   I
데이타-->해시코드+데이타
   I
sha

2) 해시코드 종류
(1) hmac-md5-96 = 128bit 해시코드 생성
(2) hmac-sha-1-96 = 160bit 해시코드 생성

6.esp 패킷 포맷 구조
esp 헤더(암호화 안함,무결성 확인) - spi(security parameter index) 32byte = 목적지ip와 sa를 조합하여 현재 패킷의 sa 값 표시
esp 헤더(암호화 안함,무결성 확인) - 순서번호=패킷마다 1씩 증가
데이타(암호화 함,무결성 확인) - data
esp 트레일러(암호화 함,무결성 확인) - 패딩
esp 트레일러(암호화 함,무결성 확인) - 패딩길이 8byte
esp 트레일러(암호화 함,무결성 확인) - 넥스트헤더 8byte
icv(intergrity check value)=데이타의 변조확인을 위하여 추가하는 hash 코드값

7.ipsec 동작모드
원래의 데이타 패킷에 vpn장비의 새로운 ip헤더를 추가하는지 여부에 따라 transport mode 인지 tunnel mode인지 구분

1) transport mode
종단장비사이에 직접 ipsec vpn을 이용한 통신이 이루어지는 경우
tunnel mode를 사용할수 도 있음

2) tunnel mode
종단장비들 전송경로 사이에 있는 ipsec vpn 게이트웨이를 이용하여 통신을 하는 경우

     

8. mtu 크기
시스코에서 권고하는 최적 mtu = 1300 byte
gre를 사용할경우 tunnel interface의 mtu 기본값이 1514 byte이므로 1300으로 수정해야함
ex) ip mtu 1300

9. esp 패킷 처리순서
1) 암호화 알고리즘을 결정하기 위하여 sa 확인
2) 패킷 암호화
3) 순서번호 생성
4) icv 계산
5) 분할
6) 전송
7) 수신
8) 수신 interface의 acl 적용
9) 패킷 조립
10) sa 확인
11) 순서번호 확인
12) 무결성 확인
13) 패킷 복호화

10.vpn 통신 순서
 1) tunnel 연결 확인
  -> 물리적으로 연결이 되어 있어야함
  -> gateway로 ping 정상인지 확인
 2) nhrp 동작 정상 확인
 -> 센타 vpn-hub의 nhrp cache에 dynamic으로 점포의 tunnel ip 와 공인 ip가 등록됨
 -> interface tunnel의 nhrp 설정이 정상인지 확인
 3) eigrp 네이버 확인
  센타 vpn-hub의 interface tunnel의 ip nhrp map multicast dynamic 설정에 의해서 dynamic방법으로 알게된 점포 nhrp 주소에 대해서만 multicast를 해당 점포로 보냄
정상 등록이 안된 점포는 eigrp  multicast 가 전송되지 않음
점포에서는 센타 네이버 안 보임
센타 vpn hup 에서는 점포가 네이버로 보임

# interface tunnel is up -> ipsec 통신 정상 -> nhrp 등록 정상 -> eigrp 네이버 수립 ->정상 통신

11. ip nrhp map 설정

 1) 라우터 a
  (config)# ip nhrp map multicast b
   -> b 라우터로만 broadcast 및 multicast 전송

 2) 라우터 a
  (config)# ip nhrp map multicast b
  -> 목적지가 한개 이므로 의미가 없다

12.recursive routing 에러
 1) 사례
  ip route 0.0.0.0 0.0.0.0 t0
  tunnel destination 1.1.1.1
  router eigrp 10
  net 1.1.1.0 0.0.0.255
  -> eigrp 설정에 목적지의 nbma ip 주소를 넣으면 recursive routing 에러 발생