ESXi 설치시 미지원 랜카드 문제로 설치 못할 경우
ESXi Customizer 를 사용하여 랜카드 드라이버를 추가 할 수 있다.
ESXi customizer
Atheros AR8161
Atheros AR8151
Realtek R8168
VMware_bootbank_net-r8168_8.013.00-3vmw.510.0.0.799733.vib
Realtek R8169
VMware_bootbank_net-r8169_6.011.00-2vmw.510.0.0.799733.vib
BGP FlowSpec은 BGP peer간에 신속하게 filtering and policing 기능을 전파시켜 DDOS 공격을 방지하는 역할을 한다.
기존의 RTBH는 ddos공격을 대상의 주소의 next-hop 을 null/discard 로 전파하여 공격을 방지 하였다. 하지만 이럴 경우 공격 공격대상이 unreachable 상태에 빠지게 된다.
FlowSpec는 기존의 RTBH와는 다르게 null/discard 동작만이 아니라 source , destination, L4 parameter, packet parameter( length, fragmentation , etc, ) 등등 더 다양한 옵션을 사용 하여 ddos 공격에 대응 할 수 있다.
Juniper FlowSpec 동작
아래 그림과 같이 BGP peer를 통해 전달받은 flow를 validation 과정을 거쳐 match 되는 flow를 Local-RIB에 저장하고 firewall filter로 변환하여 각각에 PFE에 내려주면 모든 인터페이스에 해당 filter를 적용시킨다.
LAB TEST
망 구성도
[ R1 ] --------------------- [ R2 ]
1.1.1.1 192.168.0.0/24 2.2.2.2
R1
set logical-systems TEST_1 interfaces xe-1/2/0 unit 0 family inet address 10.10.10.1/24 set logical-systems TEST_1 interfaces lo0 unit 1 family inet address 1.1.1.1/32 set logical-systems TEST_1 protocols bgp group TEST type internal set logical-systems TEST_1 protocols bgp group TEST local-address 1.1.1.1 set logical-systems TEST_1 protocols bgp group TEST family inet unicast set logical-systems TEST_1 protocols bgp group TEST family inet flow no-validate TEST_default set logical-systems TEST_1 protocols bgp group TEST neighbor 2.2.2.2 set logical-systems TEST_1 policy-options policy-statement TEST_default term 10 then accept set logical-systems TEST_1 policy-options policy-statement TEST_default term 5 then reject set logical-systems TEST_1 routing-options static route 2.2.2.2/32 next-hop 10.10.10.2 set logical-systems TEST_1 routing-options autonomous-system 1234 |
R2
set interfaces xe-1/3/0 unit 0 family inet address 10.10.10.2/24 set interfaces lo0 unit 2 family inet address 2.2.2.2/32 set routing-options static route 1.1.1.1/32 next-hop 10.10.10.1 set routing-options autonomous-system 1234 set routing-options flow route TEST match protocol icmp set routing-options flow route TEST then discard set protocols bgp group TEST type internal set protocols bgp group TEST local-address 2.2.2.2 set protocols bgp group TEST family inet unicast set protocols bgp group TEST family inet flow no-validate TEST set protocols bgp group TEST cluster 2.2.2.2 set protocols bgp group TEST neighbor 1.1.1.1 set policy-options policy-statement TEST then accept |
-> R2 에서 icmp discard 하는 flow (TEST) 를 생성하여 R1 에게 전달함.
BGP를 통해 flow를 전달받은 R1은 수신한 flow 를 보고 firewall filter 를 생성하여 모든 인터페이스에 적용시킨다.
R1에서 R2로 ping을 시도하면 수신받은 flow 기반으로 생성한 firewall filter에 의하여 icmp packet이 Drop 된다.
R1 firewall filter ( R1에서 R2로 ping 시도 후 )
icraft@Mx960# run show firewall Filter: __default_bpdu_filter__ Filter: __flowspec_default_inet__ Counters: Name Bytes Packets *,*,proto=1 588 7 [edit] icraft@Mx960# |
수신받은 flow는 show route 명령어를 통해 확인가능 하다. 해당 flow는 inetflow.0 table에 저장된다.
R1 routing table
inetflow.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both *,*,proto=1/term:1 *[Flow/5] 01:04:20 Fictitious [edit] icraft@Mx960# |
수신받을 flow 도 필터링이 가능하다. 아래와 같은 flow 를 생성 하고 라우팅 테이블을 확인해보면
R2
set routing-options flow route TEST match destination 100.100.0.0/16 set routing-options flow route TEST then accept icraft@Mx960:TEST_1# show protocols bgp group TEST { type internal; local-address 1.1.1.1; family inet { unicast; flow { no-validate TEST; } } neighbor 2.2.2.2; } |
R1
inetflow.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 100.100/16,*/term:N/A *[BGP/170] 00:02:49, localpref 100, from 2.2.2.2 AS path: I, validation-state: unverified Fictitious [edit] icraft@Mx960:TEST_1# # |
위와같이 R2로 부터 수신한 flow 가 table 에 등록되어 있는 것을 확인 가능하다.
이때 R1에 아래와 같은 정책을 적용한다.
R1
policy-statement TEST_reject { term 10 { from local-preference 100; then reject; } term 20 { then accept; } } icraft@Mx960:TEST_1# show protocols bgp group TEST { type internal; local-address 1.1.1.1; family inet { unicast; flow { no-validate TEST_reject; } } neighbor 2.2.2.2; } |
R1에서 보내준 flow는 bgp로 수신받은 flow 이기 때문에 preference 가 100이므로 해당 flow 가 reject 가 된다.
이 때 라우팅 테이블을 확인 해 보면
R1icraft@Mx960:TEST_1# run show route hidden inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) inetflow.0: 1 destinations, 1 routes (0 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 100.100/16,*/term:N/A [BGP ] 00:09:27, localpref 100, from 2.2.2.2 AS path: I, validation-state: unverified Fictitious [edit] icraft@Mx960:TEST_1# |
해당 루트가 hidden으로 빠진걸 볼 수 있다. validation에서 match 되지 않는 flow 는 hidden 으로 빠지는걸 확인 가능하다.
OSPF Support for Traffic Engineering
기본적으로 JUNOS에서는 ospf traffic engineering dlsable 상태이다.
enable 하게 되면 shortest-path-first (SPF) 알고리즘이 MPLS 계위에 설정되어 있는 LSP를 고려하여 계산을 하고 link-state
advertisements (LSAs)에 추가적인 engineering parameters 들이 붙게 된다.
또한 metric 을 설정할 경우 TE용도에 사용되고 일반적인 OSPF 포워딩 에는 영항을 주지 않는다.
user@host# show protocols ospftraffic-engineering;
[edit protocols ospf area 0.0.0.0]
user@host set interface fe-0/1/1 te-metric 10
GRES 는 라우팅엔진 switchover 시에 커널 정보와 인터페이스 정보 손실을 방지하여 트래픽 손실을 방지하는 JUNOS 의 HA 기능중 하나입니다. 커널정보와 인터페이스 정보 손실을 방지하지만 control plane( 라우팅엔진 내 정보들 ) 의 손실을 보호하지는 못합니다. 그러기 때문에 switchover가 발생하면 neighboring 라우터는 이를 감지 할 수 있습니다.
NSR(nonstop routing) 이나 GR(graceful restart) 과 같이 사용하게 되면 마스터 라우팅 엔진이 라우팅 업데이트를 받으면 그 즉시 백업 라우팅 엔진에게도 전달 해 주므로 swithover 가 발생하면 라우팅 정보는 그대로 유지 할 수 있습니다.
백업 라우팅엔진이 마스터로 부터 keepalive를 2초 동안 받지 못하면 백업라우팅엔진은 마스터가 고장난걸로 간주하고 자신이 마스터가 됩니다. PFE(packet forwarding engine)은 기존 마스터와 연결을 끊고 새로운 마스터와 새로 연결합니다. PFE는 리부팅 하지 않기 때문에 ( GRES 미 설정시에는 PFE가 리부팅 함) 트래픽이 중단되지 않습니다. 새로운 마스터 라우팅엔진은 PFE와 동기화를 하게 되고 라우팅엔진이 PFE가 가진 forwarding table 이 최신정보가 아닌 걸 알게되면 업데이트 메시지를 보내 업데이트 하게 된다.
1. 마스터 라우팅엔진 동작
2. chassisd 와 같은 routing platform processes들이 동작
3. Packet Forwarding Engine이 동작하고 마스터 라우팅엔진과 연결됨.
4. 모든 라우팅 정보들이 업데이트 된다.
5. 백업 라우팅엔진 동작
6. 라우터가 GRES가 enable 되어있는지 인지한다.
7. kernel synchronization process (ksyncd) 이 백업과 마스터 라우팅엔진을 동기화 시킨다.
8. 동기화가 완료되면 모든 상태정보와 포워딩테이블이 업데이트 된다.
1. 마스터 라우팅엔진으로부터 keepalive 를 받지 못하면 라우터는 switchover 를 수행한다.
2. Packet Forwarding Engine은 새롭게 마스터가 된 라우팅엔진과 연결을 수립한다.
3. Routing platform processes(rpd) 는 GRES가 보호하지 못하므로 rpd가 restart 된다.
4. switchover 발생 시점의 상태정보를 업데이트 한다.
5. GR (graceful restart) 가 설정되어 있다면 helper라우터로 부터 라우팅 정보를 받아서 복원한다.
출처 : http://www.juniper.net/techpubs/en_US/junos13.1/topics/concept/gres-overview.html
ESXi-Customizer-v2.7.2.exe
