Hi Forum,

I have tried many times but failed to generate traffic in IPv6 using virtual box using GNS3. I also want to capture these trafic through wireshark. So, if you guys please tell me the way to generate and capture traffic in GNS3 then it will really help me a lot. I am really at a stuck

Thanks

Hi;

I'm completely new to ASA and working on a very simple topology where I have asa with 3 ports named Internal, Outside and DMZ. each interface is connected to a router. I have configured a static nat under a Network object, so there is static entry on XLate table. my test includes seting up telnet connection between a client on internal network and a router that resides outside. don't I need to create an ACL for returning Telnet traffic on ASA (because client is inside security level 100 and destination for Telnet resides inside security level 0 network). I did created this ACL but I got no hits against it and finally I disabled it. even after disabling that ACL, I managed to issue telnet between them. it is good to mention that the NAT worked well too. so why I don't need any ACL for returning Telnet traffic considering security levels? tnx. 

I still have 4000 tokens left if anyone needs them.

Hi -

I have asa-5550 running 8.4(7)26, it support SHA-2 256, 385 & 512K per release note;

Currenlty, we are using SHA-1 for sslvpn (client & clientless) and would like to migrate to SHA-2 certificate;

However, under Configuration --> Remote Access VPN --> Advanced --> SSL Seetings ... I dont see any SHA2 encryption algorithms.  All i see are ssl encryption aes256-sha1 aes128-sha1 3des-sha1....etcs

Question - how to enable sha2-256 encryption?

Any help is much appreciated, thanks

Hi all,

I created a PIM-SSM lab on GNS3, as per the attached diagram.  The aim was to see how SSM handles send traffic to a LAN segment with multiple multicast routers (R2 and R4).   

The default configuration ( basic ospf cfg, and ip pim ssm enable) worked as expected, R4 was elected the DR (highest IP) for the 2.4.7.0/24  network, and multicast traffic flowed from source R6->R5->R3->R4->R7 host, trace and mtrace match.

Then I  changed the ospf metrics  (R4 cost for 2.4.7.0 to 1000 )   Now the path via R2is the best but the DR is R4.  Here I see a mismatch between PIM forwarding interfaces (show ip mroute) and the trace/mtrace path to the host but traffic is still forwarded, but im not sure why?

Default cfg

R4#sho ip mroute 232.1.1.1
(56.1.1.6, 232.1.1.1), 00:00:46/00:02:58, flags: sTI
  Incoming interface: FastEthernet0/0, RPF nbr 34.1.1.3
  Outgoing interface list:
    FastEthernet1/1, Forward/Sparse, 00:00:14/00:02:45
R4#
*Apr 15 21:22:40.075: IP(0): s=56.1.1.6 (FastEthernet0/0) d=232.1.1.1 (FastEthernet1/1) id=1437, ttl=252, prot=1, len=100(100), mforward

R4#sho ip pim interface
Address          Interface                Ver/   Nbr    Query  DR     DR
                                          Mode   Count  Intvl  Prior
4.4.4.4          Loopback0                v2/S   0      30     1      4.4.4.4
34.1.1.4         FastEthernet0/0          v2/S   1      30     1      34.1.1.4
2.4.7.4          FastEthernet1/1          v2/S   1      30     1      2.4.7.4
R4#

R5#mtrace 2.4.7.7
Type escape sequence to abort.
Mtrace from 2.4.7.7 to 35.1.1.5 via RPF
From source (?) to destination (?)
Querying full reverse path...
 0  35.1.1.5
-1  35.1.1.5 PIM  [2.4.7.0/24]
-2  35.1.1.3 PIM  [2.4.7.0/24]
-3  34.1.1.4 PIM  [2.4.7.0/24]
-4  2.4.7.7
\
R5#traceroute 2.4.7.7
  1 35.1.1.3 44 msec 52 msec 24 msec
  2 34.1.1.4 52 msec 24 msec 32 msec
  3 2.4.7.7 64 msec 24 msec 32 msec
R5#

R3#sho ip route 2.4.7.0
Routing entry for 2.4.7.0/24
  Known via "ospf 1", distance 110, metric 2, type intra area
  Last update from 23.1.1.2 on FastEthernet0/0, 00:00:06 ago
  Routing Descriptor Blocks:
  * 34.1.1.4, from 2.4.7.7, 01:02:53 ago, via FastEthernet1/0
      Route metric is 2, traffic share count is 1
    23.1.1.2, from 2.4.7.7, 00:00:06 ago, via FastEthernet0/0
      Route metric is 2, traffic share count is 1
R3#
R3#sho ip rpf 2.4.7.7
RPF information for ? (2.4.7.7)
  RPF interface: FastEthernet1/0
  RPF neighbor: ? (34.1.1.4)
  RPF route/mask: 2.4.7.0/24
  RPF type: unicast (ospf 1)
  RPF recursion count: 0
  Doing distance-preferred lookups across tables
R3#

 
After OSPF cost change on R4

R4#sho ip mroute 232.1.1.1
(56.1.1.6, 232.1.1.1), 00:46:14/00:02:59, flags: sTI
  Incoming interface: FastEthernet0/0, RPF nbr 34.1.1.3
  Outgoing interface list:
    FastEthernet1/1, Forward/Sparse, 00:08:44/00:02:15, A

R4#
*Apr 15 22:08:07.635: IP(0): s=56.1.1.6 (FastEthernet0/0) d=232.1.1.1 (FastEthernet1/1) id=2499, ttl=252, prot=1, len=100(100), mforward
R4#

R3 only forwards the traffic to R4

R3#SHO IP MROute 232.1.1.1
(56.1.1.6, 232.1.1.1), 00:05:20/00:03:25, flags: sT
  Incoming interface: FastEthernet1/1, RPF nbr 35.1.1.5
  Outgoing interface list:
    FastEthernet1/0, Forward/Sparse, 00:05:00/00:03:25


R2#sho ip mroute 232.1.1.1
(56.1.1.6, 232.1.1.1), 00:08:36/00:02:00, flags: sPTI
  Incoming interface: FastEthernet1/0, RPF nbr 23.1.1.3
  Outgoing interface list: Null

R2#
*Apr 15 22:14:52.211: IP(0): s=56.1.1.6 (FastEthernet1/1) d=232.1.1.1 id=2588, ttl=251, prot=1, len=114(100), not RPF interface

The below shows both unicast and multicast following the same path, but not via R4?

R5#traceroute 2.4.7.7

Type escape sequence to abort.
Tracing the route to 2.4.7.7

  1 35.1.1.3 76 msec 40 msec 20 msec
  2 23.1.1.2 8 msec 32 msec 24 msec
  3 2.4.7.7 56 msec 32 msec 76 msec

R5#MTRace 2.4.7.7

 0  35.1.1.5
