Tag Archives: ip

Quick and dirty way to create a bunch of loopbacks with IP addresses

This can be handy when doing some sort of BGP lab. There are ways to pull various source data with real prefixes into BGP, but sometimes you just want to create a bunch of local addresses.

Daniel helped me out with this initially and I’ve simple added a couple of things.

This is the script on my linux box:

#!/usr/bin/perl
for ($ip=1; $ip<256; $ip++)
{
print "interface loopback$ip\n";
print "ip address 1.2.3.$ip 255.255.255.255\n";
print "ip address 2.2.3.$ip 255.255.255.255 secondary\n";
print "ip address 3.2.3.$ip 255.255.255.255 secondary\n";
print "ip address 4.2.3.$ip 255.255.255.255 secondary\n";
print "ip address 5.2.3.$ip 255.255.255.255 secondary\n";
print "ip address 6.2.3.$ip 255.255.255.255 secondary\n";
print "ip address 7.2.3.$ip 255.255.255.255 secondary\n";
print "ip address 8.2.3.$ip 255.255.255.255 secondary\n";
print "ip address 9.2.3.$ip 255.255.255.255 secondary\n";
print "ip address 10.2.3.$ip 255.255.255.255 secondary\n";
print "ip address 11.2.3.$ip 255.255.255.255 secondary\n";
print "ip address 12.2.3.$ip 255.255.255.255 secondary\n";
print "ip address 13.2.3.$ip 255.255.255.255 secondary\n";
print "ip address 14.2.3.$ip 255.255.255.255 secondary\n";
print "ip address 15.2.3.$ip 255.255.255.255 secondary\n";
print "ip address 16.2.3.$ip 255.255.255.255 secondary\n";
print "ip address 17.2.3.$ip 255.255.255.255 secondary\n";
print "ip address 18.2.3.$ip 255.255.255.255 secondary\n";
print "ip address 19.2.3.$ip 255.255.255.255 secondary\n";
print "ip address 20.2.3.$ip 255.255.255.255 secondary\n";
}

Running the script spits out a ton of IPs:

./IP_Generate.pl
interface loopback1
ip address 1.2.3.1 255.255.255.255
ip address 2.2.3.1 255.255.255.255 secondary
ip address 3.2.3.1 255.255.255.255 secondary
ip address 4.2.3.1 255.255.255.255 secondary
ip address 5.2.3.1 255.255.255.255 secondary
ip address 6.2.3.1 255.255.255.255 secondary
ip address 7.2.3.1 255.255.255.255 secondary
ip address 8.2.3.1 255.255.255.255 secondary
ip address 9.2.3.1 255.255.255.255 secondary
ip address 10.2.3.1 255.255.255.255 secondary
ip address 11.2.3.1 255.255.255.255 secondary
ip address 12.2.3.1 255.255.255.255 secondary
ip address 13.2.3.1 255.255.255.255 secondary
ip address 14.2.3.1 255.255.255.255 secondary
ip address 15.2.3.1 255.255.255.255 secondary
ip address 16.2.3.1 255.255.255.255 secondary
ip address 17.2.3.1 255.255.255.255 secondary
ip address 18.2.3.1 255.255.255.255 secondary
ip address 19.2.3.1 255.255.255.255 secondary
ip address 20.2.3.1 255.255.255.255 secondary
interface loopback2
ip address 1.2.3.2 255.255.255.255
ip address 2.2.3.2 255.255.255.255 secondary
ip address 3.2.3.2 255.255.255.255 secondary
ip address 4.2.3.2 255.255.255.255 secondary
ip address 5.2.3.2 255.255.255.255 secondary
ip address 6.2.3.2 255.255.255.255 secondary
ip address 7.2.3.2 255.255.255.255 secondary
ip address 8.2.3.2 255.255.255.255 secondary
ip address 9.2.3.2 255.255.255.255 secondary
ip address 10.2.3.2 255.255.255.255 secondary
ip address 11.2.3.2 255.255.255.255 secondary
ip address 12.2.3.2 255.255.255.255 secondary
ip address 13.2.3.2 255.255.255.255 secondary
ip address 14.2.3.2 255.255.255.255 secondary
ip address 15.2.3.2 255.255.255.255 secondary
ip address 16.2.3.2 255.255.255.255 secondary
ip address 17.2.3.2 255.255.255.255 secondary
ip address 18.2.3.2 255.255.255.255 secondary
ip address 19.2.3.2 255.255.255.255 secondary
ip address 20.2.3.2 255.255.255.255 secondary
interface loopback3
ip address 1.2.3.3 255.255.255.255
ip address 2.2.3.3 255.255.255.255 secondary
ip address 3.2.3.3 255.255.255.255 secondary
ip address 4.2.3.3 255.255.255.255 secondary
ip address 5.2.3.3 255.255.255.255 secondary
ip address 6.2.3.3 255.255.255.255 secondary
ip address 7.2.3.3 255.255.255.255 secondary
ip address 8.2.3.3 255.255.255.255 secondary
ip address 9.2.3.3 255.255.255.255 secondary
ip address 10.2.3.3 255.255.255.255 secondary
ip address 11.2.3.3 255.255.255.255 secondary
ip address 12.2.3.3 255.255.255.255 secondary
ip address 13.2.3.3 255.255.255.255 secondary
ip address 14.2.3.3 255.255.255.255 secondary
ip address 15.2.3.3 255.255.255.255 secondary
ip address 16.2.3.3 255.255.255.255 secondary
ip address 17.2.3.3 255.255.255.255 secondary
ip address 18.2.3.3 255.255.255.255 secondary
ip address 19.2.3.3 255.255.255.255 secondary
ip address 20.2.3.3 255.255.255.255 secondary
etc
etc
etc
...

