Configuration DHCP Relay in routing instance on Juniper SRX Devices - 91Sec

Latest

Learning, Sharing, Creating

Monday, January 19, 2015

Configuration DHCP Relay in routing instance on Juniper SRX Devices

I was having DHCP Relay configured on SRX 240H Cluster devices, it was quite straightforward experience, and Juniper KB 15755 covered all points when I first configured it. It was working fine at  JUNOS version from 11.x to 12.1x44-D40.2 in cluster environment and related interfaces are in different Routing instance.

Basic topology looks like as below: DHCP Server 10.9.1.50 is in routing instance v_i on Reth2.0 interface. Three DHCP Client networks are in different routing instances, v_t and v_Def.


Global DHCP Relay configuration looks like following:
forwarding-options {
    helpers {
        traceoptions {
            file helplog;
            level all;
            flag bootp;
        }
        bootp {
            relay-agent-option;
            description DHCP-Relay-to-DHCP-server-10.9.1.50;
            server 10.9.1.50 routing-instance vr_i;
            maximum-hop-count 10;
            minimum-wait-time 300;
            client-response-ttl 20;
            interface {
                reth2.0;
                reth10.90;
                reth10.94;
                reth7.24;
            }
        }
    }
}
Although based on KB25925, DHCP is not supported on J and SRX series devices in the chassis cluster before Junos 12.1X46. The above configuration did work on my cluster environment before. Also no firewall rules are needed to allow traffic between different zones and DHCP server 10.9.1.50, which was required in KB15755.

The problem comes up when I upgraded SRX240H to SRX1400 platform. DHCP Relay completely not working.

KB 28642[SRX] Example: Configuring DHCP relay server on SRX where relay agent interface and DHCP server interfaces are in different routing-instances explained why and KB28641 [SRX] Configuring the JDHCP relay agent in Custom Routing instance provides additional set up for this feature on server side.

All steps are listed as below:

1. Forwarding Option Configuration on all related DHCP Client Routing Instance

In my environment, there are three Reth interfaces used for DHCP Clients , which is reth7.24, reth10.90 and reth10.94. Reth 7.24 is in routing instance vr_t. Both reht10.90 and reth10.94 are in routing intstance vr_def.

vr_t {
    instance-type virtual-router;
    interface reth7.24;
    routing-options {
        instance-import from_all_to_vr_t;
    }
    forwarding-options {
        dhcp-relay {
            server-group {
                DHCPSVR {
                    10.9.1.50;
                }
            }
            active-server-group DHCPSVR;
            group relay-in-vr {
                interface reth7.24;
            }
        }
    }
}
vr_def {
    instance-type virtual-router;
    interface reth10.90;
    interface reth10.94;
    routing-options {
        instance-import from_all_to_vr_def;
    }
    forwarding-options {
        dhcp-relay {
            server-group {            
                DHCPSVR {
                    10.9.1.50;
                }
            }
            active-server-group DHCPSVR;
            group relay-in-vr {
                interface reth10.90;
                interface reth10.94;
            }
        }
    }
}

2. Forward option configuration at DHCP Server Routing Instance

DHCP server 10.9.1.50 is in routing instance vr_i.
vr_i{
    instance-type virtual-router;
    interface reth2.0;
    routing-options {
        instance-import [ from_all_to_vr_i ];
    }
    forwarding-options {
        dhcp-relay {
            server-group {
                dummy-config;
            }
        }
    }
}

3. Make sure each client routing instance (vr_t and vr_def) has routes to vr_i. 

Also vr_i routing instance has routes to vr_t and vr_def. That is above instance-import configuration used for in above configuration.

Policy-statement configuration is under the policy-options:

policy-statement from_all_to_vr_t {
    term term5 {
        from instance vr_i;
        then accept;
    }
}
policy-statement from_all_to_vr_def {
    term term5 {
        from instance vr_i;
        then accept;
    }
}
policy-statement from_all_to_vr_i {
    term term4 {
        from instance vr_t;
        then accept;
    }
    term term5 {
        from instance vr_def;
        then accept;
    }
}

4. No firewall policy will be needed. But both services bootp and dhcp  have to be allowed on all DHCP client interface's host-inbound-traffic. Bootp will be needed on server side.

interfaces {
    reth2.0 {
        host-inbound-traffic {
            system-services {
                bootp;
            }
        }
    }
}
interfaces {
    reth10.90 {
        host-inbound-traffic {
            system-services {
                bootp;
                dhcp;
            }
        }
    }
}
interfaces {
    reth10.94{
        host-inbound-traffic {
            system-services {
                bootp;
                dhcp;
            }
        }
    }
}
interfaces {
    reth7.24 {
        host-inbound-traffic {
            system-services {
                bootp;
                dhcp;
            }
        }
    }
}


Reference:

No comments:

Post a Comment

Banner

BANNER 728X90