cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

ASR9000/XR Understanding DHCP relay, proxy and forwarding broadcasts

21704
Views
0
Helpful
113
Comments

Introduction

In this article we'll explain how dhcp relay is working and how broadcasts are forwarded within IOS-XR, because the DHCP relay functionality is configured and handled differently within XR vs regular IOS.

Generally broadcasts are not forwarded by routers as they typically only live on the local subnet. However sometimes it is required to forward these broadcasts and this article will detail out how that configuration works and what the limitations are.

 

Core Issue

Considering that broadcasts are handled locally on the subnet, a router will not forward these broadcasts out and locally consume them. This presents a problem when a particular interface is servicing a subnet with clients that want to use DHCP to obtain their address information. IOS-XR at the time of writing does not have a dhcp server which means that clients cannot obtain their address from an XR router.

Even if the OS would support DHCP server, like IOS, you may want to centralize your DHCP servers in a designated area of your network which would require you to forward the client's DHCP requests to that server.

 

IOS employs the concept of an ip-helper-address to take the broadcasts and send out a directed broadcast or unicast to one or multiple servers.

 

Note that by default broadcasts are NOT forwarded by a router.

Also only UDP broadcasts can be forwarded, dhcp (which is udp based) can benefit from this only.

 

Resolution

 

Broadcast forwarding

 

In order to forward udp broadcasts, IOS uses the ip helper-address configuration underneath the interface that is expected to receive broadcasts that are to be forwarded. This pertains then to ALL udp broadcasts that are received.

 

fp7200-6(config-if)#ip helper-address ?
  A.B.C.D  IP destination address

 

In IOS-XR, DHCP broadcasts are handled and configured differently then other udp based broadcasts.

 

For IOS-XR to forward broadcasts (non DHCP) the following configuration is required:

 

RP/0/RSP1/CPU0:A9K-BOTTOM(config)#forward-protocol udp ?
  <1-65535>    Port number

 

Some well known port numbers are converted into their names, such as DNS and NBNS

 

The interface configuration for IOS-XR looks like this:

 

RP/0/RSP1/CPU0:A9K-BOTTOM(config)#int g0/1/0/14
RP/0/RSP1/CPU0:A9K-BOTTOM(config-if)#ipv4 helper-address ?
  A.B.C.D  IPv4 destination address

 

Note again that this configuration will not forward DHCP packets.

 

DHCP

There are 2 key ways to handle DHCP, one is via DHCP RELAY and one is via DHCP PROXY.

 

Relay has been supported for a long time. XR421 adds the full capability of proxy (in combination with IP subscribers)

 

Configuration: in its simplist form

 

dhcp ipv4
profile MYGROUP relay
  helper-address vrf default 40.1.1.1
  helper-address vrf default 55.1.1.2
!
interface GigabitEthernet0/1/0/14 relay profile MYGROUP
!

 

There is no further interface specific configuration required as what you're used to from IOS-XR that all protocol specific configuration is done under the protocol definition and not split across different sections.

Relay

Is more dumb in the handling of dhcp broadcasts, we are effectively taking the dhcp broadcast messages and convert them into a unicast destination which are defined by the helper addresses and we send the messages back and forth, or in fact we are relaying them between the client and the helper addresses. We maintain no state pertaining to DHCP as we are simply sending them across. The return packets from the helpers are returned as broadcasts back to the subnet we are serving.

 

In dhcp relay mode (or broadcast forwarding for that matter) packets are sent to all helper addresses.

 

In XR dhcp relay, prior to XR 4.1 and as described by CSCto39520, we only forward one offer back to the client if we receive multiple offers from the various helper addresses. While this provides still redundancy, it is in certain cases not desirable to have only offer handed to the client.

The rationale in XR was that we'd be maintaining a temporary state that links the request ID to the interface, once the first offer comes in, that state is removed. This prevents the forwarding of subsequent offers.

While normally this state and interface linkage is not needed, because we could look up the giaddr to the interface and use that, in the scenario where we are unnumbered to a loopback serving multiple interfaces, this state is useful so we send it out only on the interested interface.

 

Post XR 4.1 we'll leave that state in place for 1 minute so all offers received in that time period are forwarded.

Memory is not an issue, we could theoretically serve 1M requests per minute.

However things are bound by the LPTS punt policer and the process prioritization.

 

