Closing the blog: starting a new life!

Hi all,
after a lot of inactivity, I decided to officially close the blog, the next week I will also resign from my current job and various collaborations, and shortly start a new life.

New country, new home, language to improve, new car, new collegues, new job responsabilities, MacOs to learn... so don't think to have time and the energy necessary to blog anymore.

I would like to thank all my readers and supporters, I hope to have entertained and puzzled them with my posts, I will keep up to date my profile only on Facebook and on LinkedIn.

best wishes
Marco  :-)

Mini-Lab Challenge: 6 simple tasks

Hi all,
after an intense home-working week,
I decided to challenge my readers and the Project Avatar group "CCIE mini-lab challenges" members with a small lab:

The restrictions here are:
-don't use Policy based routing
-don't use static routes

TASKS:
1- Configure interfaces and IGPs as per diagram
2- Propagate a default route to R1 and R4 using summarization
3- Configure R1 and R4 as stub
4- Redistribute RIP into EIGRP on both R1 and R4
5- Configure BGP AS 100 on R1 ; BGP AS 340 on R3 and R4 and BGP AS 200 on R2. Configure BGP peering as follow: peer R1 to R4, peer R4 to R3 and peer R3 with R2. Use only Loopback 0 for peerings
6- Redistribute RIP into BGP on both R1 and R4.

looks simple, can you imagine some problems without labbing it? (there are at least 4 issues..)
And if you lab it? how do you solve?

:-)
Have fun
Marco


PS: First think and lab it, then you can have a look at the solutions by clicking HERE

Let's start with the initial config:

## R1
hostname R1
interface Loopback0
 ip address 1.1.1.1 255.255.255.0
interface FastEthernet0/0
 ip address 10.0.12.1 255.255.255.0
line con 0
 exec-timeout 0 0
 logging synchronous

## R2
hostname R2
interface Loopback0
 ip address 2.2.2.2 255.255.255.0
interface FastEthernet0/0
 ip address 10.0.12.2 255.255.255.0
interface FastEthernet0/1
 ip address 10.0.23.2 255.255.255.0
line con 0
 exec-timeout 0 0
 logging synchronous

## R3
hostname R3
interface Loopback0
 ip address 3.3.3.3 255.255.255.0
interface FastEthernet0/0
 ip address 10.0.34.3 255.255.255.0
interface FastEthernet0/1
 ip address 10.0.23.3 255.255.255.0
line con 0
 exec-timeout 0 0
 logging synchronous

## R4
hostname R4
interface Loopback0
 ip address 4.4.4.4 255.255.255.0
interface FastEthernet0/0
 ip address 10.0.34.4 255.255.255.0
line con 0
 exec-timeout 0 0
 logging synchronous

Then solve the tasks:
1- Configure interfaces and IGPs as per diagram

This is easy and basic:

## R1
router rip
  version 2 
  no auto-summary
  network 1.0.0.0
router eigrp 100
  eigrp router-id 1.1.1.1 
  no auto-summary 
  network 10.0.12.0 0.0.0.255

## R2
router eigrp 100
  eigrp router-id 2.2.2.2
  no auto-summary
  network 0.0.0.0 0.0.0.0

## R3
router eigrp 100
  eigrp router-id 3.3.3.3
  no auto-summary
  network 0.0.0.0 0.0.0.0

## R4
router rip
  version 2 
  no auto-summary
  network 4.0.0.0
router eigrp 100
  eigrp router-id 4.4.4.4
  no auto-summary 
  network 10.0.34.0 0.0.0.255

Verify with a "show ip route eigrp" on R1 and R4:

R1#sh ip route eigrp
     2.0.0.0/24 is subnetted, 1 subnets
D       2.2.2.0 [90/156160] via 10.0.12.2, 00:01:49, FastEthernet0/0
     3.0.0.0/24 is subnetted, 1 subnets
D       3.3.3.0 [90/158720] via 10.0.12.2, 00:01:40, FastEthernet0/0
     10.0.0.0/24 is subnetted, 3 subnets
D       10.0.23.0 [90/30720] via 10.0.12.2, 00:01:49, FastEthernet0/0
D       10.0.34.0 [90/33280] via 10.0.12.2, 00:01:40, FastEthernet0/0

R4#sh ip route eigrp
     2.0.0.0/24 is subnetted, 1 subnets
D       2.2.2.0 [90/158720] via 10.0.34.3, 00:00:03, FastEthernet0/0
     3.0.0.0/24 is subnetted, 1 subnets
