유무선 통신 사업자나 일반 기업 전산망은 그들의 정책/필요성에 따라 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를 모든 라우터가 배우게 됩니다.
그럼 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에 다음과 같은 설정을 합니다.
그리고 나머지 라우터 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 |
||||||||
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가 좋더라구요. ^^*
상호: (주)엔앰씨컨설팅그룹 주소: 서울시 강남구 테헤란로 128, 3층 387호 대표이사: 손장우 전화: 02-3444-5747 메일: webmaster@netmanias.com 등록번호: 서울 아03722 제호: 넷매니아즈 등록일자: 2015년 5월 4일 발행/편집인: 손장우 청소년보호책임자: 이수정
주소: 본사: 서울시 강남구 테헤란로 128, 3층 387호 Netmanias USA: 5214 36th Ave. NE Seattle, WA 98105 USA
Copyright ⓒ 2002-2023 NMC Consulting Group. All rights reserved.
|
PBR 룰이 항상 Forwarding Table 보다 우선하는 건가요?
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
만일 R1으로 Source IP가 1.1.1.1인 패킷이 들어왔는데 R1-R4 구간이 죽었을 경우(e.g. R1의 ge3가 shutdown 된 경우)
본래의 라우팅에 따라 이 패킷은 R2로 보내지는 것인가요? 아니면 그냥 폐기되어 버리나요?
하지만 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
최인범님, 아래 Cisco Support Community 글도 참고하세요.
https://supportforums.cisco.com/thread/164757
내용을 보다 보니 궁금한게 생겨서 여쭤봅니다.
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로 보내도록 하는 경우입니다.
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
그러면 만약에
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 작업을 하려고 하거든요 ㅠㅠ
답변 주시면 더욱 감사합니다.
^^