For some actual numbers, DHCPv4-Relay over BVI can accommodate 200K sessions and qualified CPS rate is 150 RSP440 and 250 on RSP880. DHCPv4-Relay is stateless and there are no sessions created.

 

The 200K limitation is enforced because of Adjacency creation as the adjacency is framed with ARP learning for end-user while resolving gateway ip-addresses.

 

Consider 250 CPS (Calls Per second), since ASR9K acting as Relay so access-side 4 message transactions (Discover, Offer, Request, Ack) and also server-side 4 message transactions.

So, overall 8 messages transactions per session.

That means, overall 250*8*60 = 120K message transactions per second.

 

 

Currently dhcp replies being sent as broadcast to the client so after enabling the CLI "[no]broadcast-flag policy check" it will send unicast reply to the client.

 

Proxy

In dhcp PROXY mode we do maintain state as we are handling the dhcp request on behalf of the requesting client. It looks like as we are the originator of the request to the dhcp servers. Proxy for that matter is stateful.

Proxy also stores the binding on the proxy agent locally, which relay does not.

 

 

Setup configuration, sample operation and debug verification

Setup used:

Slide1.JPG

Note: One common forgotten thing is that both dhcp servers need to have a route back to the 39.1.1.1 address in this example.

So make sure there is a static route or when running an IGP that this interface/address is included (passively)


ASR9000 related configuration provided above.

IOS dhcp server configuration is as follows:

 

SERVER 1

ip dhcp excluded-address 39.1.1.1 39.1.1.100

 

ip dhcp pool SERVER1
   network 39.1.1.0 255.255.255.0
   default-router 39.1.1.1
   dns-server 1.2.3.4

 

SERVER 2

ip dhcp excluded-address 39.1.1.1 39.1.1.200

 

ip dhcp pool SERVER2
   network 39.1.1.0 255.255.255.0
   default-router 39.1.1.1
   dns-server 6.7.8.9
!

 

No specific interface configuration required on the interfaces other then ip addresses and proper routing.

 

DEBUGS

 

dhcpd relay all flag is ON
dhcpd relay errors flag is ON
dhcpd relay events flag is ON
dhcpd relay internals flag is ON
dhcpd errors flag is ON
dhcpd events flag is ON
dhcpd packet flag is ON


RP/0/RSP1/CPU0:A9K-BOTTOM(config-if)#RP/0/RSP1/CPU0:Mar 29 13:23:27.980 : dhcpd[1064]: DHCPD PACKET: TP564: L3 Packet RX from addr = 0.0.0.0, port = 68, application len 576, vrf 0x60000000 (1610612736), tbl 0xe0000000 (3758096384)
RP/0/RSP1/CPU0:Mar 29 13:23:27.980 : dhcpd[1064]: DHCPD PACKET:  >dhcpd_iox_l3_conn_hlr: recv, src 0.0.0.0 dst 255.255.255.255, L3I GigabitEthernet0_1_0_14, Null output,
RP/0/RSP1/CPU0:Mar 29 13:23:27.981 : dhcpd[1064]: DHCPD PACKET: TP608: BOOTREQUEST Rx, chaddr 0003.a0fd.28a8, interface GigabitEthernet0_1_0_14
RP/0/RSP1/CPU0:Mar 29 13:23:27.981 : dhcpd[1064]: DHCPD PACKET: TP982: DISCOVER Rx, base mode, interface GigabitEthernet0_1_0_14, chaddr 0003.a0fd.28a8

 

received dhcp request on interface


RP/0/RSP1/CPU0:Mar 29 13:23:27.981 : dhcpd[1064]: DHCPD PACKET: TP615: DISCOVER Rx, Relay chaddr 0003.a0fd.28a8
RP/0/RSP1/CPU0:Mar 29 13:23:27.981 : dhcpd[1064]: DHCPD PACKET: TP790: Client request opt 82 not untrust, chaddr 0003.a0fd.28a8
RP/0/RSP1/CPU0:Mar 29 13:23:27.982 : dhcpd[1064]: DHCPD PACKET: TP791: Giaddr not present, Set giaddr 39.1.1.2, chaddr 0003.a0fd.28a8

 

Setting GIADDR to the interface receiving the packet, this GIADDR is used to locate the right pool on the servers. So the server sneed to have a pool for the 39.1.1.0/24 subnet.


