Saturday, September 24, 2011

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  :-)

Saturday, July 23, 2011

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

Friday, July 8, 2011

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

Tuesday, June 14, 2011

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

Thursday, June 9, 2011

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

Friday, June 3, 2011

World IPv6 day: last minute suggestions

Hi all,
I read THIS interesting post written by Ivan Pepelnjak about the last minute preparation for the World IPv6 day.

Take a look on the slides shared by Ivan, they are very interesting!


Marco

Thursday, May 26, 2011

NX-OS Redistribution: what's different?

Hi all,
following the Nexus training course I taught last weeks, I would like to talk a little bit about IPv4 redistribution in NX-OS.

As you may have noticed, the redistribution between routing protocols in NX-OS follows a different logic comparing to IOS, let's try to clarify what is different using a simple two protocols topology.


If you have traditional IOS routers, in this topology you will perform a basic mutual redistribution on R2, something like:

R2(config)#router rip
R2(config-router)#redistribute ospf 1 metric 2 
R2(config-router)#
R2(config-router)#router ospf 1 
R2(config-router)#redistribute rip subnets 

In this way you are redistributing:
-the "protocol learned" routes
-the connected routes that ara participating the redistributed protocol

For example, when you perform redistribution of RIP into OSPF on R2, you will redistribute:
-the RIP learned routes:
R2#sh ip route rip
     1.0.0.0/24 is subnetted, 1 subnets
R       1.1.1.0 [120/1] via 10.12.12.1, 00:00:05, FastEthernet0/0
-the connected interfaces that are running RIP:
R2#sh ip protocols 
Routing Protocol is "rip"
[.....]

  Routing for Networks:
    2.0.0.0
    10.0.0.0

[.....]




That's why on R3 you will find all the routes correctly learned through OSPF:
R3#sh ip route 
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     1.0.0.0/24 is subnetted, 1 subnets
O E2    1.1.1.0 [110/20] via 10.23.23.2, 00:01:09, FastEthernet0/0
     2.0.0.0/24 is subnetted, 1 subnets
O E2    2.2.2.0 [110/20] via 10.23.23.2, 00:01:09, FastEthernet0/0
     3.0.0.0/24 is subnetted, 1 subnets
C       3.3.3.0 is directly connected, Loopback1
     10.0.0.0/24 is subnetted, 2 subnets
C       10.23.23.0 is directly connected, FastEthernet0/0
O E2    10.12.12.0 [110/20] via 10.23.23.2, 00:01:09, FastEthernet0/0

Ok, no surprise until here, but what's different in NX-OS ?
Let's modify the same topology, using a NX-OS L3 device instead of R2:


Obviously the routing protocol configuration is different, but is also different the redistribution logic.

1) redistribution in NX-OS ALWAYS needs a route-map:
In this case we can use a "permit any" prefix list, just to perform a quick and dirty job :-)
I believe the route map limitation was introduced to force network engineer to think about redistribution and possibly try avoid l00ps.

the config may look something like this (I don't have a 7k to test it at the moment...)
ip prefix-list ALL-NETWORKS seq 5 permit 0.0.0.0/0 le 32 

route-map ALL-NETWORKS permit 10
  match ip address prefix-list ALL-NETWORKS

router ospf 1 
  redistribute rip TEST route-map ALL-NETWORKS

2) redistribution logic is different: with the above configuration ONLY the RIP learned routes are redistributed, NOT the connected routes, even they are participating to the RIP process.
In fact, you are redistributing only the routes that you can see with the "show ip route rip" command.
That's why it's a normal behavior to have R3 receiving only the 1.1.1.0/24 prefix.
The 2.2.2.2/24 and 10.12.12.0/24 routes are NOT redistributed because they are NOT learned via RIP on N7k-2.

To have also the connected N7k-2 routes redistributed into OSPF, you have to perform another redistribution...

