'dsr'에 해당되는 글 3건

  1. 2014.04.07 Assigned Internet Protocol Numbers (1)
  2. 2009.11.30 DSR - Dynamic Source Routing Protocol
  3. 2009.01.14 DSR(Direct Server Return) with Alteon 구성 (8)
2014.04.07 18:20

Assigned Internet Protocol Numbers

Assigned Internet Protocol Numbers

DecimalKeyword Protocol IPv6 Extension Header Reference 
0HOPOPTIPv6 Hop-by-Hop OptionY[RFC2460]
1ICMPInternet Control Message[RFC792]
2IGMPInternet Group Management[RFC1112]
4IPv4IPv4 encapsulation[RFC2003]
6TCPTransmission Control[RFC793]
8EGPExterior Gateway Protocol[RFC888][David_Mills]
9IGPany private interior gateway (used by Cisco for their IGRP)[Internet_Assigned_Numbers_Authority]
10BBN-RCC-MONBBN RCC Monitoring[Steve_Chipman]
11NVP-IINetwork Voice Protocol[RFC741][Steve_Casner]
12PUPPUP[Boggs, D., J. Shoch, E. Taft, and R. Metcalfe, "PUP: An Internetwork Architecture", XEROX Palo Alto Research Center, CSL-79-10, July 1979; also in IEEE Transactions on Communication, Volume COM-28, Number 4, April 1980.][[XEROX]]
14EMCONEMCON[<mystery contact>]
15XNETCross Net Debugger[Haverty, J., "XNET Formats for Internet Protocol Version 4", IEN 158, October 1980.][Jack_Haverty]
17UDPUser Datagram[RFC768][Jon_Postel]
18MUXMultiplexing[Cohen, D. and J. Postel, "Multiplexing Protocol", IEN 90, USC/Information Sciences Institute, May 1979.][Jon_Postel]
19DCN-MEASDCN Measurement Subsystems[David_Mills]
20HMPHost Monitoring[RFC869][Bob_Hinden]
21PRMPacket Radio Measurement[Zaw_Sing_Su]
22XNS-IDPXEROX NS IDP["The Ethernet, A Local Area Network: Data Link Layer and Physical Layer Specification", AA-K759B-TK, Digital Equipment Corporation, Maynard, MA. Also as: "The Ethernet - A Local Area Network", Version 1.0, Digital Equipment Corporation, Intel Corporation, Xerox Corporation, September 1980. And: "The Ethernet, A Local Area Network: Data Link Layer and Physical Layer Specifications", Digital, Intel and Xerox, November 1982. And: XEROX, "The Ethernet, A Local Area Network: Data Link Layer and Physical Layer Specification", X3T51/80-50, Xerox Corporation, Stamford, CT., October 1980.][[XEROX]]
27RDPReliable Data Protocol[RFC908][Bob_Hinden]
28IRTPInternet Reliable Transaction[RFC938][Trudy_Miller]
29ISO-TP4ISO Transport Protocol Class 4[RFC905][<mystery contact>]
30NETBLTBulk Data Transfer Protocol[RFC969][David_Clark]
31MFE-NSPMFE Network Services Protocol[Shuttleworth, B., "A Documentary of MFENet, a National Computer Network", UCRL-52317, Lawrence Livermore Labs, Livermore, California, June 1977.][Barry_Howard]
32MERIT-INPMERIT Internodal Protocol[Hans_Werner_Braun]
33DCCPDatagram Congestion Control Protocol[RFC4340]
343PCThird Party Connect Protocol[Stuart_A_Friedberg]
35IDPRInter-Domain Policy Routing Protocol[Martha_Steenstrup]
37DDPDatagram Delivery Protocol[Wesley_Craig]
38IDPR-CMTPIDPR Control Message Transport Proto[Martha_Steenstrup]
39TP++TP++ Transport Protocol[Dirk_Fromhein]
40ILIL Transport Protocol[Dave_Presotto]
41IPv6IPv6 encapsulation[RFC2473]
42SDRPSource Demand Routing Protocol[Deborah_Estrin]
43IPv6-RouteRouting Header for IPv6Y[Steve_Deering]
44IPv6-FragFragment Header for IPv6Y[Steve_Deering]
45IDRPInter-Domain Routing Protocol[Sue_Hares]
46RSVPReservation Protocol[RFC2205][RFC3209][Bob_Braden]
47GREGeneric Routing Encapsulation[RFC1701][Tony_Li]
48DSRDynamic Source Routing Protocol[RFC4728]
49BNABNA[Gary Salamon]
50ESPEncap Security PayloadY[RFC4303]
51AHAuthentication HeaderY[RFC4302]
52I-NLSPIntegrated Net Layer Security TUBA[K_Robert_Glenn]
53SWIPEIP with Encryption[John_Ioannidis]
54NARPNBMA Address Resolution Protocol[RFC1735]
55MOBILEIP Mobility[Charlie_Perkins]
56TLSPTransport Layer Security Protocol using Kryptonet key management[Christer_Oberg]
58IPv6-ICMPICMP for IPv6[RFC2460]
59IPv6-NoNxtNo Next Header for IPv6[RFC2460]
60IPv6-OptsDestination Options for IPv6Y[RFC2460]
61any host internal protocol[Internet_Assigned_Numbers_Authority]
62CFTPCFTP[Forsdick, H., "CFTP", Network Message, Bolt Beranek and Newman, January 1982.][Harry_Forsdick]
63any local network[Internet_Assigned_Numbers_Authority]
64SAT-EXPAKSATNET and Backroom EXPAK[Steven_Blumenthal]
65KRYPTOLANKryptolan[Paul Liu]
66RVDMIT Remote Virtual Disk Protocol[Michael_Greenwald]
67IPPCInternet Pluribus Packet Core[Steven_Blumenthal]
68any distributed file system[Internet_Assigned_Numbers_Authority]
69SAT-MONSATNET Monitoring[Steven_Blumenthal]
70VISAVISA Protocol[Gene_Tsudik]
71IPCVInternet Packet Core Utility[Steven_Blumenthal]
72CPNXComputer Protocol Network Executive[David Mittnacht]
73CPHBComputer Protocol Heart Beat[David Mittnacht]
74WSNWang Span Network[Victor Dafoulas]
75PVPPacket Video Protocol[Steve_Casner]
76BR-SAT-MONBackroom SATNET Monitoring[Steven_Blumenthal]
77SUN-NDSUN ND PROTOCOL-Temporary[William_Melohn]
78WB-MONWIDEBAND Monitoring[Steven_Blumenthal]
80ISO-IPISO Internet Protocol[Marshall_T_Rose]
83VINESVINES[Brian Horn]
84TTPTransaction Transport Protocol[Jim_Stevens]
84IPTMInternet Protocol Traffic Manager[Jim_Stevens]
86DGPDissimilar Gateway Protocol[M/A-COM Government Systems, "Dissimilar Gateway Protocol Specification, Draft Version", Contract no. CS901145, November 16, 1987.][Mike_Little]
88EIGRPEIGRP[Cisco Systems, "Gateway Server Reference Manual", Manual Revision B, January 10, 1988.][Guenther_Schreiner]
90Sprite-RPCSprite RPC Protocol[Welch, B., "The Sprite Remote Procedure Call System", Technical Report, UCB/Computer Science Dept., 86/302, University of California at Berkeley, June 1986.][Bruce Willins]
91LARPLocus Address Resolution Protocol[Brian Horn]
92MTPMulticast Transport Protocol[Susie_Armstrong]
93AX.25AX.25 Frames[Brian_Kantor]
94IPIPIP-within-IP Encapsulation Protocol[John_Ioannidis]
95MICPMobile Internetworking Control Pro.[John_Ioannidis]
96SCC-SPSemaphore Communications Sec. Pro.[Howard_Hart]
97ETHERIPEthernet-within-IP Encapsulation[RFC3378]
98ENCAPEncapsulation Header[RFC1241][Robert_Woodburn]
99any private encryption scheme[Internet_Assigned_Numbers_Authority]
101IFMPIpsilon Flow Management Protocol[Bob_Hinden][November 1995, 1997.]
102PNNIPNNI over IP[Ross_Callon]
103PIMProtocol Independent Multicast[RFC4601][Dino_Farinacci]
107A/NActive Networks[Bob_Braden]
108IPCompIP Payload Compression Protocol[RFC2393]
109SNPSitara Networks Protocol[Manickam_R_Sridhar]
110Compaq-PeerCompaq Peer Protocol[Victor_Volpe]
111IPX-in-IPIPX in IP[CJ_Lee]
112VRRPVirtual Router Redundancy Protocol[RFC5798]
113PGMPGM Reliable Transport Protocol[Tony_Speakman]
114any 0-hop protocol[Internet_Assigned_Numbers_Authority]
115L2TPLayer Two Tunneling Protocol[RFC3931][Bernard_Aboba]
116DDXD-II Data Exchange (DDX)[John_Worley]
117IATPInteractive Agent Transfer Protocol[John_Murphy]
118STPSchedule Transfer Protocol[Jean_Michel_Pittet]
119SRPSpectraLink Radio Protocol[Mark_Hamilton]
121SMPSimple Message Protocol[Leif_Ekblad]
122SMSimple Multicast Protocol[Jon_Crowcroft][draft-perlman-simple-multicast]
123PTPPerformance Transparency Protocol[Michael_Welzl]
124ISIS over IPv4[Tony_Przygienda]
126CRTPCombat Radio Transport Protocol[Robert_Sautter]
127CRUDPCombat Radio User Datagram[Robert_Sautter]
130SPSSecure Packet Shield[Bill_McIntosh]
131PIPEPrivate IP Encapsulation within IP[Bernhard_Petri]
132SCTPStream Control Transmission Protocol[Randall_R_Stewart]
133FCFibre Channel[Murali_Rajagopal][RFC6172]
135Mobility HeaderY[RFC6275]
138manetMANET Protocols[RFC5498]
139HIPHost Identity ProtocolY[RFC5201]
140Shim6Shim6 ProtocolY[RFC5533]
141WESPWrapped Encapsulating Security Payload[RFC5840]
142ROHCRobust Header Compression[RFC5858]
253Use for experimentation and testingY[RFC3692]
254Use for experimentation and testingY[RFC3692]

