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