-1  35.1.1.5 PIM  [2.4.7.0/24]
-2  35.1.1.3 PIM  [2.4.7.0/24]
-3  23.1.1.2 PIM  [2.4.7.0/24]
-4  2.4.7.7
R5#

R3#sho ip route 2.4.7.0
Routing entry for 2.4.7.0/24
  Known via "ospf 1", distance 110, metric 2, type intra area
  Last update from 23.1.1.2 on FastEthernet0/0, 00:30:21 ago
  Routing Descriptor Blocks:
  * 23.1.1.2, from 2.4.7.7, 00:30:21 ago, via FastEthernet0/0
      Route metric is 2, traffic share count is 1


R3#sho ip rpf 2.4.7.0
RPF information for ? (2.4.7.0)
  RPF interface: FastEthernet0/0
  RPF neighbor: ? (23.1.1.2)
  RPF route/mask: 2.4.7.0/24
  RPF type: unicast (ospf 1)
  RPF recursion count: 0
  Doing distance-preferred lookups across tables
R3#

Hi there

Can somebody confirm me that the one difference between Nexus 7700 and Nexus 7000 series concerns Supe2E board format (half an U) and presence of F3 boards ?

I suppose that thereis also a great gain concerning switching capacity (more than 3.5 tb/s per slot I think)

Did anybody tried netflow on these equipment, is there strong improvements compared to 7k ?

Thanks for your help.

Hello Team,

I've come across few scenarios where I see it is configured in a way that a prefix-list (with a bunch of entries) is calling under an 'ip policy-map' and that policy-list is used to mach inside the route-map and to set the community attributes for the matching prefixes. My question is what is the advantage of doing this way comparing to the way where the prefix-lists are used to match the prefixes inside the route-maps (instead of policy-lists)?

Example:

ip prefix-list ALLOW_PREFIX1 permit 169.125.3.78/32

ip prefix-list ALLOW_PREFIX1 permit 10.25.33.0/24

ip prefix-list ALLOW_PREFIX1 permit 192.16.124.240/29

ip prefix-list ALLOW_PREFIX1 permit 191.33.172.240/29

ip prefix-list ALLOW_PREFIX1 permit 220.175.240/29

ip prefix-list ALLOW_PREFIX2 permit 44.3.113.0/24

ip prefix-list ALLOW_PREFIX2 permit 10.26.53.66/32

!

ip policy-list XYZ permit

match ip address prefix-list ALLOW_PREFIX1

!

ip policy-list YWX permit

match ip address prefix-list ALLOW_PREFIX2

!

route-map ABC permit 20

  match policy-list YWX

  match policy-list XYZ

set community 200:70 230:150 300:170 320:1

!

route-map ABC permit 20

  match policy-list XYZ

set community 200:70 230:150 300:170

!

router bgp 100

neighbor 192.168.10.10 remote-as 250

neighbor 192.168.10.10 route-map ABC out

Regards,

George

I spent a few hours mucking around with this only to find that my solution was exactly like the one posted.  In the real lab that would be game set and match of course, but I'm wondering if the CSR 1000vs have an issue here or whether it's operator error. :P

I am having an SPT switchover issue it seems from R6/R7.  If I disable with ip pim spt-threshold infinity I get consistent pings the entire time.

Checking routing and path on R6 I have a good RPF check all the way back to the sender.

R6#show ip route multicast 119.3.192.21

Routing Table: multicast

Routing entry for 119.3.192.0/24

  Known via "eigrp 6000", distance 170, metric 26368

  Tag 0.0.7.208, type external, 

   replicated from topology(default)

  Last update from 192.0.69.9 on GigabitEthernet1.69, 12:02:22 ago

  Routing Descriptor Blocks:

  * 192.0.69.9 (default), from 192.0.69.9, 12:02:22 ago, via GigabitEthernet1.69

      Route metric is 26368, traffic share count is 1

      Total delay is 30 microseconds, minimum bandwidth is 100000 Kbit

      Reliability 255/255, minimum MTU 1500 bytes

      Loading 1/255, Hops 2

      Route tag 0.0.7.208

R6#

R6#mtrace 119.3.192.21

Type escape sequence to abort.

Mtrace from 119.3.192.21 to 192.0.69.6 via RPF

From source (?) to destination (?)

Querying full reverse path... 

 0  192.0.69.6

-1  192.0.69.6 ==> 192.0.69.6 PIM  [119.3.192.0/24]

-2  192.0.69.9 ==> 192.0.59.9 PIM_MT  [119.3.192.0/24]

-3  192.0.59.5 ==> 100.10.50.5 PIM_MT  [119.3.192.0/24]

-4  100.10.50.1 ==> 119.3.0.1 PIM  [119.3.192.0/24]

-5  119.3.0.19 ==> 119.3.192.19 PIM_MT  [119.3.192.0/24]

-6  119.3.192.21 

I'm not really sure where to look at this point so any help is appreciated.  

-Bill

One of the tasks in this section states,

• The role DEBUG should be able to use any debug and undebug commands, and it should be able to inspect the running configuration.

I'm having an issue with a couple of branch routers not playing ball with dmvpn. My hubs are Cisco 4k series routers and working for 90% of the other sites. With other 4k series routers as spokes the config works fine. But trying to get a 1900 or 1800 series spoke router working is a nightmare, the crypto and dmvpn config won't come up properly. Below is an example of the branch config WHEN THE TNUNEL WORKS (firstly I will show you the config that actually works on either the 1800 or 1900 series spoke router).

crypto isakmp policy 1

 encr aes 256

 authentication pre-share

 group 2

crypto isakmp key xxxxxxx address 0.0.0.0 0.0.0.0

crypto isakmp invalid-spi-recovery

crypto isakmp keepalive 10 periodic

crypto ipsec transform-set DMVPN_TSet esp-aes esp-sha-hmac 

crypto ipsec profile DMVPN

 set security-association lifetime seconds 120

 set transform-set DMVPN_TSet 

interface Tunnel0

 description Tunnel to dmvpnhub1

 bandwidth 8192

 ip address 172.31.220.5 255.255.255.0

 no ip redirects

 ip mtu 1400

 ip nhrp authentication xxxxxxx

 ip nhrp map multicast 204.75.81.65

 ip nhrp map 172.31.220.1 204.75.81.65

 ip nhrp network-id 1

 ip nhrp holdtime 600

 ip nhrp nhs 172.31.220.1

 ip tcp adjust-mss 1360

 qos pre-classify

 keepalive 10 3

 tunnel source Dialer1

 tunnel mode gre multipoint

 tunnel key 0

 tunnel protection ipsec profile DMVPN shared

ip route 204.75.81.65 255.255.255.255 Dialer1

