방송이 다른 네트워크에서 어떻게 작동합니까?

DHCP를 읽고 있었는데 (RFC 2131) 릴레이 에이전트 및 브로드 캐스트에 대한 기본 지식이 있습니다. 그러나 DHCP를 심층적으로 이해하기 위해 방송 및 릴레이 에이전트 (RFC 1542)를 자세히 알아야한다는 느낌이 들었습니다. 그러나 방송에 대한 RFC (RFC919,922는별로 도움이되지 않음)를 자세히 찾을 수 없었습니다.

1. 브로드 캐스트 패킷 경로는 어떻습니까? 패킷이 소스와 다른 네트워크 용인 경우 라우터가 패킷을 삭제합니다. 이것에 대한 프로토콜이 있습니까? 라우터가 모든 브로드 캐스트를 막거나 제한적 / 로컬 브로드 캐스트 만 막습니까?

2. 브로드 캐스트 MAC 주소없이 대상이있는 직접 / 제한 브로드 캐스트 IP로 패킷을 보낼 수 있습니까? 그렇다면 MAC 주소로 인해 패킷이 단일 호스트로 전달 될 것이므로 질문이 도움이 될 것입니다.

3. 릴레이 에이전트에 의해 라우터가 활성화되어 있다고 가정하십시오. 브로드 캐스트 패킷 인 DHCPDiscover가 해당 라우터에 도착하면 어떻게 진행됩니까? 브로드 캐스트 IP에도 네트워크 "0"이 있기 때문에 가장 먼저 릴레이 에이전트는 패킷이 DHCP인지 여부를 먼저 확인합니다.

내 질문은 주제가 아닌 주제 (DHCP ond Broadcasting)가 아니므로 화를 내실 수 있지만 도와주세요. 감사합니다

라우터가 제한적이고 지시 된 브로드 캐스트를 처리하는 방법

질문에 대답하기 위해 가장 먼저 알아야 할 것은 제한된 브로드 캐스트 프레임이 라우팅되지 않는다는 것입니다. 기본적으로 라우터가 계층 2 또는 계층 3에서 브로드 캐스트되는 대상 주소가있는 프레임을 수신하면 라우터는 단순히 프레임을 삭제합니다. 이것이 라우터가 브로드 캐스트 도메인의 경계라고하는 이유입니다.

이에 대한 몇 가지 예는 다음과 같습니다.

• ff-ff-ff-ff-ff-ff (계층 2 방송)
• 255.255.255.255 (계층 3 한정 방송)

그것에 대해 생각하면, 이치에 맞습니다. 라우터가 브로드 캐스트를 전달하면 단일 arp 요청이 인터넷에서 도달 가능한 모든 단일 호스트에 도달하게되며 이는 매우 비효율적이며 다소 어리 석습니다.

반면에 직접 방송은 종종 라우팅됩니다. (IE 192.168.1.255/24) 일반적으로이 기능은 기본적으로 비활성화되어 있지만 ip directed-broadcast라우터 에서 명령을 실행하여 활성화 할 수 있습니다 . 이를 통해 라우팅 테이블에 따라 마치 일반 패킷 인 것처럼 직접 방송을 전달할 수 있습니다. 그러나 라우터가 제한된 브로드 캐스트를 전달할 수 는 없으며 기본적으로 여전히 브로드 캐스트됩니다. 이것은 또한 원래 질문과 관련하여 약간 벗어난 주제 입니다. 이에 대한 자세한 내용은 이 Cisco 양식 페이지 를 참조하십시오.

레이어 3 브로드 캐스트이지만 레이어 2가 아닙니까?

두 번째 질문에 답하기 위해 레이어 2 브로드 캐스트 주소가없는 레이어 3 브로드 캐스트 주소가있는 프레임을 갖는 것은 의미가 없습니다. 이것은 브로드 캐스트 프레임이라는 전체 목적을 무효화하고 제대로 작동하지 않습니다. 라우터가 계층 3에서 결정을 내리기 때문에 유니 캐스트 계층 2 대상 주소를 갖는 것은 라우터의 동작을 전혀 변경하지 않습니다 255.255.255.255.

이것이 중요한 것은 레이어 3 주소를 전혀 신경 쓰지 않는 스위치입니다. 스위치는 유니 캐스트 계층 2 주소 만 볼 수 있습니다. 패킷을 동일한 VLAN의 모든 인터페이스로 보내는 대신 다른 유니 캐스트 대상 주소와 마찬가지로 SAT (소스 주소 테이블)를 사용합니다. 실제로, 유니 캐스트 계층 2 주소를 할당함으로써, 프레임은 255.255.255.255계층 3에 주소를 가지 더라도 더 이상 방송 프레임이 아니다 .