출처 : iana.org

Trackback 1 Comment 1
  1. 2014.04.07 18:22 address edit & del reply


2009.11.30 16:55

DSR - Dynamic Source Routing Protocol

* hop-by-hop 라우팅 프로토콜이 아닌 source routing 기반

* route discovery, route maintenance 메커니즘을 정의

* route discovery

- Source node가 Destination까지의 경로를 찾는 과정 (캐쉬에 경로가 없을 때)
- ROUTE REQUEST 패킷을 broadcast, 이는 망에서 flood 됨
- RREQ메시지에 route record 포함 -중간 노드에서 순서대로 추가
- 중복방지를 위한 sequence number
- Destination node에서 ROUTE REPLY 패킷을 전송
- Route discovery의 cost를 줄이기 위해 각 node는 source route의 캐쉬를 유지
--- learned, overheard
--- RREQ의 propagation 범위를 줄이는 효과

* route maintenance
- 사용중인 route를 monitor 하여 link failure 검출
--- link level ACK
--- passive ACK : 패킷을 next hop에 보낸후, next hop이 패킷을 forwarding하는지 overhearing
- Link failure를 검출한 host는 ROUTE ERROR패킷을 source에게 전송
- Cache 내에서 해당 route를 모두 삭제
* Route Discovery 최적화
- Overheard, Forward한 routing information을 cache함 - route discovery 빈도를 줄임
- ROUTE REQUEST 의 propagation을 줄이기 위해 cache된 route를 사용하여 응답
- ROUTE REPLY Storm이 발생할 수 있음 - 목적지 경로까지의 홉수에 비례하는 ‘delay’를 주어 방지, Source가 최단 경로를 먼저 받을 수 있음
* Route Maintenance 최적화
- 만약 overheard 패킷의 경로보다 더 빠른 경로를 알고 있으면, gratuitous Route Reply를 보내 더 빠른 경로를 유지할 수 있도록 함

