Summit48si DHCP offer not getting back 1

T313C0mun1s7 · Jun 15, 2007

I have a Summit48si that is broken into several port based VLANs for a multi-tenant office building. Each office gets its own Class C network with 3 ports as such:

Suite 101 - VLAN ste101 non-tagged on ports 5-7 - Network 10.0.101.x/24 with the VLAN address assigned 10.0.101.1

The DHCP Server is on VLAN default which is 10.0.1.3 (DHCP Server at 10.0.1.2) and default owns ports 1-4. The Internet gateway is at 10.0.1.1. I have the following configured:

config vlan default ipaddress 10.0.1.3 255.255.255.0
config iproute add default 10.0.1.1
config default delete port 5-48
enable syslog
config syslog add 10.0.1.2 local0 notice
create vlan ste101
config ste101 ipaddress 10.0.101.1 255.255.255.0
config ste101 tag 101
config ste101 add port 5-7
enable ipforwarding
enable rip
create udp-profile dhcprelay
config dhcprelay add 67 ipaddress 10.0.1.2
config ste101 udp-profile dhcprelay
config default protocol ip
config ste101 protocol ip
config rip add vlan default
config rip add vlan ste101

With Wire Shark (etherreal) on both the DHCP server and the requesting workstation, and via syslog I can see that it appears the dhcpdiscover is going out and being forwarded to the DHCP server. The server sends a dhcpoffer, but the requesting workstation never seems to get it.

I have never worked with Extreme Networks switches before. Any help is highly appreciated, I have to get this working ASAP. I can post anything you ask for if you tell me how to get it. I already have a syslog server and Wire Shark setup.

The switch is running ExtremeWare 6.2.2 basic.

T313C0mun1s7 · Jun 16, 2007

I am still working on this issue, or should I say banging my head against the desk? Anyhow, I noticed that it looked like the DHCP server is sending the offer to 10.0.101.1 which is the VLAN interface IP. Is this normal and correct? If so how does the client then get the request? Is the switch not properly rebroadcasting the offer on the VLAN for the client to pickup?

I know I surely must have configured something wrong or missed something, but I don't know what. Again any help is appreciated.

John C. Reid, President
Computer and Network Services

T313C0mun1s7 · Jun 16, 2007

I just did a show tech-support and I found this. I am not sure what it means but it shows the offers are not being forwarded.

Code:

DHCP/BOOTP relay statistics:
        Received to server: 23  Received to client: 0
        Requests relayed: 23    Responses relayed: 0
        DHCP Discover:  20      DHCP Offer:     0
        DHCP Request:   3       DHCP Decline:   0
        DHCP Ack:       0       DHCP NAck:      0
        DHCP Release:   0       DHCP Inform:    0

Also I am seeing these warnings in the log. I don't know if it is related, but it is the correct port and a non-lease obtained IP address. I just don't know how to decipher it or how to fix it if I did.