You can redirect that to a text file to import or whatever. Adjust as needed

Reliable static routing without the need for the data license

Sometimes it’s required that you have a number of static routes on a router, maybe for management or some other reason. If the static route point to a next-hop, but the exit interface stays up, there is no way for the router to know that it’s sending traffic down a black hole. Let’s show the following diagram as an example:
reliable static Reliable static routing without the need for the data license

R2 is a CPE on site. It has a primary link on fa0/0 connected to both R3 and R4 through a switch/VPLS. R2 is running OSPF with R3 and R4 and also has a floating static default route to R4′s fa0/0 interface. If this link goes down, the floating static route should come into play and take over. While the link is up we have a static route on R2 that sends our management traffic (10.0.0.0/24) to R4′s fa0/0 interface.

R3 is originating a default route via OSPF.

But does this actually work? Let’s configure it up quickly first and then break R2′s primary link.

R3:

interface FastEthernet0/0
 ip address 192.168.234.3 255.255.255.0
 ip ospf 1 area 0
!
router ospf 1
 default-information originate always

R4:

interface FastEthernet0/0
 ip address 192.168.234.4 255.255.255.0
 ip ospf 1 area 0
!
interface Serial0/0
 ip address 24.24.24.4 255.255.255.0

R2

interface FastEthernet0/0
 ip address 192.168.234.2 255.255.255.0
 ip ospf 1 area 0
!
interface Serial0/0
 ip address 24.24.24.2 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 24.24.24.4 200
ip route 10.0.0.0 255.255.255.0 192.168.234.4

Let’s have a look at R2′s routing table:

R2#   sh ip route | begin Gate
Gateway of last resort is 192.168.234.3 to network 0.0.0.0

C    192.168.234.0/24 is directly connected, FastEthernet0/0
     24.0.0.0/24 is subnetted, 1 subnets
C       24.24.24.0 is directly connected, Serial0/0
     10.0.0.0/24 is subnetted, 1 subnets
S       10.0.0.0 [1/0] via 192.168.234.4
O*E2 0.0.0.0/0 [110/1] via 192.168.234.3, 00:01:22, FastEthernet0/0

All looks good. I have my OSPF default route and I also have my management range route to R4.

Now for some reason, R2′s primary link fails. The fa0/0 interface stays up however.The link is dodgy, r there is a mess-up with the VPLS, it doesn’t really matter. What happens then?

R2 loses it’s adjacency with R4, but what about our management traffic?

R2#   sh ip route | begin Gate
Gateway of last resort is 24.24.24.4 to network 0.0.0.0

C    192.168.234.0/24 is directly connected, FastEthernet0/0
     24.0.0.0/24 is subnetted, 1 subnets
C       24.24.24.0 is directly connected, Serial0/0
     10.0.0.0/24 is subnetted, 1 subnets
S       10.0.0.0 [1/0] via 192.168.234.4
S*   0.0.0.0/0 [200/0] via 24.24.24.4