- 각 노드는 RouteError를 야기했던 data packet을 복원하려는 시도를 함
- 받은 RouteError를 RouteRequest에 piggyback - stale 된 경로를 널리 알리기 위해
- RouteError메시지를 엿들어 자기 cache와 확인

* DSR이 다른 MANET 라우팅 프로토콜(DSDV,TORA,AODV)에 비해 좋은 성능

linux Source routing 적용 & 삭제 방법

** 적용방법 **

## 처음 상태
ezWall# ip rule list
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup 253

## 라우팅을 위한 rule 을 생성한다
ezWall# ip rule add from table 200

## 생성된 후
ezWall# ip rule list
0:      from all lookup local
32765:  from lookup 200
32766:  from all lookup main
32767:  from all lookup 253

## 생성된 rule 에 라우팅을 추가한다
ezWall# ip route add via table 200

## 생성된 후
ezWall# ip route list table 200
default via dev eth3

## cache를 삭제하여 라우팅을 적용한다
ezWall# ip route flush cache

## 적용된 후 -- 라우팅 테이블 변경사항은 표시되지 않는다
ezWall# ip route dev eth3  proto kernel  scope link  src dev eth0  proto kernel  scope link  src
default via dev eth0

ezWall# netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface   U        40 0          0 eth3   U        40 0          0 eth0         UG       40 0          0 eth0