D       3.3.3.0 [90/156160] via 10.0.34.3, 00:00:03, FastEthernet0/0
     10.0.0.0/24 is subnetted, 3 subnets
D       10.0.12.0 [90/33280] via 10.0.34.3, 00:00:03, FastEthernet0/0
D       10.0.23.0 [90/30720] via 10.0.34.3, 00:00:03, FastEthernet0/0

2- Propagate a default route to R1 and R4 using summarization
Summarization must be configured on R2 and R3 interfaces Fa0/0:

## R2 
int fa 0/0
  ip summary-address eigrp 100 0.0.0.0 0.0.0.0

## R3 
int fa 0/0
  ip summary-address eigrp 100 0.0.0.0 0.0.0.0

You will see R1 and R4 receiving only the summary:

R1#sh ip route eigrp 
D*   0.0.0.0/0 [90/30720] via 10.0.12.2, 00:00:13, FastEthernet0/0

R4#sh ip route eigrp
D*   0.0.0.0/0 [90/30720] via 10.0.34.3, 00:00:16, FastEthernet0/0

3- Configure R1 and R4 as stub
Please note the redistribution requirements in the next task. The eigrp stub configuration must allow the redistributed routes:

## R1
router eigrp 100
  eigrp stub redistributed 

## R4
router eigrp 100
  eigrp stub redistributed 

4- Redistribute RIP into EIGRP on both R1 and R4
With this redistribution you will archieve full reachability:

## R1 
router eigrp 100
redistribute rip metric 100000 100 255 1 1500

## R4
router eigrp 100
redistribute rip metric 100000 100 255 1 1500

Quickly verify with a ping between loopbacks:

R4#ping 1.1.1.1 source lo 0 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

5- Configure BGP AS 100 on R1 ; BGP AS 340 on R3 and R4 and BGP AS 200 on R2. Configure BGP peering as follow: peer R1 to R4, peer R4 to R3 and peer R3 with R2. Use only Loopback 0 for peerings.

First configure bgp peerings, then troubleshoot it :-)

## R1 
router bgp 100
  bgp router-id 1.1.1.1 
  neighbor 4.4.4.4 remote-as 340
  neighbor 4.4.4.4 update-source lo0
  neighbor 4.4.4.4 ebgp-multihop 4

## R2 
router bgp 200
  bgp router-id 2.2.2.2
  neighbor 3.3.3.3 remote-as 340
  neighbor 3.3.3.3 update-source lo0
  neighbor 3.3.3.3 ebgp-multihop 2
 
## R3
router bgp 340
  bgp router-id 3.3.3.3
  neighbor 2.2.2.2 remote-as 200
  neighbor 2.2.2.2 update-source lo0
  neighbor 2.2.2.2 ebgp-multihop 2 
  neighbor 4.4.4.4 remote-as 340
  neighbor 4.4.4.4 update-source lo0

## R4
router bgp 340
  bgp router-id 4.4.4.4
  neighbor 1.1.1.1 remote-as 100
  neighbor 1.1.1.1 update-source lo0
  neighbor 1.1.1.1 ebgp-multihop 4
  neighbor 3.3.3.3 remote-as 340
  neighbor 3.3.3.3 update-source lo0

wow simple! but are your bgp peers up? mmmm let's check:

R1#sh ip bgp summary
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 1, main routing table version 1

Neighbor        V          AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
4.4.4.4         4        340       0       0        0    0    0 never    Idle

R4#sh ip bgp summary
BGP router identifier 4.4.4.4, local AS number 340
BGP table version is 1, main routing table version 1

Neighbor        V          AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4        100       0       0        0    0    0 never    Idle
3.3.3.3         4        340       5       5        1    0    0 00:03:00        0

R3#sh ip bgp summary
BGP router identifier 3.3.3.3, local AS number 340
BGP table version is 1, main routing table version 1

Neighbor        V          AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2.2.2.2         4        200       8       8        1    0    0 00:05:10        0
4.4.4.4         4        340    1032    1033        1    0    0 00:00:03        0

Ok, seems that the peering between R1 and R4 is not working, you may remember that BGP peerings is not established through a default route.
Let's check on R4:

R4#sh ip route | beg Gate
Gateway of last resort is 10.0.34.3 to network 0.0.0.0

     4.0.0.0/24 is subnetted, 1 subnets
C       4.4.4.0 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.0.34.0 is directly connected, FastEthernet0/0
D*   0.0.0.0/0 [90/30720] via 10.0.34.3, 17:29:03, FastEthernet0/0