The problem is that we are still sending management traffic off to R4. This is the problem with a static route, it’s static! R2 has a next-hop of 192.168.234.4 – It’s interface in this subnet is still up, and so the router is trying to ARP for 192.168.234.4. Of course R4 never responds but the router will continue to try. It’ll never fail over to the backup.

Now with reliable static routing you are able to generate an IP Sla object which consistently pings another interface. If you get no response you cause the track object to go down and hence the static route goes down. The problem with this is that you need an expensive data license for the privilege of doing this.

But track objects can track a lot more than just IP Sla objects. You can also track routes. So why not track the default route considering we are learning that through the primary link? If the primary fails and OSPF times out, we will remove the OSPF default. Let’s try and see what happens:

R2:

track 1 ip route 0.0.0.0 0.0.0.0 reachability
!
ip route 10.0.0.0 255.255.255.0 192.168.234.4 track 1

Some of you may see a problem here, but bear with me.

Let’s see if this has fixed the problem:

R2#   sh ip route | begin Gate
Gateway of last resort is 24.24.24.4 to network 0.0.0.0

C    192.168.234.0/24 is directly connected, FastEthernet0/0
     24.0.0.0/24 is subnetted, 1 subnets
C       24.24.24.0 is directly connected, Serial0/0
     10.0.0.0/24 is subnetted, 1 subnets
S       10.0.0.0 [1/0] via 192.168.234.4
S*   0.0.0.0/0 [200/0] via 24.24.24.4

Hmm, we are still sending traffic to R4′s fa0/0 interface. Why is this?

R2#sh track 1
Track 1
  IP route 0.0.0.0 0.0.0.0 reachability
  Reachability is Up (static)
    1 change, last change 00:04:22
  First-hop interface is Serial0/0
  Tracked by:
    STATIC-IP-ROUTING 0

The problem is that our floating static route went live. As soon as it did we had a default route again and hence the track object is now UP.

But you don’t HAVE to track a default route. Why don’t we simply inject a phantom prefix on R3? One that will simply be used for tracking?

R3:

interface Loopback1
 ip address 3.3.3.3 255.255.255.255
 ip ospf 1 area 0

R2:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#no track 1
R2(config)#track 1 ip route 3.3.3.3/32 reachability

R2 is now tracking the loopback route from R3:

R2#sh track 1
Track 1
  IP route 3.3.3.3 255.255.255.255 reachability
  Reachability is Up (OSPF)
    2 changes, last change 00:00:03
  First-hop interface is FastEthernet0/0
  Tracked by:
    STATIC-IP-ROUTING 0
R2#   sh ip route | begin Gate
Gateway of last resort is 192.168.234.3 to network 0.0.0.0

     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/11] via 192.168.234.3, 00:00:24, FastEthernet0/0
C    192.168.234.0/24 is directly connected, FastEthernet0/0
     24.0.0.0/24 is subnetted, 1 subnets
C       24.24.24.0 is directly connected, Serial0/0
     10.0.0.0/24 is subnetted, 1 subnets
S       10.0.0.0 [1/0] via 192.168.234.4
O*E2 0.0.0.0/0 [110/1] via 192.168.234.3, 00:00:24, FastEthernet0/0

R2 now loses OSPF adjacency:

R2#
*Mar  1 00:38:51.919: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.234.3 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired
R2#
*Mar  1 00:38:55.239: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.234.4 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired
R2#
*Mar  1 00:39:05.307: %TRACKING-5-STATE: 1 ip route 3.3.3.3/32 reachability Up->Down
R2#
R2#sh track 1
Track 1
  IP route 3.3.3.3 255.255.255.255 reachability
  Reachability is Down (no route)
    3 changes, last change 00:00:11
  First-hop interface is unknown
  Tracked by:
    STATIC-IP-ROUTING 0
R2#   sh ip route | begin Gate
Gateway of last resort is 24.24.24.4 to network 0.0.0.0

C    192.168.234.0/24 is directly connected, FastEthernet0/0
     24.0.0.0/24 is subnetted, 1 subnets
C       24.24.24.0 is directly connected, Serial0/0
S*   0.0.0.0/0 [200/0] via 24.24.24.4

R2 loses the track route, removes the static and install the floating static route. All is good :)

I know there are better ways of doing the above. As in advertise management ranges via OSPF or running BFD, but not all of these are always available, especially over back up links.

