This post was created as a result of a recent groupstudy post regarding self ping over PPPoFR links.
Typically, when you create a PPPoFR link between a pair of routers, you can ping the remote end, due to peer neighbor route.
However you can’t ping your OWN interface ip.

Consider the following scenario.

R1 s0/0.12  ————— s0/0.21 R2

There is a PPPoFR link configured between R1 & R2, with the following configuration:

R1

int s0/0.12
frame int 102 ppp virtual-temp 12
int virtual-temp 12
ip add 1.1.1.1 255.0.0.0

R2

int s0/0.21
frame int 201 ppp virtual-temp 21
int virtual-temp 21
ip add 2.2.2.2 255.0.0.0

With this setup, R1 can ping 2.2.2.2 (R2) & R2 can ping 1.1.1.1 (R1).
This is because peer neighbor route (enabled by default for ppp links) results in:

• R1 receiving a /32 host route for 2.0.0.0
• R2 receiving a /32 host route for 1.0.0.0

The routing table below for R1 & R2 confirm this:

R1#sh ip ro | i /32
2.0.0.0/32 is subnetted, 1 subnets

R2#sh ip ro | i /32
1.0.0.0/32 is subnetted, 1 subnets

However, neither R1, nor R2 can ping their own IP’s:

R1#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

R2#ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

Hmm…what to do?

Well there are a no of ways to make self ping work with only slight modifications to our PPPoFR setup.
The 1st two revolve around ppp multilink, one without using interface multilink & another with interface multilink.
The 2nd solution merely employs ip unnumbered.

Solution 1 – PPP multilink + NO interface multilink

With 1 line added to R1 & R2 we can resolve the self ping problem
Simply add ppp multilink under the virtual template interfaces and you are golden!

R1

int virtual-temp12
ppp multilink

R2

int virtual-temp21
ppp multilink

You will see some error messages pop up regarding frame relay traffic shaping, but just ignore those.
As can be seen below, both R1 & R2 are now able to ping themselves now!

R1#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/8 ms

R2#ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/8 ms

Solution 2 – PPP Multilink + interface multilink

With this solution we 1st of all create a multilink interface, & tie it to the virtual-template interface.
1st of all let’s return to the original config we had for R1 & R2:

R1

int s0/0.12
frame int 102 ppp virtual-temp 12
int virtual-temp 12
ip add 1.1.1.1 255.0.0.0

R2

int s0/0.21
frame int 201 ppp virtual-temp 21
int virtual-temp 21
ip add 2.2.2.2 255.0.0.0

Modifications we need to make are as follows:

R1

int virtual-temp12
no ip address

int multilink12
ip add 1.1.1.1 255.0.0.0

int virtual-temp12
ppp multilink group 12

R2

int virtual-temp21
no ip address

int multilink21
ip add 2.2.2.2 255.0.0.0

int virtual-temp21
ppp multilink group 21

Once you do this, you see the multilink interface come up & will see some error messages but again, ignore those!

Let’s test this:

R1#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/14/48 ms

R2#ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/8 ms

Cool!

Solution 3 – IP unnumbered under virtual template interface

Again let’s return to our original base configuration:

R1

int s0/0.12
frame int 102 ppp virtual-temp 12
int virtual-temp 12
ip add 1.1.1.1 255.0.0.0

R2

int s0/0.21
frame int 201 ppp virtual-temp 21
int virtual-temp 21
ip add 2.2.2.2 255.0.0.0

Modifications we need to make are simply to move the ip addressing off the virtual template onto a loopback interface & then use ip unnumbered on the virtual template interfaces:

R1

int virtual-temp 12
ip unnumbered loopback0
int lo0
ip add 1.1.1.1 255.0.0.0

R2

int virtual-temp 21
ip unnumbered loopback0
int lo0
ip add 2.2.2.2 255.0.0.0

Testing this solution, again, self ping works just dandy:

R1#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

R2#ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

That’s the end of this post!

This post is a case of being careful, and checking dependencies.

This post follows on the back of my previous blog entry:
RIP updates over pt2pt serial: a few methods

In that post I mentioned that ONE way to get RIP updates across a pt2pt link that has ip addresses in different subnets at both ends is by using ip unnumbered.