RP/0/RSP1/CPU0:Mar 29 13:23:27.982 : dhcpd[1064]: DHCPD PACKET: TP792: Client request opt 82 nothing to add, chaddr 0003.a0fd.28a8
RP/0/RSP1/CPU0:Mar 29 13:23:27.982 : dhcpd[1064]: DHCPD PACKET: TP571: L3 packet TX unicast to dest 40.1.1.1, port 67, source 39.1.1.2, vrf 0x60000000 (1610612736), tbl 0xe0000000 (3758096384)

 

Unicast packet forwarded to the first helper


RP/0/RSP1/CPU0:Mar 29 13:23:27.982 : dhcpd[1064]: DHCPD PACKET:  >dhcpd_iox_l3_unicast_packet: xmit, src 0.0.0.0 dst 255.255.255.255, L3I GigabitEthernet0_1_0_14, Null output, FROM L3
RP/0/RSP1/CPU0:Mar 29 13:23:27.982 : dhcpd[1064]: DHCPD PACKET: TP571: L3 packet TX unicast to dest 55.1.1.2, port 67, source 39.1.1.2, vrf 0x60000000 (1610612736), tbl 0xe0000000 (3758096384)

 

Unicast packet forwarded to the second helper

they are sent in the order of configuration and the configuration is maintained in order from low to high ip address.


RP/0/RSP1/CPU0:Mar 29 13:23:27.983 : dhcpd[1064]: DHCPD PACKET:  >dhcpd_iox_l3_unicast_packet: xmit, src 0.0.0.0 dst 255.255.255.255, L3I GigabitEthernet0_1_0_14, Null output, FROM L3
RP/0/RSP1/CPU0:Mar 29 13:23:27.983 : dhcpd[1064]: DHCPD PACKET: TP835: DISCOVER Tx, chaddr 0003.a0fd.28a8

 


RP/0/RSP1/CPU0:Mar 29 13:23:27.984 : dhcpd[1064]: DHCPD PACKET: TP564: L3 Packet RX from addr = 40.1.1.1, port = 67, application len 300, vrf 0x60000000 (1610612736), tbl 0xe0000000 (3758096384)
RP/0/RSP1/CPU0:Mar 29 13:23:27.984 : dhcpd[1064]: DHCPD PACKET:  >dhcpd_iox_l3_conn_hlr: recv, src 40.1.1.1 dst 39.1.1.2, L3I GigabitEthernet0_1_0_1, Null output,
RP/0/RSP1/CPU0:Mar 29 13:23:27.984 : dhcpd[1064]: DHCPD PACKET: TP609: BOOTREPLY Rx, chaddr 0003.a0fd.28a8, interface GigabitEthernet0_1_0_1
RP/0/RSP1/CPU0:Mar 29 13:23:27.985 : dhcpd[1064]: DHCPD PACKET: TP616: OFFER Rx, Relay chaddr 0003.a0fd.28a8, yiaddr 39.1.1.216

 

Offer received and IP address offered to us


RP/0/RSP1/CPU0:Mar 29 13:23:27.985 : dhcpd[1064]: DHCPD PACKET: TP799: Server reply opt 82 not present, chaddr 0003.a0fd.28a8
RP/0/RSP1/CPU0:Mar 29 13:23:27.985 : dhcpd[1064]: DHCPD PACKET: TP892: Broadcast-flag policy Ignore, chaddr 0003.a0fd.28a8
RP/0/RSP1/CPU0:Mar 29 13:23:27.985 : dhcpd[1064]: DHCPD PACKET: TP572: L3 packet TX bcast on intf GigabitEthernet0/1/0/14 to port 68, source 39.1.1.2, vrf 0x60000000 (1610612736), tbl 0xe0000000 (3758096384)
RP/0/RSP1/CPU0:Mar 29 13:23:27.985 : dhcpd[1064]: DHCPD PACKET:  >dhcpd_iox_l3_b
roadcast_packet: xmit, src 40.1.1.1 dst 39.1.1.2, L3I GigabitEthernet0_1_0_1, Null output, FROM L3
RP/0/RSP1/CPU0:Mar 29 13:23:27.985 : dhcpd[1064]: DHCPD PACKET: TP838: OFFER Tx, chaddr 0003.a0fd.28a8, yiaddr 39.1.1.216
RP/0/RSP1/CPU0:Mar 29 13:23:27.991 : dhcpd[1064]: DHCPD PACKET: TP564: L3 Packet RX from addr = 0.0.0.0, port = 68, application len 576, vrf 0x60000000 (1610612736), tbl 0xe0000000 (3758096384)
RP/0/RSP1/CPU0:Mar 29 13:23:27.991 : dhcpd[1064]: DHCPD PACKET:  >dhcpd_iox_l3_conn_hlr: recv, src 0.0.0.0 dst 255.255.255.255, L3I GigabitEthernet0_1_0_14, Null output,
RP/0/RSP1/CPU0:Mar 29 13:23:27.991 : dhcpd[1064]: DHCPD PACKET: TP608: BOOTREQUEST Rx, chaddr 0003.a0fd.28a8, interface GigabitEthernet0_1_0_14
RP/0/RSP1/CPU0:Mar 29 13:23:27.991 : dhcpd[1064]: DHCPD PACKET: TP617: REQUEST Rx, Relay chaddr 0003.a0fd.28a8
RP/0/RSP1/CPU0:Mar 29 13:23:27.991 : dhcpd[1064]: DHCPD PACKET: TP790: Client request opt 82 not untrust, chaddr 0003.a0fd.28a8
RP/0/RSP1/CPU0:Mar 29 13:23:27.992 : dhcpd[1064]: DHCPD PACKET: TP791: Giaddr not present, Set giaddr 39.1.1.2, chaddr 0003.a0fd.28a8
RP/0/RSP1/CPU0:Mar 29 13:23:27.992 : dhcpd[1064]: DHCPD PACKET: TP792: Client request opt 82 nothing to add, chaddr 0003.a0fd.28a8

 

