Wyróżnione

become an IT expert with #humanITy

john_whitelbow

My name is Tomek De Wille. I’m the owner of humanITy, a small IT training shop for all those of you who want to change their lives and believe they can.

I used to be a language teacher but in 2009 I had a sudden change of heart. I knew I could do more than teach. I joined Nokia as a technical editor and started learning about networks. Fast forward to 2017 and i’m a senior network engineer, troubleshooting networks all around the globe. Because I still love teaching, i’ve created humanITy – a home for anyone who wants to become an IT expert. We run IT courses on Saturdays and Sundays in the beautiful city of Wroclaw, the very heart of Europe.

For a very brief (and very true) explanation of why we founded humanity, see this 3minute youtube video

If you speak English and would like to start a successful career in IT, have a look at our site http://www.humanity.pl

Follow our blog for discount codes, information on new and exciting IT courses and much, much more.

broken CCIE lab with BGP synchronization and OSPF

Hello

We have the following scenario:

Capture

IOU 4 has a static route 10.1.9.9 to IOU 9. It redistributes it into OSPF. IOU4 has OSPF adj to IOU5, IOU5 to IOU2.

IOU2 is a BGP neigh to IOU5 and also to IOU4. IOU4 and IOU5 are route reflector clients of IOU2.

The problem starts when we enable BGP synchronization on R5. What do we know about synchronization? the condition is the route in BGP needs to match the same route in IGP to avoid black holes. where R1>R2>R3 but BGP is only enabled on R1 and R3. R2 causes the black hole.

But having the routes match in BGP and IGP is not the only condition, i’m afraid… let’s have a look at this case:

R5 receives the ospf route to IOU9 from IOU4, but it receives the BGP route to IOU9 from IOU2! The route from the internal routing protocol will not get synchronized with the same route in BGP.

The only fix is to change bgp router-id on IOU2 to be the same as OSPF router-id on IOU4.

 

 

IOU images are buggy

Hello

I’m doing the labs again and so many things are not working out of the box. Today I configured three routers in an NSSA area and one of them insisted on being the translator. The problem was that it wasn’t an ABR. It thought mistakenly that it was connected to the backbone but show ip ospf topology showed status of its backbone area as INACTIVE.

The solution (as always) is to delete the route config and type it in again.

I wonder if the lab images are just as buggy during the exam.

Why vtp pruning is a bad idea

Hello

A while ago I considered implementing VTP with pruning on a client network. But it’s a bad idea because of the following (from Cisco documentation)

(In vtp v3) VTP pruning still applies only to VLANs 1 to 1005, and VLANs 1002 to 1005 are still reserved and cannot be modified.

(…)

VTP pruning is not designed to function in VTP transparent mode. If one or more switches in the network are in VTP transparent mode, you should do one of these:

Turn off VTP pruning in the entire network

Turn off VTP pruning by making all VLANs on the trunk of the switch upstream to the VTP transparent switch pruning ineligible.

There is a funny cornercase scenario related to this: if you have switch A>switch B>switch C, where switch B is a transparent vtp switch while A and C have vtp enabled with pruning, switch C may request (through B) to prune a vlan. Switch A will prune the vlan from the trunk to switch B (which may have needed it!)

In other words: avoid…

New courses in September 2018

Hello

After a short break we will be starting with new courses in September 2018:

  • Introduction to IP networks (Tuesday afternoon)
  • Introduction to IT / Comptia A+

Any questions? Go to our website humanity.pl or call us on 512056971 to talk to us about the courses.

There will be plenty more to come as we approach the new school year so make sure to visit our website once in a while.

 

Asking the right questions… wifi issues

Hello

I’ve had a spate of cases recently where not even a single command was needed to solve the problem.

Today a client called me about weak/missing wifi signal in a conference room on floor 2. The problem was that i didn’t have any map so i didn’t know what i was looking for. We called a person onsite who was heading to that building. At the time that person was sure that there was (or had been) an access point there.

On arrival, it turned out that the access point in the hallway near the conference room was nowhere to be seen. What the technician did see was a brand new metal ceiling. Apparently that new metal ceiling was fixed up directly underneath the old ceiling. The access point seemed to be trapped between the two ceilings.

When I asked the technician to connect to wifi, i saw his mac address on another AP on floor 1 instead. It seems that weak signal from floor 1 was leaking to floor 2? Again, we had no way of confirming where both APs were.

Summing up, what do you need to solve cases like this:

  • confidence to ask the right question to the right person even if this means that that person needs to walk/drive to the site
  • preferably a map with rooms and APs marked
  • if you have Cisco Prime then you’re golden because you can see AP channel utilization stats etc. etc.

 

Logical thinking and even a little knowledge goes a long way

Hello

I had an interesting problem today. The customer has two lines: MPLS and internet with dmvpn running on both.

Suddenly the voice quality dropped, and we saw that the tunnel over MPLS is down.

The route to the DMVPN hub goes through the mpls line with the IP of the CE router being 172.16.0.1

However, the arp entry for 172.16.0.1 was incomplete. Clearly the line was faulty.

A ticket to to the telecom was raised but the answer was unexpected: you haven’t been using the line for the last seven days.

I was like: what do you mean we’re not using the line! we’re not using the line because it’s DOWN, that’s what it is…but i began to think about it: in every answer there’s a grain of truth…

So i pinged the broadcast 172.16.0.255 and VOILA – 172.16.0.2 responded. But what is 172.16.0.2??? Let’s experiment since the line is down anyway
I changed the static route to go through the .2 address and of course the line was working again.

