Quantcast
Viewing all 10744 articles
Browse latest View live

Weird Routing Issue

I have an issue in the network below where R3 can't reach R1 (in that direction only). R1 can reach R3 (as verified with a debug for ICMP pings).

 

I have a 3 routers and a FW in this setup, and the dmvpn goes from r1 to r2 via the firewall (using NAT, and has a temporary policy to allow any any traffic in any direction to elimate any FW policy problems).  The DMVPN is is up and working, I can even telnet from R2 to R1 and visa versa.  However I cannot bidirectionally send traffic from R1 to R3.  The setup is drawn below

 

R1 ---- FW --(internet)---- R2 --------R3

 

I can ping between R1 and R2 on the tunnel interface (i.e. DMVPN is up and working).  ALSO, I used some ip icmp debugs on R3.  R1 can ping R3 one way (I see the ICMP hit R3 with a source IP of the tunnel interface on R1).  R3 sends an icmp echo  reply back, but it never makes it back to R1 (you will see this in the outputs below).  The traceroute shows that R3 reaches R2, but R2 doesn't forward the packet.  

 

R2 (dmvpn hub)

interface GigabitEthernet0/1

 description R2 - Outside Int.

 bandwidth 10000

 ip address 40.75.40.31 255.255.255.0

 ip flow ingress

 ip flow egress

 duplex full

 speed 1000

 no cdp enable

end

 

interface GigabitEthernet0/0

 description R2 - Inside Int towards R3

 ip address 172.24.209.2 255.255.255.252

 no ip split-horizon

 ip ospf network point-to-point

 duplex full

 speed 1000

 

interface Tunnel0

 bandwidth 10000

 ip address 172.24.210.1 255.255.255.0

 no ip redirects

 ip mtu 1400

 ip flow ingress

 ip flow egress

 ip nhrp authentication xxx

 ip nhrp map multicast dynamic

 ip nhrp network-id 1

 ip tcp adjust-mss 1360

 no ip split-horizon eigrp 90

 ip ospf network broadcast

 ip ospf cost 40

 ip ospf hello-interval 30

 ip ospf priority 150

 keepalive 10 3

 tunnel source GigabitEthernet0/1

 tunnel mode gre multipoint

 tunnel key 0

 tunnel path-mtu-discovery

 tunnel protection ipsec profile DMVPN

 

 

R1#sh dmvpn

Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete

        N - NATed, L - Local, X - No Socket

        # Ent --> Number of NHRP entries with same NBMA peer

        NHS Status: E --> Expecting Replies, R --> Responding

        UpDn Time --> Up or Down Time for a Tunnel

==========================================================================

 

Interface: Tunnel0, IPv4 NHRP Details

 

IPv4 NHS: 172.24.210.1 RE

Type:Spoke, Total NBMA Peers (v4/v6): 1

 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb    Target Network

----- --------------- --------------- ----- -------- ----- -----------------

    1   40.75.40.31    172.24.210.1    UP 00:24:18    S    172.24.210.1/32

 

interface Tunnel0

 description Tunnel to R2

 ip address 172.24.210.28 255.255.255.0

 no ip redirects

 ip mtu 1400

 ip nhrp authentication xxx

 ip nhrp map 172.24.210.1 40.75.40.31

 ip nhrp map multicast 40.75.40.31

 ip nhrp network-id 1

 ip nhrp holdtime 600

 ip nhrp nhs 172.24.210.1

 ip tcp adjust-mss 1360

 ip ospf network broadcast

 ip ospf cost 100

 ip ospf hello-interval 30

 ip ospf priority 0

 load-interval 30

 keepalive 10 3

 tunnel source FastEthernet0/0.1

 tunnel mode gre multipoint

 tunnel key 0

 tunnel protection ipsec profile DMVPN shared

end

 

interface FastEthernet0/0.1

 encapsulation dot1Q 10 native

 ip address 172.26.156.1 255.255.255.0

 ip ospf network point-to-point

 

 

R1#ping 172.24.209.2 (ping to R2's inside interface)

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.24.209.2, timeout is 2 seconds:

!!!!!

 

//debug ip icmp output (on R2) when I ping from R1 to R2's inside interface

Jan 19 21:42:00.797: ICMP: echo reply sent, src 172.24.209.2, dst 172.24.210.28, topology BASE, dscp 0 topoid 0

Jan 19 21:42:00.833: ICMP: echo reply sent, src 172.24.209.2, dst 172.24.210.28, topology BASE, dscp 0 topoid 0

Jan 19 21:42:00.873: ICMP: echo reply sent, src 172.24.209.2, dst 172.24.210.28, topology BASE, dscp 0 topoid 0

Jan 19 21:42:00.909: ICMP: echo reply sent, src 172.24.209.2, dst 172.24.210.28, topology BASE, dscp 0 topoid 0

 

 