Request packet received from client.


RP/0/RSP1/CPU0:Mar 29 13:23:27.992 : dhcpd[1064]: DHCPD PACKET: TP571: L3 packet TX unicast to dest 40.1.1.1, port 67, source 39.1.1.2, vrf 0x60000000 (1610612736), tbl 0xe0000000 (3758096384)
RP/0/RSP1/CPU0:Mar 29 13:23:27.992 : dhcpd[1064]: DHCPD PACKET:  >dhcpd_iox_l3_unicast_packet: xmit, src 0.0.0.0 dst 255.255.255.255, L3I GigabitEthernet0_1_0_14, Null output, FROM L3

 

Forwarded to helper 1


RP/0/RSP1/CPU0:Mar 29 13:23:27.992 : dhcpd[1064]: DHCPD PACKET: TP571: L3 packet TX unicast to dest 55.1.1.2, port 67, source 39.1.1.2, vrf 0x60000000 (1610612736), tbl 0xe0000000 (3758096384)
RP/0/RSP1/CPU0:Mar 29 13:23:27.993 : dhcpd[1064]: DHCPD PACKET:  >dhcpd_iox_l3_unicast_packet: xmit, src 0.0.0.0 dst 255.255.255.255, L3I GigabitEthernet0_1_0_14, Null output, FROM L3

 

Forwarded to helper 2, our reply is sent to both servers


RP/0/RSP1/CPU0:Mar 29 13:23:27.993 : dhcpd[1064]: DHCPD PACKET: TP841: REQUEST Tx, chaddr 0003.a0fd.28a8
RP/0/RSP1/CPU0:Mar 29 13:23:27.994 : dhcpd[1064]: DHCPD PACKET: TP564: L3 Packet
RX from addr = 40.1.1.1, port = 67, application len 300, vrf 0x60000000 (1610612736), tbl 0xe0000000 (3758096384)
RP/0/RSP1/CPU0:Mar 29 13:23:27.994 : dhcpd[1064]: DHCPD PACKET:  >dhcpd_iox_l3_conn_hlr: recv, src 40.1.1.1 dst 39.1.1.2, L3I GigabitEthernet0_1_0_1, Null output,
RP/0/RSP1/CPU0:Mar 29 13:23:27.994 : dhcpd[1064]: DHCPD PACKET: TP609: BOOTREPLY Rx, chaddr 0003.a0fd.28a8, interface GigabitEthernet0_1_0_1
RP/0/RSP1/CPU0:Mar 29 13:23:27.994 : dhcpd[1064]: DHCPD PACKET: TP619: ACK Rx, Relay chaddr 0003.a0fd.28a8, yiaddr 39.1.1.216
RP/0/RSP1/CPU0:Mar 29 13:23:27.994 : dhcpd[1064]: DHCPD PACKET: TP799: Server reply opt 82 not present, chaddr 0003.a0fd.28a8
RP/0/RSP1/CPU0:Mar 29 13:23:27.994 : dhcpd[1064]: DHCPD PACKET: TP892: Broadcast-flag policy Ignore, chaddr 0003.a0fd.28a8

 