06/16/2007 17:19.27 <WARN:IPRT> ip_input.c 819: DROP: Cannot forward!rtif/port=1/5 source/dest=169.254.113.134/169.254.255.255
06/16/2007 17:19.27 <WARN:IPRT> ip_input.c 819: DROP: Cannot forward!rtif/port=1/5 source/dest=169.254.113.134/169.254.255.255
06/16/2007 17:19.27 <WARN:IPRT> ip_input.c 819: DROP: Cannot forward!rtif/port=1/5 source/dest=169.254.113.134/169.254.255.255
06/16/2007 17:19.25 <WARN:IPRT> ip_input.c 819: DROP: Cannot forward!rtif/port=1/5 source/dest=169.254.113.134/169.254.255.255
06/16/2007 17:19.25 <WARN:IPRT> ip_input.c 819: DROP: Cannot forward!rtif/port=1/5 source/dest=169.254.113.134/169.254.255.255
06/16/2007 17:19.25 <WARN:IPRT> ip_input.c 819: DROP: Cannot forward!rtif/port=1/5 source/dest=169.254.113.134/169.254.255.255
06/16/2007 17:19.25 <WARN:IPRT> ip_input.c 819: DROP: Cannot forward!rtif/port=1/5 source/dest=169.254.113.134/169.254.255.255
06/16/2007 17:19.23 <WARN:IPRT> ip_input.c 819: DROP: Cannot forward!rtif/port=1/5 source/dest=169.254.113.134/169.254.255.255
06/16/2007 17:19.23 <WARN:IPRT> ip_input.c 819: DROP: Cannot forward!rtif/port=1/5 source/dest=169.254.113.134/169.254.255.255
06/16/2007 17:19.23 <WARN:IPRT> ip_input.c 819: DROP: Cannot forward!rtif/port=1/5 source/dest=169.254.113.134/169.254.255.255
06/16/2007 17:19.23 <WARN:IPRT> ip_input.c 819: DROP: Cannot forward!rtif/port=1/5 source/dest=169.254.113.134/169.254.255.255
06/16/2007 17:19.23 <WARN:IPRT> ip_input.c 819: DROP: Cannot forward!rtif/port=1/5 source/dest=169.254.113.134/169.254.255.255
06/16/2007 17:19.23 <WARN:IPRT> ip_input.c 819: DROP: Cannot forward!rtif/port=1/5 source/dest=169.254.113.134/169.254.255.255
06/16/2007 17:19.21 <WARN:IPRT> ip_input.c 819: DROP: Cannot forward!rtif/port=1/5 source/dest=169.254.113.134/169.254.255.255
06/16/2007 17:19.21 <WARN:IPRT> ip_input.c 819: DROP: Cannot forward!rtif/port=1/5 source/dest=169.254.113.134/169.254.255.255
06/16/2007 17:19.21 <WARN:IPRT> ip_input.c 819: DROP: Cannot forward!rtif/port=1/5 source/dest=169.254.113.134/169.254.255.255
. . . etc

John C. Reid, President
Computer and Network Services

rn4it · Jun 18, 2007

I believe you need to add each of the vlans to the udp profile. The following cmd tells the switch to forward udp packets to the assisgned server and port number.

conf site101 udp-profle dhcprelay

If you do a show dhcprelay

BD1:2 # sh dhcprelay
Name: Dhcprelay
Number of datagrams forwarded: 3719610
add 67 ipaddress 10.0.1.2
Applied to incoming traffic on vlans:

site101 etc

hope this helps

T313C0mun1s7 · Jun 18, 2007

The config statement is in there, it is kind of buried in first post, but it is there.

If I enter show dhcprelay I get:

Code:

Number of datagrams forwarded: 1883
destination udp port: 67        Forward to IP: 10.0.1.2
Applied to incoming traphic on vlans:
          Default, ste101

To summarize - I can see the discover being forwarded to the DHCP server, and the DHCP server send the offer out. For some reason the offer never makes it across the switch to the client.

I went and got the other two switches that we are going to use from my client. I am going to try the same config on them and see what happens. Maybe it will help me figure out if the issue is my config, or the switch.

John C. Reid, President
Computer and Network Services

T313C0mun1s7 · Jun 18, 2007

OK, new switch - same issue. This one has 7.6.1.4 on it. Here is the config as I enter it verbatim on a factory default unconfigured switch.

Code:

config banner
#########################################
##                                     ##
##  Summit48si Layer 3 routing switch  ##
##      This is switch number 1        ##
##                                     ##
#########################################

disable telnet
config vlan default ipaddress 10.0.1.3 255.255.255.0
config iproute add default 10.0.1.1
config default delete port 5-48
enable syslog
config syslog add 10.0.1.2 local0 notice
create vlan ste101
config ste101 ipaddress 10.0.101.1 255.255.255.0
config ste101 tag 101
config ste101 add port 5-7
enable ipforwarding
enable rip
create udp-profile dhcprelay
config dhcprelay add 67 ipaddress 10.0.1.2
config ste101 udp-profile dhcprelay
config rip add vlan default
config rip add vlan ste101

Running Wireshark here is what the server is getting:

Code:

1 0.000000    ExtremeN_1e:0e:b0     Extreme-EDP           EDP      EDP: Info Display Null
2 17.191063   10.0.1.3              224.0.0.9             RIPv2    Response
3 34.188628   10.0.1.3              224.0.0.9             RIPv2    Response
4 34.659873   10.0.1.3              10.0.1.2              DHCP     DHCP Discover - Transaction ID 0x7bd39d04
5 34.660056   Dell_51:b0:23         Broadcast             ARP      Who has 10.0.1.1?  Tell 10.0.1.2
6 34.660175   Intel_dc:f5:62        Dell_51:b0:23         ARP      10.0.1.1 is at 00:0e:0c:dc:f5:62
7 34.660189   10.0.1.2              10.0.101.1            DHCP     DHCP Offer    - Transaction ID 0x7bd39d04
8 37.558935   10.0.1.3              224.0.0.1             IGMP     V2 Membership Query
9 38.660046   10.0.1.3              10.0.1.2              DHCP     DHCP Discover - Transaction ID 0x7bd39d04
10 38.660189   10.0.1.2              10.0.101.1            DHCP     DHCP Offer    - Transaction ID 0x7bd39d04
11 40.431434   10.0.1.2              239.255.255.254       IGMP     V2 Membership Report
12 46.661755   10.0.1.3              10.0.1.2              DHCP     DHCP Discover - Transaction ID 0x7bd39d04
13 46.661898   10.0.1.2              10.0.101.1            DHCP     DHCP Offer    - Transaction ID 0x7bd39d04
14 47.188866   10.0.1.3              224.0.0.9             RIPv2    Response
15 59.995570   ExtremeN_1e:0e:b0     Extreme-EDP           EDP      EDP: Info Display Null
16 62.665652   10.0.1.3              10.0.1.2              DHCP     DHCP Discover - Transaction ID 0x7bd39d04
17 62.665796   10.0.1.2              10.0.101.1            DHCP     DHCP Offer    - Transaction ID 0x7bd39d04
18 77.186668   10.0.1.3              224.0.0.9             RIPv2    Response

I think 18 frames is more than enough to get the point across that the server is handing out offers, and therefore the initial forward is happening. Now here is what the client is getting on the wire:

Code:

1 0.000000    10.0.101.1            224.0.0.1             IGMP     V2 Membership Query
2 0.998062    10.0.101.1            224.0.0.2             IGMP     V2 Membership Report
3 1.099552    0.0.0.0               255.255.255.255       DHCP     DHCP Discover - Transaction ID 0x7bd39d04
4 5.099716    0.0.0.0               255.255.255.255       DHCP     DHCP Discover - Transaction ID 0x7bd39d04
5 13.101085   0.0.0.0               255.255.255.255       DHCP     DHCP Discover - Transaction ID 0x7bd39d04
6 13.642203   10.0.101.1            224.0.0.9             RIPv2    Response
7 29.104285   0.0.0.0               255.255.255.255       DHCP     DHCP Discover - Transaction ID 0x7bd39d04
8 31.496267   10.0.101.1            224.0.0.1             IGMP     V2 Membership Query
9 43.638745   10.0.101.1            224.0.0.9             RIPv2    Response
10 58.431550   ExtremeN_1e:0e:b0     Extreme-EDP           EDP      EDP: Info Display Null

As you can see from the transaction IDs on the DHCP discovers and offers, the server is responding to this clients plea for help, but the message never gets back to the client side. Because the only thing between the client and the server in the switch the issue must be in the switch. Because my config does not work on two different switches, I must have missed something.

What did I miss? I am clueless at the moment. Thank you in advance for your help.

John C. Reid, President
Computer and Network Services

T313C0mun1s7 · Jun 18, 2007

I just noticed that the frames for the DHCP offer all have a bad header checksum. All of the DHCP offer frames have a header checksum of 0x0000.

???? Huh

The DHCP server is a Windows 2003 server running on a Dell PowerEdge 2950 with GigE Broadcom cards. I have not a clue what could be causing this, but might this not cause the switch to drop those packets?

John C. Reid, President
Computer and Network Services

T313C0mun1s7 · Jun 18, 2007

Am I missing the "Edit" link in these forums somewhere? I hate chain posting.