To recap, before ip unnumbered we have this:

R1 s0/1 ————- s0/1 R2

R1 s0/1 ip: 10.1.100.1/24
R2 s0/1 ip: 10.11.100.2/24
R1 has no validate update-source in RIP.
R2 performs update source validation in RIP.

R2 rejects R1’s update:
RIP: ignored v2 update from bad source 10.1.100.1 on Serial0/1

So using ip unnumbered to resolve this issue we have:

R1
int s0/1
ip unnumbered lo0
int lo0
ip add 10.1.100.1 255.255.255.0

R2
int s0/1
ip unnumbered lo0
int lo0
ip add 10.11.100.2 255.255.255.0

All is well, R2 accepts the updates from R1:

R2
RIP: received v2 update from 10.1.100.1 on Serial0/1

But say later on we have the following task:

Create the following loopbacks & ensure only the routes that have an ODD no in the 3rd octet are advertised by RIP.

lo0 – 30.3.0.1/24
lo1 – 30.3.1.1/24
lo2 – 30.3.2.1/24
lo3 – 30.3.3.1/24
lo4 – 30.3.4.1/24

When we do this, as R2 s0/1 is ip unnumbered off loopback0, R2 s0/1 ip address changes to 30.3.0.1:

R2(config-router)#do sii
Interface                  IP-Address      OK? Method Status                Protocol
—
Serial0/1                  30.3.0.1 YES TFTP   up                    up

As Serial0/1 ip is now 30.3.0.1 what happens is that R2 now advertises routes to R1 with IP address: 30.3.0.1.

Now R1 WILL receive the RIP routes from R2 with ip 30.3.0.1, but R1 will NOT have reachability to 30.3.0.1 over s0/1:

R1
R       30.3.1.0 [120/1] via 30.3.0.1, 00:00:18, Serial0/1
R       30.3.3.0 [120/1] via 30.3.0.1, 00:00:18, Serial0/1

R1#ping 30.3.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 30.3.0.1, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5) <——————–

If reachability is desired, then clearly you do not want this.

To get around this then, I would say:

• Be wary whenever using ip unnumbered loopback command
• Use a loopback which is unlikely to be used elsewhere in the lab eg..int loopback 2147483647 (the largest loopback no! )
  • R1(config)#int loopback ?
    <0-2147483647>  Loopback interface number

    R1(config)#int loopback 2147483647

Spoiler alert: If you are doing Narbik’s new RIP lab, then please do that 1st before looking at this, otherwise it will just spoil things.

Ok let’s say you have this scenario:

R1 & R2 are connected via a serial link.
HDLC is running over this link.
You can NOT change the encapsulation over this link (ie. no enc frame-relay or ppp )
You need to exchange RIP updates over this link.
R1 can be configured with no validate update-source but R2 can NOT use this command.

R1 s0/1 ————- s0/1 R2

R1 s0/1 ip: 10.1.100.1/24
R2 s0/1 ip: 10.11.100.2/24

So we have R1 & R2 on different subnets.
R1, as it is configured to NOT validate the update source, will accept the routes received from R2 over the serial.
R2 on the other hand, will compain:

R2(config-if)#
IP: s=10.1.100.1 (Serial0/1), d=224.0.0.9, len 512, rcvd 2
RIP: ignored v2 update from bad source 10.1.100.1 on Serial0/1

So how to resolve this situation?
We have a no of ways.
There may be more ways than what I will list, but that’s life

Way 1 – Using ip unnumbered

If we remove the ip addresses from the serial ints & instead place them on loopbacks, while still running ip on the serial links, we can overcome the update source validation issue.

R1

int s0/1

ip unnumbered loopback0

int lo0

ip address 10.1.100.1 255.255.255.0

R2

R1

int s0/1

ip unnumbered loopback0

int lo0

ip address 10.11.100.2 255.255.255.0

Once done, R2 is now able to accept routes from R1:

R2(config-if)#
RIP: received v2 update from 10.1.100.1 on Serial0/1
10.1.4.0/24 via 0.0.0.0 in 2 hops
10.1.12.0/24 via 0.0.0.0 in 1 hops
10.1.13.0/24 via 0.0.0.0 in 1 hops