ACK received from our server


RP/0/RSP1/CPU0:Mar 29 13:23:27.995 : dhcpd[1064]: DHCPD PACKET: TP572: L3 packet TX bcast on intf GigabitEthernet0/1/0/14 to port 68, source 39.1.1.2, vrf 0x60000000 (1610612736), tbl 0xe0000000 (3758096384)
RP/0/RSP1/CPU0:Mar 29 13:23:27.995 : dhcpd[1064]: DHCPD PACKET:  >dhcpd_iox_l3_broadcast_packet: xmit, src 40.1.1.1 dst 39.1.1.2, L3I GigabitEthernet0_1_0_1, Null output, FROM L3
RP/0/RSP1/CPU0:Mar 29 13:23:27.995 : dhcpd[1064]: DHCPD PACKET: TP847: ACK Tx, chaddr 0003.a0fd.28a8, yiaddr 39.1.1.216
RP/0/RSP1/CPU0:Mar 29 13:23:29.985 : dhcpd[1064]: DHCPD PACKET: TP564: L3 Packet RX from addr = 55.1.1.2, port = 67, application len 300, vrf 0x60000000 (1610612736), tbl 0xe0000000 (3758096384)
RP/0/RSP1/CPU0:Mar 29 13:23:29.985 : dhcpd[1064]: DHCPD PACKET:  >dhcpd_iox_l3_conn_hlr: recv, src 55.1.1.2 dst 39.1.1.2, L3I GigabitEthernet0_1_0_0, Null output,
RP/0/RSP1/CPU0:Mar 29 13:23:29.986 : dhcpd[1064]: DHCPD PACKET: TP609: BOOTREPLY Rx, chaddr 0003.a0fd.28a8, interface GigabitEthernet0_1_0_0
RP/0/RSP1/CPU0:Mar 29 13:23:29.986 : dhcpd[1064]: DHCPD PACKET: TP259: BOOTREPLY Drop, Client not found, interface GigabitEthernet0_1_0_0, chaddr 0003.a0fd.28a8

 

This is the symptom described, the 2nd offer pre XR 4.1 is dropped by the dhcp relay agent in ios-xr. Post 4.1 we will forward all offers to the client.

 

Slide2.JPG

This picture illustrates that behavior whereby the 2nd offer is not forwarded. In this case the red line is dashed meaning it made it through. The solid green line is not forwarded and is dropped by the ASR9000 dhcp relay agent.

 

How RELAY, SNOOPING and PROXY scale, come together and its relation to BNG

 

Relay

if you have relay then we punt the dhcp packets from the client send them over to the dhcp process, convert them in a directed broadcast or unicast
towards the helper and really relay only the messages back and forth. Other then CPU there is no operational overhead. No state is maintained,
except for a few second “hole” between server and client for when the offer comes back.

Relay scale

There is no scale associated with this per-se other then cpu (ran off the LC CPU for phy/subinterfaces and RP for bundle/bvi).

 

Proxy

if you have proxy, the transaction is controlled by the dhcp process. so client talks to a9k. a9k talks to the dhcp server and it will maintain
a binding that expires on lease and absence of a renew.

 

Proxy Scale

The scale associated here is cpu for the message transaction. ARP interaction since dhcp proxy will install a arp forwarding adj also
and memory for the binding table itself.
the other scale factor is here how far the TX ADJ table can grow from ARP, we tested up to 128k, but if you have enough shared mem, this can go
further than that, depending on the LC CPU mem (phy sub/if) or RP (bvi/bundle) can increase its shmem window (this is really like a ram disk and can
dynamically grow as needed). the other part is the tx adj table of the npu, there is a defined limit of about 128k I thought it was (mem size in resolve)

Snooping

Then there is snooping; this is really the same as proxy, but in an L2 environment AND with the notion that the binding table built is installed in the hw
forwarding. this is capped at 32k per npu. Advantage of snooping is that with the binding in hw, we can do extra verification checks on ingress to make
sure the mac/ip/port matches what is in the table. for egress outbound the tx adj is used installed.

 

Bng and Proxy

