| 리포트 | 기술문서 | 테크-블로그 | 원샷 갤러리 | 네트워크/통신 뉴스 | 기술자료실 | 자유게시판      한국 ICT 기업 총람 |

제품 검색

|

통신 방송 통계

 
 
 
섹션 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/UHD IoT SDN/NFV Wi-Fi Video Streaming KT SK Telecom LG U+ OTT Network Protocol CDN YouTube Data Center
 
Private 5G | Edge 넷매니아즈 Private 5G 분석글 KT SK Telecom Verizon AT&T Vodafone DT Telefonica China Mobile Optage

NEC UPDATED

Fujitsu NEW Microsoft AWS    
  Ericsson Nokia Huawei Samsung Mavenir Affirmed Metaswitch Athonet Altiostar Airspan Kyocera Apresia   일본 Local 5G 전개 현황
 
스폰서채널 |

 

  스폰서채널 서비스란?
banner
banner
PBR(Policy Based Routing)이 뭐에요?
Basic Understanding of the PBR(Policy Based Routing)
March 07, 2012 | By 유창모 (cmyoo@netmanias.com)
banner
코멘트 (9)
19

유무선 통신 사업자나 일반 기업 전산망은 그들의 정책/필요성에 따라 IP 네트워크에 PBR(Policy Based Routing)을 적용하고 있니다. 오늘은 이 PBR의 개념과 관련 CLI(configuration)에 대해서 설명을 드리고, 다음 시간에는 국내외 통신 사업자망에서의 PBR적용 사례를 보여 드리도록 하겠습니다.

 

일반적인 IP 포워딩은...

 

원래 IP 라우터는 수신된 IP 패킷의 Destination IP 주소를, 자신이 가지고 있는 Forwarding Table과 비교(LPM; Longest Prefix Match 수행)하여 송신 포트(Outgoing Interface)를 결정하고, 그 포트로 패킷을 전달(패킷 포워딩)합니다. 

 

참고: Control Plane은 Routing Table 혹은 RIB(Routing Information Base), Data Plane은 Forwarding Table 혹은 FIB (Forwarding Information Base)라 부르며, OSPF, IS-IS, BGP와 같은 라우팅 프로토콜에 의해서 배워온 라우팅 정보를 RIB에 쓰게 되고, 그 RIB 정보는 그대로 FIB로 복사되어, 라우터는 패킷이 수신되면 FIB를 참조하여(RIB는 참조하지 않음) Wire Speed로 패킷을 포워딩함

 

 

위 그림에서 R1, R2, R3, R4, R5에는 OSPF나 IS-IS와 같은 IGP(Interior Gateway Protocol)가 돌고 있으며, IGP를 통해 R1과 R3에 연결된 S1, S2의 주소 대역(네트워크 주소)인 1.1.1.0/24와 2.2.2.0/24를 모든 라우터가 배우게 됩니다.

  • 각 라우터의 링크 cost가 모두 같다는 가정에서, IGP의 Shortest Path Algorithm(cost가 작은 경로 선택)에 따라,
  • S1에서 Destination IP 주소를 2.2.2.2로 하여 패킷을 R1으로 보내면, R1은 자신의 Forwarding Table을 lookup하여 "Destination IP 주소 2.2.2.2에 대한 Next Hop(다음 라우터의 IP 주소)은 10.1.1.2(R2의 Interface IP)이고, 나는 ge2 포트로 이패킷을 송신하면 되는구나"를 알게 되어 패킷을 R2로 전달합니다. 
  • 여기서 잠깐! 왜 Next Hop 주소가 필요할까요? 다들 잘 아시죠 ^^ 그건 바로 Next Hop의 MAC 주소를 알기 위함입니다. IP over Ethernet 환경(라우터의 포트가 Ethernet)에서는 항상 Source MAC 주소(송신 라우터의 MAC 주소, 여기서는 R1의 ge2에 할당된 MAC 주소)와 Destination MAC 주소(수신 라우터의 MAC 주소, 여기서는 R2의 ge1에 할당된 MAC 주소)가 붙어야 하기 때문입니다.
  • R1으로 부터 패킷을 수신한 R2는 자신의 Forwarding Table을 lookup하여 "Next Hop은 10.1.2.2(R3의 Interface IP)이고 송신 포트는 ge2인 것"을 알고 패킷을 R3로 송신합니다.
  • R2로 부터 패킷을 수신한 R3도 역시 자신의 Forwarding Table을 lookup하여 "Destination IP 주소 2.2.2.2는 나와 바로 붙어 있는 device이고 송신 포트는 ge3인 것"을 알고 2.2.2.2에 대해 ARP resolving 수행 후, S2로 패킷을 송신합니다.
  • 따라서 S1이 S2로 보낸 패킷은 S1 -> R1 -> R2 -> R3 -> S2 흐름을 통해 S2에 도착합니다.

 