실제로 DHCP 릴레이 작동 방식

마지막 질문에 관해서는 DHCP 릴레이는 라우터가 브로드 캐스트 패킷을 전달하지 않는 규칙을 "속이는"방법입니다. DHCP Discover 패킷을 보자 :

• 소스 MAC : [소스의 유니 캐스트 맥]
• 대상 MAC : ff-ff-ff-ff-ff-ff
• 소스 IP : 0.0.0.0
• 대상 IP : 255.255.255.255
• 소스 포트 : UDP 68
• 대상 포트 : UDP 67

라우터가 패킷이 ip helper-address구성된 명령으로 인터페이스에 도착하면 패킷이 기본적으로 "도움이되는"또는 전역 ip forward-protocol명령으로 구성된 프로토콜과 일치하는지 확인합니다 . 이 경우 라우터는 DHCP이므로 대상 포트가 UDP 67과 일치하고 패킷이 "도움"될 수 있도록합니다. 그런 다음 라우터는 목적지 IP 주소를 명령에 255.255.255.255의해 구성된 IP 주소 ip helper-address로 변경하고 소스 주소를 패킷이 도착한 라우터 인터페이스의 주소로 변경하고 패킷을 나머지 라우팅 로직으로 전달합니다.

이제 패킷에 유니 캐스트 대상 주소가 있으므로 라우터는 다른 패킷처럼 취급합니다. 대상 IP 주소 (현재 도우미 주소)에 대해 arps 한 다음 패킷을 적절한 인터페이스로 보내기 전에 계층 2 주소를 바꿉니다.

다시 돌아 가기

라우터는 클라이언트로 다시 전송되는 DHCP 제공에 대해 본질적으로 동일한 프로세스를 반대로 사용합니다. DHCP 서버는 DHCP Discover 패킷에서 소스 주소로 지정된 IP 주소로 오퍼를 보냅니다. 따라서 DHCP 서버를 떠나는 패킷은 다음과 같습니다.

• 소스 MAC : DHCP 서버의 유니 캐스트 맥
• 대상 MAC : 라우터의 맥 주소 또는 DHCP 서버의 기본 게이트웨이
• 원본 IP : DHCP 서버의 유니 캐스트 IP 주소
• 대상 IP : DHCP Discover 패킷이 도달 한 첫 번째 라우터 인터페이스의 IP 주소
• 소스 포트 : UDP 67
• 대상 포트 : UDP 68

이 패킷에는 유니 캐스트 계층 3 대상 주소가 있으므로 라우터는 패킷의 대상 IP와 일치하는 IP 주소를 가진 인터페이스가있는 라우터에 도달 할 때까지 패킷을 정상적으로 전달합니다. 이 라우터는 ip helper-address해당 인터페이스에 여전히 구성 이 있음을 이전부터 기억하십시오 . 라우터는 패킷이 DHCP Offer인지 확인한 후 패킷을 다시 작성하여 브로드 캐스트 패킷이되고 DHCP 클라이언트가 해당 네트워크 세그먼트에 있다는 것을 알고 해당 인터페이스로 다시 보냅니다. 라우터를 떠나는 패킷은 이제 다음과 같습니다.

• 소스 MAC : 라우터 인터페이스의 유니 캐스트 맥
• 대상 MAC : ff-ff-ff-ff-ff-ff
• 원본 IP : DHCP 서버의 유니 캐스트 IP 주소
• 대상 IP : 255.255.255.255
• 소스 포트 : UDP 67
• 대상 포트 : UDP 68

TL : DR; ip helper-address라우터가 패킷을 전송하기 전에 패킷의 대상 IP 주소를 DHCP 서버의 유니 캐스트 IP 주소로 변경하여 제한된 브로드 캐스트를 전달할 수 없다는 규칙에 따라 인터페이스 하위 명령 "치트"를 사용하는 DHCP 릴레이 . 따라서 회선의 모든 라우터가 패킷을 DHCP 서버에 적절하게 라우팅 할 수 있습니다. DHCP 서버는 응답 할 때 DHCP Discover 패킷 ( ip helper-interface명령 이있는 패킷)을 처음 수신 한 라우터 인터페이스의 유니 캐스트 IP 주소로 패킷을 다시 보냅니다 . 라우터가 오퍼를 다시 받으면이를 브로드 캐스트 패킷으로 다시 변환하여 브로드 캐스트 도메인의 클라이언트와 인터페이스를 보냅니다.