Now when you do BNG with proxy, it combines the operation of proxy and snooping:
a binding created by proxy is now installed in hw also, with those checks mention in effect. this caps bng/proxy to 32k per npu.

Summary

For proxy, snoop, bng/proxy
the 128k limit is really a testing limit defined by:
- (lc/rp) cpu capabity
- (lc/rp) cpu memory
- tx adj table

for snoop and bng/proxy since it is hw installed it caps it at
32k per npu, which is a hw limit.

for those sessions not needing bng, but requiring dhcp services, to allow for better mem/cpu control and scale, it might make more sense to do relay
here, but there is nothing against use of proxy per-se.

 

 

Related Information

All broadcasts are handled on the RP, in the ASR9000 or any XR platform for that matter, we use LPTS (local packet transport services) similar as what IOS calls COPP (control plane policing)

The policing is on a per NPU basis. Look at Packet trace and troubleshooting in the ASR9000

for more information on packet troubleshooting in the ASR9000.

Comments
Cisco Employee

There's a feature called "UDP Forwarding Support for IP Redundancy Virtual Router Groups" in IOS. So only the active router will relay the DHCP requests.  The command is "ip-helper x.x.x.x redundancy <hsrp group>". Do you know if there's an equivalent feature in XR?

Cisco Employee

Hi Yufeng,

That configuration setting we don't have in XR today as far as I know.

I think this feature was necessary in IOS because of sw forwarding platforms always listening to the virtual dmac.

In A9K/XR there is no hw forwarding natively when the router is standby, so with that said, the functionality you are asking for is natively supported already because of the forwarding architecture.

I'll check in to make sure, but if you don't hear from me, then it is confirmed we forward packets subject to helper only on the active/master.

cheers

xander

Beginner

Hello Xander,

I have a question regarding the DHCP relay in VRF feature.

In my network, DHCP servers are part of a Central services MPLS VPN that is imported/exported into Customer VRFs defined on an ASR9K.

If I understand properly how this feature works, I will need to define on the A9K one DHCPv4 relay profile for every Customer MPLS VPN that needs to have access to the DHCP servers, where the only difference would be that I would define the same DHCP server address into different Customer VRFs. Am I correct or can I associate an interface in VRFA to a DHCP profile that defines helper addresses in VRFB? If one profile per Customer VRF is the way to go, is there any limitation on how many DHCPv4 relay profiles I can define on an A9K, that I should be aware of?

Thank you in advance,

Eirini

Cisco Employee

Correction.  Under relay:

 

In XR dhcp relay, prior to XR 4.1 and as desribed by CSC39520

 

 

The bug id is CSCto39520.

 

Manuel

 

 

Enthusiast

Hello Xander,

 

I hope that you are well.

 

I have a question regarding Option 82 for IPoE subs.

I am using a Catalyst switch with dhcp snooping and DHCP Option 82.

When I check subscriber session on BNG with 5.3.2 I see the remote and circuit-id in Hex format because the Catalyst switch is sending this info in that format.

Is there a way to get this in clear text format on the BNG because we want to see the location of the sub in clear text for our guys from helpdesk because there will be users connected directly on switches.

 

With PPPoE we have this info in clear text. Probably because DSLAMs are working different than the switch.

Example: Circuit ID: Si_Bascarsija 11/27/1

 

p.s. I am waiting to get a GPON CPE for testing. Maybe we will have clear text on this one. I will update as soon it's done.

p.p.s. Many times remote-id is missing for some subs even the switch is sending it (checked with Wireshark). After I have more info I will update you and probably create a TAC SR.

 

 

 

Cisco Employee

hey smail!

yeah we basically use transparently what the switch is sending us, so if the switch is sending us 61 62 63 (abc) then we would display 616263

I believe the ability for cat switches to send RID/CID is somewhat flexible to configure.

have you seen this guide for the CID/RID insertion?

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dhcp/configuration/15-s/dhcp-15-s-book/dhcp-option-82.html#GUID-251A1ABD-3F26-4961-A812-EA276DD1E6E7

Where is the RID getting lost? is it received but not used by the bng? if so the issue could be here that we need to "service" the remote ID under the dhcp ipv4 config.

we could also see the received pieces via show dhcp ipv4 proxy binding detail.

cheers!

xander

Enthusiast

Aha ok, this explains everything.

I have configured custom remote and circuit ID and checked with Wireshark what the cat sw has sent to us.

It would be cool if BNG had an option to convert from hex to text (not sure if this is possible), but this is not that important. 