——- rest of update omitted for brevity purposes

Cool

Way 2 – Using NAT!

Now bear in mind I am using dynamips here, so I do not know if this will work for sure on real routers, but here is another simple solution.
It is based on this idea:
We know R2 cannot accept by default routes from R1 as it is from a different update source.
But what if we changed the updates R1 sends so that R2 sees them coming in from the SAME subnet as R2’s s0/1?
NAT can do this.

R1

ip nat inside source static 10.1.100.1 10.11.100.1
int s0/1
ip nat outside

And thats it!

Debug ip rip & debug ip packet on R2 shows this:

IP: s=10.11.100.1 (Serial0/1), d=224.0.0.9, len 512, rcvd 2
RIP: received v2 update from 10.11.100.1 on Serial0/1
10.1.4.0/24 via 0.0.0.0 in 2 hops
10.1.12.0/24 via 0.0.0.0 in 1 hops
10.1.13.0/24 via 0.0.0.0 in 1 hops

Thats it for now

This example is taken from Narbik’s workbook on redistribution.
For those who don’t have Narbik’s workbooks & can afford to obtain them (they are great value) & have the time to do them, I thoroughly recommend them

Anyway, this tutorial is a great example in being CAREFUL, & rechecking the task to ENSURE you have done what was asked before moving onto the next task.
For those who will be doing Narbiks redistribution labs (Volume 4), Id suggest you dont read this post!

Consider the following scenario:

R1 <==10.1.12.0/24==> R2 <==10.1.23.0/24==> R3

R1 is running RIP only.
R2 is running RIP & OSPF.
R3 is running OSPF only.

We have the following task requirements:

• Create Lo40 on R1: 172.16.0.1/24
• R1 should be configured to advertise this loopback interface into RIPv2
• Ensure that the ONLY 172.16.x.x route present in R2’s routing table is 172.16.0.0/24
• R3 should see 172.16.0.0/16 ONLY & not 172.16.0.0/24

Lets do this:
On R1, let’s create int lo40 with ip 172.16.0.1/24, & have RIP advertise it to R2:

R1
int lo40
ip add 172.16.0.1 255.255.255.0
router rip
net 10.0.0.0
net 172.16.0.0

Checking R2 we see it has the RIP route:

R2#sh ip route rip
172.16.0.0/24 is subnetted, 1 subnets
R       172.16.0.0 [120/1] via 10.1.12.1, 00:00:07, FastEthernet0/0.12

Ok so let’s redistribute this into OSPF so that R3 learns about it:

R2
access-list 1 permit 172.16.0.0
route-map RIP->OSPF permit 10
match ip address 1
router ospf 1
redistribute rip subnets route-map RIP->OSPF

Checking R3 we see that it has 172.16.0.0/24:

R3#sh ip ro
–
172.16.0.0/24 is subnetted, 1 subnets
O E2    172.16.0.0 [110/20] via 10.1.23.2, 00:00:01, FastEthernet0/0

However checking the task:

• R3 should see 172.16.0.0/16 ONLY & not 172.16.0.0/24

Now of course, when we redistributed the RIP route into OSPF on R2, R2 immediately became an ASBR.
As such we are able to summarise any redistributed routes with the summary-address command under the ospf process.

R2
router ospf 1
summary-address 172.16.0.0 255.255.0.0

If we check R3 now, we see that we have indeed met the task requirement of R3 ONLY having 172.16.0.0/16 in its RIB:

R3#sh ip ro
—
O E2 172.16.0.0/16 [110/20] via 10.1.23.2, 00:34:43, FastEthernet0/0

Now some people may easily move onto the next task in “error” thinking they have the full marks for the task.
But we are not done yet.

We still have the following task requirement:

• Ensure that the ONLY 172.16.x.x route present in R2’s routing table is 172.16.0.0/24

By default, the commands summary-address on ASBRs (& area-range on ABRs), create a discard route to Null0:

R2#sh ip ro
—
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
R       172.16.0.0/24 [120/1] via 10.1.12.1, 00:00:11, FastEthernet0/0.12
O       172.16.0.0/16 is a summary, 00:00:10, Null0