3) redistribute CONNECTED need a different command! (can't understand why! the old one was so ugly?)
You need also a route-map to perform the connected redistribution. The config will look something like this:
ip prefix-list CONN seq 5 permit 2.2.2.0/24 
ip prefix-list CONN seq 10 permit 10.12.12.0/24 

route-map CONN>OSPF permit 10
  match ip address prefix-list CONN

router ospf 1 
  redistribute direct route-map CONN>OSPF
You can also avoid using a prefix list and simply use a match interface on the route-map...


Summary: when you are configuring redistribution in NX-OS, probably you will need to configure a double redistribution, the first for the protocol learned routes and the second for the connected routes.




cheers
Marco


{ Advertisement mode on }

If you and your company are interested to learn more about NX-OS and Nexus devices, you may consider to attend a NEXUS Advanced Training Course by Europa Networking, having good chances to have me as instructor. :-)

{ Advertisement mode off }

Tuesday, May 24, 2011

Still alive

Hi all,
some of my readers mailed me or chatted to know if I still alive, well, thanks a lot, I'm actually breathing, but I was busy on various projects in the last 3 months.

I started developing CCIE R&S products for IPExpert Inc, I hope you will see my name listed on the IPExpert web site and my insane labs in their workbooks soon.
That's why I stopped posting labs on the blog, I was using all my fantasy resources for the workbook. (by the way... if you want to buy it... :-) )

Also I managed to collaborate with Europa Networking to deliver an Advanced Nexus Training.

Here's a shot:

It was also a nice opportunity to play a lot with a couple of Nexus platforms, the course was a good balance between theory and practice.
(...and if your organization has just acquired some Nexus platforms or you are planning to use the Nexus 1000V on your VMware infrastructure, take a look on the Europa Networking web site, you have good chances to have me as instructor).

Plans for the future:
-Deliver more and more NX-OS training on various locations worldwide
-Hopefully continue the collaboration with IPExpert
-Do some consulting-spots (1 or 2 weeks) in UK or in other english/german/spanish speaking country (any proposal?)

:-)
Marco

Wednesday, April 13, 2011

Cisco announces Cisco Learning Labs

Hi all,
as probably most of you know, Cisco has announced yesterday a new service:

the "Cisco Learning Labs" based on IOU, IOS on Unix.

You can read all the details on the Cisco Learning Network Store

I found also a very interesting this post of Keith Barker:

https://learningnetwork.cisco.com/blogs/vip-perspectives/2011/04/12/cisco-ios-on-unix-labs-are-available-now

(nice to see the Cisco Learning Labs in action!)

These labs are designed for CCNP, CCIP and CCNA students, they haven't announced anything for CCIEs (not yet maybe?), so what's the interest for a CCIEs candidates?

Well, as you might know, the first part of the CCIE routing and switching exam is based on IOU, so it can be a good idea to try this platform before the "big day", just to see how do you feel on IOU routers and switches.

Marco

nice to read also:

-Greg Ferro's point of view: http://etherealmind.com/cisco-learning-network-iou-labs-students/

-Wendell Odom's point of view: http://www.networkworld.com/community/CLL-1


Demo videos:
By Wendell Odom:


By Keith Barker:

Thursday, March 24, 2011

Got new gadgets

Hi all,
I have received two new gadgets today :-)




The plaque is very nice and elegant!

I'm so extremely busy on projects that haven't even responded to the previous comments, I apologize with readers about that.

I hope to restart blogging very soon and add some amazing news, can't say anything... :-)

cheers
Marco

Monday, February 7, 2011

CCIE LAB Exam result: PASS!

Hi all,

I did the ccie lab exam on Friday 4th, I got the result this morning:

PASS and CCIE #28129


Marco Rizzi CCIE #28129 R&S


The journey was long, starting on 2005 with CCNA, CCNP (2008) and CCIP (2009).
On september 2009 started the CCIE preparation with a written course (at EuropaNetworking), after a while I did the written on dec 2009.
Then, the lab preparation was long and hard, I did approx every evening 2/3 hours studying and labbing, and 2 full days every weekend for a year.
The last month I was doing 8 hours labs everyday and attended a bootcamp at EuropaNetworking.

The exam on Feb 4th:

Starting with troubleshooting, I was a little bit nervous, I had to learn a new interface (perhaps easy) and solve the tickets. I got spare 30 minutes from tshoot, and I started really slow the lab, I was scared about that, anyway I try to read the tasks calm, drawing my diagrams, trying to understand the requirements, the topology...

At home usually I take 1 hour to read and do a scheme of a complete lab, well.... everything in the real lab takes a little bit more, maybe you are just more excited, the stress... who knows.

The fact was that lunch time was there, and I barely touched the machines with show commands, when the proctor said something like "lunch time, guys save your configs" in that moment I realized that I had nothing to save, I did just ten lines on notepad.

That's why it was a bad lunch, I felt terrible, I just stick on another candidate and choosed the same dish, the only word I can articulate was "me too", so I landed to our table with a steak and vegetables, and a sparkling water (In normal condition I will never choose sparkling)

During the lunch I said myself "wake up, wake up, you will recover during the afternoon", and that was helpful a little bit.

I was through the whole lab sections in 3 hour and a half, having enough time to review all and catch some little mistakes.

Then reached the end, I was happy, I had all working as expected and walked to my room at NH Hotel very happy.

When I arrived, called my family, had a shower and relaxed but.... some doubts started... and I asked myself over and over "did I configure in this way? or in this one?" in my mind I found 2 or 3 errors on the configuration section, so I wasn't anymore so sure of my result.

I started friday at 10 pm checking my email, no result.

Then I felt sleep and rechecked on 5.00 am, it was supposed to being a result, but nothing, I rechecked every hour..... began Saturday night, nothing.

On Sunday, opened the mail and ccie certification site in the morning, and until midnight clicked on refresh time to time (read: every 15 mins). Nothing, again.

Then finally on monday morning at 7.30 am the email appeared in my gmail account, and the result was there, on the Ccie Certification Status page:

It was a PASS! I Got the #28129 at FIRST ATTEMPT !

It was definitely more stressful waiting the result than doing the exam! :-)

Next CCIE lab I will remember NOT book on Friday.

I have to thank a lot my beautiful wife to have supported me during the long preparation, she was patient and always motivating me on proceed studying.

I have to thank also Rocco Tessicini of Europa Networking for his extremely high dedication on doing my bootcamp, his labs were hard and tricky. His bootcamp was a detailed review of the core technologies on routing and switching, very recommended.


Now next steps will be:

-reading the book: "OSPF and IS-IS: Choosing an IGP for Large-Scale Networks" by Jeff Doyle, Addison Wesley
and the ISIS chapter of Routing TCP/IP vol.1, to have the necessary knowlege of this wonderful protocol, I was keeping it as is not on the RS blueprint, but looks really interesting.

-have some fun and relax with my family


cheers
Marco Rizzi



Marco Rizzi CCIE #28129 R&S

Friday, January 21, 2011

Today's review lab: MPLS L3 Vpns

Hi all,

today I did a review lab on mpls vpns.

Here is the topology, a nice pyramid form:


and here is the .net file, you may adapt it to your ios path.

.net file [+/-]


autostart = False
[localhost:7200]
workingdir = /tmp
udp = 10000
[[3725]]
ghostios = True
image = /opt/IOS/c3725-adventerprisek9-mz.124-15.T10.bin
ram = 256
sparsemem = True
idlepc = 0x60c056e4
[[ROUTER R1]]
model = 3725
console = 20001
f0/0 = R2 f0/0
f0/1 = R3 f0/0
[[ROUTER R2]]
model = 3725
console = 20002
f0/0 = R1 f0/0
f0/1 = R3 f0/1
slot1 = NM-1FE-TX
f1/0 = R4 f0/0
slot2 = NM-1FE-TX
f2/0 = R5 f0/0
[localhost:7201]
workingdir = /tmp
udp = 10100
[[3725]]
ghostios = True
image = /opt/IOS/c3725-adventerprisek9-mz.124-15.T10.bin
ram = 256
sparsemem = True
idlepc = 0x60c056e4
[[ROUTER R3]]
model = 3725
console = 20003
f0/0 = R1 f0/1
f0/1 = R2 f0/1
slot1 = NM-1FE-TX
f1/0 = R5 f1/0
slot2 = NM-1FE-TX
f2/0 = R6 f0/0
[[ROUTER R5]]
model = 3725
console = 20005
f0/0 = R2 f2/0
f0/1 = R4 f0/1
slot1 = NM-1FE-TX
f1/0 = R3 f1/0
slot2 = NM-1FE-TX
f2/0 = R6 f0/1
[localhost:7202]
workingdir = /tmp
udp = 10200
[[3725]]
ghostios = True
image = /opt/IOS/c3725-adventerprisek9-mz.124-15.T10.bin
ram = 256
sparsemem = True
idlepc = 0x60c056e4
[[ROUTER R6]]
model = 3725
console = 20006
f0/0 = R3 f2/0
f0/1 = R5 f2/0
[localhost:7203]
workingdir = /tmp
udp = 10300
[[3725]]
ghostios = True
image = /opt/IOS/c3725-adventerprisek9-mz.124-15.T10.bin
ram = 256
sparsemem = True
idlepc = 0x60c056e4
[[ROUTER R4]]
model = 3725
console = 20004
f0/0 = R2 f1/0
f0/1 = R5 f0/1



Tasks:
-configure mpls backbone between R2 - R3 - R5 using ospf process 1 and mpBGP as 10
-configure mpls vpn customers on R1 - R4 - R6 using eigrp as 100 on R1, ospf process 2 on R6 and BGP as 400 on R4
-avoid customers route looping in the mpls core

Here are the initial configs, as you can see I used only legacy technology (IPv4) for this lab :-D

Initial config [+/-]


#### R1 initial config ###
hostname R1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
ip address 10.0.12.1 255.255.255.0
no shut
!
interface FastEthernet0/1
ip address 10.0.13.1 255.255.255.0
no shut
end
#### END R1 initial config ###

#### R2 initial config ###
hostname R2
!
ip vrf R1
rd 1:2
!
ip vrf R4
rd 4:2
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
ip vrf forwarding R1
ip address 10.0.12.2 255.255.255.0
no shut
!
interface FastEthernet0/1
ip address 10.0.23.2 255.255.255.0
no shut
!
interface FastEthernet1/0
ip vrf forwarding R4
ip address 10.0.24.2 255.255.255.0
no shut
!
interface FastEthernet2/0
ip address 10.0.25.2 255.255.255.0
no shut
#### END R2 initial config ###

#### R3 initial config ###
hostname R3
!
ip vrf R1
rd 1:3
!
ip vrf R6
rd 6:3
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet0/0
ip vrf forwarding R1
ip address 10.0.13.3 255.255.255.0
no shut
!
interface FastEthernet0/1
ip address 10.0.23.3 255.255.255.0
no shut
!
interface FastEthernet1/0
ip address 10.0.35.3 255.255.255.0
no shut
!
interface FastEthernet2/0
ip vrf forwarding R6
ip address 10.0.36.3 255.255.255.0
no shut
end
#### END R3 initial config ###

#### R4 initial config ###
hostname R4
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
interface FastEthernet0/0
ip address 10.0.24.4 255.255.255.0
no shut
!
interface FastEthernet0/1
ip address 10.0.45.4 255.255.255.0
no shut
end
#### END R4 initial config ###

#### R5 initial config ###
hostname R5
!
ip vrf R4
rd 4:5
!
ip vrf R6
rd 6:5
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
interface FastEthernet0/0
ip address 10.0.25.5 255.255.255.0
no shut
!
interface FastEthernet0/1
ip vrf forwarding R4
ip address 10.0.45.5 255.255.255.0
no shut
!
interface FastEthernet1/0
ip address 10.0.35.5 255.255.255.0
no shut
!
interface FastEthernet2/0
ip vrf forwarding R6
ip address 10.0.56.5 255.255.255.0
no shut
end
#### END R5 initial config ###

#### R6 initial config ###
hostname R6
!
interface Loopback0
ip address 6.6.6.6 255.255.255.255
!
interface FastEthernet0/0
ip address 10.0.36.6 255.255.255.0
no shut
!
interface FastEthernet0/1
ip address 10.0.56.6 255.255.255.0
no shut
end
#### END R6 initial config ###


Please note that I used different RD on the vrfs, to avoid bgp bestpath selection problems during the import/export part later.

Let's start configuring the mpls backbone:
on R2:

mpls label range 2000 2999
mpls label protocol ldp
!
interface FastEthernet0/1
mpls ip
!
interface FastEthernet2/0
mpls ip
!
router ospf 1
router-id 2.2.2.2
log-adjacency-changes
network 2.2.2.2 0.0.0.0 area 0
network 10.0.23.0 0.0.0.255 area 0
network 10.0.25.0 0.0.0.255 area 0
!
router bgp 10
template peer-session IBGP
remote-as 10
update-source Loopback0
exit-peer-session
!
bgp router-id 2.2.2.2
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 3.3.3.3 inherit peer-session IBGP
neighbor 5.5.5.5 inherit peer-session IBGP
!
address-family vpnv4
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 send-community both
neighbor 5.5.5.5 activate
neighbor 5.5.5.5 send-community both
exit-address-family
!
address-family ipv4 vrf R4
no synchronization
exit-address-family
!
address-family ipv4 vrf R1
no synchronization
exit-address-family
!
mpls ldp router-id Loopback0 force

I used the template-peer on R2, just to have a little practice on it, no special meanings in this scenario.

on R3:

mpls label range 3000 3999
mpls label protocol ldp
!
interface FastEthernet0/1
mpls ip
!
interface FastEthernet1/0
mpls ip
!
router ospf 1
router-id 3.3.3.3
log-adjacency-changes
network 3.3.3.3 0.0.0.0 area 0
network 10.0.23.0 0.0.0.255 area 0
network 10.0.35.0 0.0.0.255 area 0
!
router bgp 10
bgp router-id 3.3.3.3
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor IBGP peer-group
neighbor IBGP remote-as 10
neighbor IBGP update-source Loopback0
neighbor 2.2.2.2 peer-group IBGP
neighbor 5.5.5.5 peer-group IBGP
!
address-family vpnv4
neighbor IBGP send-community both
neighbor 2.2.2.2 activate
neighbor 5.5.5.5 activate
exit-address-family
!
address-family ipv4 vrf R6
no synchronization
exit-address-family
!
address-family ipv4 vrf R1
no synchronization
exit-address-family
!
mpls ldp router-id Loopback0 force


on R5:

mpls label range 5000 5999
mpls label protocol ldp
!
interface FastEthernet0/0
mpls ip
!
interface FastEthernet1/0
mpls ip
!
router ospf 1
router-id 5.5.5.5
log-adjacency-changes
network 5.5.5.5 0.0.0.0 area 0
network 10.0.25.0 0.0.0.255 area 0
network 10.0.35.0 0.0.0.255 area 0
!
router bgp 10
bgp router-id 5.5.5.5
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 10
neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 10
neighbor 3.3.3.3 update-source Loopback0
!
address-family vpnv4
neighbor 2.2.2.2 activate
neighbor 2.2.2.2 send-community both
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 send-community both
exit-address-family
!
address-family ipv4 vrf R6
no synchronization
exit-address-family
!
address-family ipv4 vrf R4
no synchronization
exit-address-family
!
mpls ldp router-id Loopback0 force


Then the CE-PE routing:
on R1:

router eigrp 100
network 1.1.1.1 0.0.0.0
network 10.0.12.0 0.0.0.255
network 10.0.13.0 0.0.0.255
no auto-summary
eigrp router-id 1.1.1.1


on R4:

router bgp 400
no synchronization
bgp router-id 4.4.4.4
bgp log-neighbor-changes
network 4.4.4.4 mask 255.255.255.255
network 10.0.24.0 mask 255.255.255.0
network 10.0.45.0 mask 255.255.255.0
neighbor 10.0.24.2 remote-as 10
neighbor 10.0.24.2 send-community both
neighbor 10.0.45.5 remote-as 10
neighbor 10.0.45.5 send-community both
no auto-summary


on R6:

router ospf 2
router-id 6.6.6.6
log-adjacency-changes
network 6.6.6.6 0.0.0.0 area 0
network 10.0.36.0 0.0.0.255 area 0
network 10.0.56.0 0.0.0.255 area 0


Nothing special on customer side, on the provider side you need:

on R2:

router eigrp 1
auto-summary
!
address-family ipv4 vrf R1
redistribute bgp 10 metric 100000 100 255 1 1500
network 10.0.12.0 0.0.0.255
no auto-summary
autonomous-system 100
eigrp router-id 2.2.2.2
exit-address-family
!
router bgp 10
address-family ipv4 vrf R4
neighbor 10.0.24.4 remote-as 400
neighbor 10.0.24.4 activate
neighbor 10.0.24.4 send-community both
no synchronization
exit-address-family
!
address-family ipv4 vrf R1
redistribute eigrp 100
no synchronization
exit-address-family


on R3:

router eigrp 1
auto-summary
!
address-family ipv4 vrf R1
redistribute bgp 10 metric 100000 100 255 1 1500
network 10.0.13.0 0.0.0.255
no auto-summary
autonomous-system 100
eigrp router-id 3.3.3.3
exit-address-family
!
router ospf 2 vrf R6
router-id 10.0.36.3
log-adjacency-changes
redistribute bgp 10 subnets
network 10.0.36.0 0.0.0.255 area 0
!
router bgp 10
address-family ipv4 vrf R6
redistribute ospf 2 vrf R6
no synchronization
exit-address-family
!
address-family ipv4 vrf R1
redistribute eigrp 100
no synchronization
exit-address-family


on R5:

router ospf 2 vrf R6
router-id 10.0.56.5
log-adjacency-changes
redistribute bgp 10 subnets
network 10.0.56.0 0.0.0.255 area 0
!
router bgp 10
address-family ipv4 vrf R6
redistribute ospf 2 vrf R6
no synchronization
exit-address-family
!
address-family ipv4 vrf R4
neighbor 10.0.45.4 remote-as 400
neighbor 10.0.45.4 activate
neighbor 10.0.45.4 send-community both
no synchronization
exit-address-family


Now it's time to play with import/export on vrfs, as you may noticed, on the initial config there where no import/export route-targets.
Let's say that:
-R1 customer must reach R4 prefixes through R3 and R5 (and viceversa)
-R1 customer must reach R6 prefixes through R2 and R5 (and viceversa)

You can obtain this with mpls Traffic Engineering too, but this time I want to test selective imports/exports

Let's configure our PE routes:
on R2:

ip vrf R1
rd 1:2
route-target export 1:2
route-target import 6:5


on R3:

ip vrf R1
rd 1:3
route-target export 1:3
route-target import 4:5


on R5:

ip vrf R4
rd 4:5
route-target export 4:5
route-target import 1:3
!
ip vrf R6
rd 6:5
route-target export 6:5
route-target import 1:2


With this configuration I expect the traffic flowing in this way:


But what happens on R1 customer site? Well, since I'm using two different entry points without any filter in import and export on vrf R1, it happens that R4 routes are exported on R2 as rd:1:2 too, and R6 routes are exported on R3 as rt:1:3.
So R4 and R6 gain an unwanted connectivity:
R4#sh ip route  | beg Gate
Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
B 1.1.1.1 [20/0] via 10.0.45.5, 00:27:31
4.0.0.0/32 is subnetted, 1 subnets
C 4.4.4.4 is directly connected, Loopback0
6.0.0.0/32 is subnetted, 1 subnets
B 6.6.6.6 [20/0] via 10.0.45.5, 00:27:31
10.0.0.0/24 is subnetted, 6 subnets
B 10.0.12.0 [20/0] via 10.0.45.5, 00:27:31
B 10.0.13.0 [20/0] via 10.0.45.5, 00:27:31
C 10.0.24.0 is directly connected, FastEthernet0/0
C 10.0.45.0 is directly connected, FastEthernet0/1
B 10.0.36.0 [20/0] via 10.0.45.5, 00:27:31
B 10.0.56.0 [20/0] via 10.0.45.5, 00:27:31
R4#traceroute 6.6.6.6

Type escape sequence to abort.
Tracing the route to 6.6.6.6

1 10.0.45.5 8 msec 8 msec 4 msec
2 10.0.13.3 [AS 10] [MPLS: Label 3004 Exp 0] 16 msec 8 msec 16 msec
3 10.0.13.1 [AS 10] 20 msec 20 msec 16 msec
4 10.0.12.2 [AS 10] 20 msec 16 msec 24 msec
5 10.0.56.5 [AS 10] [MPLS: Label 5003 Exp 0] 28 msec 28 msec 24 msec
6 10.0.56.6 [AS 10] 32 msec * 48 msec
R4#


ok and how to fix it? well, Site of Origin, also called SoO is not a solution here, mainly because we have different RDs, so mpbgp doesn't find the same SoO extended community on vpnv4 vrfs.

We can filter exports using an export map! Again, no luck, this solution won't work, since if a prefix-list is not matched, the prefix is not blocked. Export maps are used only to set additional route targets to an exported prefix.

A dirty and quick solution can be filter internal eigrp routes during redistribution on mpbgp:

On R2 and on R3:

router bgp 10
address-family ipv4 vrf R1
redistribute eigrp 100 route-map EIGRP>BGP
!
route-map EIGRP>BGP permit 10
match route-type internal

In this way R4 and R6 haven't that l00ped reachability:

R4#sh ip route | b Gate
Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
B 1.1.1.1 [20/0] via 10.0.45.5, 19:55:19
4.0.0.0/32 is subnetted, 1 subnets
C 4.4.4.4 is directly connected, Loopback0
10.0.0.0/24 is subnetted, 4 subnets
B 10.0.12.0 [20/0] via 10.0.45.5, 19:55:19
B 10.0.13.0 [20/0] via 10.0.45.5, 19:55:19
C 10.0.24.0 is directly connected, FastEthernet0/0
C 10.0.45.0 is directly connected, FastEthernet0/1
R4#


Another solution can involve the use of Import maps, but this will force you to filter with a prefix-list the prefixes to import and to deny, not exactly scalable on large customers.


As final, now we need connectivity from R4 to R6 passing through R2 and R3, the configuration is a little bit different, since R4 is running BGP and receives routes from mpBGP as 10. The routes R1 aren't re-imported back on R2, due to BGP same-as loop avoidance.

on R2

ip vrf R4
rd 4:2
route-target export 4:2
route-target import 6:3


on R3:

ip vrf R6
rd 6:3
route-target export 6:3
route-target import 4:2
!
router bgp 10
address-family ipv4 vrf R6
redistribute ospf 2 vrf R6 route-map OSPF>BGP
route-map OSPF>BGP permit 10
match route-type internal


on R5, to avoid re-export with rt 6:5...