As expected, only a default route is received via EIGRP, due to the summarization task #2.
To have peering correctly working in both direction, you need a route to 4.4.4.0 on R1 and a route to 1.1.1.0 on R4, since static routing is not allowed, you may configure a leak map on the summary:

## R2 
ip prefix-list LEAK_PREFIX permit 4.4.4.0/24
route-map LEAK_MAP permit 10
  match ip address prefix-list LEAK_PREFIX
int fa 0/0
  ip summary-address eigrp 100 0.0.0.0 0.0.0.0 leak-map LEAK_MAP

## R3
ip prefix-list LEAK_PREFIX permit 1.1.1.0/24
route-map LEAK_MAP permit 10
  match ip address prefix-list LEAK_PREFIX
int fa 0/0
  ip summary-address eigrp 100 0.0.0.0 0.0.0.0 leak-map LEAK_MAP

Let's verify the routing table and bgp peering on R1 and R4:

R1#sh ip route | beg Gate
Gateway of last resort is 10.0.12.2 to network 0.0.0.0

     1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, Loopback0
     4.0.0.0/24 is subnetted, 1 subnets
D EX    4.4.4.0 [170/58880] via 10.0.12.2, 00:01:49, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.0.12.0 is directly connected, FastEthernet0/0
D*   0.0.0.0/0 [90/30720] via 10.0.12.2, 17:54:10, FastEthernet0/0

R1#sh ip bgp summary
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 1, main routing table version 1

Neighbor        V          AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
4.4.4.4         4        340       8       8        1    0    0 00:02:36        0

R4#sh ip route | beg Gate
Gateway of last resort is 10.0.34.3 to network 0.0.0.0

     1.0.0.0/24 is subnetted, 1 subnets
D EX    1.1.1.0 [170/58880] via 10.0.34.3, 00:03:04, FastEthernet0/0
     4.0.0.0/24 is subnetted, 1 subnets
C       4.4.4.0 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.0.34.0 is directly connected, FastEthernet0/0
D*   0.0.0.0/0 [90/30720] via 10.0.34.3, 17:54:37, FastEthernet0/0

R4#sh ip bgp summary
BGP router identifier 4.4.4.4, local AS number 340
BGP table version is 1, main routing table version 1

Neighbor        V          AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4        100       9       9        1    0    0 00:03:03        0
3.3.3.3         4        340    1062    1061        1    0    0 00:29:25        0

6- Redistribute RIP into BGP on both R1 and R4.
As usual, let's configure first, then troubleshoot:

## R1
router bgp 100
  redistribute rip 

## R4
router bgp 340
  redistribute rip

You are expected to see both prefixes (1.1.1.0/24 and 4.4.4.0/24) inserted in all bgp tables.

R1#sh ip bgp
BGP table version is 65, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       0.0.0.0                  0         32768 ?
*> 4.4.4.0/24       4.4.4.4                  0             0 340 ?

R4#sh ip bgp    
BGP table version is 9, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       1.1.1.1                  0             0 100 ?
*> 4.4.4.0/24       0.0.0.0                  0         32768 ?

R3#sh ip bgp 
BGP table version is 68, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
r>i1.1.1.0/24       1.1.1.1                  0    100      0 100 ?
r>i4.4.4.0/24       4.4.4.4                  0    100      0 ?

R2#sh ip bgp 
BGP table version is 31, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       3.3.3.3                                0 340 100 ?
*> 4.4.4.0/24       3.3.3.3                                0 340 ?

There are two problems:
-R1 and R4 have a bad recursive routing for 4.4.4.0/24 and 1.1.1.0/24 respectively. That happens when you receive via eBGP the same prefix that you use for peering..
-on R2 the 1.1.1.0/24 prefix is reachable via R3, that creates a blackhole/loop for that prefix.

To solve the first issue you have to configure BGP BACKDOOR on R1 and R4. (see my old post to a more detailed analysis of the bgp recursive routing)

## R1
router bgp 100
  network 4.4.4.0 mask 255.255.255.0 backdoor

## R4
router bgp 340
  network 1.1.1.0 mask 255.255.255.0 backdoor

###### Check on R4
R4#sh ip bgp
BGP table version is 302, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
r> 1.1.1.0/24       1.1.1.1                  0             0 100 ?
*> 4.4.4.0/24       0.0.0.0                  0         32768 ?

###### Check on R1
R1#sh ip bgp 
BGP table version is 927, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       0.0.0.0                  0         32768 ?
*> 4.4.4.0/24       4.4.4.4                  0             0 340 ?

