Does anyone know more about this problem. Regards, Arnold Serpil Bayraktar wrote:
Message-Id: <199404190507.AA76544@knock.aa.ans.net> To: nipper@xlink.net Cc: vimal@ans.net, db3l@ans.net, sbb@noc.ans.net Subject: BGP 4 Date: Tue, 19 Apr 1994 05:07:13 UTC From: Serpil Bayraktar <sbb@noc.ans.net>
I know this is getting very confusing, but.. we really need to switch back to old version soon. Basically all our customers connected to New York are having name service problems and it would be wonderful if we could take care of this today. Our NOC is going to get in touch with you around 8 AM your time (or 07:00 GMT). If you can change your configuration to let your router negotiate or do v3, we will reload our New York router. If you want me to be on the phone with you during these changes please let our NOC know, but basically as soon as you modify your config file all it takes is to reload our Cisco.
Serpil
-- Arnold Nipper / email: nipper@xlink.net NTG Netzwerk und Telematic GmbH \/ phone: +49 721 9652 0 Geschaeftsbereich XLINK /\ LINK fax: +49 721 9652 210 Vincenz-Priessnitz-Str. 3 /_______ D-76131 Karlsruhe, Germany
This has nothing to do with BGP at all, rather we fixed a bug in 9.21 that we left alone in 9.1, and it triggered some weirdness in ANSs's setup (they are playing games with netmasks and their nameserver host ended up being on an 'all zeros broadcast address' and when we cleaned up some of the directed broadcast code in 9.21, it blew things up for them. This shouldn't affect anyone else.
Arnold, we are using 6 bit subnet masks for our Cisco core router in New York. In order to accomadate additional hosts on this ethernet we had to do some complex subnetting and secondary addressing. One of these hosts is our name server. The problem is the IP address of this name server (192.103.63.100) is illegal from Cisco's point of view due to the subnet mask we are using. The work around to the problem was to make a static ARP entry in Cisco's ARP table with the MAC address of the name server so that Cisco would be able to reach the name server. However, by 9.21 upgrade to support BGP4 we have seen that the Cisco 7000 stopped passing traffic to the name server. The .100 happens to be the all zeros broadcast address on the subnet. It seems that 9.21 changes the destination address of any IP broadcast address to 255.255.255.255 where the destinationation address was kept as .100 in the previous Cisco code (Dave or Paul can correct me). We are planning to do some renumbering on Friday in order to solve this problem. Serpil
Not quite true--the game with IP addresses only happens on pings directly from the 7000. The problem with forwarding centers around forwarding directed broadcasts (which is what these addresses look like) which I believe at this point to be a configuration issue. (Note that it was a miracle that this ever worked in the first place...) Date: Tue, 19 Apr 1994 15:22:28 UTC From: Serpil Bayraktar <sbb@noc.ans.net> Arnold, we are using 6 bit subnet masks for our Cisco core router in New York. In order to accomadate additional hosts on this ethernet we had to do some complex subnetting and secondary addressing. One of these hosts is our name server. The problem is the IP address of this name server (192.103.63.100) is illegal from Cisco's point of view due to the subnet mask we are using. The work around to the problem was to make a static ARP entry in Cisco's ARP table with the MAC address of the name server so that Cisco would be able to reach the name server. However, by 9.21 upgrade to support BGP4 we have seen that the Cisco 7000 stopped passing traffic to the name server. The .100 happens to be the all zeros broadcast address on the subnet. It seems that 9.21 changes the destination address of any IP broadcast address to 255.255.255.255 where the destinationation address was kept as .100 in the previous Cisco code (Dave or Paul can correct me). We are planning to do some renumbering on Friday in order to solve this problem. Serpil
participants (4)
-
Arnold Nipper -
Dave Katz -
Paul Traina -
Serpil Bayraktar