This VIOLATES the task requirement:

• Ensure that the ONLY 172.16.x.x route present in R2’s routing table is 172.16.0.0/24

So we need to remove the discard route.
As the discard route was generated when we redistributed a RIP route into OSPF we do:

R2
router ospf 1
no discard-route external

(NB, we would use no discard-route internal if we wanted to remove a discard route created with the area-range command)

Now rechecking R2 we see we have met the task requirement:

R2#sh ip ro
–
172.16.0.0/24 is subnetted, 1 subnets
R       172.16.0.0 [120/1] via 10.1.12.1, 00:00:09, FastEthernet0/0.12

————-

This is an easy scenario, but I hope it goes to show some people (& that includes me!) that you really do need to be careful in rechecking you have the task requirements before moving on from the task.

Happy labbing!

With incompatible network types, if the hello/dead timers match, we can get the OSPF adjacency to form BUT no OSPF routes will be installed.

Consider the following topology:

R1 s0/0.12 <====102===201====> s0/0 R2

R1 & R2 are connected via a frame relay PVC.
R1 s0/0.12 & R2 s0/0 are both in OSPF Area 2.

Configs:

R1

interface Serial0/0.12 point-to-point
ip address 10.1.12.1 255.255.255.0
ip ospf 1 area 2
ip ospf network point-to-multipoint non-broadcast
frame-relay interface-dlci 102

R2

interface Serial0/0
ip address 10.1.12.2 255.255.255.0
encapsulation frame-relay
ip ospf 1 area 2
ip ospf network non-broadcast
ip ospf priority 0
frame-relay map ip 10.1.12.1 201 broadcast
no frame-relay inverse-arp

The following interfaces on R1 & R2 are participating in OSPF:

R1#sh ip o int b
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0          1        0               1.1.1.1/8          1     LOOP  0/0
Se0/0.12     1      2               10.1.12.1/24       64    P2MP  1/1

R2#sh ip o int b
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Se0/0        1     2               10.1.12.2/24       64    DROTH 1/1
Lo0          1     2               2.2.2.2/8          1     LOOP  0/0

Now R1 & R2 are incompatible network types, but as they have the same hello/dead timers (hello – 30, dead – 120), a full OSPF adjacency is formed, so R1 & R2 HAVE synched their LSDBs:

R1#sh ip o n

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/  - 00:01:56    10.1.12.2       Serial0/0.12

R2#sh ip o n

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/DR 00:01:56    10.1.12.1       Serial0/0

Notice above that the neighbor state on R1 is FULL/- i.e no DR/BDR election takes place, as opposed to R1 seeing neighbor state as FULL/DR.
The config on R2 has ip ospf priority 0, so R2 knows it CANT be the DR, & so thinks that R1 MUST be the DR, even though R1 does not engage in the DR/BDR election.

However neither R1 nor R2 have INSTALLED the OSPF routes into their respective routing tables, due to the incompatible network types, as seen below:

R1# sh ip ro os
R1#

R2# sh ip ro os
R2#

What to do?
Well we can resolve this by making both R1 & R2 network types compatible with each other.
See the INE blog article if you are unaware about which network types are compatible.

However what if we had the following scenario:

• Ensure that these routers install OSPF routes into their routing tables, WITHOUT changing the network types.

Hmm…

Well we can resolve this using good ol’ GRE tunnels.
What we will do is create a GRE tunnel in Area 0 to connect R1’s Area 2 to R2’s Area 2.

Config

R1

interface Tunnel12
ip address 200.1.1.1 255.255.255.0
ip ospf 1 area 0
tunnel source Serial0/0.12
tunnel destination 10.1.12.2

R2

interface Tunnel21
ip address 200.1.1.2 255.255.255.0
ip ospf 1 area 0
tunnel source Serial0/0
tunnel destination 10.1.12.1

R1#sh ip ro os
2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/11112] via 200.1.1.2, 00:00:14, Tunnel12

Ok looks good so far…but wait:

R1#
*Mar  1 08:26:30.602: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Tunnel12 from FULL to DOWN, Neighbor Down: Dead timer expired
R1#
*Mar  1 08:27:01.473: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Tunnel12 from LOADING to FULL, Loading Done
R1#