Anyhow - Found the Broadcom "Checksum Offload" feature in the NIC Driver. I Disabled the checksum offload allowing the checksum to be calculated by the protocol stack, and the checksums are now correct. This, however, did not fix my issue with the offer not making it back to the client.

I also noticed that the offer had a destination address of 10.0.101.1 which is the VLAN interface itself. Is this correct? Why is a DHCP offer addressed to an IP, when (among other things) an IP is what the client wants. Maybe I don't understand DHCP, but I thought it would be a unicast addressed to a MAC maybe. The switch then would send it to the port that MAC was attached to.

I am still digging. Please feel free to jump in anytime, as right now my digging just seems to be making my hole deeper.

John C. Reid, President
Computer and Network Services

T313C0mun1s7 · Jun 18, 2007

Another link in the chain.

I have GOT to be missing a needed routing rule to send the packet back to the client. Further investigation of the offer packet shows the destination MAC address to be the MAC of the network card in my gateway AKA the default route in my configuration. It seems the DHCP server is somehow picking up the MAC of the default route and addressing the offer packet to go there rather than the originating client sending the discover. Hmmm . . .

John C. Reid, President
Computer and Network Services

T313C0mun1s7 · Jun 18, 2007

I tried changing from udp-profile back to bootprelay to simplify the issue. Nothing has changed. I still see the offer addressed to the MAC of the default route's NIC with an IP address of the VLAN interface.

John C. Reid, President
Computer and Network Services

T313C0mun1s7 · Jun 19, 2007

I am thinking that my issue may be that the switch is not routing. If I remove the DHCP server from the picture and I have the switch act as the DHCP server on my VLANS the clients get addresses right off, but they can not get out of the VLAN. Likewise, if I assign static addresses they are stuck in the VLAN. This is great except I want them to have Internet access and they are not even getting to the default route.

Each VLAN has an IP assigned, there is a default route assigned, and all VLANS have IP forwarding and RIP enabled. What else do I need?

If someone could post an example of a working config that would be great. Here is what I am looking for:

1) multiple port based vlans, each with a separate subnet getting addresses via a common DHCP server through bootprelay
2) all VLANs should be able to get to default route for Internet access
3) all VLANs should be able to get to a common VLAN that has shared printer, file server, Exchange server, etc.
4) VLANs should otherwise be segregated from one another.

I am having no luck with multiple switches and multiple versions of the firmware at this point. I am tired and worn out, and I would really appreciate any help. I am not sure if anyone is even reading these posts, as this forum is lacking many simple features such as the number of times viewed, and the ability to edit posts. Please, even if you don't have an answer, if you have any suggestions to get me pointed in the right direction let me know. At this point even a friendly, hello - I read your thread, would be somewhat comforting as I feel I am lost in a deep, dark cave all alone, with no assistance in this issue - I thought the mission of Tek-Tips was to elevate that.

Once again thank you in advance.

John C. Reid, President
Computer and Network Services

rn4it · Jun 19, 2007

The switch that is doing the udp-forwarding do the client patch directly into that switch or is there another switch that patches into it? If the later is being done, has you patched a laptop directly into the switch doing the udp-forwarding?

I have a config that works which is identical to yours. Have you compared your DHCPscope information on the server to that on the switch? Are they the same?

when you used the switch has the dhcp server what IP and default gateway did they get and could they ping the gateway address?

thanks

T313C0mun1s7 · Jun 19, 2007

rn4it - part 1 said:
The switch that is doing the udp-forwarding do the client patch directly into that switch or is there another switch that patches into it? If the later is being done, has you patched a laptop directly into the switch doing the udp-forwarding?

The clients are plugged directly into the Summit48si. It is a 1:1 scenario. This is for a multi-tenant office building, each office has three ports, and each port goes directly into a port on the switch. I am using three of Summit48si switches to have the required number of ports.

SW1 vlan default ports 1-4, vlan ste101 ports 5-7, vlan ste102 ports 8-10, ect . . .
SW2 vlan default ports 1-4, vlan ste115 ports 5-7, vlan ste116 ports 8-10,etc . . .
SW3 vlan default ports 1-4, vlan ste130 ports 5-7, vlan ste131 ports 8-10,etc . . .