그럼 PBR(Policy Based Routing)은?

 

반면 PBR은 패킷의 Destination IP 주소 이외에 다른 필드들(Source IP 주소, TCP/UDP port # 등)을 참조하여 송신 포트를 결정(패킷 포워딩)하는 기술로, 시스코(Cisco)에서는 이를 PBR(Policy Based Routing)이라 부르지만, 주니퍼(Juniper)의 경우 FBF(Filter Based Forwarding)이라 부릅니다.

 

이제 PBR/FBF 설정을 통해 S1에서 S2으로 가는 패킷을 S1 -> R1 -> R4 -> R5 -> R3 -> S2로 변경해 보도록 하겠습니다. (아래 그림)

이를 위해 R1에 다음과 같은 설정을 합니다.

  • S1과 연결된 Interface인 ge1으로 Source IP 대역이 1.1.1.0/24인 패킷이 수신되면
  • 이 패킷은 R4(10.1.3.2)로 포워딩함

그리고 나머지 라우터 R4, R5, R3에는 별다른 설정이 필요 없습니다. 왜냐면 Destination IP 주소 2.2.2.2인 패킷에 대해서 Forwarding Table lookup에 의해 S2로 전달 될 수 있기 때문입니다.

만약 S2에서 S1으로의 패킷 흐름도 R5, R4를 거치도록 하려면 R3에 역시 PBR/FBF 설정을 하면 됩니다.

 

 

 

Cisco PBR(Policy Based Routing) CLI

 

R1 PBR Configuration

 1  

2  



3  

 
 access-list 1 permit 1.1.1.0 0.0.0.255
 !
 route-map S1-to-S2 permit 10
   match ip address 1
   set ip next-hop 10.1.3.2 
 !
 interface ge1
   ip policy route-map S1-to-S2

 

  1. ACL 1은 Source IP 주소가 1.1.1.0 ~ 1.1.1.255인 패킷을 분류하는 classification rule입니다.
  2. "S1-to-S2"라는 route-map을 선언하여, ACL 1에 match 되는 패킷은 Next Hop이 10.1.3.2(R4의 ge1 interface IP 주소)인 라우터로 보냅니다. "set ip next-hop 10.1.3.2" 대신에 "set interface ge3"으로 하여 패킷을 R4로 PBR하게 할 수도 있습니다.
  3. 위에서 정의한 route-map "S1-to-S2"를 패킷이 수신되는 interface인 ge1에 적용합니다. 이를 통해 R1은 ge1으로 수신되는 패킷 중에 Source IP 대역이 1.1.1.0 ~ 1.1.1.254인 패킷에 대해서 R4로 PBR을 하게 됩니다.

 

Juniper FBF(Filter Based Forwarding) CLI

 

R1 FBF Configuration

   1  
















   2  







   3  









   4  








 
 filter S1-to-S2 {
        term redirect {
               from {
                      source-address {   /* S1 source address prefixes */
                             1.1.1.0/24;
                      }
               }
               then {
                      routing-instance s1-to-s2-route;
               }
        }
        term default {   /* Accept all other traffic */
               then {     
                      accept;   /* Forwarding using inet.0 */         
               }
        }
 }
 routing-instances {
        s1-to-s2-route {
               instance-type forwarding;
               static {
                      route 0.0.0.0/0 nexthop 10.1.3.2; /* Static default route */
               }
        }
 }
 routing-options {
        interface-routes {
               rib-group inet fbf-group;
        }
        rib-groups {
               fbf-groups {
                      import-rib {inet.0 s1-to-s2-route.inet0}; 
               }              
        }
 }
 interfaces ge1 {
        unit 0 {
               family inet {
                      filter {
                             input S1-to-S2;
                      }
               }
        }
 }

 

Juniper CLI는 Cisco 보다 좀 많이 복잡합니다. 전 그래도 Juniper가 좋더라구요. ^^*

  1. "S1-to-S2"라는 이름의 filter rule을 정의합니다. 이 rule에는 Source IP 주소 대역이 1.1.1.0/24(1.1.1.0 ~ 1.1.1.255)인 패킷에 대해서는 일반 Forwarding Table(inet.0)이 아닌 "s1-to-s2-route"라는 이름의 Forwarding Table에 의해서 패킷이 포워딩이 되도록 정의합니다.
  2. 이제 "s1-to-s2-route"라는 이름의 routing-instance(Forwarding Table)를 정의할 차례입니다. 여기에 선언된 Forwarding Entry는 하나만 필요합니다. 모든 패킷(0.0.0.0/0, default route)을 Next Hop 10.1.3.2로 포워딩합니다. 위에 1번과 함께 묶어 생각하면 Source IP 주소 대역이 1.1.1.0/24인 패킷은 Destination IP 주소에 상관없이(0.0.0.0/0)  모두 10.1.3.2를 Next Hop으로 합니다.
  3. skip 하겠습니다. -.-;;
  4. 앞서 선언한 filer rule "S1-to-S2"를 패킷이 수신되는 interface인 ge1에 적용합니다. 이로써  R1은 ge1으로 수신되는(input) 패킷 중에 Source IP 대역이 1.1.1.0 ~ 1.1.1.254인 패킷에 대해서 R4로 FBF를 하게 됩니다.

 

박준영 2012-03-12 10:29:48
질문이 하나 있는데요.
PBR 룰이 항상 Forwarding Table 보다 우선하는 건가요?
넷매니아즈 2012-03-13 10:26:01
둘 다 가능합니다.
1. PBR 룰을 우선으로 하고 싶으면... set ip next-hop
2. Forwarding Table을 우선으로 하고 싶으면... set ip default next-hop

관련 설명은 아래와 같구요.
When using the set ip next-hop command traffic is policy routed first then passed onto a destination based routing method. When using the set ip default next-hop the destination based routing method is used first then it will be passed to policy routing.

그리고 관련 링크는 아래와 같습니다.
http://www.cisco.com/en/US/tech/tk364/technologies_configuration_example09186a00801f3b54.shtml
최인범 2013-04-24 06:22:13
위의 Cisco PBR 케이스에서,
만일 R1으로 Source IP가 1.1.1.1인 패킷이 들어왔는데 R1-R4 구간이 죽었을 경우(e.g. R1의 ge3가 shutdown 된 경우)
본래의 라우팅에 따라 이 패킷은 R2로 보내지는 것인가요? 아니면 그냥 폐기되어 버리나요?
신성균 2013-04-25 02:48:50
일반적으로 PBR에서 정의한 Next-hop IP address 가 Unreacheable이면, Normal-forwarding 이되어 라우팅 Table을 참조하여 Next-hop 이 결정됩니다.
하지만 PBR이란 것이 아무래도 인위적인 Routing 결정이므로 일반적으로 Next-hop을 2개이상 설정하는 방법을 더 많이 사용하는 편이며, Cisco Conifiguration 은 다음과 같습니다.
set ip next-hop 10.1.3.2 10.1.1.2
이와같이 설정하면 첫번째 next-hop인 10.1.3.2 가 unreacheable 이면 10.1.1.2 로 next-hop이 바뀝니다.

IP SLA(Track)을 사용하여 Reliable 한 Failover Option도 제공합니다.
더 자세한 것은 아래 링크된 문서 참조 바랍니다.
http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_pi/configuration/12-4/iri-pbr-mult-track.html
넷매니아즈 2013-04-25 10:28:33
신성균님, 좋은 답변 감사드립니다.
최인범님, 아래 Cisco Support Community 글도 참고하세요.
https://supportforums.cisco.com/thread/164757
Ffan 2013-06-07 14:33:51
잘보고갑니다. 감사합니다.
Hun 2013-10-20 01:20:31
좋은 자료 감사합니다.
내용을 보다 보니 궁금한게 생겨서 여쭤봅니다.
PBR에서 Next-hop이 Unreacheable 한지를 결정할 때, Connected Network가 아닌 라우팅 프로토콜(OSPF, BGP, Static)에 의해 참조되는 경로로 포워딩 할 수 있는 방법이 있는지요?
예를 들면, PBR의 Next-hop이 1.1.1.1 일 경우, 이 IP address가 BGP를 통해 1.1.1.1/32 GW 2.2.2.2 이렇게 announce 될 경우에만 2.2.2.2로 보내도록 하는 경우입니다.
유서영 2013-10-22 10:09:39
■ Object Tracking
Object tracking is an independent process that monitors objects such as the following:
- State of the line protocol of an interface (conntected network 검사)
- Existence of an entry in the routing table (말씀하신 routing table 존재유무 검사)
- Results of a Service Assurance Agent (SAA) operation, such as a ping (직접 ping을 통해 확인)
Clients such as Hot Standby Router Protocol (HSRP), Virtual Router Redundancy Protocol (VRRP), Gateway Load Balancing Protocol (GLBP), and (with this feature) PBR can register their interest in specific, tracked objects and then take action when the state of the objects changes.

■ PBR Support for Multiple Tracking Options Feature Design
The PBR Support for Multiple Tracking Options feature gives PBR access to all the objects that are available through the tracking process. The tracking process provides the ability to track individual objects--such as ICMP ping reachability, routing adjacency, an application running on a remote device, a route in the Routing Information Base (RIB)--or to track the state of an interface line protocol.

Object tracking functions in the following manner. PBR will inform the tracking process that a certain object should be tracked. The tracking process will in turn notify PBR when the state of that object changes.

출처: http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_pi/configuration/12-4/iri-pbr-mult-track.html
문영민 2014-02-04 02:52:53
안녕하세요
그러면 만약에
routing-instances {
s1-to-s2-route {
instance-type forwarding;
static {
route 0.0.0.0/0 nexthop 10.1.3.2; /* Static default route */
-------------------------------------------------------------------------------------------
여기서
static {
route 0.0.0.0/0[
nexthop 10.1.3.2; /* Static default route */
qualified-next-hop10.1.3.X
metric 100이라 하면

시스코에서는 qualified-next-hop10.1.3.X 의 기능을 대신 할수 없지 않나요? metric이야 설정하면 되겠지만요

그래도 이페이지를 찾을 수 있어서 정말 너무 다행입니다.

지금 밤을 지새우며 Juniper -> cisco 작업을 하려고 하거든요 ㅠㅠ

답변 주시면 더욱 감사합니다.
Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
View All (995)
5G (75) AI (5) ALTO (1) AR (2) ARP (6) AT&T (1) Akamai (5) Authentication (5) BT (1) Backhaul (2) Big Data (2) Bridging (5) C-RAN/Fronthaul (17) CDN (20) CIoT (2) CPRI (6) Carrier Aggregation (5) Charging (2) China Mobile (2) Cisco (6) CoMP (3) Comcast (1) DHCP (6) DNS (15) Data Center (15) EDGE (14) EMM (1) EPS Bearer (7) Ethernet (3) FTTH (8) GSLB (5) Gigabit Internet (17) Google (17) Google Global Cache (8) Google TV (1) HLS (5) HTTP (5) HTTP Adaptive Streaming (7) HTTP Progressive Download (2) Handover (5) Huawei (1) IGMP (3) IP (6) IP Allocation (8) IP Routing (20) IPSec (4) IPTV (25) IoST (2) IoT (50) KT (45) Korea (8) Korea ICT Vendor (1) L3 Switch (5) LG U+ (24) LTE (99) LTE-A (10) LTE-A Pro (1) LTE-M (1) LTE-U (3) LoRa (5) MEC (14) MPLS (3) MWC 2013 (1) MWC 2015 (3) MWC 2016 (2) MWC 2017 (1) Mobile IPTV (1) Multi-Screen (1) Multicast (2) NAT (9) NB-IoT (6) NTT Docomo (1) Netflix (5) Network Protocol (49) Network Slicing (3) OSPF (3) OTT (20) Operator CDN (1) P2P (3) PS-LTE (3) Pooq (2) Private 5G (1) QoS (5) RCS (1) RRH (1) Request Routing (3) SD-WAN (8) SDN/NFV (37) SK Broadband (1) SK Telecom (38) Samsung (2) Security (8) Self-Driving (3) Shortest Path Tree (2) Small Cell (3) Spectrum Sharing (1) TAU (2) Transparent Caching (9) UHD (7) VLAN (2) VPN (3) VR (3) Video Streaming (22) VoLTE (1) VoWiFi (1) WAN Optimization (1) Wi-Fi (30) WiBro(WiMAX) (2) YouTube (16) eICIC (1) eMBMS (1) ePDG (6) u+ tv G (4) 로컬 5G (1)

 

 

     
         
     

 

     
     

넷매니아즈 회원 가입 하기

2020년 1월 현재 넷매니아즈 회원은 49,000+분입니다.

 

넷매니아즈 회원 가입을 하시면,

► 넷매니아즈 신규 컨텐츠 발행 소식 등의 정보를

   이메일 뉴스레터로 발송해드립니다.

► 넷매니아즈의 모든 컨텐츠를 pdf 파일로 다운로드

   받으실 수 있습니다. 

     
     

 

     
         
     

 

 

비밀번호 확인
코멘트 작성시 등록하신 비밀번호를 입력하여주세요.
비밀번호