2012년 11월 30일 금요일

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 값






2012년 11월 28일 수요일

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 시험 해야함



2012년 11월 27일 화요일

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