1. 라우터는 구성된 경우 192.168.1.255/24와 같은 직접 브로드 캐스트를 전달합니다. Cisco의 경우 인터페이스에서 'no ip direct-broadcast'를 사용하여이 동작을 비활성화 할 수 있습니다.

라우터가 한 인터페이스에서 다른 인터페이스로 로컬 브로드 캐스트 (255.255.255.255)를 전달하도록하려면이 두 인터페이스를 브리지해야합니다. IRB 또는 CRB 및 BVI를 구성하는 IE

1. 불가능합니다. 라우터는 전달해야 할 모든 링크에 대해 새로운 Dst MAC 주소를 구축합니다.

2. 라우터는 DHCP 패킷임을 확인하고 유니 캐스트를 통해 프로비저닝 된 DHCP '도우미'주소로 보냅니다.

다음은 자세한 내용을 제공하고 도움을 줄 수있는 좋은 기사입니다.

http://www.ciscopress.com/articles/article.asp?p=330807&seqNum=9

HTH

방송에 대한 특정 표준은 없습니다. 일반 IP (인터넷 프로토콜)를 사용하여 특정 주소와주고받습니다.

나는 여러 브랜드의 자동화 시스템에서 일했으며 대부분은 서버 기반입니다. 사무실 PC 네트워크와 같은 일반 네트워킹 장비를 사용합니다. 둘 다 동일한 시스템에서 실행되는 것을 보았지만 한 명의 사용자가 브로드 캐스트 오디오를 중단시킬 수 있기 때문에 대규모 스테이션에서는 작동하지 않습니다. 그것들을 분리하는 것이 가장 좋습니다.

연결하는 것이 합리적 일 수있는 유일한 장소는 "트래픽"입니다. 계약마다 광고가 재생되도록하고,이를 확인하기 위해 로깅합니다.

이러한 방송 오디오 시스템의 작동 방식은 메일 서버 또는 Netflix와 매우 유사합니다. 특정 스튜디오는 특정 파일 (노래 또는 프로모션 등)에 대해 서버에 "요청"한 다음이를 제어 보드를 통해 전송기로 이어지는 출력으로 스트리밍합니다. 재생 목록은 일반적으로 PD (프로그램 디렉터) 사무실에있는 하나의 PC에서 설정됩니다.

DHCP에 대해 물었습니다. 단순히 스튜디오의 제어 보드와 PD의 PC에 주소를 자동으로 할당하는 방법입니다. 이메일을 검색하기 위해 메일 서버에 접속하거나 비디오를보기 위해 Netflix에 접속할 때 ISP의 주소와 같이 특정 주소 자체는 중요하지 않습니다.

중요한 주소는 서버 자체입니다. 이메일 서버와 마찬가지로 pop.xyzcorp.com 및 smtp.xyzcorp.com 또는 www.netflix.com. 이러한 주소는 일반적으로 전자 메일 프로그램이 전자 메일을 보내고받는 데 사용되는 서버의 주소를 '기억'하는 것처럼 각 스튜디오에 코딩됩니다.

대부분의 자동화 서버 시스템은 DHCP 서비스 (동일한 박스에 있든 다른 네트워크에 있든)를 제공하므로 각 클라이언트 스튜디오에 고정 IP 주소를 입력 할 필요가 없습니다.

신호가 어떻게 엉키지 않고 잘못된 장소로 보내지는지 궁금하다면 스튜디오와 서버를 상호 연결하는 스위치에서 답을 찾을 수 있습니다. 대상 주소를 검사하고 해당 특정 주소를 가진 스튜디오의 올바른 포트로 패킷을 보냅니다.

그렇습니다. 업계에서는 모든 것을 구어 적으로 라우터라고 부르지 만, 라우터가 비디오 신호를 한 곳에서 다른 곳으로 보내는 물리적 장치였던 옛날 텔레비전 시절의 보류입니다.

그것들은 크로스 포인트 스위처 였지만 단순히 라우터라고 불렀습니다. 단순히 입력 x에서 비디오를 가져 와서 출력 y로 보내도록 지시 할 때 지시대로 신호를 라우팅하는 것을 처리하기 때문입니다.

네트워크 스위치는 ISP가 모든 이웃이 아닌 사용자에게 이메일을 보내는 것처럼 서버 파일을 올바른 스튜디오로 전송할 수있을 정도로 똑똑합니다. 이것이 IP (Internet Protocol)의 본질입니다.