R1#ping 172.24.209.1 (to R3's interface that connects to R2, notice it's the same subnet as before)

 

//debug ip icmp output (on R3) when I ping from R1 to R3

1112349: Jan 19 21:42:03.597 GMT: ICMP: echo reply sent, src 172.24.209.1, dst 172.24.210.28

1112350: Jan 19 21:42:05.593 GMT: ICMP: echo reply sent, src 172.24.209.1, dst 172.24.210.28

1112351: Jan 19 21:42:07.593 GMT: ICMP: echo reply sent, src 172.24.209.1, dst 172.24.210.28

1112352: Jan 19 21:42:09.593 GMT: ICMP: echo reply sent, src 172.24.209.1, dst 172.24.210.28

 

 

06680r1#show ip route 172.24.209.2

Routing entry for 172.24.0.0/16

  Known via "ospf 100", distance 110, metric 140

  Tag 555, type extern 1

  Last update from 172.24.210.1 on Tunnel0, 00:00:16 ago

  Routing Descriptor Blocks:

  * 172.24.210.1, from 172.24.210.1, 00:00:16 ago, via Tunnel0

      Route metric is 140, traffic share count is 1

      Route tag 555

//Routing from R3
R3#show ip route 172.24.210.28
Routing entry for 172.24.210.0/24
  Known via "ospf 100", distance 110, metric 110
  Tag 777, type extern 1
  Last update from 172.24.209.2 on GigabitEthernet4/21, 3w1d ago
  Routing Descriptor Blocks:
  * 172.24.209.2, from 172.24.15.244, 3w1d ago, via GigabitEthernet4/21
      Route metric is 110, traffic share count is 1
      Route tag 777

!NOTE: gi4/21 is the interface connecting to R2 (the IP is on the same subnet).
R3#traceroute 172.24.210.28
Type escape sequence to abort.
Tracing the route to 172.24.210.28
  1 R2.com (172.24.209.2) 0 msec 0 msec 0 msec
  2  *  *  * 
  3  *  *  * 
There was no problems pinging between R1 and R2, so as long as R3 sends traffic in the direction to reach R1, everything should work. But it just doesn't 

EIGRP flaping on N7K

Hi Evryone!

I have strange flapping situtaion on my two N7K they have VPC-PEER-LINK (the port-channel) (don't have vlan 302, it's excluded), and second connection is via 10G normal trunk, who have only routed vlans (in my situation 302), on VPC are non routed vlans. This normal trunk iterface have MTU with 1500.

On debug log I see that one dvice recive and send HELLO, but seccond only send HELLO but don't recive anything. Parameters of this two nexuses are thisame

Hardware are: cisco Nexus7000 C7004 

Software are: 6.2(8a)

 

N7K1:

                        Xmit Queue   Mean   Pacing Time   Multicast    Pending

Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes

Vlan302            0        0/0         0       0/0         50             0

  Hello interval is 5 sec

  Holdtime interval is 15 sec

  Next xmit serial <none>

  Un/reliable mcasts: 0/6  Un/reliable ucasts: 11/126

  Mcast exceptions: 0  CR packets: 0  ACKs suppressed: 0

  Retransmissions sent: 101  Out-of-sequence rcvd: 0

  Authentication mode is not set

  Use multicast

  Classic/wide metric peers: 0/0

N7K2:
                        Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Vlan302            0        0/0         0       0/0         50             0
  Hello interval is 5 sec
  Holdtime interval is 15 sec
  Next xmit serial <none>
  Un/reliable mcasts: 0/6  Un/reliable ucasts: 42/329
  Mcast exceptions: 0  CR packets: 0  ACKs suppressed: 4
  Retransmissions sent: 296  Out-of-sequence rcvd: 97
  Authentication mode is not set
  Use multicast
  Classic/wide metric peers: 0/0

Show from log:

2014 Dec 17 16:02:08 PLCORE01 %EIGRP-5-NBRCHANGE_DUAL:  eigrp-100 [6601] (default-base) IP-EIGRP(0) 100: Neighbor 192.168.78.2 (Vlan302) is up: new adjacency

2014 Dec 17 16:02:09 PLCORE01 %EIGRP-5-NBRCHANGE_DUAL:  eigrp-100 [6601] (default-base) IP-EIGRP(0) 100: Neighbor 192.168.78.2 (Vlan302) is down: interface status down