Do we now need a security IOS license simply to provide OSPF authentication for IPv6?

While going through the CCIE 4th edition cert guide, I’ve come across something that is potentially a very big problem. Currently if you want to authenticate OSPF and EIGRP neighbours you can do so via plain-text or MD5 passwords. With IPv6 you need to use OSPFv3 and EIGRP. Here’s where it get’s bad. OSPFv3 does NOT give you the option to use authentication in the OSPFv3 configuration section. Rather it relies on IPv6′s inherent authentication properties.

However!

In order to use IPv6′s authentication properties, you NEED a crypto license on your device. This means you can no longer authenticate OSPF for IPv6 with a base license IOS. EIGRP on the other hand still allows you to authenticate with MD5 and plain-text. Let’s put this to the test.

I’ve got a vanilla Cisco 1941 here with the base license.

1941test(config-if)#ipv6 ospf ?
  <1-65535>            Process ID
  cost                 Route cost of this interface
  database-filter      Filter OSPF LSA during synchronization and flooding
  dead-interval        Interval after which a neighbor is declared dead
  demand-circuit       OSPF demand circuit
  flood-reduction      OSPF Flood Reduction
  hello-interval       Time between HELLO packets
  mtu-ignore           Ignores the MTU in DBD packets
  network              Network type
  priority             Router priority
  retransmit-interval  Time between retransmitting lost link state
                       advertisements
  transmit-delay       Link state transmit delay

What I’m looking for is the ipv6 ospf authentication ipsec command. As I have no security license, it’s not there.

1941test(config-router)#ipv6 router ospf 1
1941test(config-rtr)#area 0 ?
  default-cost  Set the summary default-cost of a NSSA/stub area
  nssa          Specify a NSSA area
  range         Summarize routes matching address/mask (border routers only)
  stub          Specify a stub area

No area 0 authentication option!

Interestingly enough, EIGRP for IPv6 still uses EIGRP’s internal authentication algorithm.

interface GigabitEthernet0/1
 ip address 10.0.4.254 255.255.255.252
 ipv6 address 2001:D08::C671:FEFF:FE65:55A1/64
 ipv6 eigrp 1
 ipv6 authentication mode eigrp 1 md5
 ipv6 authentication key-chain eigrp 1 chain
!
key chain chain
 key 1
  key-string 7 010703174F

The problem with authentication being left to IPv6 itself, is shown in this very example. As far as I can see, unless you’re buying an expensive security license for each and every OSPF router, you can forget about authenticating your OSPF adjacencies!

I hope I’m mistaken. If anyone has a way of getting it to work, I’d like to know.

Updated post here: http://mellowd.co.uk/ccie/?p=1421

Juniper olive on old Nokia IP330

I’ve been wanting to do more Juniper studies. Unfortunately at work we only have 2 Junipers on the BGP edge so we don’t exactly get to play with them.

I’ve known about olives on the PC for a while, but I wanted something better. I could not afford to buy a J2300 so I went he next best route – The 1U Olive

I’ve just got it working too!

root> show version
Model: olive
JUNOS Base OS boot [7.1R2.2]
JUNOS Base OS Software Suite [7.1R2.2]
JUNOS Kernel Software Suite [7.1R2.2]
JUNOS Packet Forwarding Engine Support (M20/M40) [7.1R2.2]
JUNOS Routing Software Suite [7.1R2.2]
JUNOS Online Documentation [7.1R2.2]
JUNOS Crypto Software Suite [7.1R2.2]

root> show interfaces terse
Interface Admin Link Proto Local Remote
dsc up up
fxp0 up down
fxp1 up down
fxp2 up down
gre up up
ipip up up
lo0 up up
lo0.16385 up up inet
inet6 fe80::200:ff:fe00:1
lsi up up
mtun up up
pimd up up
pime up up
tap up up

I’ve got a couple of other IP330′s so I just need to replicate this. I’ll stick this in the lab. This essentially gives 4 me Juniper routers!

The next step is to upgrade the JUNOS version on this one and do a few more. Then put them together and see what happens.

HSRP Object tracking

HSRP can track interfaces, which is pretty handy if they are tracking the WAN interface to get out the network. There are times when tracking the interface itself is not enough. This is a great example:
HSRPObject1 HSRP Object tracking