** 삭제방법 ** 

## 설정된 rule 을 삭제한다
ezWall# ip rule list
0:      from all lookup local
32765:  from lookup 200
32766:  from all lookup main
32767:  from all lookup 253

ezWall# ip rule del from table 200

## 삭제된 후
ezWall# ip rule list
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup 253

## cahe를 삭제하여 라우팅을 적용한다
ezWall# ip route flush cache

## 삭제된 후 -- 라우팅 테이블 변경사항은 표시되지 않는다
ezWall# ip route dev eth3  proto kernel  scope link  src dev eth0  proto kernel  scope link  src
default via dev eth0

ezWall# netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface   U        40 0          0 eth3   U        40 0          0 eth0         UG       40 0          0 eth0

출처 : http://cafe.naver.com/kbnetworking

Trackback 0 Comment 0
2009.01.14 14:31

DSR(Direct Server Return) with Alteon 구성

1. Alteon의 SLB (Server Load Balancing ; 일반적인 구성)

DSR구성을 아시려면 먼저 Alteon의 SLB부터 아셔야 하는데여... 


Layer 4 switch는 기본적으로 TCP header를 살펴보고 header 정보를 이용하여 ,  Traffic을 배분하여 주는 장비를 이야기 합니다.이런 부분은 기존의 Layer 3장비와 다르다고 하여서(Layer 2 switch는 layer 2 정보를 참조하여 traffic을 배분하고 Layer 3는 layer3까지의 정보를 참조하여 Traffic의 방향을 결정해 주져..^^) Layer 4 switch라고 이야기들을 많이 합니다. 정확한 명칭은 Multilayer application switch라고 하는 것이 맞을 것 같습니다. 이런 기법을 이용하여 여러가지것들을.. 주로 loadbalancing하는데 사용되어 지는데...대표적인 것이 SLB(Server Load Balancing)와 FWLB(Firewall Load balancing)과 같은 것이 있읍니다.

 SLB에서 중요한 것은 TCP의 해당 서비스 별로 이를 서버에게 배분해주어야 하는 문제점이 생기는데 이를 위해서 IP header부분의 destination ip와 destination mac정보를 바꾸어 주는 일을 filter를 통해서 하고, 이런 filter들을 server enable, client enable이라고 표현합니다.

보통의 Cisco Access-list에서는 IP header정보를 바꾸거나 하는 일을 하지 않습니다.(단지 drop이냐 permit이냐의 결정을 하져..) 하지만 layer 4 장비에서는 이런일들을 하기 때문에 잘 살펴보아야 정확한 loadbalancing을 해줄 수 있읍니다.


SLB를 하실때 중요한 점은 먼저 무슨 서비스(web, email, dns...)를 어떤 IP하나로 묶어주느냐를 먼저 결정해야 합니다. 즉 실재 서버(이를 Real Server IP ; RIP)들을 하나로 묶어 줄 IP가 필요하게 되는데 이를 VIP(Virtual Server IP)라고 합니다. VIP는 알테온 장비가 가지고 있는 가상 IP이며 가상 mac을 가지게 됩니다.

* 여담이지만 과거에 어떤분이 저에게 DHCP서버를 Load balancing해달라고 해서..ㅎㅎ DHCP서버는 Load balancing 불가입니다.  이 부분은 나중에 또 기회있으면 왜 안되는지 이야기 해보겠읍니다.