Show from debug:
N7K2:
2014 Dec 18 11:47:52.031574 eigrp: 100 [6606] (default-base)  EIGRP: Sending HELLO on Vlan302
2014 Dec 18 11:47:52.031591 eigrp: 100 [6606] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:47:52.031599 eigrp: 100 [6606] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:47:55.834580 eigrp: 100 [6606] (default-base)  EIGRP: Received HELLO on Vlan302
2014 Dec 18 11:47:55.834620 eigrp: 100 [6606] (default-base)  nbr 192.168.78.1
2014 Dec 18 11:47:55.834646 eigrp: 100 [6606] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:47:55.834669 eigrp: 100 [6606] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:47:55.834691 eigrp: 100 [6606] (default-base)  peerQ un/rely 0/1
2014 Dec 18 11:47:56.764744 eigrp: 100 [6606] (default-base)  EIGRP: Sending HELLO on Vlan302
2014 Dec 18 11:47:56.764780 eigrp: 100 [6606] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:47:56.764805 eigrp: 100 [6606] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:48:00.644895 eigrp: 100 [6606] (default-base)  EIGRP: Received HELLO on Vlan302
2014 Dec 18 11:48:00.644974 eigrp: 100 [6606] (default-base)  nbr 192.168.78.1
2014 Dec 18 11:48:00.645000 eigrp: 100 [6606] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:00.645023 eigrp: 100 [6606] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:48:00.645045 eigrp: 100 [6606] (default-base)  peerQ un/rely 0/1
2014 Dec 18 11:48:01.504971 eigrp: 100 [6606] (default-base)  EIGRP: Sending HELLO on Vlan302
2014 Dec 18 11:48:01.505008 eigrp: 100 [6606] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:01.505033 eigrp: 100 [6606] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:48:05.234037 eigrp: 100 [6606] (default-base)  EIGRP: Received HELLO on Vlan302
2014 Dec 18 11:48:05.234114 eigrp: 100 [6606] (default-base)  nbr 192.168.78.1
2014 Dec 18 11:48:05.234140 eigrp: 100 [6606] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:05.234163 eigrp: 100 [6606] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:48:05.234186 eigrp: 100 [6606] (default-base)  peerQ un/rely 0/1
2014 Dec 18 11:48:05.962235 eigrp: 100 [6606] (default-base)  EIGRP: Sending HELLO on Vlan302
2014 Dec 18 11:48:05.962277 eigrp: 100 [6606] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:05.962301 eigrp: 100 [6606] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:48:05.964607 eigrp: 100 [6606] (default-base)  EIGRP: Received HELLO on Vlan302
2014 Dec 18 11:48:05.964679 eigrp: 100 [6606] (default-base)  nbr 192.168.78.1
2014 Dec 18 11:48:05.964704 eigrp: 100 [6606] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:05.964727 eigrp: 100 [6606] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:48:05.964749 eigrp: 100 [6606] (default-base)  peerQ un/rely 0/1
2014 Dec 18 11:48:10.667492 eigrp: 100 [6606] (default-base)  EIGRP: Sending HELLO on Vlan302
2014 Dec 18 11:48:10.667536 eigrp: 100 [6606] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:10.667561 eigrp: 100 [6606] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:48:10.861817 eigrp: 100 [6606] (default-base)  EIGRP: Received HELLO on Vlan302
2014 Dec 18 11:48:10.861889 eigrp: 100 [6606] (default-base)  nbr 192.168.78.1
2014 Dec 18 11:48:10.861914 eigrp: 100 [6606] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:10.861937 eigrp: 100 [6606] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:48:10.861959 eigrp: 100 [6606] (default-base)  peerQ un/rely 0/1
2014 Dec 18 11:48:15.080747 eigrp: 100 [6606] (default-base)  EIGRP: Sending HELLO on Vlan302
2014 Dec 18 11:48:15.080785 eigrp: 100 [6606] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:15.080809 eigrp: 100 [6606] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:48:15.441051 eigrp: 100 [6606] (default-base)  EIGRP: Received HELLO on Vlan302
2014 Dec 18 11:48:15.441129 eigrp: 100 [6606] (default-base)  nbr 192.168.78.1
2014 Dec 18 11:48:15.441155 eigrp: 100 [6606] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:15.441179 eigrp: 100 [6606] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:48:15.441201 eigrp: 100 [6606] (default-base)  peerQ un/rely 0/1
2014 Dec 18 11:48:19.357977 eigrp: 100 [6606] (default-base)  EIGRP: Sending HELLO on Vlan302
2014 Dec 18 11:48:19.358020 eigrp: 100 [6606] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:19.358046 eigrp: 100 [6606] (default-base)  iidbQ un/rely 0/0
N7K1:
2014 Dec 18 11:48:20.264723 eigrp: 100 [6601] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:20.264746 eigrp: 100 [6601] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:48:25.052925 eigrp: 100 [6601] (default-base)  EIGRP: Sending HELLO on Vlan302
2014 Dec 18 11:48:25.052967 eigrp: 100 [6601] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:25.052991 eigrp: 100 [6601] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:48:29.513154 eigrp: 100 [6601] (default-base)  EIGRP: Sending HELLO on Vlan302
2014 Dec 18 11:48:29.513196 eigrp: 100 [6601] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:29.513220 eigrp: 100 [6601] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:48:30 PLCORE01 %EIGRP-5-NBRCHANGE_DUAL:  eigrp-100 [6601] (default-base) IP-EIGRP(0) 100: Neighbor 192.168.78.2 (Vlan302) is down: holding time expired
2014 Dec 18 11:48:30.077284 eigrp: 100 [6601] (default-base)  EIGRP: Sending HELLO on Vlan302
2014 Dec 18 11:48:30.077312 eigrp: 100 [6601] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:30.077334 eigrp: 100 [6601] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:48:35.055529 eigrp: 100 [6601] (default-base)  EIGRP: Sending HELLO on Vlan302
2014 Dec 18 11:48:35.055572 eigrp: 100 [6601] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:35.055599 eigrp: 100 [6601] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:48:35.069128 eigrp: 100 [6601] (default-base)  EIGRP: Received HELLO on Vlan302
2014 Dec 18 11:48:35.069144 eigrp: 100 [6601] (default-base)  nbr 192.168.78.2
2014 Dec 18 11:48:35.069153 eigrp: 100 [6601] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:35 PLCORE01 %EIGRP-5-NBRCHANGE_DUAL:  eigrp-100 [6601] (default-base) IP-EIGRP(0) 100: Neighbor 192.168.78.2 (Vlan302) is up: new adjacency
2014 Dec 18 11:48:35.070242 eigrp: 100 [6601] (default-base)  EIGRP: Sending HELLO on Vlan302
2014 Dec 18 11:48:35.070274 eigrp: 100 [6601] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:35.070296 eigrp: 100 [6601] (default-base)  iidbQ un/rely 0/1
2014 Dec 18 11:48:40.076076 eigrp: 100 [6601] (default-base)  EIGRP: Sending HELLO on Vlan302
2014 Dec 18 11:48:40.076116 eigrp: 100 [6601] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:40.076139 eigrp: 100 [6601] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:48:44.394315 eigrp: 100 [6601] (default-base)  EIGRP: Sending HELLO on Vlan302
2014 Dec 18 11:48:44.394356 eigrp: 100 [6601] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:44.394380 eigrp: 100 [6601] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:48:48.873604 eigrp: 100 [6601] (default-base)  EIGRP: Sending HELLO on Vlan302
2014 Dec 18 11:48:48.873644 eigrp: 100 [6601] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:48.873667 eigrp: 100 [6601] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:48:50 PLCORE01 %EIGRP-5-NBRCHANGE_DUAL:  eigrp-100 [6601] (default-base) IP-EIGRP(0) 100: Neighbor 192.168.78.2 (Vlan302) is down: holding time expired
2014 Dec 18 11:48:50.084675 eigrp: 100 [6601] (default-base)  EIGRP: Sending HELLO on Vlan302
2014 Dec 18 11:48:50.084703 eigrp: 100 [6601] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:50.084727 eigrp: 100 [6601] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:48:54.772941 eigrp: 100 [6601] (default-base)  EIGRP: Sending HELLO on Vlan302
2014 Dec 18 11:48:54.772980 eigrp: 100 [6601] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:54.773004 eigrp: 100 [6601] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:48:59.226245 eigrp: 100 [6601] (default-base)  EIGRP: Sending HELLO on Vlan302
2014 Dec 18 11:48:59.226288 eigrp: 100 [6601] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:48:59.226312 eigrp: 100 [6601] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:49:03.495479 eigrp: 100 [6601] (default-base)  EIGRP: Sending HELLO on Vlan302
2014 Dec 18 11:49:03.495521 eigrp: 100 [6601] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:49:03.495544 eigrp: 100 [6601] (default-base)  iidbQ un/rely 0/0
2014 Dec 18 11:49:04.320708 eigrp: 100 [6601] (default-base)  EIGRP: Received HELLO on Vlan302
2014 Dec 18 11:49:04.320723 eigrp: 100 [6601] (default-base)  nbr 192.168.78.2
2014 Dec 18 11:49:04.320733 eigrp: 100 [6601] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:49:04 PLCORE01 %EIGRP-5-NBRCHANGE_DUAL:  eigrp-100 [6601] (default-base) IP-EIGRP(0) 100: Neighbor 192.168.78.2 (Vlan302) is up: new adjacency
2014 Dec 18 11:49:04.321902 eigrp: 100 [6601] (default-base)  EIGRP: Sending HELLO on Vlan302
2014 Dec 18 11:49:04.321934 eigrp: 100 [6601] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:49:04.321956 eigrp: 100 [6601] (default-base)  iidbQ un/rely 0/1
2014 Dec 18 11:49:08.998143 eigrp: 100 [6601] (default-base)  EIGRP: Sending HELLO on Vlan302
2014 Dec 18 11:49:08.998180 eigrp: 100 [6601] (default-base)    AS 100, Flags 0x0, Seq 0/0idbQ 0/0
2014 Dec 18 11:49:08.998204 eigrp: 100 [6601] (default-base)  iidbQ un/rely 0/0
Any idea, why one nexus send only Hello, and second send and recive?