Our customer is running HSRP between 2 routers connected to his local LAN. All PC’s connected to his switch are using 10.1.1.254 as their default gateway. R1 is the primary HSRP router and R2 is the backup.

HSRP allows you to track an interface and lower the priority if this happens. So let’s say R1′s WAN interface goes down, HSRP will notice that, and allow R2 to take over the HSRP group. This allows the customer to continue to get to the cloud. A basic config here:
R1:

interface FastEthernet0/1
 description LAN
 ip address 10.1.1.1 255.255.255.0
 standby version 2
 standby 1 ip 10.1.1.254
 standby 1 priority 110
 standby 1 preempt
 standby 1 track FastEthernet0/0 65

R2:

interface FastEthernet0/1
 description LAN
 ip address 10.1.1.2 255.255.255.0
 standby version 2
 standby 1 ip 10.1.1.254
 standby 1 preempt
 standby 1 track FastEthernet0/0 50

What happens if the interface stays up though? In the above diagram, R1′s WAN interface connects to a switch. Now this could be a local switch or a 3rd party NTE (which often happens on leased lines) – The circuit from the switch to the cloud could be down, but the port between the router and switch are still up.HSRPObject2 HSRP Object tracking
As far as HSRP is concerned, that interface is up and healthy. All LAN PC’s will continue to send traffic to R1, but that traffic gets dropped at the switch. Another case is if you’ve got some sort of MPLS/VPLS solution with your provider. They could have a problem and all traffic is getting black-holed inside their network. But R1 still thinks the link is healthy and sends it on it’s way.

There is a better way of doing this.

IOS allows you to track object. An object could be an IP SLA instance. That IP SLA instance could very easily be an ICMP echo from another device in the cloud. See where I’m going here?

Assume R3 has a rock solid connection. We could assume is a big bad router with multiple power feeds on multiple phases with multiple WAN connections. 192.168.1.1 is the loopback of this device accessible from multiple connections. Basically we assume that 192.168.1.1 is ALWAYS available.

Let’s create an IP SLA instance that tests connectivity to 192.168.1.1. We then tell HSRP to track reachability to that instance. If it cannot get to the instance, we can assume that the link to it is dead, regardless of whether R1′s WAN interface is up or not. First up is the IP SLA instance:

ip sla monitor 10
 type echo protocol ipIcmpEcho 192.168.1.1
 frequency 5
ip sla monitor schedule 10 life forever start-time now

Here we’ve told the router to ping 192.168.1.1 every 5 seconds and never stop. If I get a reply, consider the SLA a success. If I get no response, consider it a failure.

Now we tell IOS that we want to create an object and track this IP SLA instance:

track 100 rtr 10

I create an object labelled 100 that is tracking instance 10 of IP SLA we created above.

We now amend R1′s HSRP config as follows:

interface FastEthernet0/1
 description LAN
 ip address 10.1.1.1 255.255.255.0
 no ip redirects
 standby version 2
 standby 1 ip 10.1.1.254
 standby 1 priority 110
 standby 1 preempt
 standby 1 track FastEthernet0/0 65
 standby 1 track 100 decrement 65

I’ve kept the interface tracking there as if it goes down, why wait for IP SLA to timeout?

But does it work? Let’s have a look and see. Let’s kill S1′s connection into the cloud. Once that’s done, let’s have a look at R1:

R13#sh standby
FastEthernet0/1 - Group 1 (version 2)
  State is Standby
    7 state changes, last state change 00:01:08
  Virtual IP address is 10.1.1.254
  Active virtual MAC address is 0000.0c9f.f001
    Local virtual MAC address is 0000.0c9f.f001 (v2 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 0.052 secs
  Preemption enabled
  Active router is 10.1.1.2, priority 100 (expires in 9.052 sec)
  Standby router is local
  Priority 45 (configured 110)
    Track interface FastEthernet0/0 state Up decrement 65
    Track object 100 state Down decrement 65
  IP redundancy name is "hsrp-Fa0/1-1" (default)

R1#sh int fa0/0
FastEthernet0/0 is up, line protocol is up

IOS is telling us that although the interface is up, it’s passed the HSRP group to R2. Now we don’t have to worry about traffic getting black-holed!

btw, if you need to ping an address and can’t guarantee 100% availability, you could just as easily track 2 objects. Weight it so that only if pings fail to both will the HSRP group failover.