[j-nsp] JUNOS BootP-relay Behaviour

[alain.briant]

When I configure DHCP relay like this on an EX switch:

"set forwarding-options helpers bootp interface XX server @IPDHCPserver"

The outgoing relayed paquets are received on the DHCP server with a
source address
of the outgoing interface of the EX switch (the Net IP.B address)

__________
_______ { }
Net IP.A | | Net IP.B { }
DHCP client |----------| EX SW |----------{ NET }--| DHCP
server
|_______| { }
{__________}



On a C router and other brands the behaviour is different and the
address used
is the one from the incoming interface (the Net IP.A address)

Does someone know if the behaviour of the JUNOS relay can be changed to
use the
incomming interface address?

Thanks for your help
Alain

[Phil Mayers]

Post by alain.briant
The outgoing relayed paquets are received on the DHCP server with a
source address
of the outgoing interface of the EX switch (the Net IP.B address)
__________
_______ { }
Net IP.A | | Net IP.B { }
DHCP client |----------| EX SW |----------{ NET }--| DHCP
server
|_______| { }
{__________}
On a C router and other brands the behaviour is different and the
address used
is the one from the incoming interface (the Net IP.A address)

We see this too, but why does it matter? DHCP servers are required to
inspect the "giaddr" field in the BOOTP/DHCP header, not the source of
the IP packet.

[alain.briant]

Hi Phil

This does matter because the DHCP server has to answer back to the source address of the packets received and in case you have a firewall between the NET and the DHCP server the firewall could be configured to deny packets from the net.ipB interface and only allow packets from net.IPA.

Finally I have done some tests on the DHCP relay on an M7i (so a real Juniper router) and the behaviour is the same as with Cisco.

So the Case that I opened on the JTAC was lastly taken in account as a real bug.

I am waiting for a new release now.

Yes indeed the problem in the majority of the cases is not very painful but in some cases you can get stuck!

Kind regards
Alain


-----Message d'origine-----
De : Phil Mayers [mailto:p.mayers at imperial.ac.uk]
Envoy? : lundi 9 mars 2009 13:03
? : Briant,A,Alain,JPECS R
Cc : juniper-nsp at puck.nether.net
Objet : Re: [j-nsp] JUNOS BootP-relay Behaviour

Post by alain.briant
The outgoing relayed paquets are received on the DHCP server with a
source address of the outgoing interface of the EX switch (the Net
IP.B address)
__________
_______ { }
Net IP.A | | Net IP.B { }
DHCP client |----------| EX SW |----------{ NET }--| DHCP
server
|_______| { }
{__________}
On a C router and other brands the behaviour is different and the
address used is the one from the incoming interface (the Net IP.A
address)

We see this too, but why does it matter? DHCP servers are required to inspect the "giaddr" field in the BOOTP/DHCP header, not the source of the IP packet.

[Phil Mayers]

Post by alain.briant
Hi Phil
This does matter because the DHCP server has to answer back to the
source address of the packets received and in case you have a

No - the RFCs specifically state that replies either go to:

* ciaddr - for unicast bootp/dhcp requests
* giaddr - for relayed bootp/dhcp requests
* direct layer2 transmission, for local requests

See RFC 2131 section 4.1. There's nothing about the source IP of the
packet, for the simple reason that multiple relays is legal. The
following setup for example:

client -- router1 -- router2 -- router3 -- dhcpserver

* client transmits request
* router1 forwards to router2 and sets giaddr, increments "hops"
* router2 forwards to router3, increments "hops"
* router3 sends to dhcpserver, increments "hops"
* dhcpserver replies to giaddr i.e. router1

This is useful if you want to give a customer DHCP service but would
rather not give out the IPs of your DHCP servers; you can tell them to
relay to your router, and setup the forwarding on your router.

I agree this makes firewalling DHCP messages tedious, but it's an old
protocol, and storing a full return-path on relays or in the message
itself would be tedious.

[Daniel.Hilj]

Try the "vpn" keyword. That's how you change this behaviour with JunosES at least, haven't got a EX to test on now but possibly the same.

set forwarding-options helpers bootp ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
client-response-ttl IP time-to-live value to set in responses to client (1..255)
description Text description of servers

interface Incoming BOOTP/DHCP request forwarding interface configuration

maximum-hop-count Maximum number of hops per packet (1..16)
minimum-wait-time Minimum number of seconds before requests are forwarded (0..30000)
relay-agent-option Use DHCP Relay Agent option in relayed BOOTP/DHCP messages

server Server information

vpn Enable vpn encryption


Regards
Daniel

-----Original Message-----
From: Phil Mayers [mailto:p.mayers at imperial.ac.uk]
Sent: 09 March 2009 12:03
To: alain.briant at bt.com
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] JUNOS BootP-relay Behaviour