router bgp 10
address-family ipv4 vrf R6
redistribute ospf 2 vrf R6 route-map OSPF>BGP
route-map OSPF>BGP permit 10
match route-type internal


OK, now from customers can reach each others using the required paths.

R4#traceroute 1.1.1.1

Type escape sequence to abort.
Tracing the route to 1.1.1.1

1 10.0.45.5 8 msec 8 msec 4 msec
2 10.0.13.3 [AS 10] [MPLS: Label 3003 Exp 0] 24 msec 12 msec 12 msec
3 10.0.13.1 [AS 10] 20 msec * 12 msec
R4#traceroute 6.6.6.6

Type escape sequence to abort.
Tracing the route to 6.6.6.6

1 10.0.24.2 24 msec 4 msec 8 msec
2 10.0.36.3 [AS 10] [MPLS: Label 3004 Exp 0] 16 msec 8 msec 8 msec
3 10.0.36.6 [AS 10] 20 msec * 28 msec
R4#

R1#traceroute 4.4.4.4

Type escape sequence to abort.
Tracing the route to 4.4.4.4

1 10.0.13.3 4 msec 12 msec 4 msec
2 10.0.45.5 [MPLS: Label 5008 Exp 0] 12 msec 8 msec 8 msec
3 10.0.45.4 16 msec * 40 msec
R1#traceroute 6.6.6.6

Type escape sequence to abort.
Tracing the route to 6.6.6.6

1 10.0.12.2 20 msec 8 msec 8 msec
2 10.0.56.5 [MPLS: Label 5003 Exp 0] 8 msec 16 msec 8 msec
3 10.0.56.6 16 msec * 32 msec
R1#

R6#traceroute 1.1.1.1

Type escape sequence to abort.
Tracing the route to 1.1.1.1

1 10.0.56.5 32 msec 12 msec 4 msec
2 10.0.12.2 [MPLS: Label 2003 Exp 0] 24 msec 8 msec 12 msec
3 10.0.12.1 20 msec * 28 msec
R6#traceroute 4.4.4.4

Type escape sequence to abort.
Tracing the route to 4.4.4.4

1 10.0.36.3 8 msec 8 msec 4 msec
2 10.0.24.2 [MPLS: Label 2009 Exp 0] 8 msec 8 msec 12 msec
3 10.0.24.4 16 msec * 20 msec
R6#


Note also that there's no backup connectivity in case of one customer loose a PE exit point, so this is absolutely NOT a best practice, it's just a lab.
:-D

have a nice weekend
Marco

Thursday, January 13, 2011

Administrative Distance Mini-Labs

Days ago a friend asked me some clarifications about administrative distance during a redistribution task.
I suggested him to take the time and test administrative distance in a simple topology, then finished to test myself too and to propose 3 mini labs to my readers.

Here is the topology: simply 4 routers with two loopbacks to redistribute as external.



Minilab 1: EIGRP and OSPF redistribution. How to obtain the optimal path to reach R4 Lo0?


Minilab 2: RIP and EIGRP redistribution. Same problem as previous, but a different configuration must be done.


Minilab 3: RIP and OSPF redistribution. Same story, again.


Ok, well, I don't provide any initial configuration here.
Try to figure out what can be the problem for each minilab, and one or more possible solutions.

This is my approach to redistribution problems: first think, make a simple diagram for redistribution, then configure and test.
In this way, you already know looking at the topology where and when there will be problems.

Problem sources during redistribution, in my opinion and experience:

-EIGRP external routes. (that damn AD 170...)
-OSPF nssa/stub areas. (have to think on it differently from the rest of ospf domain)
-filters on particular prefixes on one protocol of a single router (that prefix will be learned through other protocol on that router, loops are possible)
-OSPF transit capability (if disabled ad hoc, in a middle of one area with virtual-links, can cause loops)

Hoping that someone of my readers will try these minilabs and post his/her opinons about, I go back to my studies. (sorry but I don't have time now to write a detailed explaination... :-) )

Marco