I got a GPON CPE and I got this circuit-id: 10.100.6.4:1-1-8-933-gponport-2755

which is cool.

Regarding missing remote-id, I checked on the uplink from sub to BNG (l2vpn) and I saw it.

Yesterday was the case where we had remote-id only on one of three sessions.

Not sure what is going on. I will later troubleshoot and collect some captures and logs.

 

Not sure if I have understood you about "service" the remote-id under dhcp config.

 

Here is our dhcp ipv4 config:

dhcp ipv4
 profile DHCP_PROXY_FTTH proxy
  helper-address vrf default 10.100.31.9 giaddr 10.100.31.156
  relay information check
  relay information policy keep
  relay information option allow-untrusted

 interface Bundle-Ether12.996 proxy profile DHCP_PROXY_FTTH
 interface Bundle-Ether12.2755 proxy profile DHCP_PROXY_FTTH

Cisco Employee

hi smail,

you have the right config for the "servicing" it was the relay information policy config, which you have.

it could be that the gpon is not sending the right option number for the RID, a sniffer trace can confirm. best to check with the  dhcp debugging also if and how the dhcp on the bng is handling it.

the conversion of hex to string could be done, but it is merely that the sender, gpon here needs to be customized to have a better setting of the strings. but it could be done in XR bng side also. But not sure if that is worth the effort as you say.

cheers!

xander

Enthusiast

Hi Xander!

Many thanks for replying. GPON is sending only circuit-id but it looks like a combo of remote and circuit-id, and it has a seperator (:) between IP address and Port Number.

Take a look.

"10.100.6.4:1-1-8-933-gponport-2755"

I am trying like mad to get to the right guy just to click the right checkbox to get RID and CID.

DLSAMs have many option and every vendor is different. Maybe this one is sending RID and CID in Circuit-id field?

 

The thing with CID/RID in hex format is only on the catalyst switch but this does not bother me. I was just curious why with DSLAM we have readable CID and with Cat SW only hex.

 

p.s. One question regarding bug https://tools.cisco.com/bugsearch/bug/CSCuu35990

We had this problem with same logs and one access-interface was not working any more. Second acc-intf was working fine after I have added and configured it.

Few days later the previously used acc-intf (the one with the bug) was working again. Only difference was dhcp ipv4 with different profile names...

This bug is severity 2 but it is terminated and no fix is planned!

Do you know why?

Cisco Employee

yeah it looks like your dslam/gpon sends a concatenated RID:CID. interesting.

I could possibly split that in XRBNG with a trick, but ideally it be best if that side fixes it. reason being is that if I say split a received string on a ":" and if someone confiures a "true" CID with a ':' I might split it erroneously you see what I mean, fix one thing create 5 other troubles :)

let me know if you get anywhere from your end, if not I'll see what I can do to make XR help in that regard.

On the bug, I reviewed it, it seems that was a one time hit. a tac lab reproduction appeared to be there, but wasn't the same. an EEM script was enabled to capture more relevant data to capture the info that was necessary, but the issue never re-appeared. Hence we had to mark the bug as U and for the issue that we did reproduce we noticed that it was fixed in 5.2.4 onward (this user was running 5.2.2).

cheers!

xander

 

 

Enthusiast

Hi,

 

No need to do anything on xr because this is really something that has to be fixed on other side. The DSLAM with GPON LC has this option for sure.

Thank you, but there is absolutely no need to use your time for this! This "issue" is peanuts because xr is working fine.

 

Regarding the bug, we are running 5.3.2 (because we had to). 

I hope that we will not see this bug in production. If yes I will inform TAC about that.

 

 

Hello Xander

I have similar config as smailmilak, with dhcp server 172.21.1.12

!

dhcp ipv4
  profile IPOE_V4 proxy
  helper-address vrf default 172.21.1.12 giaddr 0.0.0.0
  relay information option
  relay information policy keep
  relay information option allow-untrusted
 !
 interface Bundle-Ether10.502 proxy profile IPOE_V4
 interface GigabitEthernet0/0/1/3.301 proxy profile IPOE_V4
!

This work well

Now I want to provide a new service with differents ip addresses using DHCP in a vrf  as I don't want to mix with existing routing table, ie. creating virtual router on ASR9001 to provide dedicated service, with its own routing table, interface etc...

I created vrf called service, dynamic-template in this vrf.

!