It turned out that the telecom replaced the line a while ago and changed the ip address of the CE router.

Now my point is here: i only used logic and one simple ip route command. No big deal, yet nobody else has come up with the idea to look for other addresses on the subnet. This is great new for beginners in the IT world: keep your mind open, be on the ball and even limited knowledge can bring great results.

ospf sham-link

Hello

Today another episode of ”things that sound complex but are in reality very easy”.

Why create a sham-link?

Normally, prefixes received from your other PE look like IA routes (because of the existence of the super core concept in BGP VPNv4), so if you have a backup link between your CEs (just in case), the backup link will always be preferred because the intra area prefixes will be always preferred over the inter-area prefixes from your PE, who is treated as an ABR between a normal area and the supercore.

The problem is that the backup link is a private link, so it might be a more expensive link, something we want to use it for emergencies only, not as the primary link.

What we will be doing is creating a standard vpnv4 tunnel (BGP session through an MPLS core) and then creating another ospf virtual-link tunnel through it. This overlay tunnel is a sham-link. Think of the sham-link as an improved ospf virtual-link. This is why it’s called a shamlink – a false impression of a true link.

 

Prerequisites

  • mpls-enabled core between loopbacks of PEs (command mpls ip everywhere or simply mpls ldp autoconfig under the ospf process everywhere)

Step 1

Assuming that you already have mpls between the /32 loopbacks of PEs, build a bgp session with the other PE router, creating effectively a tunnel across an OSPF provider core. So apart from the normal bgp session, you need to activate the address family vpnv4. Activating ipv4 family is not needed so you can add the command no bgp default ipv4-unicast to disable the default ipv4 address-family.

router bgp 100
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 150.1.4.4 remote-as 100
neighbor 150.1.4.4 update-source Loopback0
!
address-family ipv4
exit-address-family
!
address-family vpnv4
neighbor 150.1.4.4 activate
neighbor 150.1.4.4 send-community extended
exit-address-family

Step 2

Create a new loopback address and advertise it into BGP address family ipv4 just like you would advertise your other addresses to the other PE.

interface Loopback 200
ip vrf forwarding VPN_A
ip address 150.1.55.55 255.255.255.255

router bgp 100
address-family ipv4 vrf VPN_A
network 150.1.55.55 mask 255.255.255.255

Step 3

Create a sham link with the new loopback of the other PE.

router ospf 100 vrf VPN_A
area 1 sham-link 150.1.55.55 150.1.66.66 cost 1

Additionally, you might want to make sure that the new loopback is not advertised to the CE.

 

Verification command:

show ip ospf sham-links

R6#show ip ospf sham-links
Sham Link OSPF_SL0 to address 150.1.55.55 is up
Area 1 source address 150.1.66.66
Run as demand circuit
DoNotAge LSA allowed. Cost of using 1 State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40,
Hello due in 00:00:00
Adjacency State FULL (Hello suppressed)
Index 2/2, retransmission queue length 0, number of retransmission 0
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
Last retransmission scan length is 0, maximum is 0
Last retransmission scan time is 0 msec, maximum is 0 msec
You do the same thing on the other PE and voila! it’s done. Now your sham-link vpnv4 prefixes are also intra-area prefixes, just like your backup link prefixes. You can now use cost to prefer sham-link prefixes over backup link prefixes.

R8#show ip route ospf
Codes: L – local, 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, H – NHRP, l – LISP
a – application route
+ – replicated route, % – next hop override

Gateway of last resort is not set

150.1.0.0/32 is subnetted, 4 subnets
O 150.1.7.7 [110/11] via 155.1.78.7, 00:32:39, Ethernet0/0.78
155.1.0.0/16 is variably subnetted, 12 subnets, 2 masks
O 155.1.7.0/24 [110/20] via 155.1.78.7, 00:32:39, Ethernet0/0.78
O 155.1.37.0/24 [110/20] via 155.1.78.7, 00:32:39, Ethernet0/0.78
O 155.1.67.0/24 [110/20] via 155.1.78.7, 00:01:44, Ethernet0/0.78
O 155.1.79.0/24 [110/20] via 155.1.78.7, 00:32:39, Ethernet0/0.78
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
O 172.16.7.7/32 [110/11] via 155.1.78.7, 00:32:39, Ethernet0/0.78
O E2 192.168.6.0/24 [110/1] via 155.1.58.5, 00:26:42, Ethernet0/0.58

 

Then you can run:

show ip ospf topology network

show ip ospf topology router

 

to check the reasoning of OSPF (why it chooses intra area path through router 5 than through the backup link of router 7). Specifically, if you set the cost on r8, you need to check LSA router of R8 – what it thinks is the cost to get to r7. The same on the other end

LS age: 1263
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 172.16.7.7
Advertising Router: 172.16.7.7
LS Seq Number: 8000000C
Checksum: 0x1987
Length: 108
Number of Links: 7

Link connected to: a Stub Network
(Link ID) Network/subnet number: 150.1.7.7
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 1

Link connected to: a Stub Network
(Link ID) Network/subnet number: 172.16.7.7
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 1

Link connected to: a Stub Network
(Link ID) Network/subnet number: 155.1.79.0
(Link Data) Network Mask: 255.255.255.0
Number of MTID metrics: 0
TOS 0 Metrics: 10

Link connected to: a Transit Network
(Link ID) Designated Router address: 155.1.78.8
(Link Data) Router Interface address: 155.1.78.7
Number of MTID metrics: 0
TOS 0 Metrics: 500