Now, when I apply the following config to make the dmvpn use a front door vrf, the tunnel breaks and won't come up.

ip vrf dmvpnvrf

 rd 1:1

crypto keyring dmvpnkeyring vrf dmvpnvrf

  pre-shared-key address 0.0.0.0 0.0.0.0 key xxxxxx

ip route vrf dmvpnvrf 0.0.0.0 0.0.0.0 di1

int di1

ip vrf forwarding dmvpnvrf

ip address negotiated

int tun0

tunnel vrf dmvpnvrf

int tun1

tunnel vrf dmvpnvrf

If I shut all interfaces down, clear the crypto and dmvpn sessions, then bring it all up, i get some debugs showing the crypto goes to QM_IDLE (indicating it works), and then goes down again. I will provide these debugs below. Please note that there are some NAT-T messages in the debug, but my router ain't using NAT so I don't know why I've getting NAT-T in the debugs.

06650r2#

06650r2#

06650r2#

Apr 16 07:07:44.633 GMT: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...

Apr 16 07:07:44.633 GMT: ISAKMP (0): incrementing error counter on sa, attempt 5 of 5: retransmit phase 1

Apr 16 07:07:44.633 GMT: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE

Apr 16 07:07:44.633 GMT: ISAKMP:(0): sending packet to 204.75.81.65 my_port 500 peer_port 500 (I) MM_NO_STATE

Apr 16 07:07:44.633 GMT: ISAKMP:(0):Sending an IKE IPv4 Packet.

06650r2#

Apr 16 07:07:46.689 GMT: ISAKMP:(0): retransmitting phase 1 MM_SA_SETUP...

Apr 16 07:07:46.689 GMT: ISAKMP (0): incrementing error counter on sa, attempt 5 of 5: retransmit phase 1

Apr 16 07:07:46.689 GMT: ISAKMP:(0): retransmitting phase 1 MM_SA_SETUP

Apr 16 07:07:46.689 GMT: ISAKMP:(0): sending packet to 195.143.92.34 my_port 500 peer_port 500 (R) MM_SA_SETUP

Apr 16 07:07:46.689 GMT: ISAKMP:(0):Sending an IKE IPv4 Packet.

Apr 16 07:07:48.076 GMT: ISAKMP:(0): retransmitting phase 1 MM_SA_SETUP...

Apr 16 07:07:48.076 GMT: ISAKMP (0): incrementing error counter on sa, attempt 5 of 5: retransmit phase 1

Apr 16 07:07:48.076 GMT: ISAKMP:(0): retransmitting phase 1 MM_SA_SETUP

Apr 16 07:07:48.076 GMT: ISAKMP:(0): sending packet to 195.81.160.82 my_port 500 peer_port 500 (R) MM_SA_SETUP

Apr 16 07:07:48.076 GMT: ISAKMP:(0):Sending an IKE IPv4 Packet.

Apr 16 07:07:48.112 GMT: ISAKMP:(0): retransmitting phase 1 MM_SA_SETUP...

Apr 16 07:07:48.112 GMT: ISAKMP (0): incrementing error counter on sa, attempt 5 of 5: retransmit phase 1

Apr 16 07:07:48.112 GMT: ISAKMP:(0): retransmitting phase 1 MM_SA_SETUP

Apr 16 07:07:48.112 GMT: ISAKMP:(0): sending packet to 213.39.51.226 my_port 500 peer_port 500 (R) MM_SA_SETUP

Apr 16 07:07:48.112 GMT: ISAKMP:(0):Sending an IKE IPv4 Packet.

Apr 16 07:07:48.120 GMT: ISAKMP (0): received packet from 213.39.51.226 dport 500 sport 500 dmvpnvrf (N) NEW SA

Apr 16 07:07:48.120 GMT: ISAKMP: Created a peer struct for 213.39.51.226, peer port 500

Apr 16 07:07:48.120 GMT: ISAKMP: New peer created peer = 0x662FC558 peer_handle = 0x80000019

Apr 16 07:07:48.120 GMT: ISAKMP: Locking peer struct 0x662FC558, refcount 1 for crypto_isakmp_process_block

Apr 16 07:07:48.120 GMT: ISAKMP: local port 500, remote port 500

Apr 16 07:07:48.120 GMT: ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 668F896C

Apr 16 07:07:48.120 GMT: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

Apr 16 07:07:48.120 GMT: ISAKMP:(0):Old State = IKE_READY  New State = IKE_R_MM1 

Apr 16 07:07:48.120 GMT: ISAKMP:(0): processing SA payload. message ID = 0

Apr 16 07:07:48.124 GMT: ISAKMP:(0): processing vendor id payload

Apr 16 07:07:48.124 GMT: ISAKMP:(0): vendor ID seems Unit

06650r2#y/DPD but major 69 mismatch

Apr 16 07:07:48.124 GMT: ISAKMP (0): vendor ID is NAT-T RFC 3947

Apr 16 07:07:48.124 GMT: ISAKMP:(0): processing vendor id payload

Apr 16 07:07:48.124 GMT: ISAKMP:(0): vendor ID seems Unity/DPD but major 245 mismatch

Apr 16 07:07:48.124 GMT: ISAKMP (0): vendor ID is NAT-T v7

Apr 16 07:07:48.124 GMT: ISAKMP:(0): processing vendor id payload

Apr 16 07:07:48.124 GMT: ISAKMP:(0): vendor ID seems Unity/DPD but major 157 mismatch

Apr 16 07:07:48.124 GMT: ISAKMP:(0): vendor ID is NAT-T v3

Apr 16 07:07:48.124 GMT: ISAKMP:(0): processing vendor id payload

Apr 16 07:07:48.124 GMT: ISAKMP:(0): vendor ID seems Unity/DPD but major 123 mismatch

Apr 16 07:07:48.124 GMT: ISAKMP:(0): vendor ID is NAT-T v2

Apr 16 07:07:48.124 GMT: ISAKMP:(0):found peer pre-shared key matching 213.39.51.226

Apr 16 07:07:48.124 GMT: ISAKMP:(0): local preshared key found

Apr 16 07:07:48.124 GMT: ISAKMP : Scanning profiles for xauth ...

Apr 16 07:07:48.124 GMT: ISAKMP:(0):Checking ISAKMP transform 1 against priority 1 policy

Apr 16 07:07:48.124 GMT: ISAKMP:      encryption AES-CBC

Apr 16 07:07:48.124 GMT: ISAKMP:      keylength of 256

Apr 16 07:07:48.124 GMT: ISAKMP:      hash SHA

Apr 16 07:07:48.124 GMT: ISAKMP:      default group 2

Apr 16 07:07:48.124 GMT: ISAKMP:      auth pre-share

Apr 16 07:07:48.124 GMT: ISAKMP:      life type in seconds

Apr 16 07:07:48.124 GMT: ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80 

Apr 16 07:07:48.124 GMT: ISAKMP:(0):atts are acceptable. Next payload is 0

Apr 16 07:07:48.124 GMT: ISAKMP:(0):Acceptable atts:actual life: 0

Apr 16 07:07:48.124 GMT: ISAKMP:(0):Acceptable atts:life: 0

Apr 16 07:07:48.124 GMT: ISAKMP:(0):Fill atts in sa vpi_length:4

Apr 16 07:07:48.124 GMT: ISAKMP:(0):Fill atts in sa life_in_seconds:86400

Apr 16 07:07:48.124 GMT: ISAKMP:(0):Returning Actual lifetime: 86400

Apr 16 07:07:48.124 GMT: ISAKMP:(0)::Started lifetime timer: 86400.

Apr 16 07:07:48.128 GMT: ISAKMP:(0): processing vendor id payload

Apr 16 07:07:48.128 GMT: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch

Apr 16 07:07:48.128 GMT: ISAKMP (0): vendor ID is NAT-T RFC 3947

Apr 16 07:07:48.128 GMT: ISAKMP:(0): processing vendor id payload

Apr 16 07:07:48.128 GMT: ISAKMP:(0): vendor ID seems Unity/DPD but major 245 mismatch

Apr 16 07:07:48.128 GMT: ISAKMP (0): vendor ID is NAT-T v7

Apr 16 07:07:48.128 GMT: ISAKMP:(0): processing vendor id payload

Apr 16 07:07:48.128 GMT: ISAKMP:(0): vendor ID seems Unity/DPD but major 157 mismatch

Apr 16 07:07:48.128 GMT: ISAKMP:(0): vendor ID is NAT-T v3

Apr 16 07:07:48.128 GMT: ISAKMP:(0): processing vendor id payload

Apr 16 07:07:48.128 GMT: ISAKMP:(0): vendor ID seems Unity/DPD but major 123 mismatch

Apr 16 07:07:48.128 GMT: ISAKMP:(0): vendor ID is NAT-T v2

Apr 16 07:07:48.128 GMT: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE

Apr 16 07:07:48.128 GMT: ISAKMP:(0):Old State = IKE_R_MM1  New State = IKE_R_MM1 

Apr 16 07:07:48.128 GMT: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID

Apr 16 07:07:48.128 GMT: ISAKMP:(0): sending packet to 213.39.51.226 my_port 500 peer_port 500 (R) MM_SA_SETUP

Apr 16 07:07:48.128 GMT: ISAKMP:(0):Sending an IKE IPv4 Packet.

Apr 16 07:07:48.128 GMT: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE

Apr 16 07:07:48.132 GMT: ISAKMP:(0):Old State =

06650r2# IKE_R_MM1  New State = IKE_R_MM2 

06650r2#

Apr 16 07:07:50.736 GMT: ISAKMP (0): received packet from 213.39.109.98 dport 500 sport 500 dmvpnvrf (R) MM_SA_SETUP

Apr 16 07:07:50.736 GMT: ISAKMP:(0): phase 1 packet is a duplicate of a previous packet.

Apr 16 07:07:50.736 GMT: ISAKMP:(0): retransmitting due to retransmit phase 1

Apr 16 07:07:51.236 GMT: ISAKMP:(0): retransmitting phase 1 MM_SA_SETUP...

Apr 16 07:07:51.236 GMT: ISAKMP (0): incrementing error counter on sa, attempt 3 of 5: retransmit phase 1

Apr 16 07:07:51.236 GMT: ISAKMP:(0): retransmitting phase 1 MM_SA_SETUP

Apr 16 07:07:51.236 GMT: ISAKMP:(0): sending packet to 213.39.109.98 my_port 500 peer_port 500 (R) MM_SA_SETUP

06650r2#

Apr 16 07:07:51.236 GMT: ISAKMP:(0):Sending an IKE IPv4 Packet.

06650r2#

Apr 16 07:07:54.632 GMT: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...

Apr 16 07:07:54.632 GMT: ISAKMP:(0):peer does not do paranoid keepalives.

Apr 16 07:07:54.632 GMT: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (I) MM_NO_STATE (peer 204.75.81.65)

Apr 16 07:07:54.632 GMT: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (I) MM_NO_STATE (peer 204.75.81.65) 

Apr 16 07:07:54.632 GMT: ISAKMP: Unlocking peer struct 0x668EE114 for isadb_mark_sa_deleted(), count 0

Apr 16 07:07:54.632 GMT: ISAKMP: Deleting peer node by peer_reap for 204.75.81.65: 668EE114

Apr 16 07:07:54.632 GMT: ISAKMP:(0):deleting node 1202920501 error FALSE reason "IKE deleted"

Apr 16 07:07:54.632 GMT: ISAKMP:(0):deleting node -2119501275 error FALSE reason "IKE deleted"

Apr 16 07:07:54.632 GMT: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL

Apr 16 07:07:54.632 GMT: ISAKMP:(0):Old State = IKE_I_MM1  New State = IKE_DEST_SA 

Apr 16 07:07:54.936 GMT: ISAKMP:(0): SA request profile is (NULL)

Apr 16 07:07:54.936 GMT: ISAKMP: Created a peer struct for 204.75.81.65, peer port 500

Apr 16 07:07:54.936 GMT: ISAKMP: New peer created peer = 0x668EE114 peer_handle = 0x8000001E

Apr 16 07:07:54.936 GMT: ISAKMP: Locking peer struct 0x668EE114, refcount 1 for isakmp_initiator

Apr 16 07:07:54.936 GMT: ISAKMP: local port 500, remote port 500

Apr 16 07:07:54.936 GMT: ISAKMP: set new node 0 to QM_IDLE      

Apr 16 07:07:54.936 GMT: ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 665F5600

Apr 16 07:07:54.936 GMT: ISAKMP:(0):Can not start Aggressive mode, trying Main mode.

Apr 16 07:07:54.936 GMT: ISAKMP:(0):found peer pre-shared key matching 204.75.81.65

Apr 16 07:07:54.936 GMT: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID

Apr 16 07:07:54.940 GMT: ISAKMP:(0): constructed NAT-T vendor-07 ID

06650r2#

Apr 16 07:07:54.940 GMT: ISAKMP:(0): constructed NAT-T vendor-03 ID

Apr 16 07:07:54.940 GMT: ISAKMP:(0): constructed NAT-T vendor-02 ID

Apr 16 07:07:54.940 GMT: ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM

Apr 16 07:07:54.940 GMT: ISAKMP:(0):Old State = IKE_READY  New State = IKE_I_MM1 

Apr 16 07:07:54.940 GMT: ISAKMP:(0): beginning Main Mode exchange