Please note that the problem on R1 is NOT solved, the prefix 4.4.4.0/24 does NOT have the "rib failure" marked.
This could mean that the prefix is not learned via IGP!
Remember that EIGRP is a distance vector protocol (altrough it's called "hybrid"), it advertises ONLY the routes he has in the routing table or directly connected advertised by the "network" command.
In this case, R2 has now the 4.4.4.0/24 route learned via BGP, and EIGRP is not sending this route to R1 anymore.
Let's check and correct this issue using administrative distance on R2, this will also correct the bgp blackhole on R2 for the 1.1.1.0/24 prefix.

## R2
router eigrp 100
  distance eigrp 90 19 

##### Verify on R1
R1#sh ip route | beg Gate
Gateway of last resort is 10.0.12.2 to network 0.0.0.0

     1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, Loopback0
     4.0.0.0/24 is subnetted, 1 subnets
D EX    4.4.4.0 [170/58880] via 10.0.12.2, 00:20:30, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.0.12.0 is directly connected, FastEthernet0/0
D*   0.0.0.0/0 [90/30720] via 10.0.12.2, 00:20:31, FastEthernet0/0

R1#sh ip bgp
BGP table version is 949, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       0.0.0.0                  0         32768 ?
r> 4.4.4.0/24       4.4.4.4                  0             0 340 ?

##### Verify on R2
R2#sh ip bgp
BGP table version is 189, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
r> 1.1.1.0/24       3.3.3.3                                0 340 100 ?
r> 4.4.4.0/24       3.3.3.3                                0 340 ?

:-)
Marco

TSHOOT, the funny side

Sometimes happens, you volunteer or someone else try to volunteer you to solve some "strange issues" of networking devices.

Nothing bad, in my opinion it's always a good tshoot exercise, here a collection of the funniest tshoot issues I recently played with.

4th place for: "BGP doesn't work"
that was a nice trouble, trying to get bgp working on an old netscreen. The ScreenOs documentation at the moment is little or not helpful at all, so I finished solving thanks to the "ScreenOs Cookbook".
By the way, you have to enable bgp under the interface on ScreenOs, otherwise won't work.

3rd place for: "Fix my trunk"
a simple trunk between two switches wasn't working. With CDP enabled, the two switches wasn't even listed as cdp neighbors, but both ports were up and STP was placing the ports in FWD state. After asking them to change cables and ports, realized that probably one switch had some software crash. Reloaded the one with uptime 1 year+, all worked like a charm.

2nd place for: "Don't touch my QoS"
during a NAT configuration on a 800 series, the owner said something like "don't touch my qos, now voip is working very well". Was something like "class-map VOIP, match access-group 180, service policy blah, class VOIP, priority 8000000, interface dialer, service-policy output blah". The line speed was 8Mbps in total, and the access-list 180 was missing. I must admit, I obeyed, haven't touched it.

1st place for: "can't ping"
a /24 subnet with only one server and a netscreen firewall as gateway. Was awesome to find the ".0" ip address assigned on the netscreen interface, something like: "interface ethernet3 ip 192.168.0.0/24"

:-D

Marco

IP Telephony first steps with Packet Tracer

Hi all,

I'm so bored today... that I started moving my first steps into the magic wonders of IP Telephony! :-)

The only tool I have at the moment is the great Packet Tracer, as I'm a Networking Academy instructor and Alumni.

Well, I have to admit that I'm completely a newbie on IP Telephony, so like every CCNA, I started using Packet Tracer to simulate a simple multisite CME installation.

Here is the result:

You can download the Packet Tracer topology file Here, the topology is already configured and ready to play with.

The relevant topics I have learned with this small lab are:
-the use of option 150 in DHCP for IP Phones
-the basic dial peer configuration for multisite CME

Have fun
Marco

World IPv6 day: looking for results

Hi all,

as network engineer I'm excited to see results and analisys of the yesterday's World IPv6 Day.

First of all, like a technician does, I looked at the graphs provided by Arbor Networks. Seems that the IPv6 traffic has been increased yesterday, reaching the 0.04% of all internet traffic, according to their measurements points. (Is this data exciting? Need to search more in depth!)

Another source of informations and graphs is the RIPE NCC World IPv6 Day Measurements Page.

The participants have added AAAA DNS entries for their main sites, increasing mainly the NATIVE portion of IPv6 traffic, that's a good thing...

I look forward to see the updated Google IPv6 statistics, just to have an idea of the real impact on a single organization...

Facebook declares the results HERE, but without providing much data or graphs.

I personally hope to see all the participants with permanent AAAA records, but also to see my home ISP start supporting IPv6 ...

cheers
Marco