iBGP full mesh

Hi there,

I have question about iBGP full mesh,

To solve BGP split horizen issue, we need to make full mesh all iBGP.

I know that there is route reflector to decrease number of BGP peer.

The question is that why full mesh is default way to solve issue as design?

I think hub and spoke diagram ,means route reflector?, is enough diagram to solve issue.

If we need more fault tolerance it's ok to put 2 hub.

I want to know the reason why iBGP was designed as it needs full mesh as default.

CCNA Video

Hello,

  I was wondering if there was going to be any learning materials from INE on the CCNA Video line?

Thanks!

Automatic reply: How to save/load UCS configs

Jag är på utbildning och återkommer den 13/2 - 2015, jag kommer att läsa mail sporadiskt under denna tid


I'm away on training and will return the 13 of february 2015, i will check mail from time to time

How to save/load UCS configs

Hi All,

I tried to save and load UCS configs from many Labs now, but I've never managed to get it working (load config highlighted in blue, but nothing is moving anywhere)...

I'm doing my UCS Lab with a Windows VM and a Chrome browser. Does anyone know how to proceed to save and load configs?

Thanks for your feedback 
--
Pierre-Louis Gingembre
pierre-louis@gingembre.net
+33 6 33 26 75 45
@plgingembre

ACL Deny log