vrf service
 address-family ipv4 unicast
 !

!

dynamic-template

 !
 type ipsubscriber SERV_IPOE_TEMPLATE
  vrf service
  accounting aaa list default type session
  ipv4 unnumbered Loopback21
 !

!

but I cannot configure dhcp ipv4 under this vrf service, which to point to specific DHCP server.

The following config seems not working:

!

dhcp ipv4
 vrf service proxy profile SERV_IPOE_V4
 profile IPOE_V4 proxy
  helper-address vrf default 172.21.1.12 giaddr 0.0.0.0
  relay information option
  relay information policy keep
  relay information option allow-untrusted
 !
 profile SERV_IPOE_V4 proxy
  helper-address vrf default 172.21.1.16 giaddr 0.0.0.0
 !
 interface Bundle-Ether10.502 proxy profile IPOE_V4
 interface GigabitEthernet0/0/1/3.301 proxy profile IPOE_V4
 interface GigabitEthernet0/0/1/3.512 proxy profile SERV_IPOE_V4
!

Is the configuration wrong ?

Thanks for your help

Jean

Enthusiast

Hi Jean,

you do not need "vrf service proxy profile SERV_IPOE_V4" under DHCP IPv4 config mode.

It's only important that you can reach the DHCP server.

For VRF "service" you need to create a new profile with giaddr Loopback21 IP address.

DHCP server will see this IP and pick an IP address from the pool.

Also, add vrf service and ipv4 unnumbered loo21 under  "interface GigabitEthernet0/0/1/3.512" 

Do some debug dhcp ipv4 proxy on the BNG and check the logs on DHCP server.

p.s. It's important that DHCP server can reach you subscriber subnet.

Try with ping:  ping 172.21.1.12 source "Loopback21 IP address" 

Hello smailmilak

thansk for your answer.

I've done followinf config as expected:

!

dynamic-template

 !
 type ipsubscriber SERV_IPOE_TEMPLATE
  vrf service
  accounting aaa list default type session
  ipv4 unnumbered Loopback21
 !

!

dhcp ipv4
 vrf service proxy profile SERV_IPOE_V4
 profile IPOE_V4 proxy
  helper-address vrf default 172.21.1.12 giaddr 0.0.0.0
  relay information option
  relay information policy keep
  relay information option allow-untrusted

!
! the profile i use
 profile SERV_IPOE_V4 proxy  
  helper-address vrf default 172.21.1.16 giaddr 0.0.0.0
 !
 interface Bundle-Ether10.502 proxy profile IPOE_V4
 interface GigabitEthernet0/0/1/3.301 proxy profile IPOE_V4
 interface GigabitEthernet0/0/1/3.512 proxy profile SERV_IPOE_V4
!

interface GigabitEthernet0/0/1/3.512
 description >>> DHCP MULTICAST <<<
 vrf iptv
 ipv4 point-to-point
 ipv4 unnumbered Loopback21
 service-policy type control subscriber IPTV_IPOE_PM
 encapsulation dot1q 512
 ipsubscriber ipv4 l2-connected
  initiator dhcp
  initiator unclassified-source
 !
!

But this configuration is not working,I have following message:

LC/0/0/CPU0:Nov  7 20:36:41.437 : dhcpd[157]: DHCPD PROXY: TP1955: FSM called for chaddr 3872.c0f6.82ea with event PACKET_DISCOVER state INIT
LC/0/0/CPU0:Nov  7 20:36:41.437 : dhcpd[157]: DHCPD PROXY: TP1903: Process packet event in INIT state called for chaddr 3872.c0f6.82ea
LC/0/0/CPU0:Nov  7 20:36:41.447 : dhcpd[157]: DHCPD PROXY: TP1955: FSM called for chaddr 3872.c0f6.82ea with event DPM_NOK state INIT_DPM_WAIT
LC/0/0/CPU0:Nov  7 20:36:41.447 : dhcpd[157]: DHCPD PROXY: TP2805: Client delete called for chaddr 3872.c0f6.82ea due to reason Session start failure

Do I miss something ?

Thnaks for help

Jean

Enthusiast

Hi,

I doubt that DHCP Discovery messages are getting to the DHCP server.

Have you tried to ping it with source IP address of Loop21?

Why do you have vrf "iptv" under interface GigabitEthernet0/0/1/3.512?

It should be vrf "service".

Do you have vrf "service" under loo21?

CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards