EIGRP Tunnel and neighbor flapping

Hi,
     First I would like to note that I sanitized the IP addresses in these logs. I am by far no expert on VPNs, but I am trying to pinpoint a solution for a far reaching problem we are having. We have a DMVPN setup that has two destinations from the client end. The client is using a Cisco 871 with
c870-advipservicesk9-mz.124-15.T9 Ios image. I should note that we only have access to the client end, so we are unable to make any changes to the other side. At some sites, everything works perfect and there are never any drops. At other sites we get neighbor and tunnel drops that can go on for hours in a cycle, a few minutes apart. Below are logs from one of the sites, showing the type of events that we are seeing.
510505: Dec 24 11:30:50.269 EST: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 175: Neighbor 10.109.147.1 (Tunnel2) is up: new adjacency
510506: Dec 24 11:31:42.284 EST: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=15.28.146.234, prot=50, spi=0x608EF276(1619980918), srcaddr=112.72.37.119
510507: Dec 24 11:32:05.446 EST: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to down
510508: Dec 24 11:32:05.446 EST: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 175: Neighbor 10.109.147.1
(Tunnel2) is down: interface down
510509: Dec 24 11:33:20.449 EST: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up
510510: Dec 24 11:33:20.461 EST: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 175: Neighbor 10.109.147.1
(Tunnel2) is up: new adjacency
Sometimes this will be one tunnel with this issue, and sometimes it is both tunnels. The tunnel is mostly for redundancy, but there are some functions unique to each tunnel. We also get the
510506: Dec 24 11:31:42.284 EST: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=15.28.146.234, prot=50, spi=0x608EF276(1619980918), srcaddr=112.72.37.119
message which I would assume is a packet from the previous tunnel coming through. and being rejected because it does not match the new keys. I have looked into the keep alive times and adjusted them both down and up, but the trouble continued. What can cause this kind of flapping? Is there anything that can be done from just the client end to correct this issue? Any help would be greatly appreciated. Below you can see the configuration we have on the tunnel. If you have any questions, please let me know.
Router#sh int tun2
Tunnel2 is up, line protocol is up
  Hardware is Tunnel
  Description: Tunnel to Destination2
  Internet address is 10.129.167.4/17
  MTU 1514 bytes, BW 192 Kbit/sec, DLY 7500000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive set (15 sec), retries 3
  Tunnel source 10.124.8.6 (Loopback1), destination 219.224.19.22
  Tunnel protocol/transport GRE/IP
    Key 0x68A92, sequencing disabled
    Checksumming of packets disabled
  Tunnel TTL 255
  Fast tunneling enabled
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Last input 00:00:01, output 00:00:07, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1588
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     7388052 packets input, 1813050207 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     7655854 packets output, 3329592353 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
*Note that we do not always see output drops

GRE keepalives are not supported with IPsec when tunnel protection is being used.
If this is DMVPN it's phase 1, invalid SPI recovery COULD be triggered by keepalives brining the tunnel down.
Also that's pretty old software - 12.4(15)T has had a few revisions since 9.

Similar Messages

  • EIGRP MTU Size Causing Neighbor Flap - Pls help!

    I've been reading the post here which is quite good but, I have some outstanding questions I hope someone can help me with?
    https://learningnetwork.cisco.com/thread/43100#233367
    Essentially, we have a DCI which is an evpl link - layer 2. The evpl connection is terminated with a Cisco 3925 at each location (once it comes out of the provider's Ciena box). It is a dot1g tagged trunk - L2 connection. We are running EIGRP between the two. Before setting up OTV, all link sizes were 1500 MTU...which obviously will not work with OTV....and it didnt!. OTV is running on 7Ks a few hops away from each 3925. So, I went on each and every link - (pain stakingly) and configured MTU size for 9216 - enabling jumboframes at the system level too where applicable. What do you know, OTV started working and i could ping to at least up to 2000 bytes with DF-bit set too! (I didn't try any higher).
    Last night, our provider did some 'maintenance' without telling us - which brought the link down. The link was 'down' even after the maintenace was completed. After looking in the logs and seeing this, I suspected it had to do with MTU sizes after quickly googling around.
    May 13 12:33:13.698: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 198.28.132.30 (GigabitEthernet0/0.2) is down: Interface PEER-TERMINATION received
    May 13 12:33:13.976: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 198.28.132.30 (GigabitEthernet0/0.2) is up: new adjacency
    May 13 12:33:24.266: %SYS-5-CONFIG_I: Configured from console by izzi on vty0 (10.241.6.12)
    May 13 12:34:00.286: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 198.28.132.30 (GigabitEthernet0/0.2) is down: Interface PEER-TERMINATION received
    May 13 12:34:00.616: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 198.28.132.30 (GigabitEthernet0/0.2) is up: new adjacency
    May 13 12:34:46.922: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 198.28.132.30 (GigabitEthernet0/0.2) is down: Interface PEER-TERMINATION received
    May 13 12:34:47.280: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 198.28.132.30 (GigabitEthernet0/0.2) is up: new adjacency
    May 13 12:35:37.364: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 198.28.132.30 (GigabitEthernet0/0.2) is down: holding time expired
    May 13 12:37:29.725: %SYS-5-CONFIG_I: Configured from console by izzi on vty0 (10.241.6.12)
    May 13 12:37:47.430: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 198.28.132.30 (GigabitEthernet0/0.2) is up: new adjacency
    May 13 12:39:01.508: %SYS-5-CONFIG_I: Configured from console by izzi on vty0 (10.241.6.12)
    May 13 12:39:11.943: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 198.28.132.30 (GigabitEthernet0/0.2) is down: Interface PEER-TERMINATION received
    May 13 12:39:13.973: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 198.28.132.30 (GigabitEthernet0/0.2) is up: new adjacency
    So, I reduced the MTU size back to 1500 and low and behold, adjacency stayed. Let me also say that there weren't any errors on the links too. So, I decided to try and increase the MTU back up to 9216 - OTV started working again and adjancey held - it didnt flap. I thought for a second and decided to bounce the link. Once i did this, EIGRP started flapping again with the same exact behavior. After calling the provider, they claim that their max MTU is only 1522 for our EVPL link. I don't see this being possible since I was able to ping DF-BIT set way above 1522. Maybe I'm missing something. We are going to coordinate with them to increase the MTU size on the link. But why/how did it work to begin with - especially since OTV doesn't support fragmenation....I understand that OTV adjacency can still form since ISIS only needs 14xx something...but I wasn't able to get certain protocals/services like esxi host management to work via OTV until i increased MTU size.
    Also, after reading the above article it sounds like EIGRP will 'peer' or decide on MTU of it's update packets? If that's the case, maybe the bouncing of the link allowed EIGRP to negotiate it's packet sizes to above 1500 and that's why if I change the MTU size to above 1500 everything works fine - OTV/2000 byte bf-bit set ping, until I bounce the link? If this is the case, is there anyway to 'force' EIGRP to use 1500 for it's packets for its protocol traffic and allow everything else to use the MTU set on the link?
    I would appreciate any help explaining this - hopefully you're not as confused as I was after reading it again!

    Did you ever find the root cause and this solution for this?  We are experiencing the same issues with our 2 4500  Catalyst and a couple of routers on our inter routing VLAN that we use for only the 2 chassis and a couple of router.  MTU is already set at 1500 on the 2 chassis.
    005326: Jan 19 11:30:02: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65001: Neighbor 10.190.254.21 (Vlan990) is down: Peer goodbye received
    005327: Jan 19 11:30:05: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65001: Neighbor 10.190.254.1 (Vlan990) is up: new adjacency
    005328: Jan 19 11:30:05: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65001: Neighbor 10.190.254.21 (Vlan990) is up: new adjacency
    005329: Jan 19 11:30:07: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65001: Neighbor 10.190.254.12 (Vlan990) is down: holding time expired
    005330: Jan 19 11:30:27: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65001: Neighbor 10.190.254.21 (Vlan990) is down: Peer goodbye received
    005331: Jan 19 11:30:28: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65001: Neighbor 10.190.254.11 (Vlan990) is down: Peer goodbye received
    005332: Jan 19 11:30:28: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65001: Neighbor 10.190.254.1 (Vlan990) is down: Peer goodbye received
    005333: Jan 19 11:30:30: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65001: Neighbor 10.190.254.12 (Vlan990) is up: new adjacency
    005334: Jan 19 11:30:30: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65001: Neighbor 10.190.254.11 (Vlan990) is up: new adjacency
    005335: Jan 19 11:30:30: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65001: Neighbor 10.190.254.1 (Vlan990) is up: new adjacency
    005336: Jan 19 11:30:32: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65001: Neighbor 10.190.254.21 (Vlan990) is up: new adjacency

  • ASA 5505 site-to-site VPN tunnel and client VPN sessions

    Hello all
    I have several years of general networking experience, but I have not yet had to set up an ASA from the ground up, so please bear with me.
    I have a client who needs to establish a VPN tunnel from his satellite office (Site A) to his corporate office (Site Z).  His satellite office will have a single PC sitting behind the ASA.  In addition, he needs to be able to VPN from his home (Site H) to Site A to access his PC.
    The first question I have is about the ASA 5505 and the various licensing options.  I want to ensure that an ASA5505-BUN-K9 will be able to establish the site-to-site tunnel as well as allow him to use either the IPsec or SSL VPN client to connect from Site H to Site A.  Would someone please confirm or deny that for me?
    Secondly, I would like to verify that no special routing or configuration would need to take place in order to allow traffic not destined for Site Z (i.e., general web browsing or other traffic to any resource that is not part of the Site Z network) to go out his outside interface without specifically traversing the VPN tunnel (split tunneling?)
    Finally, if the client were to establish a VPN session from Site H to Site A, would that allow for him to connect directly into resources at Site Z without any special firewall security rules?  Since the VPN session would come in on the outside interface, and the tunnel back to Site Z goes out on the same interface, would this constitute a split horizon scenario that would call for a more complex config, or will the ASA handle that automatically without issue?
    I don't yet have the equipment in-hand, so I can't provide any sample configs for you to look over, but I will certainly do so once I've got it.
    Thanks in advance for any assistance provided!

    First question:
    Yes, 5505 will be able to establish site-to-site tunnel, and he can use IPSec vpn client, and SSL VPN (it comes with 2 default SSL VPN license).
    Second question:
    Yes, you are right. No special routing is required. All you need to configure is site-to-site VPN between Site A and Site Z LAN, and the internet traffic will be routed via Site A internet. Assuming you have all the NAT statement configured for that.
    Last question:
    This needs to be configured, it wouldn't automatically allow access to Site Z when he VPNs in to Site A.
    Here is what needs to be configured:
    1) Split tunnel ACL for VPN Client should include both Site Z and Site A LAN subnets.
    2) On site A configures: same-security-traffic permit intra-interface
    3) Crypto ACL for the site-to-site tunnel between Site Z and Site A needs to include the VPN Client pool subnet as follows:
    On Site Z:
    access-list permit ip
    On Site A:
    access-list permit ip
    4) NAT exemption on site Z needs to include vpn client pool subnet as well.
    Hope that helps.
    Message was edited by: Jennifer Halim

  • Transparent Tunneling and Local Lan Access via VPN Client

    Remote users using Cisco VPN 4.2 connect successfully to a Cisco Pix 515 (ver. 6.3). The client is configured to allow Transparent Tunneling and Local Lan access, but once connected to the Pix, these two options are disabled. What configuration changes are required on the Pix to enable these options? Any assistance will be greatly appreciated.
    Mike Bowyer

    Hi Mike,
    "Transparent Tunneling" and "Local Lan Access" are two different things. "Transparent Tunneling" is dealing with establishing an IPSec Tunnel even if a NAT device is between your client and the VPN-Headend-Device. "Local LAN Access" is dealing with access to devices in the LAN your VPN-Client-Device is connected to.
    What do you mean exactly with "disabled once the connection is made" ?
    You can check the local LAN Access by having a look at the Route-Table of the VPN-Client:
    Right Click the yellow VPN-lock Icon in System-Tray while the VPN-Connection is active and select "Statistics ...". Have a look at the second register page "route details".
    Are any local LAN routes displayed when your are connected ?
    And - always remember two important restrictions the Online Help of the VPN-Client is mentioning:
    1: This feature works only on one NIC card, the same NIC card as the tunnel.
    2: While connected, you cannot print or browse the local LAN by name; when disconnected, you can print and browse by name.
    Carsten
    PS: Removing Split Tunnel won't enable local LAN access as all traffic would be sent into the IPSec tunnel.

  • HTTP Tunneling and Load Balancing with Weblogic Server 6.1

    We use T3 for Java client to application server communication (Weblogic Server
    6.1) and keep the session open for the life of the client. We many customers
    using this with load balancers and all works fine. We have just started to use
    BEA's HTTP tunneling and I have a question concerning how this will work with
    load balancers. Since the single T3 connection has been replaced with a series
    of stateless HTTP connections, does the BEA tunneling code put session information
    in the HTTP header? If so, what information does it place in the header. If
    it does we should be able to use that to make sure that the load balancer always
    sends HTTP requests with that session to the same application server.
    Thanks!
    Rick

    Rick,
    You may want to look at the Alteon and F5 configuration we have on edocs.
    Take a look at the following URLs for a possible solution
    http://edocs.bea.com/wls/docs61/cluster/alteon.html#591902
    http://edocs.bea.com/wls/docs61/cluster/bigip.html#591902
    Chuck Nelson
    DRE
    BEA Technical Support

  • TS3694 Hi, My iphone 5 loses the 3G connections everytime i go into tunnel and also to holland park and it does not come back untill i restart the phone? i dont know why is it happening?

    Hi, My iphone 5 loses the 3G connections everytime i go into tunnel and also to holland park and it does not come back untill i restart the phone? i dont know why is it happening?

    Hi, beth.lau.gr.
    Thank you for visiting Apple Support Communities.  
    I understand you have been experiencing issues with your iPhone restarting and showing you a blue screen.  I wont be able to give you an exact answer as to why this is happening.  However, this is the most relevant troubleshooting article for this issue.  This article also provides options to reach out to us via phone for additional assistance.  
    If your iOS device restarts, displays the Apple logo, or powers off while you're using it
    http://support.apple.com/en-us/HT203899
    Cheers, 
    Jason H.  

  • Wind tunnel and more

    Wind tunnel and more http://www.riyadh-leaks.com/ 

    You can try a NVRAM reset, which often helps with firewire related issues:
    Steps to reset nvram :
    Power Down
    Hold down Cmd-Opt-O-F
    Power On
    at Open Firmware prompt, type:
    reset-nvram
    reset-all (this just reboots)
    If you can't get this far:
    Try to boot off the install DVD. If you can then...
    Check your hardware using the hardware test disk that came with your system. (Sometimes this is included on the install, or recover disk).
    If you just keep getting nothing, it's time for the apple store

  • Vpn tunnels and Nat on Cisco soho 91 routers ??

    Is it possible to create the following, using the soho 91 routers:
    Router A (192.168.1.0) network
    E0 192.168.1.250
    E1 external ip (world ip)
    Router B (192.168.99.0) network
    E0 192.168.99.1
    E1 external ip (world ip)
    Router C (192.168.103.0) network
    E0 192.168.103.1
    E1 external ip (world ip)
    tunnel1 = from Router A to Router B
    tunnel2 = from Router A to Router C
    on Router A
    ip route 192.168.2.0 255.255.255.0 192.168.1.2
    ip route 192.168.3.0 255.255.255.0 192.168.1.3
    ip route 192.168.4.0 255.255.255.0 192.168.1.4
    ip route 192.168.99.0 255.255.255.0 to-tunnel1
    ip route 192.168.103.0 255.255.255.0 to-tunnel2
    ip route nat (everything thing else)
    on Router B
    ip route 192.168.1.0 255.255.255.0 to-tunnel1
    ip route 192.168.103.0 255.255.255.0 to-tunnel1
    ip route nat (everything else)
    on Router C
    ip route 192.168.1.0 255.255.255.0 to-tunnel2
    ip route 192.168.103.0 255.255.255.0 to-tunnel2
    ip route nat (everything else)
    Thanks.
    Wayne

    I assume you are using GRE tunnel and not IPSec. If GRE tunnel, the configuration looks OK except for Router C. The "ip route 192.168.103.0 255.255.255.0 to-tunnel2" should be "ip route 192.168.99.0 255.255.255.0 tunnel2 " pointing to the network connected to Router B. Also the correct command should not have "to-tunnel1", it is simply "tunnel1"

  • IPSec Tunnel and Making Changes While Up

    My main MPLS circuit is down and i have two IPSec tunnels up to my remote sites.
    Everything is routing fine but i wanted to add a sub net to my NAT and Tunnels.
    Can i add a new subnet to my local network/remote network and save/apply without killing or reseting my active IPSec tunnels?                  

    Reza has interpreted your question in terms of NAT and I agree with him that you should be able to change the NAT configuration without impacting other parts of the router operation and connectivity.
    But I read your question as involving both NAT and IPSec tunnels. And I believe that the answer is different when you consider IPSec tunnels. You can go ahead and change the configuration of the tunnels while they are up. But the tunnels negotiated their Security Associations based on the config in place when the tunnels came up. They will continue to use those Security Associations after you make your config change. So if you are changing things like what subnets are in the access list used to identify traffic for IPSec these changes will not take effect until a new Security Association is negotiated. You can either wait for the lifetime to expire and new SA negotiated or your can reset the IPSec tunnels and force a new negotiation. Also note that if you are changing the access list on your end that someone on the other end needs to make a corresponding change on their end.
    HTH
    Rick

  • Lost dust Jacket front and back flap

    I composed a book in Aperture using the Journal theme. After making a couple of PDF previews, somehow???? I have lost the dust JAcket front and back flap pages. I can't find a way to re-insert these from a master or build them any other way. I have tried to show the master pages and select the front dust jacket flap master and then 'Add New Page From Master', but it won't allow me to select that option. I still have the front cover and Back cover in the Pages layout. So, how do I rebuild the dust jacket flaps? My pages are as follows: 1st is the Front Cover; 2nd is a Blank page; then 3rd is my Table of Contents page(currently showing as Page 1). I made a duplicate (to experiment with ways to solve it) and tried to rebuild it using the same theme, but it makes a mess of it, loosing all my layouts. After having spent dozens of hours on this book and it was almost ready to send, I don't want to have to start all over again. Help!!!

    I composed a book in Aperture using the Journal theme. After making a couple of PDF previews, somehow???? I have lost the dust JAcket front and back flap pages. I can't find a way to re-insert these from a master or build them any other way. I have tried to show the master pages and select the front dust jacket flap master and then 'Add New Page From Master', but it won't allow me to select that option. I still have the front cover and Back cover in the Pages layout. So, how do I rebuild the dust jacket flaps? My pages are as follows: 1st is the Front Cover; 2nd is a Blank page; then 3rd is my Table of Contents page(currently showing as Page 1). I made a duplicate (to experiment with ways to solve it) and tried to rebuild it using the same theme, but it makes a mess of it, loosing all my layouts. After having spent dozens of hours on this book and it was almost ready to send, I don't want to have to start all over again. Help!!!

  • HT4199 when I set my network airport to lock, it doesn't stay locked and neighboring families networks popup on my screen, and the lock clicks open.  Why doesn't it stay in the locked position?

    when I set my network airport to lock, it doesn't stay locked and neighboring families networks popup on my screen, and the lock clicks open.  Why doesn't it stay in the locked position?  JOHNPEG

    Open the Security pane of System Preferences and set it to require a password to unlock each secure pane. This is designed to stop people using the computer from changing the settings and won't do anything if an issue on the computer itself causes the change.
    (51259)

  • IPSEC tunnel and Routing protocols Support

    Hi Everyone,
    I read IPSEC does not support Routing Protocols with Site to Site VPN as they both are Layer4.
    Does it mean that If Site A  has to reach Site B over WAN  link we should use Static IP on Site A and Site B  Router?
    In  my home Lab i config Site to Site IPSES  VPN  and they are working fine  using OSPF  does this mean that IPSEC supports Routing Protocol?
    IF someone can explain me this please?
    OSPF  config A side
    router ospf 1
    router-id 3.4.4.4
    log-adjacency-changes
    area 10 virtual-link 10.4.4.1
    passive-interface Vlan10
    passive-interface Vlan20
    network 3.4.4.4 0.0.0.0 area 0
    network 192.168.4.0 0.0.0.255 area 10
    network 192.168.5.0 0.0.0.255 area 0
    network 192.168.10.0 0.0.0.255 area 0
    network 192.168.20.0 0.0.0.255 area 0
    network 192.168.30.0 0.0.0.255 area 0
    network 192.168.98.0 0.0.0.255 area 0
    network 192.168.99.0 0.0.0.255 area 0
    3550SMIA#sh ip route
    Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
           D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
           N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
           E1 - OSPF external type 1, E2 - OSPF external type 2
           i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
           ia - IS-IS inter area, * - candidate default, U - per-user static route
           o - ODR, P - periodic downloaded static route
    Gateway of last resort is 192.168.5.3 to network 0.0.0.0
    O    192.168.12.0/24 [110/13] via 192.168.5.3, 3d17h, FastEthernet0/11
         100.0.0.0/32 is subnetted, 1 subnets
    O       100.100.100.100 [110/3] via 192.168.5.3, 3d17h, FastEthernet0/11
         3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
    O       3.3.3.3/32 [110/2] via 192.168.5.3, 3d17h, FastEthernet0/11
    C       3.4.4.0/24 is directly connected, Loopback0
    C    192.168.30.0/24 is directly connected, Vlan30
         64.0.0.0/32 is subnetted, 1 subnets
    O E2    64.59.135.150 [110/300] via 192.168.5.3, 1d09h, FastEthernet0/11
         4.0.0.0/32 is subnetted, 1 subnets
    O       4.4.4.4 [110/2] via 192.168.5.3, 3d17h, FastEthernet0/11
    C    192.168.10.0/24 is directly connected, Vlan10
         172.31.0.0/24 is subnetted, 4 subnets
    O E2    172.31.3.0 [110/300] via 192.168.5.3, 3d17h, FastEthernet0/11
    O E2    172.31.2.0 [110/300] via 192.168.5.3, 3d17h, FastEthernet0/11
    O E2    172.31.1.0 [110/300] via 192.168.5.3, 3d17h, FastEthernet0/11
    O E2    172.31.0.0 [110/300] via 192.168.5.3, 3d17h, FastEthernet0/11
    O    192.168.11.0/24 [110/3] via 192.168.5.3, 3d17h, FastEthernet0/11
    O    192.168.98.0/24 [110/2] via 192.168.99.1, 3d17h, FastEthernet0/8
    C    192.168.99.0/24 is directly connected, FastEthernet0/8
    C    192.168.20.0/24 is directly connected, Vlan20
         192.168.5.0/31 is subnetted, 1 subnets
    C       192.168.5.2 is directly connected, FastEthernet0/11
    C    10.0.0.0/8 is directly connected, Tunnel0
         192.168.6.0/31 is subnetted, 1 subnets
    O       192.168.6.2 [110/2] via 192.168.5.3, 3d17h, FastEthernet0/11
    O    192.168.1.0/24 [110/13] via 192.168.5.3, 3d17h, FastEthernet0/11
    O*E2 0.0.0.0/0 [110/1] via 192.168.5.3, 1d09h, FastEthernet0/11
    B Side Config
    Side A
    router ospf 1
    log-adjacency-changes
    network 192.168.97.0 0.0.0.255 area 0
    network 192.168.98.0 0.0.0.255 area 0
    network 192.168.99.0 0.0.0.255 area 0
    1811w#  sh ip route
    Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
           D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
           N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
           E1 - OSPF external type 1, E2 - OSPF external type 2
           i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
           ia - IS-IS inter area, * - candidate default, U - per-user static route
           o - ODR, P - periodic downloaded static route
    Gateway of last resort is 192.168.99.2 to network 0.0.0.0
    O    192.168.12.0/24 [110/14] via 192.168.99.2, 3d17h, FastEthernet0
         100.0.0.0/32 is subnetted, 1 subnets
    O       100.100.100.100 [110/4] via 192.168.99.2, 3d17h, FastEthernet0
         3.0.0.0/32 is subnetted, 2 subnets
    O       3.3.3.3 [110/3] via 192.168.99.2, 3d17h, FastEthernet0
    O       3.4.4.4 [110/2] via 192.168.99.2, 3d17h, FastEthernet0
    O    192.168.30.0/24 [110/2] via 192.168.99.2, 3d17h, FastEthernet0
         64.0.0.0/32 is subnetted, 1 subnets
    O E2    64.59.135.150 [110/300] via 192.168.99.2, 1d09h, FastEthernet0
         4.0.0.0/32 is subnetted, 1 subnets
    O       4.4.4.4 [110/3] via 192.168.99.2, 3d17h, FastEthernet0
    O    192.168.10.0/24 [110/2] via 192.168.99.2, 3d17h, FastEthernet0
         172.31.0.0/24 is subnetted, 4 subnets
    O E2    172.31.3.0 [110/300] via 192.168.99.2, 3d17h, FastEthernet0
    O E2    172.31.2.0 [110/300] via 192.168.99.2, 3d17h, FastEthernet0
    O E2    172.31.1.0 [110/300] via 192.168.99.2, 3d17h, FastEthernet0
    O E2    172.31.0.0 [110/300] via 192.168.99.2, 3d17h, FastEthernet0
    O    192.168.11.0/24 [110/4] via 192.168.99.2, 3d17h, FastEthernet0
    C    192.168.98.0/24 is directly connected, BVI98
    C    192.168.99.0/24 is directly connected, FastEthernet0
    O    192.168.20.0/24 [110/2] via 192.168.99.2, 3d17h, FastEthernet0
         192.168.5.0/31 is subnetted, 1 subnets
    O       192.168.5.2 [110/2] via 192.168.99.2, 3d17h, FastEthernet0
         192.168.6.0/31 is subnetted, 1 subnets
    O       192.168.6.2 [110/3] via 192.168.99.2, 3d17h, FastEthernet0
    O    192.168.1.0/24 [110/14] via 192.168.99.2, 3d17h, FastEthernet0
    O*E2 0.0.0.0/0 [110/1] via 192.168.99.2, 1d09h, FastEthernet0
    Thanks
    Mahesh

    Hello,
    I'm saying crypto maps have a lot of limitations. Tunnel Protection make way more sense
    U can configure in 2 ways [ and multicast WILL work over it]
    1- GRE over IPSEC
    crypto ipsec transform-set aes esp-aes 256 esp-sha-hmac
    mode transport
    crypto ipsec profile tp
    set transform-set aes
    int tu1
    ip address 255.255.255.252
    tunnel source
    tunnel destination
    tunne protection ipsec profile tp
    We have configured mode transport because we encrypt GRE + what ever we encapsule in GRE [ eg OSPF - telnet - http ]
    Pros:
    We can as well transport IPV6 or CDP
    Cons:
    4 bytes of overhead due to GRE
    2- IP over IPSEC
    crypto ipsec transform-set aes esp-aes 256 esp-sha-hmac
    mode tunnel
    crypto ipsec profile tp
    set transform-set aes
    int tu1
    ip address 255.255.255.252
    tunnel source
    tunnel destination
    tunnel mode ipsec ipv4
    tunne protection ipsec profile tp
    This config is in fact closer from a crypto map [ from encapsulation standpoint]. The transform-set then NEED to be in tunnel-mode
    Pro:
    4 bytes overhead less than GRE over IPSEC
    Cons:
    Cannot transport CDP or MPLS or IPV6. Very limiting IMHO
    Cheers
    Olivier

  • EIGRP IPv6 and VLAN interfaces

    We've found that we have to set static link local IPs when two routers might peer over multiple VLAN interfaces.
    The issue is that the routers, 6500s with sup720s, utilize the same autoconfig'd link local address on each VLAN interface.   EIGRP IPv6 refuses to peer with the other router on multple VLANs when the link local are the same.
    Anyone else encounter this?   Did we miss a config option that would force unique link locals on different VLANs interfaces?
    Because of this issue, we've made it our best practice to configure static link local for all inter-router transits.

    HI Gary,
    I had a setup with SU720 on 2 7600s and I am able to enable the neighborship without any issues. I didnt configure static link local as below,
    Ryanair#show ipv6 int vlan 500  | inc FE
      IPv6 is enabled, link-local address is FE80::21C:B0FF:FEB5:6D00
    Ryanair#sho ipv6 int vlan 501 | inc FE
      IPv6 is enabled, link-local address is FE80::21C:B0FF:FEB5:6D00
    Ryanair#show ipv6 eigrp nei
    EIGRP-IPv6 neighbors for process 100
    H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                                (sec)         (ms)       Cnt Num
    1   Link-local address:     Vl501             11 00:15:51  816  4896  0  13
        FE80::222:55FF:FE17:25C0
    0   Link-local address:     Vl500             11 00:17:14    1   200  0  12
        FE80::222:55FF:FE17:25C0
    Ryanair#
    Can you let us know the version on oth the devices?.
    Regards,
    Nagendra

  • EIGRP , successor and feasible successor

    what happen in EIGRP if a successor fails and a Feasible successor is not present ?
    i mean if ther'es  route in the topology table but the route for the destination is not a Feasible Successor.
    does the router discard che packet or use the route without the feasibility condition ?

    Hi Joseph,
    You are welcome!
    why when the link R1-R3 was active the link R2-R3 did not met the FC ?
    This question goes back to the definition of the Feasible Distance. The Feasible Distance is a record of the lowest distance towards a particular destination since the last time the destination went from Active to Passive state. The Feasible Distance is therefore not necessarily the current distance, rather, it is a historical minimum of the distance (with the history starting anew with the Active->Passive transition). The Feasible Distance can be reset and newly initialized in the moment of Active->Passive transition (meaning it can also increase during this transition) but otherwise, during a stable Passive state, the Feasible Distance can only decrease.
    If we understand the Feasible Distance as the minimal historical distance to a destination then the Feasibility Condition that says: RD < FD can be put into words as follows:
    Any neighbor who is closer to the destination than we have ever been is not on a routing loop.
    Assuming that in your network, R2 was not considered a feasible successor to 192.168.1.0/24, this tells us that the R2 is not closer to the destination than we have ever been. Why would that be? Well, we can always construct a network in which the link metrics are chosen so that while R2 is not going to route packets back to R1, it won't pass the FC check, like here:
    R1's FD to the destination LAN behind R3 is 16, following the shortest path R1-R3. R2's distance to the same LAN is 18. Notice that R2 is certainly not using the path via R1 - that path would be much longer (20+15+1=36). However, at this point, R2 does not meet the FC check from R1's viewpoint. R1's FD is 16, R2's reported distance is 18, so R1 can not be sure if R2 is or is not using R1 to reach the destination. This is the exact situation where the FC check is actually more strict than necessary but it is better to be too cautious against routing loops than to be too trusting.
    So in this network, R1 does not consider R2 to be a feasible successor because it is not closer to the destination than R1 has ever been (the RD of R2, 18, is more than the FD of R1, 16).
    When the link from R1 to R3 fails, R1 loses its successor, and because the next router, in this case R2, provides the next least cost path but does not meet the FC check, R1 will put the network into active state and start sending Queries. These Queries simply contain the current increased distance of R1 to the destination (in this case, infinity because the path has been totally lost). Basically, R1 is informing its neighbors that its own distance has increased, and expects the neighbors to reevaluate their own choices of successors (subject to their own FDs and FC checks). If R1's increased distance does not influence the neighbor's selection of successor, it simply sends a Reply with the current distance. If, however, R1 has been a successor for some neighbor up to the moment of the distance increase and now, because of the increased distance, R1 does not meet the FC check from that neighbor's viewpoint anymore, that neighbor has just lost a successor and must deal with it exactly in the way I've explained in my first reply. It is possible that this neighbor will also have to put the destination into Active state and start sending Queries itself. This is what is called a Diffusing Computation in EIGRP.
    In this network, after the R1-R3 link is torn down, R1 will indeed send a Query to R2, indicating its current infinite distance to the LAN. However, R2 does not currently consider R1 a successor - it is using R3 as its successor. So, for R2, the increased distance of R1 to the destination is irrelevant as it does not influence its own choice of successor. Here, R2 merely sends back a Reply immediately, indicating its current distance to R1, saying that the distance stays at 18 despite R1's increase of distance. Because R2 is R1's only neighbor, this Reply is the last expected Reply, after which R1 can put the route back into Passive state and reset the FD to the newly found shortest path metric, in this case, the route through R2, with the metric being 20+17+1=38.
    This is why the Active->Passive transition allows you to reset and reinitialize, even increase the FD - because as a result of sending Queries, you have forced your neighbors to reevaluate their own choice of successors. If a neighbor sends you a Reply, you can be sure that it has taken your new increased distance into account and has modified its routing table accordingly - in any case, in such a way there is no routing loop, subject to that neighbor's own FD and its own FC check. Therefore, now you simply choose the least cost path and set the FD to its cost.
    Note that the situation will be different if we change the metrics like this:
    The R1's FD to the LAN is still 16. However, R2's reported distance is 11, so here, it meets the FC check even though it is not considered to be a successor by R1 because the total path through it would be 31. It it still a feasible successor, though.
    Here, if the link between R1 and R3 is torn down, R1 will find in its topology table that R2 provides the next least cost path and it is a feasible successor as well. So here, the route will never enter the Active state - it will remain Passive, just the successor will be changed to R2 and the current distance on R1 will increase to 31. Notice, however, that because we have not gone through the Active state (we did not need to), the FD at R1 will not change and will remain on the previous value of 16!
    This example shows the true behavior of FD. It is a record of the minimum distance to the destination since the last time it entered the Passive state, and is used for FC checks only. It does not necessarily represent the current distance, contrary to the popular - and incorrect - belief.
    Now let's modify this network a little more:
    R1's shortest path to the destination LAN is via R3, with the FD being set to 16. R2's shortest path is via R3 and its distance is 11, therefore, R2 is a feasible successor. R4's shortest path is via R3 as well, and its distance is 18, but because 18 is more than R1's FD of 16, R4 is not considered a feasible successor.
    Note, however, that while R2 is a feasible successor here, the route from R1 through R2 to the destination would have the metric of 31, while the route through R4 - even though R4 is not considered a feasible successor - would have the metric of 23. Quite a difference, isn't it? Now, if R1-R3 link fails, what should R1 do?
    If it decides to go with R2 as the feasible successor, it will surely be using a loop free path but at the same time, that path won't be the shortest one that is available. The path through R4 at this point seems to be shorter but because R4 fails the FC check, R1 is not sure - is R4 actually using R1 as its next hop, or is it using a different router? That is why R1 has to make sure.
    So in this network, if R1-R3 link fails, R1 will find out that the router providing the next least cost path is R4, not R2, and that the R4 does not meet the FC check. So R1 will again go Active and start sending out Queries, indicating its current (infinite) distance to the LAN network. Both R2 and R4 will receive this Query, and because neither of them is using R1 as its next hop, the increased distance on R1 is irrelevant to them, so they immediately send a Reply with their current metrics: R2 replies with 11 and R4 replies with 18. When R1 receives both Reply messages, it goes back to Passive state, resets the FD and chooses the neighbor that provides the least cost path - in this case, R4. The current metric will be set to 23 including the FD, as the FD has been reset. Note that R2 was and has remained a feasible successor all the time - it has never been promoted to successor role.
    Quite a lengthy explanation, I admit - but these are not intuitive facts so it takes a little to digest them.
    Please feel welcome to ask further!
    Best regards,
    Peter

  • Will EIGRP form a neighbor with stanby address?

    We have two core 6509's connected to several distribution layer switches all of which are running EIGRP, the core switches are connected to a PIX which is the gateway to the internet. We are currently running HSRP between the core switches and the standby address is the gateway of last resort for the distribution layer switches. Is this the right way to do this or should we just configure the PIX to be the gateway of last resort? Also how does EIGRP deal with the standby address being its neighbor?

    Harold
    The drawing did not seem to make it into the post, so I am not sure what your environment is. Assuming that there is more than one VLAN present I still am inclined to advocate the use of HSRP. I think we can consider several aspects of this question. When your original post referred to using the standby as the default gateway for the distribution switches I am not clear whether you meant literally that the distribution switches would be configured with a gateway address of the standby or whether you meant that end stations connected to the switches would use the standby address. Especially from the standpoint of the end stations I believe that the standby address is an advantage. You could configure the end stations with a gateway using the PIX address. But if you do you will be depending on proxy ARP for all the VLANs that are not locally connected to the PIX (and that is likely to be all of the user VLANs). Not only do I consider relying on proxy ARP to be a weakness but you also should consider this scenario: an end station ARPs for its gateway address (the PIX address) and one of the switches will answer, and the MAC supplied will be the MAC of the switch. The end station now has a MAC for its gateway. If there is a problem and that particular switch becomes available then the gateway for the end station is not available until the end station clears it ARP entry and ARPs again.
    So unless there is something about your environment that I do not understand I would be in favor of continuing to use the standby address.
    hTH
    Rick

Maybe you are looking for