Hi Guys,

I'm trying to build a new access-list for some dmvpn hub routers that are also using IPSec.  I want to know how you can identify precisely the rules and ports to allow through from using logs on the cmd line.  For example:

 

#int gi0/1

 # desc outside_interface

 # ip access-group 101 in

!

#access-list 101 deny tcp any any log

#access-list 101 deny udp any any log

#access-list 101 deny ip any any log

 

The problem I'm having, is that I can't seem to identify the ports, see the bits in bold below.  How can I make the ports visible?  I'm using a #sh log, and #debug ip packet detail 101 for this output.

 

Jan 26 10:13:46.762: %SEC-6-IPACCESSLOGP: list 101 denied udp 15.15.15.15(0) -> 16.16.16.16(0), 25 packets  

Jan 26 10:13:46.762: %SEC-6-IPACCESSLOGP: list 101 denied tcp 10.10.10.10(0) -> 10.10.20.11(0), 4 packets  

Jan 26 10:13:46.762: %SEC-6-IPACCESSLOGDP: list 101 denied icmp 16.16.16.16 -> 15.15.15.15 (0/0), 20 packets  

 

Is this just the fact that I need to be specific with the protocols, eg ICMP, GRE, ESP etc etc rather than just do the things i did above?

UK Study group/ Partner

Hi All,

 

I am currently starting to study for CCIE R&S, I think being part of a study group would be useful. I am based in the UK. Please feel free to message me.

 

Cheers,

 

Andrew


Unable to boot ESXi (PSOD)

I've been using the INE racks (with the UCS add-on), and I was unable to get the ESXi to boot. It would PSOD every single time.

Image may be NSFW.
Clik here to view.

 

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

According to VMWare's KB, this particular error points to a corrupt installation. With the WB specifically asking us not to reinstall ESXi, that's where I had to stop the lab.

 

However, the fact that it happened to me on multiple racks (at least rack 5 and 3, possibly rack 6 as well) makes me wonder if it's not something in my config that caused it. But I just cannot imagine what kind of mistake would cause this kind of result.

 

Did you ever see this in your rack rental sessions? Or were you able to boot ESXi on those particular racks without any issues?

 

[ Edit, since the system seems to not allow double-posting without moderator approval:

While we're on the subject of ESXi booting - I was completely unable to boot the second ESXi instance. According to the WB, it should boot from LUN 2. Yet the storage only presents two LUNs (0 and 1) to the server...

Image may be NSFW.
Clik here to view.

]

Cisco Documentation

Doing the INE ATC video, I see Brian McGahan using the Cisco Docs. a lot, and I try to do the same.

But new releases are out, and the placement of the configurationguides seem very random.

Is it me or are you experiencing the same, if not, maybe someone could give me some pointers.

/Morten

 

 

Cisco C6500 to NX7006 refresh

Anyone out there work on a C6500 to N7K migration?  Would like to see the detailed plan if possible.

 