중요한 것은 Alteon이 SLB할때 어떤일을 하는지를 이야기 하는 것이 중요하므로...암튼 DHCP가 down되어도 골치아픈데..쩝..

그림을 한번 그려 보겠읍니다.

                             Client A(IP 4번)





              alteon ( vip 1번)    service web


                          |                        |

                          |                        |

                          |                        |

              real server(IP 2번)   real server (IP 3번)

s : server enable filter 

c : client enable filter  (해당 uplink port에 enable)                    

Virtual IP를 알테온이 가지고 있다고 이야기 했져... 그럼 실재 통신이 어떻게 되는지 봐가면서 이야기 하면 원리를 이해 할 수 있읍니다.

Client 4는 VIP1번으로 80통신을 하고자 합니다. VIP 1번은 당연히 DNS에 등록이 되어 있겠져...www.xxx.com 처럼 말이져... Real Server의 IP를 DNS에 등록하는게 아닙니다.

그럼 client 4가 VIP 1번으로 실제 통신할때의 TCP/IP 3 way handshake는 어떤식으로 맺어지게 될까여?

Client to Server        :  Sip ( 4번-client ip )       Dip ( 1번- virtual ip )     SYN

이 패킷이 알테온 스위치까지 당연히 오겠져.. Alteon이 1번 VIP를 가지고 있으니까여?

그런데 위에서 간단히 쓴 SYN packet은 당연히 Real server로 보내져야 합니다. Real server로 어떻게 보낼까여?  목적지 IP가 1번이기 때문에 알테온스위치에서 더이상 나아가지 못합니다. 지금 상태로는 ..(1번은 VIP이고 1번에 대한 IP정보 MAC정보 모두 알테온에 설정되어 있으니까여..)  서비스를 받기 위해서는 당연히 Real server로 보내야 겠져...어떻게 보낼까여?

당연히 DIP를 바꾸어 주면 됩니다. DIP를 Real Server IP인 2번 아니면 3번으로 바꾸어 주면 되겠져...

그리고 당연히 Dmac또한 Real Server의 mac으로 바꾸어 주는 작업을 하게 되면 됩니다.

이런 역활을 하기 위해서 client enable이라는 filter가 존재합니다. client enable filter는 외부에서 오는 packet을 검사하여 destination이 vip이고 해당 tcp destination port가 web일 경우 destination ip를 vip에서 rip로 virtual mac에서 real server의 mac으로 바꾸어주는 일을 합니다.

그런데 또 문제가 있읍니다. 이번에는 반대로 Real Server가 syn에 대한 syn-ack packet을 client로 날릴때도 생각을 해주어야 합니다.

그럼 Real Server 2번이 syn을 받았다고 하고 보내는 경우를 가정 하겠읍니다.

Server to Client   : Sip ( 2번-real server ip )     Dip ( 4번- client ip )       syn-ack

흠 이러면 통신이 될까여 ?  당연히 안되겠져...ㅎㅎ

왜냐하면 현재 통신이 Client IP (4번)이 VIP (1번)과 통신하려고 syn을 보냈는데 이에 대한 응답측 source ip가 (2번 - real server ip)그대로 나아가게 되면 안되겠져..당연히 source ip인 2번을 virtual ip인 4번으로 누군가가 바꾸어 주어야 합니다.

이런 역활을 Alteon이 해주게 되고 이런일을 하는 filter를 server enable이라고 표현을 합니다.

server enable filter는 해당 서버에서 날아오는 packet중에 source web이고 source ip가 real server이다면 real server의 IP를 virtual server의 ip로 바꾸어 주는 일을 하게 됩니다.

그리고 중요한 점은 Alteon으로 SLB구성을 하실때 client to server syn packet이 반드시 알테온을 거쳐서 가야 하며 이에대한 응답도 alteon을 거쳐서 가야 한다는 점입니다. 이런 과정을 무시한 것을 DSR이라고 하는데여...이부분은 2편에서 보시면 됩니다. ^^

흠 머리가 복잡하시져..  정리를 하면..

SLB에서 알테온 스위치가 해야 할 일을 다시한번 정리하면


알테온 스위치는 destination이 vip이고 destination service가 web인 packet(session)을 찾아서