The outgoing relayed paquets are received on the DHCP server with a
source address
of the outgoing interface of the EX switch (the Net IP.B address)
__________
_______ { }
Net IP.A | | Net IP.B { }
DHCP client |----------| EX SW |----------{ NET }--| DHCP
server
|_______| { }
{__________}
On a C router and other brands the behaviour is different and the
address used
is the one from the incoming interface (the Net IP.A address)

We see this too, but why does it matter? DHCP servers are required to
inspect the "giaddr" field in the BOOTP/DHCP header, not the source of
the IP packet.

----------------------------------------------------------------------------------------------------------
Synetrix Holdings Limited
Tel: [phone]
www.synetrix.co.uk

Synetrix (Holdings) Limited is a limited company registered in England and Wales. Registered number: 0349 1956. VAT number: GB776 1259 07. Registered office: Synetrix House, 49-51 Victoria Road, Farnborough, Hampshire, GU14 7PA.

IMPORTANT NOTICE:
This message is intended solely for the use of the Individual or organisation to whom it is addressed. It may contain privileged or confidential information. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you should not use, copy, alter, or disclose the contents of this message. All information or opinions expressed in this message and/or any attachments are those of the author and are not necessarily those of Synetrix Holdings Limited. Synetrix Holdings Limited accepts no responsibility for loss or damage arising from its use, including damage from virus.

[alain.briant]

Thanks for your answers, but like I told you the JTAC admited that the implementation done on JUNOS on the M series is the correct one.

Buy the way on the EX the VPN keyworkd doesn't exist:

--- JUNOS 9.4R1.8 built 2009-02-08 16:30:58 UTC
Alain at Switch_EX3200> set forwarding-options helpers bootp ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
client-response-ttl IP time-to-live value to set in responses to client (1..255)
description Text description of servers

dhcp-option82 Configure DHCP option 82
interface Incoming BOOTP/DHCP request forwarding interface configuration

maximum-hop-count Maximum number of hops per packet (1..16)
minimum-wait-time Minimum number of seconds before requests are forwarded (0..30000)
relay-agent-option Use DHCP Relay Agent option in relayed BOOTP/DHCP messages

server Server information

[edit]

Kind regards
Alain


-----Message d'origine-----
De : Daniel.Hilj at synetrix.co.uk [mailto:Daniel.Hilj at synetrix.co.uk]
Envoy? : lundi 9 mars 2009 15:41
? : p.mayers at imperial.ac.uk; Briant,A,Alain,JPECS R
Cc : juniper-nsp at puck.nether.net
Objet : RE: [j-nsp] JUNOS BootP-relay Behaviour

Try the "vpn" keyword. That's how you change this behaviour with JunosES at least, haven't got a EX to test on now but possibly the same.

set forwarding-options helpers bootp ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these
+ groups
client-response-ttl IP time-to-live value to set in responses to client (1..255)
description Text description of servers

interface Incoming BOOTP/DHCP request forwarding interface configuration

maximum-hop-count Maximum number of hops per packet (1..16)
minimum-wait-time Minimum number of seconds before requests are forwarded (0..30000)
relay-agent-option Use DHCP Relay Agent option in relayed BOOTP/DHCP messages

server Server information

vpn Enable vpn encryption


Regards
Daniel

-----Original Message-----
From: Phil Mayers [mailto:p.mayers at imperial.ac.uk]
Sent: 09 March 2009 12:03
To: alain.briant at bt.com
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] JUNOS BootP-relay Behaviour

The outgoing relayed paquets are received on the DHCP server with a
source address of the outgoing interface of the EX switch (the Net
IP.B address)
__________
_______ { }
Net IP.A | | Net IP.B { }
DHCP client |----------| EX SW |----------{ NET }--| DHCP
server
|_______| { }
{__________}
On a C router and other brands the behaviour is different and the
address used is the one from the incoming interface (the Net IP.A
address)

We see this too, but why does it matter? DHCP servers are required to inspect the "giaddr" field in the BOOTP/DHCP header, not the source of the IP packet.

----------------------------------------------------------------------------------------------------------
Synetrix Holdings Limited
Tel: [phone]
www.synetrix.co.uk

Synetrix (Holdings) Limited is a limited company registered in England and Wales. Registered number: 0349 1956. VAT number: GB776 1259 07. Registered office: Synetrix House, 49-51 Victoria Road, Farnborough, Hampshire, GU14 7PA.

IMPORTANT NOTICE:
This message is intended solely for the use of the Individual or organisation to whom it is addressed. It may contain privileged or confidential information. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you should not use, copy, alter, or disclose the contents of this message. All information or opinions expressed in this message and/or any attachments are those of the author and are not necessarily those of Synetrix Holdings Limited. Synetrix Holdings Limited accepts no responsibility for loss or damage arising from its use, including damage from virus.