Collaboration Workbooks

Hi Guys,

Can someone please help me understand what is the next step after i completed watching the Collaboration ATC videos?

I intend to use the INE's Rack rental but i am very confused about the study materials, i can't use the old CCIE voice workbooks since it has different topology.

Thanks!!!

Tom.

EIGRP Poisoned Floating Summarization

Am I right in thinking that in IOS 15.X, a poisoned summary route will NOT make it to the routing table and will NOT be advertise? Where in IOS 12.X, the summary route does not get placed in the routing table but still gets advertised? If my understanding is correct, I'm not sure I understand the purpose for creating a poisoned summary route in this lab. If the summary route is not in the routing table nor advertise, why bring them into EIGRP using the network command in the first place?

Redistribution Case #2 Question.

Image may be NSFW.
Clik here to view.


R9 is redistributing its loopback into EIGRP which both R1 and R3 learn.

R1 sends the loopback from EIGRP into OSPF per its OSPF to EIGRP redistribution.

R3 then installs the lower AD route via OSPF and redistributes it into EIGRP.

R1 receives the R9 loopback route via R3 via EIGRP with a lower metric than the route for R9 via R6.

R1 then flushes the old route, and adds the new one.

When R1 flushes the R9 route via R6, it stops sending it into OSPF. This causes R3 to stop originating a lower cost route for R9’s loopback which causes R1 to use the R9 route via R6 which starts the cycle again.

My question is when R1 receives the R9 route that R3 originates, why does it flush its current route from EIGRP and thus OSPF instead of just sending an update? I thought in EIGRP that when a route with a better metric is received, the route is left in the table, but EIGRP UPDATE messages are sent reflecting the new metric.

IPV6 RA Suppress

I cant find where the below statmet out of the IPV6 Autoconfig lab is true. The command appears to be wrong and even if you use "no ipv6 nd ra suppress" command it does not show up in the running config either. This would lead me to belive they are unsuppressed by default. are they really suppresed by default?

(“suppress-ra” is enabled by default on Ethernet interfaces; this default behavior can be changed with the no ipv6 nd suppress-ra)


LDP | Session hold time

It appears that LDP has 4x different holddown timers,  three listed in the output of "show mpls ldp param"  and the forth being "session protection" duration.

3 of the 4 I fully understand their use and purpose,  however "session hold time" is one that I can't figure out how/why its used.   Can anyone shed some light on this for me?

Rack102R18#show mpls ldp parameters | beg Prot

Protocol version: 1

Session hold time: 180 sec; keep alive interval: 60 sec

Discovery hello: holdtime: 15 sec; interval: 5 sec

Discovery targeted hello: holdtime: 90 sec; interval: 10 sec

Downstream on Demand max hop count: 255

LDP for targeted sessions

LDP initial/maximum backoff: 15/120 sec

LDP loop detection: off

LDP NSR: Disabled

 

Rack102R4(config)#mpls ldp session protection duration ?

  <30-2147483>  Holdup time in seconds

///////

The command reference, uses the term “session peer”

 

To change the time for which an Label Distribution Protocol (LDP) session is maintained in the absence of LDP messages from the session peer, use the mpls ldp holdtime command in global configuration mode. To disable this command, use the no form of the command.

 

If “targeted hellos” were not mentioned in the above output, I would have thought it meant that….

 

 

Workbook mistake (?) in RIP

Hi guys,

Anyone can help to confirm this for me:

 

1. RIPv2 Filtering with Prefix Lists:

 

  • Using a prefix-list, configure R5 to filter any IPv4 updates received inbound from R4 over the DMVPN cloud.
  • Solution : ip prefix-list NOT_FROM_R4 seq 5 deny 155.1.0.4/32
  • R4 IPv4 address is 155.1.0.4 /24. Will the prefix list match this? I was under the assumption 155.1.0.4/32 in prefix list means exact match 155.1.0.4 and subnet mask has to be 255.255.255.255. Thus, it will not match 155.1.0.4 /24?
        From Brian's blog:
        “ip prefix-list LIST permit 1.2.3.0/24″ would be an exact match for the prefix 1.2.3.0 with a subnet mask of 255.255.255.0. This does not match 1.2.0.0/24, nor does it match 1.2.3.4/32, nor anything in between.

2. RIPv2 Filtering with Extended ACL:

  • Configure an extended access-list filter on R5 so that routes for VLAN 7 and VLAN 9 are accepted only from R1:
    • additionally, routes to R1’s Loopback0 and VLAN 146 are accepted only from R3.
  • Solution :
    • access-list 100 deny ip host 155.1.0.3 host 155.1.7.0
    • access-list 100 deny ip host 155.1.0.3 host 155.1.9.0
  • Shouldn't it be 155.1.7.0 0.0.0.255 and 155.1.9.0 0.0.0.255 ?