destination ip를 vip에서 rip1혹은 rip2  destination mac을 vmac에서 rmac으로 바꾸어 주는 일을 해야하며- 이런 일을 하는 filter를 client enable이라고 합니다.

또한 반대로 real server에서 응답이 올때 real server에서 온 packet의 4계층 header정보를 조사하여 source port가 80이며 ip가 real server일 경우 rip를 vip로 바꾸어서 최종적으로 응답을 하게 하는 일을 하는데 이 역활을 하는 filter를 server enable이라고 표현을 한다.


어느정도 정리 되실지 모르겠읍니다. 또하나 더 이야기를 하자면 Alteon에서의 filter는 모두 inbound 방향의 filter입니다. Cisco의 Access-list처럼 in, out 양방향의 filter를 가질 수가 없읍니다.


      A=CIP                       B=VIP                        C =RIP1, C1=RIP2


                                   Alteon switch


               ------------------>  Client enable   ------------------à

(1)                                                                              (2)

               ß-----------------  Server enable   <-------------------

(4)                                 (3)

지난번 이야기한 SLB 내용이 너무 난해 한 것 같아서 그림을 다시 그려보았습니다.


* CIP : Client IP  VIP : Virtual IP         RIP : Real Server IP


  SMAC        SIP         DIP        DMAC      구분


                   CIP        VIP          VMAC     (1)

                   CIP        RIP          RMAC     (2)

                   RIP1       CIP                        (3)

                   VIP        CIP                         (4)



위 표 중에 빨간색칠 한데를 잘 보시면 무엇이 Traffic흐름에 따라서 바뀌는지 잘 표시되어 있읍니다.

헐 제 정성 브이 ^^ 말을 못하니 표라도 많이 그려야지..ㅎㅎ


이때 어떤 filter가 적용되는지는 말 안해도 되리라 굳게 믿습니다.



SMAC은 왜 생략되었는지 아실 것 같아 생략하였습니다. 또한 DMAC도 마찬가지로여..^^ Alteon은 layer 2 switch역활 layer 3역활을 그대로 수행한다고 생각하셔도 됩니다. 일반적인 Traffic은여 ..



2. DSR(Direct Server Return)이란   ?




                                                                    RIP 1, RIP2


위 그림이 DSR의 전형적인 그림입니다. 중간에 스위치는 L2 switch 이고여  초록색 상자가 L4 switch입니다.


지난번에 L4 switch의 SLB의 중요한 점은 한번 packet이 L4로 지나가면 그에 대한 응답도 반드시 L4로 지나가야 한다고

말한 것 같습니다. 그런데 DSR은 말 그대로 (Direct Server Return) 서버의 응답패킷이 L4를 거치지 않고 바로 클라이언트에게


가야 한다는데 문제가 생깁니다.  그럼 뭐하러 DSR을 쓸까여 DSR은 L4 switch의 port(물리적 PORT)가 부족하거나 할 때 구성하는 방법 중에 하나입니다.



이제 그림 보면서 이야기 해보겠습니다. 위에 그림 그려놓은 것 중에서 (1)번 과정은 똑같습니다. 다시 위에 표를 가지고 와보겠습니다.



SMAC        SIP         DIP        DMAC      구분


                CIP        VIP          VMAC     (1)

                CIP        RIP          RMAC     (2)

                RIP1       CIP                       (3)

                VIP        CIP                       (4)


(1)에서 DIP가 VIP가 되는 것 까지는 좋은데 문제는 (3)에서부터 발생하게 됩니다. 위의 구성이라면여 , DSR은 (4)이 생략되기 때문에 (3)번의 packet이 client에게 직접가게 됩니다. 이러면 통신이 될까여? 절대 안되겠져.. Client입장에서는 VIP를 목적지로 통신을 시도하려고 했는데 목적지에서 날아온 패킷의 SIP가 RIP1으로 기재되어 있다면 Client는 이를 무시하게 됩니다. 흠 그럼 무언가 해결 방법이 있어야 할 것 같은데 ?


해결 방법은 간단합니다. 위의 그림에서 (2)번으로 packet을 보낼 때 RIP를 변경시키지 않는 것입니다. 다시 표를 그려볼게여


SMAC        SIP         DIP        DMAC      구분


                CIP        VIP          VMAC     (1)

                CIP        VIP          RMAC     (2)

                VIP        CIP                        (3)


