Multicast mac address isn't learned, igmp-snooping

I have PIM router which connects to the cat 2960 switch and also I have host which connects to another port on the same switch. Host was joined to the IGMP group 224.1.1.1. I see that the router generates igmp-query and the host respons. IGMP-snooping process sees that process and updates appropriate entries:
2960-5#sh ip igmp snooping mrouter
Vlan    ports
  15    Gi2/0/32(dynamic)
2960-5#sh ip igmp snooping groups
15        224.1.1.1                igmp        v2          Gi2/0/32, Gi2/0/33
But when I command "sh mac address-table multicast" I see nothing:
2960#sh mac address-table multicast
Vlan    Mac Address       Type        Ports
What is reason of this problem?

There is the following statement from the "CCNP Practical Studies: Switching:
the process of populating the bridge table with multicast MAC addresses is based upon inspection of the destination MAC address, unlike unicast MAC addresses where the source MAC address of unicast frames is examined to generate bridge table entries.
And this book describes other parts of the mac learning process and says that after exchanging IGMP-message MAC-table must be populated by multicast mac-addresses. But later I found some Cisco and Jupiner documentation which says there is two way to perform multicast forwarding - MAC and IP. Default metod is IP multicast forwarding. When this metod is used multicast MAC-addresses isn't learnt and process of packet forwarding uses special forwarding cache which includes list of mapping IP and appropriate interfaces. It all means that this book isn't actual. All modern switchs perform multicast forwarding by IP metod and MAC-addresses don't populate CAM. 