Apr 16 07:07:54.940 GMT: ISAKMP:(0): sending packet to 204.75.81.65 my_port 500 peer_port 500 (I) MM_NO_STATE

Apr 16 07:07:54.940 GMT: ISAKMP:(0):Sending an IKE IPv4 Packet.

06650r2#

Apr 16 07:07:56.688 GMT: ISAKMP:(0): retransmitting phase 1 MM_SA_SETUP...

Apr 16 07:07:56.688 GMT: ISAKMP:(0):peer does not do paranoid keepalives.

Apr 16 07:07:56.688 GMT: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (R) MM_SA_SETUP (peer 195.143.92.34)

Apr 16 07:07:56.688 GMT: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (R) MM_SA_SETUP (peer 195.143.92.34) 

Apr 16 07:07:56.688 GMT: ISAKMP: Unlocking peer struct 0x661043E0 for isadb_mark_sa_deleted(), count 0

Apr 16 07:07:56.688 GMT: ISAKMP: Deleting peer node by peer_reap for 195.143.92.34: 661043E0

Apr 16 07:07:56.688 GMT: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL

06650r2#

Apr 16 07:07:56.688 GMT: ISAKMP:(0):Old State = IKE_R_MM2  New State = IKE_DEST_SA 

Apr 16 07:07:58.076 GMT: ISAKMP:(0): retransmitting phase 1 MM_SA_SETUP...

Apr 16 07:07:58.076 GMT: ISAKMP:(0):peer does not do paranoid keepalives.

Apr 16 07:07:58.076 GMT: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (R) MM_SA_SETUP (peer 195.81.160.82)

Apr 16 07:07:58.076 GMT: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (R) MM_SA_SETUP (peer 195.81.160.82) 

Apr 16 07:07:58.076 GMT: ISAKMP: Unlocking peer struct 0x66577DF0 for isadb_mark_sa_deleted(), count 0

Apr 16 07:07:58.076 GMT: ISAKMP: Deleting peer node by peer_reap for 195.81.160.82: 66577DF0

Apr 16 07:07:58.076 GMT: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL

Apr 16 07:07:58.076 GMT: ISAKMP:(0):Old State = IKE_R_MM2  New State = IKE_DEST_SA 

Apr 16 07:07:58.112 GMT: ISAKMP:(0): retransmitting phase 1 MM_SA_SETUP...

Apr 16 07:07:58.112 GMT: ISAKMP:(0):peer does not do paranoid keepalives.

Apr 16 07:07:58.112 GMT: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (R) MM_SA_SETUP (peer 213.39.51.226)

Apr 16 07:07:58.112 GMT: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (R) MM_SA_SETUP (peer 213.39.51.226) 

Apr 16 07:07:58.112 GMT: ISAKMP: Unlocking peer struct 0x6661AD08 for isadb_mark_sa_deleted(), count 0

06650r2#

Apr 16 07:07:58.112 GMT: ISAKMP: Deleting peer node by peer_reap for 213.39.51.226: 6661AD08

Apr 16 07:07:58.112 GMT: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL

Apr 16 07:07:58.112 GMT: ISAKMP:(0):Old State = IKE_R_MM2  New State = IKE_DEST_SA 

Apr 16 07:07:58.120 GMT: ISAKMP (0): received packet from 213.39.51.226 dport 500 sport 500 dmvpnvrf (R) MM_SA_SETUP

Apr 16 07:07:58.120 GMT: ISAKMP:(0): phase 1 packet is a duplicate of a previous packet.

Apr 16 07:07:58.120 GMT: ISAKMP:(0): retransmitting due to retransmit phase 1

Apr 16 07:07:58.620 GMT: ISAKMP:(0): retransmitting phase 1 MM_SA_SETUP...

06650r2#

Apr 16 07:07:58.620 GMT: ISAKMP (0): incrementing error counter on sa, attempt 1 of 5: retransmit phase 1

Apr 16 07:07:58.620 GMT: ISAKMP:(0): retransmitting phase 1 MM_SA_SETUP

Apr 16 07:07:58.620 GMT: ISAKMP:(0): sending packet to 213.39.51.226 my_port 500 peer_port 500 (R) MM_SA_SETUP

Apr 16 07:07:58.620 GMT: ISAKMP:(0):Sending an IKE IPv4 Packet.

06650r2#

Apr 16 07:08:00.736 GMT: ISAKMP (0): received packet from 213.39.109.98 dport 500 sport 500 dmvpnvrf (R) MM_SA_SETUP

Apr 16 07:08:00.736 GMT: ISAKMP:(0): phase 1 packet is a duplicate of a previous packet.

Apr 16 07:08:00.740 GMT: ISAKMP:(0): retransmitting due to retransmit phase 1

Apr 16 07:08:01.240 GMT: ISAKMP:(0): retransmitting phase 1 MM_SA_SETUP...

Apr 16 07:08:01.240 GMT: ISAKMP (0): incrementing error counter on sa, attempt 4 of 5: retransmit phase 1

Apr 16 07:08:01.240 GMT: ISAKMP:(0): retransmitting phase 1 MM_SA_SETUP

Apr 16 07:08:01.240 GMT: ISAKMP:(0): sending packet to 213.39.109.98 my_port 500 peer_port 500 (R) MM_SA_SETUP

06650r2#

Apr 16 07:08:01.240 GMT: ISAKMP:(0):Sending an IKE IPv4 Packet.

06650r2#

Apr 16 07:08:04.939 GMT: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...

Apr 16 07:08:04.939 GMT: ISAKMP (0): incrementing error counter on sa, attempt 1 of 5: retransmit phase 1

Apr 16 07:08:04.939 GMT: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE

Apr 16 07:08:04.939 GMT: ISAKMP:(0): sending packet to 204.75.81.65 my_port 500 peer_port 500 (I) MM_NO_STATE

Apr 16 07:08:04.939 GMT: ISAKMP:(0):Sending an IKE IPv4 Packet.

06650r2#

Apr 16 07:08:08.075 GMT: ISAKMP (0): received packet from 195.81.160.82 dport 500 sport 500 dmvpnvrf (N) NEW SA

Apr 16 07:08:08.075 GMT: ISAKMP: Created a peer struct for 195.81.160.82, peer port 500

Apr 16 07:08:08.075 GMT: ISAKMP: New peer created peer = 0x661043E0 peer_handle = 0x80000013

Apr 16 07:08:08.075 GMT: ISAKMP: Locking peer struct 0x661043E0, refcount 1 for crypto_isakmp_process_block

Apr 16 07:08:08.075 GMT: ISAKMP: local port 500, remote port 500

Apr 16 07:08:08.075 GMT: ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 6501348C

Apr 16 07:08:08.075 GMT: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

Apr 16 07:08:08.075 GMT: ISAKMP:(0):Old State = IKE_READY  New State = IKE_R_MM1 

Apr 16 07:08:08.079 GMT: ISAKMP:(0): processing SA payload. message ID = 0

Apr 16 07:08:08.079 GMT: ISAKMP:(0): processing vendor id payload

Apr 16 07:08:08.079 GMT: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch

Apr 16 07:08:08.079 GMT: ISAKMP (0): vendor ID is NAT-T RFC 3947

Apr 16 07:08:08.079 GMT: ISAKMP:(0): processing vendor id payload

Apr 16 07:08:08.079 GMT: ISAKMP:(0): vendor ID seems Unity/DPD but major 245 mismatch

Apr 16 07:08:08.079 GMT: ISAKMP (0): vendor ID is NAT-T v7

Apr 16 07:08:08.079 GMT: ISAKMP:(0): processing vendor id payload

Apr 16 07:08:08.079 GMT: ISAKMP:(0): vendor ID seems Unity/DPD but major 157 mismatch

Apr 16 07:08:08.079 GMT: ISAKMP:(0): vendor ID is NAT-T v3

Apr 16 07:08:08.079 GMT: ISAKMP:(0): processing vendor id payload

Apr 16 07:08:08.079 GMT: ISAKMP:(0): vendor ID seems Unity/DPD but major 123 mismatch

Apr 16 07:08:08.079 GMT: ISAKMP:(0): vendor ID is NAT-T v2

Apr 16 07:08:08.079 GMT: ISAKMP:(0):found peer pre-shared key matching 195.81.160.82

Apr 16 07:08:08.079 GMT: ISAKMP:(0): local preshared key found

Apr 16 07:08:08.079 GMT: ISAKMP : Scanning profiles for xauth ...

Apr 16 07:08:08.079 GMT: ISAKMP:(0):Checking ISAKMP transform 1 against priority 1 policy

Apr 16 07:08:08.079 GMT: ISAKMP:      encryption AES-CBC

Apr 16 07:08:08.079 GMT: ISAKMP:      keylength of 256

Apr 16 07:08:08.079 GMT: ISAKMP:      hash SHA

Apr 16 07:08:08.079 GMT: ISAKMP:      default group 2

Apr 16 07:08:08.079 GMT: ISAKMP:      auth pre-share

Apr 16 07:08:08.079 GMT: ISAKMP:      life type in seconds

Apr 16 07:08:08.079 GMT: ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80 

Apr 16 07:08:08.079 GMT: ISAKMP:(0):atts are acceptable. Next payload is 0

Apr 16 07:08:08.079 GMT: ISAKMP:(0):Acceptable atts:actual life: 0

Apr 16 07:08:08.079 GMT: ISAKMP:(0):Acceptable atts:life: 0

Apr 16 07:08:08.079 GMT: ISAKMP:(0):Fill atts in sa vpi_length:4

Apr 16 07:08:08.079 GMT: ISAKMP:(0):Fill atts in sa life_in_seconds:86400

Apr 16 07:08:08.079 GMT: ISAKMP:(0):Returning Actual li

06650r2#fetime: 86400

Apr 16 07:08:08.083 GMT: ISAKMP:(0)::Started lifetime timer: 86400.

Apr 16 07:08:08.083 GMT: ISAKMP:(0): processing vendor id payload

Apr 16 07:08:08.083 GMT: ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch

Apr 16 07:08:08.083 GMT: ISAKMP (0): vendor ID is NAT-T RFC 3947

Apr 16 07:08:08.083 GMT: ISAKMP:(0): processing vendor id payload

Apr 16 07:08:08.083 GMT: ISAKMP:(0): vendor ID seems Unity/DPD but major 245 mismatch

Apr 16 07:08:08.083 GMT: ISAKMP (0): vendor ID is NAT-T v7

Apr 16 07:08:08.083 GMT: ISAKMP:(0): processing vendor id payload

Apr 16 07:08:08.083 GMT: ISAKMP:(0): vendor ID seems Unity/DPD but major 157 mismatch

Apr 16 07:08:08.083 GMT: ISAKMP:(0): vendor ID is NAT-T v3

Apr 16 07:08:08.083 GMT: ISAKMP:(0): processing vendor id payload

Apr 16 07:08:08.083 GMT: ISAKMP:(0): vendor ID seems Unity/DPD but major 123 mismatch

Apr 16 07:08:08.083 GMT: ISAKMP:(0): vendor ID is NAT-T v2

Apr 16 07:08:08.083 GMT: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE

Apr 16 07:08:08.083 GMT: ISAKMP:(0):Old State = IKE_R_MM1  New State = IKE_R_MM1 

Apr 16 07:08:08.083 GMT: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID

Apr 16 07:08:08.083 GMT: ISAKMP:(0): sending packet to 195.81.160.82 my_port 500 peer_port 500 (R) MM_SA_SETUP

Apr 16 07:08:08.083 GMT: ISAKMP:(0):Sending an IKE IPv4 Packet.

Apr 16 07:08:08.087 GMT: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE

Apr 16 07:08:08.087 GMT: ISAKMP:(0):Old State = IKE_R_MM1  New State = IKE_R_MM2 

Apr 16 07:08:08.123 GMT: ISAKMP (0): received packet from 213.39.51.226 dport 500 sport 500 dmvpnvrf (R) MM_SA_SETUP

Apr 16 07:08:08.123 GMT: ISAKMP:(0): phase 1 packet is a duplicate of a previous packet.

Apr 16 07:08:08.123 GMT: ISAKMP:(0): retransmitting due to retransmit phase 1

06650r2#

Apr 16 07:08:08.623 GMT: ISAKMP:(0): retransmitting phase 1 MM_SA_SETUP...

Apr 16 07:08:08.623 GMT: ISAKMP (0): incrementing error counter on sa, attempt 2 of 5: retransmit phase 1

Apr 16 07:08:08.623 GMT: ISAKMP:(0): retransmitting phase 1 MM_SA_SETUP

Apr 16 07:08:08.623 GMT: ISAKMP:(0): sending packet to 213.39.51.226 my_port 500 peer_port 500 (R) MM_SA_SETUP

Apr 16 07:08:08.623 GMT: ISAKMP:(0):Sending an IKE IPv4 Packet.

06650r2#

Apr 16 07:08:10.739 GMT: ISAKMP (0): received packet from 213.39.109.98 dport 500 sport 500 dmvpnvrf (R) MM_SA_SETUP

Apr 16 07:08:10.739 GMT: ISAKMP:(0): phase 1 packet is a duplicate of a previous packet.

Apr 16 07:08:10.739 GMT: ISAKMP:(0): retransmitting due to retransmit phase 1

Apr 16 07:08:11.239 GMT: ISAKMP:(0): retransmitting phase 1 MM_SA_SETUP...

Apr 16 07:08:11.239 GMT: ISAKMP (0): incrementing error counter on sa, attempt 5 of 5: retransmit phase 1

Apr 16 07:08:11.239 GMT: ISAKMP:(0): retransmitting phase 1 MM_SA_SETUP

Apr 16 07:08:11.239 GMT: ISAKMP:(0): sending packet to 213.39.109.98 my_port 500 peer_port 500 (R) MM_SA_SETUP

06650r2#

Apr 16 07:08:11.239 GMT: ISAKMP:(0):Sending an IKE IPv4 Packet.

I'm working on ASA NAT. I have ASA connected to 3 different devices by internal, dmz and outside interfaces. I want to configure ASA so if a router resides in the outside connects to ASA's external port with destination port 4444, ASA forwards it to internal router with destination port 23. my config is as follows:

nat (dmz,outside) source static R4_ETHERNET interface service R4_TELNET_23 TELNET_R4_PUBLIC

!

object network R4_ETHERNET

 host 14.14.14.4

object network R1_ETHERNET

 host 1.1.1.11 ------> IP address of R1

object service R4_TELNET_23

 service tcp source eq telnet 

object service TELNET_R4_PUBLIC

 service tcp source eq 4444 

ciscoasa(config)# sh inter ip br

Interface                  IP-Address      

GigabitEthernet0           1.1.1.254

GigabitEthernet1           12.12.12.254

GigabitEthernet2           14.14.14.254

but there is no hit on the NAT rule. any idea?

A little question about duplicate router-id, 

suppose that instead of using 2 areas, Area67 and Area79, we have only area0, but we hardcore assigned R6 with a router-id of 0.0.0.9, 

and did the same for R9, i.e. a router-id of 0.0.0.9 the same as for R6.

Since we are using a duplicate router-ids on R6, and R9,

how does none check that there is a dublicate router id in the same area0, in this case, 

say, using debugs.  

Hi guys,

I'm having a doubt when it comes to filtering using route-maps.  I have the tendency to configure the deny/permit statements at the

acl or prefix level instead of the route-maps.  I always get the result I want, but in terms of the LAB exam, should that be valid ?

I ask because technically (I think), the acl/prefix do the filtering. Don't know If im explaining this correctly . . .  It's like I'm using a route-map indeed, but not filtering with them (explicitly).

An example:  W.Book Task BGP Aggregation - Suppress-map. 

INE SOLUTION:

ip prefix-list NET_2 permit 10.0.2.0/24
!
route-map SUPPRESS_MAP deny 10  << -----------------
match ip address prefix-list NET_2
!
route-map SUPPRESS_MAP permit 100
!
router bgp 200
aggregate-address 10.0.0.0 255.255.252.0 suppress-map SUPPRESS_MAP

MINE:
ip prefix-list SUPPRESS_LIST seq 5 deny 10.0.2.0/24  <<---------------
ip prefix-list SUPPRESS_LIST seq 10 permit 0.0.0.0/0 le 32
!
route-map SUPPRESS_MAP permit 10
 match ip address prefix-list SUPRESS_LIST
!        
 aggregate-address 10.0.0.0 255.255.252.0 suppress-map SUPPRESS_MAP

HELLO ALL,

         I am writing this to check my logic and to ensure that I have everything straight in my mind. I have just wrote up a little review. Please give me feedback so that I can fill any gaps in my knowledge.

Respectfully,

AntRal

EIGRP CLASSIC vs. NAMED (Authentication and Converting) 

The Basic behavior of EIGRP 

EIGRP uses Diffusing Update Algorithm (DUAL) to calculate and provide “loop-free” 

paths throughout the network allowing multiple routes to sync at the same time. Before any 

route in EIGRP can be added to the routing table it must meet the feasibility condition. The 

feasibility condition basically demands that the reported distance of a route must be less than 

the feasible distance before it is considered a loop-free path. The best path to a destination is 

installed into the routing table and selected as the next hop is called the successor, while the 

next best route that meets the feasibility condition is then installed as a feasible successor. The 

feasible successor makes it possible for EIGRP to recover from losing the successor quicker and 

without having to converge. 

EIGRP is a distance vector routing protocol that just advertises what it is directly 

connected to, this is sometimes referred to as “routing by rumor”. The benefit of this is that the 

network topology can be more forgiving than that of the link state routing protocols, making it 

possible to summarize at desire of the administrator and not on an area border router as in 

OSPF.  

EIGRP Packets

  Hello/Ack-   Has to be sent by both routers to establish and keep a neighbor adjacent with 

each other. They are sent to multicast address 224.0.0.10 in IPv4 and FF02::A in IPv6.

  Update- Once an adjacency has been created the routers send each other update packets. 

These are used to send the full table of known routes to the newly formed neighbor. These 

packets are also sent multicast. 

Query-   This packet is used to ask routers for a path for a destination, it also triggers all routers 

to converge. The response does not have to contain the exact same response of the request. 

This is where summarization can come in handy to limit the range of the query domain; this is 

also referred to as query scoping. Query scoping will help to prevent stuck in active in EIGRP 

domains that have grown to large. 

 Reply- Sent as a response to a query. 

Metrics Classic and Wide

   While there is a complex formula for both metrics all that needs to be remembered in this is 

that the classic metric is 32 bits with a multiplier of 256 only using the bandwidth and the delay 

( in milliseconds) by default. The wide metric has changed a few things from the classic first it 

has two scales that it uses as multipliers. When calculating the metric it multiplies by the wide 

scale which is 65536; this turns the metric into 64 bits. This large of a metric can make EIGRP 

more granular when picking the best routes. Once it has established the best route it will then 

divide it by the RIB-Scale before inserting it   into the RIB. 

Authentication in Classic EIGRP

   Classic EIGRP only supports clear text and MD5 authentication using key chains that are 

applied to the interfaces. The configurations are bulky and counter intuitive. (Note: the key 

string does count blank spaces as charters) 

Example –

Router1

!

Key Chain TEST 

Key 1

 Key-string CISCO

 Accept-life   00:05:00 Jan 1 2015 00:15:00 Jan 2 2016 

Send-life   00:05:00 Jan 1 2015 00:15:00 Jan 2 2016

Key 2 

Key-string CCIE

 Accept-life   00:05:00 Jan 1 2016 infinite

Send-life   00:05:00 Jan 1 2015 infinite 

!

Interface f0/0

IP authentication mode eigrp 100 MD5/TEXT 

IP authentication key-chain eigrp 100 TEST 

!

As you can see you need to have a little overlap time when you are configuring multiple keys to 

ensure that there is no re-convergence needed in the network. In addition to this it is a good 

