Re: [c-nsp] cisco interface shutdown detection, how is possible?
Can I conclude from all discussions above that the ethernet protocol support a feature named dying gasp which inform the other end that it is going to shutdown? It seems that it works when we intentionally try to shutdown an interface but when there is a failure on layer2 connection it couldn't help?! I've also tested Cisco router connection on different systems with different OSes. On Win systems, when I disable the Ethernet card, router detects it at the time but on FreeBSD systems, when I set interface down, the router shows Line Protocol as up! I tried to capture packets with Wireshark on Win system to find out if any packet is sent out before the interface is disabled but I see no packet! I thought maybe it stops capturing on interface and then send the supposed packet out! I really confused by what I saw in different scenarios! I need help to fix it up. On Sat, Jan 5, 2013 at 11:15 PM, Jay Hennigan j...@west.net wrote: On 1/5/13 3:44 AM, h bagade wrote: Hi all, I was wondering how Cisco routers could detect the directly connected interface at the other end is shutdown! there are two general possibility on my point of view: 1- the other device is sending special information before shutting down the interface. 2- there are some method of polling which is done periodically and based on the answer, the router detect the interface is up or no! Some of this depends on the layer 2 protocol (Ethernet vs. DS-3 for example) but in most cases there isn't any detectable difference between the remote end being administratively shut down and a failure of the interconnecting medium. The exception is that in some metro ethernet scenarios you can use OAM to capture dying-gasp, error disable, or shutdown events. It isn't a periodic poll, but rather like a one-time Going down now!, your scenario 1. As Cisco router is not able to detect the interface shutdown on the other side when connected to some other device, not Cisco like unix systems, it seems, it has some sort of protocol for detection which is number 2 of above guesses! The router will absolutely detect the lack of line protocol and carrier and flag the link as down but this would be the case whether the remote side is administratively shut down or the cable is just unplugged. could you please help me on this? Or provide me a scenario witch I could find out if any packet is transmitted between Cisco routers to inform the interface shutdown! See: http://www.cisco.com/en/US/docs/switches/metro/me3400/software/release/12.2_46_se/configuration/guide/swoam.pdf -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Not a valid host address error
Thanks guys. The guides solved my problem completely. On Thu, Oct 11, 2012 at 9:29 AM, Mikael Abrahamsson swm...@swm.pp.sewrote: On Wed, 10 Oct 2012, h bagade wrote: Thanks all. Thanks Gert for your complete answer. It cleared the vague parts but one still remains! what about ip address like 0.2.3.1 255.255.255.0! what's the rule for this one? 0.0.0.0/8 doesn't contain any valid IPv4 addresses. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Not a valid host address error
Hi all, I want to know in what condition this error occurres when defining ip addresses on interfaces? I test many IP addresses and diverse error messages happens which I don't know the reasons. Is there any reference which I could find the invalid pattern of ip addresses? some of my tests are: Router(config-if)#ip address 172.0.3.2 255.255.255.255 Bad mask /32 for address 172.0.3.2 Router(config-if)#ip address 255.0.3.2 255.255.255.255 Not a valid host address - 255.0.3.2 Router(config-if)#ip address 255.0.3.2 255.255.255.0 Not a valid host address - 255.0.3.2 Router(config-if)#ip address 254.0.3.2 255.255.255.0 Not a valid host address - 254.0.3.2 Router(config-if)#ip address 224.10.3.2 255.255.255.0 Not a valid host address - 224.10.3.2 Router(config-if)#ip address 224.10.3.2 255.0.0.0 Not a valid host address - 224.10.3.2 Router(config-if)#ip address 224.10.3.2 239.0.0.0 Not a valid host address - 224.10.3.2 Router(config-if)#ip address 224.0.0.0 239.0.0.0 Not a valid host address - 224.0.0.0 Router(config-if)#ip address 195.0.0.0 239.0.0.0 Bad mask 0xEF00 for address 195.0.0.0 Router(config-if)#ip address 223.0.0.0 239.0.0.0 Bad mask 0xEF00 for address 223.0.0.0 thanks in advance ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Not a valid host address error
Thanks all. Thanks Gert for your complete answer. It cleared the vague parts but one still remains! what about ip address like 0.2.3.1 255.255.255.0! what's the rule for this one? On Wed, Oct 10, 2012 at 4:25 PM, Gert Doering g...@greenie.muc.de wrote: Hi, On Wed, Oct 10, 2012 at 04:08:03PM +0330, h bagade wrote: I want to know in what condition this error occurres when defining ip addresses on interfaces? I test many IP addresses and diverse error messages happens which I don't know the reasons. Is there any reference which I could find the invalid pattern of ip addresses? networking 101? - don't use IP addresses out of Class D or E space - don't use netmasks that are not left-contiguous (no 0-bits mixed into 1-bits) - don't use /32 masks on anything that's not a loopback - don't use IP addresses that would be the network or broadcast address in a given subnet In essence, except for the non-contiguous netmask thing don't do things that are not permitted by the networking-101 text book. And don't use IPv4 either. gert -- USENET is *not* the non-clickable part of WWW! // www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] why to define both inside and outside interfaces when setting up nat?
Hi all, I'm wondering why we should define both inside and outside interfaces to get nat worked when we just only want to run inside source natting? In the case of inside source nat, only outside interface is important for natting; the packets are natted on their way outside so there is no need to specify inside interfaces. Is there a specific reason that both inside and outside interfaces should be specified? here is an example of nat configuration: interface GigabitEthernet0/0 ip address 11.11.11.1 255.255.255.0 ip nat inside ! interface GigabitEthernet0/1 ip address 172.16.10.64 255.255.255.0 ip nat outside ! ip nat pool test 172.16.10.1 172.16.10.63 prefix-length 24 ip nat inside source list 7 pool test ! access-list 7 permit 11.11.11.0 0.0.0.255 ! in this example, packets from inside network with source addresses of 11.11.11.0 are natted to the range (172.16.10.1-172.16.10.63) when exiting GigabitEthernet0/1 which is outside interface. why should GigabitEthernet0/0 should be specified as inside interface to make the nat do its work? any comments are appreciated. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] why to define both inside and outside interfaces when setting up nat?
On Sun, Aug 28, 2011 at 2:24 PM, Gert Doering g...@greenie.muc.de wrote: Hi, On Sun, Aug 28, 2011 at 01:38:53PM +0430, h bagade wrote: I'm wondering why we should define both inside and outside interfaces to get nat worked when we just only want to run inside source natting? In the case of inside source nat, only outside interface is important for natting; the packets are natted on their way outside so there is no need to specify inside interfaces. Is there a specific reason that both inside and outside interfaces should be specified? You could have multiple inside and outside interfaces, and the router needs to know when to NAT and when *not* to NAT. Yes, this is true that router should know about on which interfaces nat should be applied but it could be done on just inside or outside interfaces not both! for inside source and destination natting, nat should be checked on outside and for outside source, nat should be checked on inside interface only and not the both! in this example, packets from inside network with source addresses of 11.11.11.0 are natted to the range (172.16.10.1-172.16.10.63) when exiting GigabitEthernet0/1 which is outside interface. why should GigabitEthernet0/0 should be specified as inside interface to make the nat do its work? This is how IOS NAT is defined: NAT will apply when a packet traverses from an inside to an outside interface - and this is cool, because it gives you lots of flexibility for non-standard rules. doesn't the IOS nat definition equal to nat applies when a packet goes out of an outside interface? because when a packet lefts an outside interface, it surely comes from inside interface. isn't it? Unfortunately, lots of people have complained that this is too complicated (after all, their $30-only-a-single-WAN-Interface router at home can do it with a single click) so now we have the abomination of NVIs... gert -- USENET is *not* the non-clickable part of WWW! // www.muc.de/~gert/ http://www.muc.de/%7Egert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] clear ip ospf redistribution
Hi all, what does this command do exactly and in which situations we should use it? As I noticed, when we use the command, all routes which were previously distributed via redistribution commands, will be announced as withdrawn and after 30 mins they will be announced again! Is this 30mins related to a relative timer which can be adjusted or it is just fixed on 30mins? I would be graceful to hear your ideas and comments on this command. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