So far I am still trying to get one vlan with bootprelay and route to the default route working - unsuccessfully. I have tried on all tree switches now, so I am pretty sure it is not the hardware.

rn4it - part 2 said:
I have a config that works which is identical to yours. Have you compared your DHCPscope information on the server to that on the switch? Are they the same?

Yes, have checked the scopes on the DHCP server. The fact that the DCHP server is willing to hand out an address and gives an offer, ack, or nack shows that it had an appropriate scope available and is willing to deal.

rn4it - part 3 said:
when you used the switch has the dhcp server what IP and default gateway did they get and could they ping the gateway address?

I setup ste101 which had an interface address of 10.0.101.1 to hand out addresses in the range of 10.0.101.2 - 10.0.101.254 /24, with a gateway of the interface address 10.0.101.1. I could ping the interface address which is the scope gateway, and I have IP forwarding turned on, but I could not ping the router's default gateway of 10.0.1.1 which is entered in the router via "config iproute add default 10.0.1.1"

I have also tried statically assigning IP addresses in the correct scope for the port (and vlan) I am plugged into. Again I am unable to ping any address outside my scope (like the default route in the switch). This is why I think maybe routing is not correct, and maybe why the DHCP server response is not making it back. The bootprelay is taking care of the forwarding of the request, but it is a one way ticket, and there is no valid path back to the vlan that the request came from.

My assumption was that bootprelay took care of the return path, and that "enable ipforwarding" would take care of my being able to get to the default route and out to the Internet. Otherwise I must just be stupid.

John C. Reid, President
Computer and Network Services

rn4it · Jun 19, 2007

from the switch can you ping the default gateway? Can you upload the results of a 'show vlan' command?

T313C0mun1s7 · Jun 19, 2007

Code:

Summit48si:1 # ping 10.0.1.1
Ping(ICMP) 10.0.1.1: 4 packets, 8 data bytes, interval= 1.
16 bytes from 10.0.1.1: icmp_seq=0 ttl=64 time=0 ms
16 bytes from 10.0.1.1: icmp_seq=1 ttl=64 time=0 ms
16 bytes from 10.0.1.1: icmp_seq=2 ttl=64 time=0 ms
16 bytes from 10.0.1.1: icmp_seq=3 ttl=64 time=0 ms

--- 10.0.1.1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0/0/0 ms
Summit48si:2 # show vlan
Name               VID  Protocol Addr        Flags        Proto   Ports
Default            1    10.0.1.3       /24 -----Tf--r---- ANY     2/6  
MacVlanDiscover    4095 ------------------ --------       ANY     0/0  
ste101             101  10.0.101.1     /24 ------f--r---- ANY     1/3  
ste102             102  10.0.102.1     /24 ------f--r---- ANY     0/3  
ste103             103  10.0.103.1     /24 ------f--r---- ANY     0/3  

Flags: (C) Domain-masterVlan, (c) Domain-memberVlan, (d) DVMRP Enabled
       (E) ESRP Slave, (f) IP Forwarding Enabled, (G) GVRP Enabled
       (i) ISIS Enabled, (I) IP Forwarding lpm-routing Enabled
       (L) Loopback Enabled, (M) ESRP Master, (m) IPmc Forwarding Enabled
       (N) GNS Reply Enabled, (o) OSPF Enabled, (P) IPX SAP Enabled
       (p) PIM Enabled, (R) SubVLAN IP Range Configured, (r) RIP Enabled
       (S) SuperVlan, (s) SubVlan, (T) Member of STP Domain
       (v) VRRP Enabled, (V) VPLS/TLS Enabled, (X) IPX RIP Enabled
       (Z) Translation-Vlan, (z) Member-Vlan
       (2) IPX Type 20 Forwarding Enabled