Similar Messages

  • Multicast mac-address Nexus 7k

    Hi,
    i'm going to use Nexus 7000 in Data Center.
    During analysis configuration, I need define mac-address-static configuration for multicast mac address for Firewall Checkpoint cluster.
    In "Layer 2 Switching Configuration Guide, Release 4.1.pdf" documentation speak about
    "Configuring a Static MAC Address
    [..]You cannot configure broadcast or multicast addresses as static MAC addresses[..]"
    Have you a suggestion to manage this problem and why is it not possible configure mac address static multicast?
    Regards
    Dino

    Joseph - The ClusterXL A/A configuration is a variation of the  StoneSoft or Rainfinity clustering technologies that have been used to  cluster Solaris and other *NIX flavored servers and firewalls for  years.  (In fact, StoneSoft filed suit against Check Point in Europe 8  or 9 years ago for patent violations, and lost.)  These configurations  were very common on Check Point clusters running on Solaris from the  late 90's forward - and, as you describe, have unicast IP's with a  multicast MAC for the VIP.  Even from the days of installing these on  the brand new (at the time) 2900 series switches you had to do exactly  as you state above - static MAC entries (or in some cases port mirrors)  so traffic was directed to both active switch ports.  In Active/Passive  mode Check Point ClusterXL clusters are almost always "plug and play"  today - rarely do the switches need anything beyond speed/duplex  settings.  The VIP assumes the MAC of the physical NIC it is currently  bound to, and therefore there are no issues as far as switch config or  proxy ARP entries on the gateways.  All of these issues have to do with  traffic flowing to the VIP and through the firewall, and the ability of  the switch to correctly identify which physical switch port(s) the VIP  is currently patched in to.  This is one of three types of traffic  associated with ClusterXL itself.  The second is state synchronization,  which is accomplished through a crossover cable and therefore not  relevant.  Even when using a switch state sync is a typical TCP 18181  connection from a unicast IP/unicast MAC on one gateway to the other  through a dedicated interface pair.
    The challenge described by CJ is not with the traffic  flowing to the VIP, however.  It is an entirely separate process - Check  Point Clustering Protocol (aka CPHA if filtering in WireShark) is  essentially the heart beat traffic.  Every interface pair within a Check  Point cluster continually communicates with its "partner" interface on  the other cluster members.  If any packet takes over 100ms or shows more  than a 5% loss the gateway is forced in to "probing" mode where it  falls back to ICMP to determine the state of the other cluster member.   Depending on the CPHA timing settings an active gateway will failover to  the passive in as quickly as 500ms or so.  ClusterXL will fail over the  entire gateway to the standby to avoid complications with asynchronous  routing.
    Out of the box, CCP is configured to use  multicast, but it supports broadcast as well. To change this in real  time (no restart required) simply issue the command:
    cphaconf set_ccp {broadcast/multicast}
    At  the Ethernet level, CCP traffic will always have a source MAC of the  Magic MAC of 00:00:00:00:xx:yy where XX is the “Cluster ID” – something  identical on each cluster member but unique from one cluster to another,  and YY is the cluster priority (00, 01, etc.) based on the priority  levels set on cluster members within Dashboard on the cluster object.  The destination MAC will always be the Ethernet broadcast of  ff:ff:ff:ff:ff:ff.
    At the IP level the source of CCP  will always appear as 0.0.0.0. The destination will always be the  network address (ie, x.x.x.0).
    Similarly in multicast mode you will see the same traffic  at the IP level but at the Ethernet level the destination will now be a  IPv4 multicast MAC (ie, 01:00:5e:4e:c2:1e).
    In a tcpdump  with the –w flag opened in WireShark and a filter applied of just “cpha”  (without the quotes) you should see a continual stream of traffic with  the same source and destination IPs on all packets (0.0.0.0 and network  IP), the destination of either a bcast or mcast MAC and the source MAC  alternating between 00:00:00:00:xx:00 and 00:00:00:00:xx:01.
    Long story short, the problem CJ is describing is a  behavior on the 7K where a packet capture taken on the Check Point  interface itself (ie, tcpdump –i eth0 –w capture.cap) ONLY shows CPHA  traffic from it’s own source MAC and no packets from it’s partner. A  tcpdump on the 7K itself will show traffic from both.
    As CJ mentioned, a simple NxOS upgrade will fix the issue per:
    This one:CSCtl67036  basically pryer to NX-OS 5.1(3) the nexus will discard packets that have a source of 0.0.0.0.  Which in broadcast mode is exactly what the CCP heartbeat is.  We bypassed this one.CSCsx47620 is the bug for the for static multicast MAC address feature but it requires 5.2 code on the 7k
    (NOTE:Additional RAM may be required for the 5.2 update)
    Also note that Check Point gateways do support IGMP  multicast groups, given that you have the correct license. It is a  feature of SecurePlatform Professional on the higher end gateways or as a  relatively inexpensive upgrade on the lower end boxes or open  platforms. For lab purposes you can simply type “pro enable” at the CLI  (without the quotes). As of the latest build there is no technical  limitation (no license check) so you can enable advanced routing  features as needed for testing in a lab. For step by step details on  configuring IGMP on SPLAT Pro go to the Check Point support site and  search for sk32702.
    This can be a frustrating issue to troubleshoot, so hopefully this helps someone avoid the headaches I ran in to.

  • ACE How can we do a static arp to multicast mac address?

    I have a architecture that uses ACE to do Firewall Load Balancing. I need to add a static map of a VIP IP to a multicast mac address (Microsoft servers with NLB in multicast mode). The ACE does not accept multicast mac address in the static arp statement, anybody knows why? Is there any other way to do that?
    Regards,
    Artur Pinto

    Hi,
    The ACE doesn't support multicast MAC addresses. This is a limitation impose by the hardware used on the boards. Syed has previously proposed a workaround at https://supportforums.cisco.com/message/464174#464174 . I don't know if that will be applicable in your case.
    HTH
    Cathy

  • CSCuj20687 - Enh Configuring static multicast mac-address for N6K NLB implementation

    Hi
    Does we fix release avilable for nexus 6k?

    It seems that all 7.x releases should have this enhancement.  The release note would also seem to indicate that
    6.0(2)N2(1) has the fix for the Nexus 6000.
    Are you experiencing something different?

  • SG300 inter-VLAN routing and MAC address changes in incoming packets

    Hello
    I have SG300-20 working in Layer3 mode
    VLAN1 is not used
    Internet gateway is in VLAN211
    Clients are in other VLANs
    Switch is default gateway for clients and itself has internet gateway as default route.
    MAC address of switch is XX:XX:XX:XX:XX:63
    When client sends trafic to Internet destination MAC address in outgoing packets is XX:XX:XX:XX:XX:63
    But in incoming packets source MAC address is XX:XX:XX:XX:XX:69
    Why does it change? And how can I setup switch to use only XX:XX:XX:XX:XX:63 MAC address?

    Hi Robert,
    I'd like to pick up this old thread because we have a huge problem with the behavior of the SG300 router/switch regarding the "spoofed" MAC source addresses. We have connected this switch to another router which has some special routing capabilities. It routes certain IP packets directly to MAC addresses which it learned from snooping on special traffic.
    When connected to a SG300 router with an Ethernet base address of XX:XX:XX:XX:XX:48 we receive packets with Ethernet source addresses like e. g. XX:XX:XX:XX:XX:49 or XX:XX:XX:XX:XX:4D (depending on which hardware port they came from). Our special router "learns" these MAC addresses and tries to send associated outgoing packets directly to these addresses using e. g. XX:XX:XX:XX:XX:49 as the MAC destination address.
    Our problem is that the SG300 does not forward the packet if the MAC destination address is not equal to the switch's Ethernet base address (XX:XX:XX:XX:XX:48 in our case). This renders the SG300 series useless for our systems.
    Is there new firmware available which fixes this problem for us? We don't care which MAC source address the SG300 uses in incoming packets we receive, but we expect that the SG300 handles packets correctly for outgoing packets we send with this MAC address as the destination address.
    Thanks,
    Chris

  • Force mapping to a specific MAC address a multicast IP address in ARP cache table with netsh

    Hi all,
    I would like to know if there is any solution (netsh option, registry entry, whatever...) to force mapping a given MAC address to a multicast IP address (224.x.y.z) in my ARP cache table.
    I am doing the following:
    netsh.exe interface ip add neighbors "Ethernet" "224.224.xxx.yyy"
    "00-80-EE-UU-VV-WW"
    But the entry in the ARP table is substitued by the calculated multicast MAC@ corresponding to my multicast IP@ :
    netsh.exe interface ip show neighbors "Ethernet"
    Interface 12 : Ethernet
    Internet Address  
    Physical Address Type
    224.0.0.22 
    01-00-5e-XX-YY-ZZ 
    static
    224.224.yyy.zzz 
    01-00-5e-UU-VV-WW 
    static
    (For information, calculation of the Multicast MAC Address is described in RFC1112§6.4 -> The MAC@ equals 01-00-5e + the last 23 digits of the multicast MAC Address)
    My problem is that I'm not using an Ethernet network but an AFDX (used on Airbus A380, Boeing 787 Dreamliner, by the NASA...). This network topology is a deterministic Ethernet. The network must know accurately where each network packet is going. Thus...
    the multicast MAC@ cannot be accepted and packet destinated to that MAC@ are not going anywhere.
    So, I must match accurately my multicast IP@ to my MAC@ (00-80...).
    It used to work with Windows XP (which was not doing any "magical" MAC@ substitution on multicast IP@), but since Windows Vista, netsh is doing the substitution described above. Is there any way to disable this substitution or force my IP
    to MAC mapping in ARP table? And of course, I'm not using XP anymore ;)... but a tablet with Windows 8.1.
    Thanks for any help.
    Cheers,
    Olivier.

    Hi,
    The article you pointed me to is just an explanation of what I said in my original post : "Multicast MAC Address is described in RFC1112§6.4".
    But, as I said in my original post, this is true ONLY for Ethernet network. And I am NOT on an Ethernet network.
    So MAC address automatic calculation for my IP address done by Windows/netsh/arp is wrong in my case. The calculation Windows is doing is correct ONLY for Ethernet network. Since I am not on Ethernet, I don't want these calculations, and I'm looking for
    a solution to disable them.
    So, the underlying question is : "Is Microsoft/netsh/arp able to handle other network's type than Ethernet ?"
    Thanks,
    Olivier Dupré.

  • Windows Network Load Balancing - Virtual MAC Address

    Hi All,
    I have environment that running 2 Exchange 2010 server with CASHT and join windows network load balancing as a node.
    My question is,
    If NLB service is restart, is it virtual MAC Address for NLB will change to new virtual MAC Address?
    Thanks for response,
    Best Regards,
    Henry Stefanus

    Hi Henry Stefanus,
    The NLB work mechanism will not change whether what higher application we used and I am not very familiar with Exchange NLB architecture, may the following KB and article
    may help you.
    When you use the unicast method, all cluster hosts share an identical unicast MAC address. Network Load Balancing overwrites the original MAC address of the cluster adapter
    with the unicast MAC address that is assigned to all the cluster hosts.
    When you use the multicast method, each cluster host retains the original MAC address of the adapter. In addition to the original MAC address of the adapter, the adapter is
    assigned a multicast MAC address, which is shared by all cluster hosts. The incoming client requests are sent to all cluster hosts by using the multicast MAC address.
    Selecting the Unicast or Multicast Method of Distributing Incoming Requests
    http://technet.microsoft.com/en-us/library/cc782694(v=ws.10).aspx
    The related third party article:
    Building NLB Exchange 2010 RTM CAS / HT Servers (Hyper-V) – Part 1
    http://blog.morecoffeeany1.com/2010/03/19/building-nlb-exchange-2010-rtm-cas-ht-servers-hyper-v-%E2%80%93-part-1/
    I’m glad to be of help to you!
    *** This response contains a reference to a third party World Wide Web site. Microsoft is providing this information as a convenience to you. Microsoft does not control these
    sites and has not tested any software or information found on these sites; therefore, Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. There are inherent dangers in the use
    of any software found on the Internet, and Microsoft cautions you to make sure that you completely understand the risk before retrieving any software from the Internet. ***
    We
    are trying to better understand customer views on social support experience, so your participation in this
    interview project would be greatly appreciated if you have time.
    Thanks for helping make community forums a great place.

  • 802.1x phone with two MAC address

    Hello,
    I have following scenario: Computers are connected behind phones, and phones are authenticating with MAB. The problem is with phones, because they have two mac addresses one is in voice vlan and another is in data vlan. Both phone and computer are authenticated successfully but when switch sees additional MAC address of phone in data vlan it shuts down port. Here is sample configuration:
    interface FastEthernet0/1
    switchport mode access
    switchport access vlan 10
    switchport voice vlan 15
    authentication host-mode multi-domain
    authentication port-control auto
    dot1x pae authenticator
    authentication violation shutdown
    mab
    spanning-tree portfast

    Can you verify if the phone's mac address is being learned on the data vlan and the voice vlan? Because cisco phones use cdp to discover if a voice vlan is configured on the switchport before forwarding traffic.
    Please issue a show mac address table interface x/y after bouncing the port to see what is causing the port to error disable.
    Also what version of code is running on the switch and phone?
    Thanks

  • ARP cache not adding MAC address

    Hi,
    We have a network in the company where visitors\customers can connect their PCs to pick up a IP address & access the internet via our cluster of Checkpoint firewalls. The problem we are having is that whenever somebody with a Mac tries to use this network they cannot access the internet although it works fine for all Windows based PCs. So to investigate I got hold of a IBook & made the following observations.
    The gateway provided by the DHCP servers is a IP address (192.168.48.203) on a multicast mac address that represents both of the firewalls, which in turn have a physical address of 192.168.48.201 & 192.168.48.202 respectively. This is done to provide redundancy.
    What happens on the IBook is that it picks up a DHCP address as well as the DNS & gateway address as supplied by the DHCP server, but then when you try to access the internet you have no joy. If you check the arp table you will then notice that the table have not been updated with the mac address of the 192.168.48.203 gateway. If you then manualy add the mac address of 192.168.48.203, using arp -s, it works fine or if you staticaly configure the IP address settings to use either 192.168.48.201 or 202 as gateways (which have unicast mac addresses) it also solves the problem & immediately updates the arp cache with the mac addresses of either of these two interfaces depending on which one you are using.
    We put a sniffer on the network & could see that the mac address for 192.168.48.203 is being passed on to the IBook but for some reason it just does not update the arp cache with this details. Also tried this on some of the other networks we are running that uses the same concept & the same thing happens. As I mentioned no Windows hosts are having this problem & immediately updates their arp details to include the mac address of the .203 address.
    On a Mac after obataining a DHCP address & running "netstat -r" you get the following:
    Internet:
    Destination Gateway Flags Refs Use Netif Expire
    default 192.168.48.203 UGSc 5 5 en1
    127 localhost UCS 0 0 lo0
    localhost localhost UH 9 2477 lo0
    169.254 link#5 UCS 0 0 en1
    192.168.48/22 link#5 UCS 1 0 en1
    192.168.48.203 link#5 UHRLW 4 30 en1
    192.168.51.1 localhost UHS 0 1 lo0
    Then after adding the mac address manualy it looks as follows & works fine:
    Internet:
    Destination Gateway Flags Refs Use Netif Expire
    default 192.168.48.203 UGSc 26 6 en1
    127 localhost UCS 0 0 lo0
    localhost localhost UH 9 12353 lo0
    169.254 link#5 UCS 0 0 en1
    192.168.48/22 link#5 UCS 0 0 en1
    192.168.48.203 1:0:5e:7c:0:48 UHLS 26 28 en1
    192.168.51.1 localhost UHS
    Any ideas why this is happening ?
    Regards
    IBook G4   Mac OS X (10.4.3)  

    Hi,
    I am facing exactly the same problem here with an iMac G5. I have called the apple support and the conclusion was that they have no clue for that and we should wait for an update that will hopefully resolve this.
    I was also aksing them if there was a way in the mac to set a static mac address for the gateway in the macintosh so I don't have to run the terminal and type the arp -s every time I start up. They said it is out of the kind of support they can provide... Do you have an idea on how to add a static ARP entry in the table ?
    Thank you.

  • Disable Multicast MAC Addr restricted in Catalyst 3750 and C3560G

    Hi All,
    I'm using Cisco 3750 Catalyst and C3560G, recent days ago i purchased a pair of WatchGuard Firewalls and put in the system to run HA Active/Active model.
    The requirement to run WatchGuard Firewall HA A/A model is to allow ARP request if the response contains a multicast MAC Address in Routers and Switches.
    I read somewhere that Routers and layer 3 switches, the default behavior is to follow RFC 1812, which says that the routers must not believe any ARP reply that claims that the link later address of another host or router is a broadcast or multicast address.
    Can you pl show me the command to Allow all Multicast MAC Address for interfaces? Or disable RFC 1812 in order to get WatchGuard Firewall works properly.
    Here is the information from WatchGuard firewall: "When you configure WatchGuard FireCluster in an active/active configuration, the cluster uses multicast MAC addresses for all interfaces that send network traffic. Before you enable FireCluster, make sure your network switches, routers, and other devices are configured to route network traffic with multicast MAC addresses.
    Pl help. Thanks.

    Disclaimer
    The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
    Liability Disclaimer
    In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
    Posting
    My experience on 3750 has been generally only a reload will clear the detailed MLS QoS stats.
    However, I thought could could clear the interface stats, although, if not, might be a bug in your IOS version (you didn't note actual 3750 model or specific IOS version being used).
    Lastly, the interface stats don't clear at all?  Reason I ask, disabling QoS doesn't preclude you still getting drops.

  • MAC address issue...old, but have question

    I missed all the news about bios 2.5 but anyway did it screw up the MAC address? I flashed it but it never let me into windows saying I didn't have an acpi compliant bios.
    I see some things about it messing up the MAC...
    If the mac address isn't all zeros is it ok? Or did the bios just change it altogether to a diiferent value?
    Sorry for late post about it...I missed it when bios 2.5 out to do my comp being down at the time.

    Quote
    Originally posted by J*A*G
    It looks odd it is like a bunch of 8080808080....maybe I better try the fix.
    Uh-yup.  You got a busted MAC address.  Off to the catacombs with ya!  At least the search function runs good now.
    Jef

  • Ip igmp snooping querier on Nexus, what source IP address to use?

    Am looking at a problem with servers in the same vlan across multiple switches that are unable to communicate using multicast. I have found that in the systen I'm to set up I need to apply the ip igmp snooping querier command, in the vlan, but it needs a source IP address.
    Different documents make conflicting recommendations for this address, one suggests that any unused address will do, another suggests to use the IP address that is configured on the SVI for the vlan.
    Which is correct?

    Eventually I had to ask Cisco TAC, the response was that any IP address within the subnet could be used. The recommendation was to allocate an unused address in the vlan subnet for this purpose, use the same address on multiple switches should resiliance be required.

  • Multicasting (IGMP Snoop) between Nortel and Cisco

    We are currently having issues with Zen imaging (multicasting) and our setup is the following.
    Please take into account, our knowledge is very limited with IGMP Snooping setup etc.
    MDF = 6 Nortel 450-24T's using FirmWare -1.48 / SoftWare - 4.5.2.4
    IGMP Settings are such :
    VLAN: [ 1 ]
    Snooping: [ Enabled ]
    Proxy: [ Disabled ] -----> This was on...but once off, runs much smoother.
    Robust Value: [ 2 ]
    Query Time: [ 125 seconds ]
    Set Router Ports: [ Version 1 ]
    In the MDF (anythig directly in those switches) images fine now. (once I disabled PROXY)
    However I have a few IDF's off the MDF that are using OLD Nortel 350F-HD's (no IGMP Snooping support) and it's horrible (can only do a few computers at a time.
    So in one of the IDF's (the biggest one) I pulled out the 350F-HD and replaced it with a CISCO 2950 w/Fiber and it's using 12.1.20EA1 and I left IGMP Snooping on (thinking this will fix it) and couldn't even get ONE machine to connect and image in the multicast session. It's settings were (by default):
    Global IGMP Snooping configuration:
    IGMP snooping : Disabled
    IGMPv3 snooping (minimal) : Enabled
    Report suppression : Enabled
    TCN solicit query : Disabled
    TCN flood query count : 2
    Vlan 1:
    IGMP snooping : Disabled
    Immediate leave : Disabled
    Multicast router learning mode : pim-dvmrp
    Source only learning age timer : 10
    I then completly disabled IGMP Snooping on the CISCO and we're able to Image 5-7 Computers without a crash (more than that and it crashes - disconnects etc)
    In the area's that I have All 450's or all CIsco's the imaging seems to go fine. (with minor errors)
    Can any one give me some advice (or hopefully ran into this mixed setup before)?
    Thank you.

    Bosalaza,
    Thank you for replying (and I read even more on the ip multicast routing). However I've not ran into the same issue at any school that has 100% cisco switches or 100% Nortels (that are setup correctly and not older than dirt). I think we've not needed the multicast routing setup as we only have one router on the network (and it's flat at the moment anyway). As long as IGMP Snooping is enabled correctly (on the switches) it seems to serve us well.
    Although from what I've read (where you pointed me too) it seems even in our setup we would benifeit from taking time to setup "ip pim ....." etc.
    I was able to scrounge from another network and change out a few very old Nortels (that didn't support IGMP Snoop) and all seems well now.
    So long story short (and incase anyone else needs this info. The Nortel 350T and F - HD's were the main issue. It seems (for now) that a mixture of Nortel 350/450-24T's (any model that at least has IGMP Snooping) and Cisco's mixed (also Snoop on) works pretty well.
    I'm going to consider this solved as I was able to fix it with changing out some old product. However I really appreciate your efforts and pointing my towards some good info. (Which I'm going to read up on more, as I'm sure we'll need to get it setup in the near future.)
    Thanks again.

  • Switch learning mac addresses

    In a video that I watched a few days ago someone explained a basic process of booting up a switch and how a switch learns mac addresses. He said something that I would like to discuss. I know... it is not important but want to clarify :)
    PC1---SW1----PC2
    PC1 wants to send sth to PC2. In the video it was said:
    'a frame arrives at SW1 and SW1 learns the mac address of pc1 but it does not know the mac address of pc2 so it will flood this frame to all ports'
    My uderstanding is that it all starts with an arp message: pc1 does not know the mac address and sends an arp and it will allow the switch to learn both mac addresses: pc1 and pc2. I am too lazy to do it in wireshark but did that in PT and that's what I saw as well. After the arp - switch learnt both macs and did not flood the frame.
    Am I correct? I know it is not important but... ;-)

    It may be possible that there was some aspect of the switch environment in the video that would change the behavior (perhaps something like a long timer for the ARP cache in the PC and a short MAC ageing timer on the switch). But in general you are correct. PC1 would send an ARP request as a broadcast, the switch would learn the MAC of PC1 and forward the ARP request. When PC2 sends its response to the ARP request the switch would learn the MAC of PC2 and forward the ARP response. So the switch should have both MAC addresses when data traffic begins to flow.
    HTH
    Rick

  • Fails to learn mac address on Fiber interface with ISP

    Hi,
    We have a problem to bring a new 3750 switch interface up with the ISP.
    Current interface configuration on the router 7500 with SC/Single mode 1000 Base LX is
    interface GigabitEthernet4/0/0
    description ###### ISP #######
    ip address 1.1.1.2 255.255.255.252
    no ip redirects
    no ip unreachables
    load-interval 30
    no negotiation auto
    no cdp enable
    end
    works perfectly fine.
    we are trying to move this link to a Cisco 3750G on SFP single mode 1000 baase LX with the same configuration as below
    interface GigabitEthernet1/0/51
    no switchport
    ip address 1.1.1.2 255.255.255.252
    load-interval 30
    no ip redirects
    no ip unreachables
    no cdp enable
    speed nonegotiate
    we dont get any errors on the link but it fails to learn the mac address from the isp.
    checked the following.
    1. tried changing the SFP and the fiber.
    2. checked internally connecting back to back with another cisco device - works fine .
    3. checked with the isp for any static arp on their side and it is a no.
    I am wondering why it fails to learn the mac-address when it can self ping its own ip address and also the layer stays up with no errors on both the sides.
    Thanks

    Doesn't feel like a fiber/optical issue but a configuration mismatch on one of the end devices.

Maybe you are looking for