Checking R2 we see recursive routing issues!

R2#
*Mar  1 08:27:03.941: %TUN-5-RECURDOWN: Tunnel21 temporarily disabled due to recursive routing
*Mar  1 08:27:04.942: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel21, changed state to down
*Mar  1 08:27:04.942: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Tunnel21 from FULL to DOWN, Neighbor Down: Interface down or detached
R2#u all
*Mar  1 08:28:04.945: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel21, changed state to up
*Mar  1 08:28:05.265: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Tunnel21 from LOADING to FULL, Loading Done

The problem is this.
When the tunnel comes up, a /32 route for 10.1.12.1/32 gets advertised by R1 to R2.
When R2 receives this route, as it is more specific than the /24 route that R2 has for its direct connection to R1, the 10.1.12.1/32 route is preferred.
But this /32 host route is learned via the tunnel, and as we know you cannot route to the tunnel destination VIA the tunnel itself.
Hence we have recursive routing issues.

With tunnel DOWN:

R2#sh ip ro 10.1.12.1
Routing entry for 10.1.12.0/24
Known via “connected”, distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Serial0/0
Route metric is 0, traffic share count is 1

With tunnel UP:

R2#sh ip ro 10.1.12.1
Routing entry for 10.1.12.1/32
Known via “ospf 1″, distance 110, metric 11111, type inter area
Last update from 200.1.1.1 on Tunnel21, 00:00:01 ago
Routing Descriptor Blocks:
* 200.1.1.1, from 1.1.1.1, 00:00:01 ago, via Tunnel21
Route metric is 11111, traffic share count is 1

Now some of you may be wondering why R2 is receiving /32 host route in the 1st place.
The reason?
We have ip ospf network point-to-multipoint non-broadcast on R1 s0/0.12 !

R1#sh run int s0/0.12 | i ospf
ip ospf network point-to-multipoint non-broadcast
ip ospf 1 area 2

With the network types ip ospf network point-to-multipoint non-broadcast, ( & ip ospf network point-to-multipoint), R1 advertises all routes to R2 with a /32 host route that is itself.

As the /32 host route 10.1.12.1 just happens to correspond to R2’s tunnel DESTINATION, it is R2 that is having trouble with routing to the tunnel destination VIA the tunnel.

We can resolve this issue in a few ways:

1) Change the network type on R1 <— not permitted to by our task requirement!
2) NOT run OSPF on R1’s serial0/0.12 interface!

The reason 2) works is that, after all we really don’t NEED to be running OSPF, and advertising 10.0.12.0/24 to R2, as it already knows about it, as it is directly connected.
This plus the fact that we are using a GRE tunnel, so there is no NEED to be running OSPF on the serial interfaces when we want OSPF to run on the GRE tunnel between R1 & R2.

Config:

R1(config)#int s0/0.12
R1(config-subif)#no ip ospf 1 area 2
R1#
*Mar  1 08:42:59.655: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial0/0.12 from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar  1 08:43:00.509: %SYS-5-CONFIG_I: Configured from console by console
R1#
*Mar  1 08:43:21.555: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Tunnel12 from LOADING to FULL, Loading Done

Now if we check R1 & R2 we see they are both seeing each other’s loopbacks & all is well!

R1#sh ip ro | b Gate
Gateway of last resort is not set

C    1.0.0.0/8 is directly connected, Loopback0
2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/11112] via 200.1.1.2, 00:01:01, Tunnel12
C    200.1.1.0/24 is directly connected, Tunnel12
10.0.0.0/24 is subnetted, 1 subnets
C       10.1.12.0 is directly connected, Serial0/0.12

R2#sh ip ro | b Gate
Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/11112] via 200.1.1.1, 00:00:32, Tunnel21
C    2.0.0.0/8 is directly connected, Loopback0
C    200.1.1.0/24 is directly connected, Tunnel21
10.0.0.0/24 is subnetted, 1 subnets
C       10.1.12.0 is directly connected, Serial0/0

As can be seen above, no issues with learning /32 host routes

That’s it for this tutorial.