Total number of Vlan(s) : 5
Summit48si:3 # show default
VLAN Interface[0-200] with name "Default" created by user
     Tagging:   802.1Q Tag 1 
     Priority:  802.1P Priority 7 
     IP:        10.0.1.3/255.255.255.0    
     STPD:      s0(Disabled,Auto-bind) 
     Protocol:  Match all unfiltered protocols.
     Loopback:  Disable
     RateShape: Disable
     QosProfile:QP1
     QosIngress:None
     Ports:     6.     (Number of active ports=2)
        Flags:  (*) Active, (!) Disabled
                (B) BcastDisabled, (R) RateLimited, (L) Loopback
                (g) Load Share Group
        Untag:  *1   *2    3    4    49   50  


Summit48si:4 # show ste101
VLAN Interface[2-201] with name "ste101" created by user
     Tagging:   802.1Q Tag 101 
     Priority:  802.1P Priority 7 
     IP:        10.0.101.1/255.255.255.0    
     STPD:      None
     Protocol:  Match all unfiltered protocols.
     Loopback:  Disable
     RateShape: Disable
     QosProfile:QP1
     QosIngress:None
     Ports:     3.     (Number of active ports=1)
        Flags:  (*) Active, (!) Disabled
                (B) BcastDisabled, (R) RateLimited, (L) Loopback
                (g) Load Share Group
        Untag:  *5    6    7

John C. Reid, President
Computer and Network Services

rn4it · Jun 19, 2007

do you have access to the 10.0.1.1 device? If so can you ping the VLAN IPs? Also runs debug-trace udp-profile on the vlan that you are testing with, 'conf debug-trace udp-forwarding' lets see what it shows us

T313C0mun1s7 · Jun 19, 2007

ARRG!

My gateway router does not know that the 10.0.101.0/24, 10.0.102.0/24, etc subnets are BEHIND it. A traceroute to those subnets from the gateway goes out to the Internet rather than back to the summit switch. I need to get that fixed (obviously).

If I ping (from a statically assigned IP on ste101 of 10.0.101.2) 10.0.1.1 I get no response. I understand this as it is probably sending the response out the other interface to the Internet until I get it fixed.

If I ping 10.0.1.2 - The DHCP server I see no replies on the client. However, WireShark packet sniffing is showing the DHCP server is receiving the ping and sending the pong, it just never makes it all the way back to the client. This is the same behavior as the DHCP offer never making it back.

Here is a link to a debug level syslog of the last couple of days working on this:

http://www.keeptechworking.com/SyslogCatchAll.txt

John C. Reid, President
Computer and Network Services

rn4it · Jun 19, 2007

Does the DHCP server use the 10.0.1.1 as it's gateway? If so, correct it and DHCP should start working. In your syslog I keep seeing the following mesage "IPRT: bootp relay: no udp forwarding instance for interface ste101" which is just after "bootprelay: request forwarded to 10.0.1.2" So I suspect that the DHCP server doesn't know how to get all the way back to the clients, probably the gateway router.
good luck

T313C0mun1s7 · Jun 19, 2007

Yes, the DHCP server has 10.0.1.1 as it's gateway. It is all starting to become clear. The DHCP server want's to send a packet back to a different network, so it takes the route given my it's gateway - DUH!

My gateway router WAS IPCop. It does not truly support multiple subnet interfaces behind it. I am going to try ClarkConnect instead. I tried it once years ago to get a VPN going, but I did not like it then. It looks like it has come a long way since then, and it supports multiple subnets (and supposably even VLANs via tagging) so I will see what this does.

Thank you once again. Before the day is done I will have my new gateway up and report back. I wish I could give more than one "Thank you star" for you last post.

John C. Reid, President
Computer and Network Services

rn4it · Jun 19, 2007

couldn't you just add a static route on it for those subnets? might be easier, just an idea.
good luck

Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Summit48si DHCP offer not getting back 1

IS-IT--Management

IS-IT--Management

IS-IT--Management

MIS

IS-IT--Management

IS-IT--Management

IS-IT--Management

IS-IT--Management

IS-IT--Management

IS-IT--Management

IS-IT--Management

MIS

IS-IT--Management

MIS

IS-IT--Management

MIS

IS-IT--Management

MIS

IS-IT--Management

MIS

Similar threads

Log in

Part and Inventory Search

Sponsor