I have a 1720 which is running in bridged mode at a client site. It is required that they be bridged due to a non-routable protocol.
The problem is that each side is owned by a different group and use different IP subnets. Both groups would like to do DHCP for ease of management, but there has been no way to prevent each client from obtaining addresses from the other's DHCP server.
Is there a command that will block specifically DHCP and still allow all other broadcasts?
I'm shooting from the hip here but I'll give you two Ideas to try.
Option 1 is to create a normal access-list and try denying dhcp on the ethernet bridged interfaces.
Option 2 is to create a mac access-list and deny the mac address's of the dhcp servers if they don't need to talk across the bridge for any other reason than DHCP. Place the Mac access-list on your switch port connected to the bridging router.
access-list 100 deny udp any any eq 67
access-list 100 deny udp any any eq 68
access-group 100 in
access-group 100 out
mac access-list extended DENYDHCP
deny cccc.aaaa.1111 ffff.ffff.ffff any
mac access-group out DENYDHCP
I haven't had a chance to test either of these so if it works and my syntax might be off on this so look up the mac access-list in the command referece.
I like the thought process here but I do not believe that either of these are likely to solve the problem. I believe that if the router is configured with no ip routing as the original post implied, then the router is not likely to accept an extended IP access list on the Ethernet interface. The MAC address filter might work if the DHCP server is connected on the local broadcast domain and if there is no other need for the server to communicate with anything through the router. But if the server is not connected on the local broadcast domain then the MAC address in the DHCP frame will not be the address of the server. And if the server needs to communicate with anything through the router then the MAC filter will not work.
I am puzzled by the explanation in the original post about the need for bridging everything. It mentions some unroutable protocol but does not provide any specifics. The router is quite capable of routing IP and bridging some other protocol (perhaps NetBIOS or SNA or whatever non-routable protocol) at the same time. I do not understand why it is not possible to route IP and bridge the other protocol. This would automatically provide the separation of DHCP that they want.
Perhaps the original post can provide some more details about this environment.
Thanks Rick. I orininally was looking for the integrated solution so that I could route IP and bridge the DECLat traffic. I was probably misinformed about being able to do this on the cisco 1721 running 11.3. I have no previous experience using the DECLat protocol, but configuring this router to only bridge the DECLat would solve my problem.
On the flipside, it does appear that I could use a MAC filter as long as I move the DHCP server to some other machine.
Can you point me to an example of routing IP and bridging a protocol like DECLat?
I am not sure what you were told, but I am not aware of any reason that the 1721 could not route IP and bridge DECLat. The essentials of the configuration would look something like this:
ip address 172.16.1.1 255.255.255.0
ip address 172.16.2.1 255.255.255.0
bridge 1 protocol ieee
obviously you would need to adjust things like interface id and IP address to fit your situation. But this configuration will route on each interface for IP and will bridge between the two LAN interfaces for DECLat.
This certainly changes and complicates the situation. In general bridging over a WAN is considered a sub-optimal solution. There might be a couple of options that you could consider. There was a feature for doing protocol translation which would transport DEC over a WAN as an IP packet and translate it back. I looked in Software Advisor on CCO and I do not see this feature in the 1700 software. I am not sure whether that means it is not in the 1700 software or if it is a flaw in the Software Advisor (it would be quite easy to miss this one). You might check to see if the translate command is supported in your version of IOS.
Another possibility exists if the serial connection between the routers can be treated as Frame Relay (either it can be a real Frame Relay connection from a service provider or it can be using frame-relay encapsulation router to router back to back over the T1). If the serial can be treated as Frame Relay then you can configure two PVCs. On one PVC you configure routing for the IP traffic and on the other PVC you configure bridging for the DECLat traffic.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...