idea to use network time protocol (NTP) to sync times on the neighbors. 

 Authentication in Named EIGRP

          Named EIGRP can support MD5 clear text and SHA-256 authentication. MD5 and clear 

text are both use key chains, while SHA-256 is done completely inside of the EIGRP process. 

Example –

Router2

!

Key Chain TEST 

Key 1

 Key-string CISCO

 Accept-life   00:05:00 Jan 1 2015 infinite  

Send-life   00:05:00 Jan 1 2015  infinite 

!

Router EIGRP TEST

address-family IPv4 unicast autonomous-system 100

af-interface f0/0

authentication mode MD5

authentication key-chain TEST 

!

Af-interface default 

Authentication mode hmac-sha-256 CCIE

!

 As you can see the configurations for authentication in EIGRP named mode are much simpler 

and more logical. What happened in this example is that we tide the key chain with MD5 to 

interface f0/0 while we set all of the other interfaces to use SHA by default. The MD5 is 

backwards compatible with classic EIGRP. (Note: in named mode you cannot apply the 

authentication through the interface its self.) 

Classic to named Upgrade 

   You can upgrade classic EIGRP to named mode without flapping neighbor 

adjacencies through the use of the “eigrp upgrade-cli” command. You have to 

implement this per autonomous system number.

Example-

Router eigrp 100

Network 210.1.1.0 

Eigrp upgrade-cli TEST

It looks like cisco change the loopback address of ntp internal master server from 127.127.7.1 to 127.127.1.1

I think I finally figured out why cisco changed that IP address to 127.127.1.1.

For the version of IOS that I am running with 127.127.1.1 I didn't have to add the internal loopback address to that access-group, but for IOS versions that had 127.127.7.1 IP address I had to include that loopback address in the access group or else the local time sync would not work.. Here is are my configs and outputs:

.. new IOS version without allowing the loopback address:

Rack1R4#sh run | i ntp
ntp access-group peer 1
ntp master 5
ntp peer 150.1.6.6

Rack1R4#sh ip access-lists 1
Standard IP access list 1
    20 permit 150.1.6.6 (68 matches)

Rack1R4#sh ntp associations

  address         ref clock       st   when   poll reach  delay  offset   disp
*~127.127.1.1     .LOCL.           4      7     16   377  0.000   0.000  0.241
 ~150.1.6.6       127.127.1.1      5     22     64   377  0.000  -4.211  5.791
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
Rack1R4#sh ver | i Ver

ROM: System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1)




.....now for the old version

BB2#sh run | i ntp
 ntp master 4
 ntp access-group peer 1

BB2#sh ip access-lists
Standard IP access list 1
    10 permit 4.4.4.4

 
BB2#sh ntp associations

      address         ref clock     st  when  poll reach  delay  offset    disp
 ~127.127.7.1      127.127.7.1       3   972    64    0     0.0    0.00  16000.
 * master (synced), # master (unsynced), + selected, - candidate, ~ configured


BB2#sh ver | i Ver
Cisco IOS Software, 2800 Software (C2800NM-ADVENTERPRISEK9-M), Version 12.4(15)T, RELEASE SOFTWARE (fc3)


.....as you can see the difference in version, in loopback addresses and whether the acl with loopback on the master is needed.

Hope that clears things out for people in the future, cause it took me few hours to get this.

Regards,

Tom Kacprzynski

I'm currently studying for v5 Routing and Switching and wanted to see if there was any interest out there in a Study Group in the San Diego / SoCal area.  I feel meeting in person is best, but nowdays with Skype and Webex, really only the time zone (Pacific US) is important.

I've taken the RS v4 Lab twice and I'm going for the v5 late summer / early fall.  I have to take the v5 written again to re-qualify (I took a break).

What I hope to get from study partners is:

Ability to socialize about the CCIE - most wives aren't interested in hearing about OSPF LSA types. :)

Comparing study strategies

Opportunity to see other angles and ideas about the topics

And other similar benefits.

If this is something that seems like a good fit, please reply here or feel free to PM me.

thanks in advance for any interest!

Hi, all,

I still don't understand clearly DH group and Perfect Forward Secrecy (PFS)

Refering to this video: https://www.youtube.com/watch?v=M-0qt6tdHzk

g is the base and p is the prime number for mod

I understand that both Alice and Bob must agree on the g and p first before they can create a shared secret, and this shared secret is called the master key.

1) My first question is, when we configure diffie-hellman group with the "group" command,  what are we doing?  Are we choosing the p?  or are we choosing both g and p? 

(*The command can be found here: http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_ikevpn/configuration/15-2mt/sec-key-exch-ipsec.html)

2) Assuming that we are choosing both g and p with the "group" command,  is it always the same number for p?  From this link: https://tools.ietf.org/html/rfc3526  ,  you can see that it says THE prime (p) and THE generator (g).   So I guess if we put "group 5" on a Cisco device,  we are choosing the 1536-bit group, and whenever we put "group 5", the p and g are always the same two numbers?

3) Referring to this video: https://www.youtube.com/watch?v=M-0qt6tdHzk

The master key is ((g^a)^b) mod p,  where a is the secret from Alice and b is the secret from Bob.

Now, I heard that this master key can generate many session keys and these session keys are used for real encryption/decription (for the IPSEC SA)

Does anyone have any information about how this master key can generate many session keys?  This master key is just a number.  What is the way of generate many keys from this number?

5) This question is regarding Perfect Forward Secrecy.

If we enable PFS, what does it mean?  Does it mean that Bob and Alice will re-pick the numbers a,b,g and p,  run the DH exchange again, and calculate a new master key?  Then using the new master key to generate a new session key?  (For g and p is fixed,  does it mean that when we enable PFS,  Bob and Alice will re-pick just a and b, run the DH exchange again and calculate a new master key and then a new session key?)

6) I read many documents mentioning the "keying materials".  Does it mean the number a, b, g and p?

I am sorry for so many questions.  But I am so confused.  Wondering whether we should understand all these just to be a Network Security Engineer, and wondering how many Network Security Engineer really knows these.  Thanks in advance.

Hi, 

I have my DC lab sheduled in Brussels on the 25th of Spetember 2015. I just found out that INE have a boot camp in London 9th - 20th of Novemeber.

What would really like to do is to do the DC bootcamp with INE and shedule the Exam for the beginning of December, for this i have a couple of problems;

I cant see any dates available in Decmeber, is this because its fully booked? or can the exam not be sheduled that far in advance?

Thanks in advance.  

I'm looking for clarity on when we add an interface to the vsan database. Especially as it pertains to FCoE.

From my understanding with FC we only add "access" ports of you will and not ISL to the vsan database. 

As for FCoE, i don't have a clear understanding when we add an VFC interface to the vsan databse. Also, when running FCOE NPV/NPIV which interfaces get added to the vsan databse.