Cheers.
Andy

OTV not passing traffic between sites

I have configured OTV as per INE Nexus Technology Labs OTV specified..it did not work. I reset the devices and copy paste the configuration from workbook, still did not work. I have run out ideas after 3 hours troubleshooting as evetrything looked fine to me, apart from OTV does not passing traffic between sites. 

I can see OTV has established adjancency ok, AED active, ISIS database has remote sites' MACs, ARP has got reply, but ICMP ping packet simply unable to reach the other site...I run WireShark to caputure packet from hosts, only able to see echo request but not any reply. I was using Rack8. I almost start to think if it is hardware/software issue...But this is my first time configuring OTV, so quite possible I have missed something, could anyone help please? 

Configuration (the other site just change the IP and site Identifier):

feature otv

vlan 10,999

otv site-vlan 999

otv site-identifier 0x101

 

interface Overlay1

  otv join-interface Ethernet1/25

  otv control-group 224.1.1.1

  otv data-group 232.1.1.0/24

  otv extend-vlan 10

 

interface Ethernet1/25

  ip address 169.254.0.71/24

  ip igmp version 3

 

interface Ethernet2/27-28

  switchport mode trunk

  spanning-tree port type network

  medium p2p

  no shutdown

N7K7(config)# sh otv

 

OTV Overlay Information

Site Identifier 0000.0000.0101

 

Overlay interface Overlay1

 

 VPN name            : Overlay1

 VPN state           : UP

 Extended vlans      : 10 (Total:1)

 Control group       : 224.1.1.1

 Data group range(s) : 232.1.1.0/24 

 Broadcast group     : 224.1.1.1

 Join interface(s)   : Eth1/25 (169.254.0.71) 

 Site vlan           : 999 (up) 

 AED-Capable         : Yes 

 Capability          : Multicast-Reachable

 

 

N7K7(config)# sh otv vlan

 

OTV Extended VLANs and Edge Device State Information (* - AED)

 

Legend: 

(NA) - Non AED, (VD) - Vlan Disabled, (OD) - Overlay Down

(DH) - Delete Holddown, (HW) - HW: State Down 

 (NFC) - Not Forward Capable 

 

VLAN   Auth. Edge Device                     Vlan State                 Overlay

----   -----------------------------------   ----------------------       -------

  10*  N7K7                                  active                  Overlay1 

N7K7# sh otv isis da detail 

OTV-IS-IS Process: default LSP database VPN: Overlay1

 

OTV-IS-IS Level-1 Link State Database

  LSPID                 Seq Number   Checksum  Lifetime   A/P/O/T

  N7K8.00-00            0x00000019   0xA44B    845        0/0/0/1

    Instance      :  0x00000017

    Area Address  :  00

    NLPID         :  0xCC 0x8E

    Hostname      :  N7K8               Length : 4

    Extended IS   :  N7K7.01            Metric : 40        

    Vlan          : 10 : Metric     : 1

      MAC Address     : 000c.29a7.7595

      MAC Address     : 000d.eca3.2dfc

    Site ID       : 0000.0000.0102 

    AED-Server-ID : 0026.980c.2145 

10Version 11

      ED Summary      :     Device ID  : 0026.980c.2145 : fwd_ready : 1

    Site ID       : 0000.0000.0102 : Partition ID    : ffff.ffff.ffff

    Device ID  : 0026.980c.2145  Cluster-ID    : 0 

    Vlan Status   :     AED : 1 Back-up AED   : 0  Fwd ready : 1    Priority : 0 Delete     : 0  Local      : 1 Remote     : 1 Range      : 1  Version    : 1

Start-vlan    : 10 End-vlan      : 10 Step          : 1

    Site ID       : 0000.0000.0102 : Partition ID    : ffff.ffff.ffff

    Device ID  : 0026.980c.2145  Cluster-ID    : 0 

    AED SVR status :     Old-AED  : 0000.0000.0000 New-AED  : 0026.980c.2145

    old-backup-aed  : 0000.0000.0000 new-backup-aed   : 0000.0000.0000

    Delete-flag     : 0 No-of-range      : 1 Version         : 1

Start-vlan    : 10 End-vlan      : 10 Step          : 1

    Digest Offset :  0

  N7K7.00-00          * 0x00000029   0xA3A3    756        0/0/0/1

    Instance      :  0x00000029

    Area Address  :  00

    NLPID         :  0xCC 0x8E

    Hostname      :  N7K7               Length : 4

    Extended IS   :  N7K7.01            Metric : 40        

    Vlan          : 10 : Metric     : 1

      MAC Address     : 0050.5687.1347

      MAC Address     : 0005.9b2a.47fc

    Site ID       : 0000.0000.0101 

    AED-Server-ID : 68bd.abd7.6045 