위와같이 변경시키면 될 것 같습니다. 위의 표처럼 IP를 바꾸지 않고 MAC만 바꾸어 주어서 traffic의 방향을 변경시키면 됩니다.다시한번 말하면 (1)에서 변경시켜야 할부분은 VMAC-> RMAC으로 변경시키고 VIP는 변경을 하지 않는 것 입니다. 그런데 이렇게 해서 (2)으로 넘어가게 되면 서버가 자신의 MAC주소로 온 packet은 맞는데 자신의 IP가 아닌 VIP를 목적지로 온 packet이라 drop을 하는 문제점이 생기게 됩니다. 그래서 생각해낸 것이 Server에 local loopback 주소를 VIP로 맞추어주게 되면 이를 해결 하게 될 수 있습니다.


그때 언뜻 질문내용이 기억이 안나는데 서버에 왜 local loopback주소를 VIP로 하냐고 질문하신 분이 계셔서 이렇게 허접 하게 답변을 해봅니다

이렇게 되면 전혀 문제가 없겠져(관련설정은 생략하겠습니다. 넘 말이 길어지니까..혹 매뉴얼 보시면 설정하는 것은 자세히 나옵니다.)


그리고 주의하셔야 할 사항은 L4 옆에 스위치가 L2 switch라는 점입니다. 왜 L2 switch일까는 L4 switch가 packet의 header중에 어디를 ( L2정보만을) 변경시켜서

loadbalancing을 하는지를 생각하신다면 쉽게 의문이 풀리실 겁니다.


도움이 되셨는지 모르겠습니다. 참고삼아 대형 portal site중에 저런 DSR구성을 한데가 있읍니다.

주로 portal service를 하는데서  위와 같은 구성을 하려고 하져..


그렇지만 관리적 측면에서 위와 같이 구성하는 것은 한번쯤 생각을 더 해보아야 하지 않을까 하는 생각이 가끔이지만 들때가 있읍니다.

Trackback 0 Comment 8
  1. 김기원 2011.01.13 18:30 address edit & del reply

    감사합니다...너무나 소중한 자료 잘 보았습니다...이해가 쏙쏙 되네요...
    잘 사용하는 엔지니어가 되겠습니다^^

  2. 민상훈 2011.05.11 17:47 address edit & del reply

    저도 감사합니다. 이렇게 개념이 쏙쏙 이해되다니 너무 행복합니다.
    저도 훌륭한 엔지니어가 되도록 하겠습니다.

  3. 감사합니다. 2015.01.21 09:25 address edit & del reply

    좋은 글 진심으로 감사드립니다.

  4. 감사합니다. 2015.01.21 09:25 address edit & del reply

    좋은 글 진심으로 감사드립니다.

  5. 감사합니다. 2015.01.21 09:25 address edit & del reply

    좋은 글 진심으로 감사드립니다.

  6. 감사합니다. 2015.03.10 17:14 address edit & del reply

    잘 읽었습니다. 이해가 정말 잘 됩니다. 감사합니다.

  7. L4 AlteonER 2016.04.10 22:47 address edit & del reply

    감사합니다. 정말 좋은 글이네요. 이런 글이 많아졌으면 좋겠습니다. ^^

  8. L4 AlteonER 2016.04.11 00:23 address edit & del reply

    근데 뒷부분에서 궁금한 점이 있는데요. Alteon L4 가 Client enable Filter 로 Destination MAC 주소만 VMAC 을 Real server MAC 으로 변경한다고 하시면서 Loopback 주소를 VIP로 맞춰준다고 하는데 이 부분이 잘 이해가 안되는데..
    서버에 Loopback 주소를 A라고 준다면 Alteon L4 에서 VIP 주소에 A라고 똑같이 적으면 IP가 충돌이 발생할 것 같은데 Alteon L4 에서 VIP 주소를 특정 주소가 아니라 Server Loopback IP 라고 경로로 잡아준다는 말인가요? ^^;;
    장비를 실제로 본 적도 없고, Config 들어가서 뭘 만져본 적도 없이 이론적으로만 접근하려고 하니까 어려움이 있네요. 그래도 이해를 좀 해보려고 하는데 설명 좀 부탁드립니다 ^^;