10Version 11

      ED Summary      :     Device ID  : 68bd.abd7.6045 : fwd_ready : 1

    Site ID       : 0000.0000.0101 : Partition ID    : ffff.ffff.ffff

    Device ID  : 68bd.abd7.6045  Cluster-ID    : 0 

    Vlan Status   :     AED : 1 Back-up AED   : 0  Fwd ready : 1    Priority : 0 Delete     : 0  Local      : 1 Remote     : 1 Range      : 1  Version    : 1

Start-vlan    : 10 End-vlan      : 10 Step          : 1

    Site ID       : 0000.0000.0101 : Partition ID    : ffff.ffff.ffff

    Device ID  : 68bd.abd7.6045  Cluster-ID    : 0 

    AED SVR status :     Old-AED  : 0000.0000.0000 New-AED  : 68bd.abd7.6045

    old-backup-aed  : 0000.0000.0000 new-backup-aed   : 0000.0000.0000

    Delete-flag     : 0 No-of-range      : 1 Version         : 1

Start-vlan    : 10 End-vlan      : 10 Step          : 1

    Digest Offset :  0

  N7K7.01-00          * 0x0000000F   0xF8F9    934        0/0/0/1

    Instance      :  0x0000000F

    Extended IS   :  N7K8.00            Metric : 0         

    Extended IS   :  N7K7.00            Metric : 0         

    Digest Offset :  0

 

 

 

 

 

BGP Free core with MPLS traceroute issue

Hi experts,

I'm currently testing out BGP free core using mpls and i'm missing some traces between endpoint. Here is topology

Image may be NSFW.
Clik here to view.

Goal is to tunnel traffic from AS4 to AS5 over the mpls core without running BGP on the P routers. I was able to get reachability but when i trace from one side to the other, the P router cant respond to the trace. Is this normal??

R5(config-router)#do trace 4.4.4.4 so lo 0
Type escape sequence to abort.
Tracing the route to 4.4.4.4
VRF info: (vrf in name/id, vrf out name/id)
  1 35.0.0.3 100 msec 56 msec 32 msec
  2  *  *  *  ----------------------------------------------------R2 cant respond to traceroute
  3 10.0.12.1 76 msec 96 msec 72 msec
  4 14.0.0.4 104 msec 140 msec 108 msec

Find configs below, can copy and paste directly to test.

R1
conf t
int f0/1
 ip add 10.0.12.1 255.255.255.0
 mpls ip
 no sh
int f0/0
 ip add 14.0.0.1 255.255.255.0
 no sh
int lo 0
 ip add 10.0.0.1 255.255.255.255

router ospf 1
 network 10.0.0.0 0.255.255.255 a 0

router bgp 123
 no bgp default ipv4
 nei 10.0.0.3 remote-as 123
 nei 14.0.0.4 remote-as 4
 nei 10.0.0.3 up lo 0

 address-family ipv4
  nei 14.0.0.4 activate
  nei 10.0.0.3 activate
  nei 10.0.0.3 next-hop-self

R2
conf t

int f0/0
 ip add 10.0.12.2 255.255.255.0
 mpls ip
 no shut
int f0/1
 ip add 10.0.23.2 255.255.255.0
 mpls ip
 no shut
int lo 0
 ip add 10.0.0.2 255.255.255.255
router ospf 1
 network 10.0.0.0 0.255.255.255 a 0

R3
conf t
int f0/0
 ip add 10.0.23.3 255.255.255.0
 mpls ip
 no sh
int f0/1
 ip add 35.0.0.3 255.255.255.0
 no shut
int lo 0
 ip add 10.0.0.3 255.255.255.255

router ospf 1
 network 10.0.0.0 0.255.255.255 a 0

router bgp 123
 no bgp default ipv4
 nei 10.0.0.1 remote-as 123
 nei 35.0.0.5 remote-as 5
 nei 10.0.0.1 up lo 0

 address-family ipv4
  nei 35.0.0.5 activate
  nei 10.0.0.1 activate
  nei 10.0.0.1 next-hop-self


R4
conf t
int f0/0
 ip add 14.0.0.4 255.255.255.0
 no sh
int lo 0
 ip add 4.4.4.4 255.255.255.0
router bgp 4
 nei 14.0.0.1 remote-as 123
 network 4.4.4.0 mask 255.255.255.0


R5
conf t
int f0/0
 ip add 35.0.0.5 255.255.255.0
 no sh
int lo 0
 ip add 5.5.5.5 255.255.255.0
router bgp 5
 nei 35.0.0.3 remote-as 123
 network 5.5.5.0 mask 255.255.255.0


Thanks.

Nexus 7000 White Papers

Viewing all 10744 articles
Browse latest View live