I can’t tell you how many times I’ve seen this when speaking to customers. I ask what their LAN range is and they’ll give me something like 192.10.0.0/16

Hang on a minute, has your provider assigned 192.10.0.0/16 for you to use on your network? Of course not! So why exactly are you using it?

Typical excuses:
1. “When I started working at the company it was addressed that way”
2. “It’s always worked, so why change it?”
3. “We NAT our traffic when going out to the internet, so what harm does it do?”

My responses:
1. Perhaps you were employed to make better changes to the network? Surely you have a plan to change the internal network addressing some time? Are you just going to continue to run bad practice?
2. It will eventually break something. The reason why is shown in point #3
3. In the above example, Customer A says that they are using 192.10.0.0/16 internally. They have essentially assigned 65535 public IP’s for use inside their LAN. But they are NAT’ing, so what’s the harm? Let’s say user 1 in Customer A needs to use a service on the internet. That service happened to be assigned a public address in the range that Customer A is now using on their LAN. What’s going to happen? They are going to happilly send traffic off to 192.10.100.50 – only for their router to send that traffic straight back into the LAN. – You’ve now black-holed 65535 public IP’s getting reached from within your network.

RFC1918 gives you a total of 16 843 007 addresses to use. More than enough! Use them!

/rant

Tagged with:  

MHSRP & OSPF design

On September 25, 2010, in CCIE, by Darren

I’m going to start blogging about various design stuff that I do these days at work. Maybe you can get some ideas from these types of posts.

I’m going to run this simple topology:
HSRP Secondary1 MHSRP & OSPF design

The client has 2 networks at the first site – 192.168.1.0/24 and 10.10.10.0/24. These are both connected to R1 and R2 (via a switch not shown) – R1 and R2 are running MHSRP, with R1 being the master of 192.168.1.254 and R2 being the master of 10.10.10.254. Both routers are the backup of each others group.

I want the link from R1 to be used for 192.168.1.0 and I want the link from R2 to be used for 10.10.10.0. I also want return traffic to take the same path. i.e. if R3 needs to send traffic to 10.10.10.0 – it needs to prefer the direct path to R2.

Another constraint is that I need convergence to be fast, therefore I’m not going to run HSRP on the WAN side of R1 and R2 and have to wait for the IGP to re-converge.

The final constraint is that I don’t want to have to use route-map’s on R3 itself. Let’s pretend there are going to be a lot more routers connected to OSPF area 0. I want to make it as simple as possible when newer routers come into the area. Therefore all this routing needs to be controlled by R1 and R2 themselves.

So far, pretty simple. So let’s get cracking!

Let’s do R1 first, this is the relevant config:

interface FastEthernet0/1
ip address 10.10.10.1 255.255.255.0 secondary
ip address 192.168.1.1 255.255.255.0
standby version 2
standby 1 ip 192.168.1.254
standby 1 priority 110
standby 1 preempt
standby 1 track FastEthernet0/0 50
standby 2 ip 10.10.10.254
standby 2 preempt
standby 2 track FastEthernet0/0 50

And now R2:

interface FastEthernet0/1
ip address 10.10.10.2 255.255.255.0
ip address 192.168.1.2 255.255.255.0 secondary
standby version 2
standby 1 ip 192.168.1.254
standby 1 preempt
standby 1 track FastEthernet0/0 50
standby 2 ip 10.10.10.254
standby 2 priority 110
standby 2 preempt
standby 2 track FastEthernet0/0 50

Now let’s set up OSPF. Remember that I want 192.168.1.0 traffic to go via R1 and 10.10.10.0 to go via R2. There are a number of ways of doing this.

First let’s try and set up regular OSPF with a metric:

router ospf 1
 R1(config-router)#network 10.10.10.0 0.0.0.255 area 0 ?
  cr>
 R1(config-router)#network 10.10.10.0 0.0.0.255 area 0

OSPF will not allow you to specify a metric under the network command!

There is another way. Run 2 OSPF processes and redistribute with a higher metric.

router ospf 1
 redistribute ospf 2 metric 50 metric-type 1 subnets
 network 1.1.1.0 0.0.0.255 area 0
 network 192.168.1.0 0.0.0.255 area 0
!
router ospf 2
 network 10.10.10.0 0.0.0.255 area 0

Let’s check R3′s routing table:

R3#sh ip route
     1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, FastEthernet0/0
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.50.0 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 1 subnets
O E1    10.10.10.0 [110/51] via 1.1.1.1, 00:00:39, FastEthernet0/0
O    192.168.1.0/24 [110/2] via 1.1.1.1, 00:00:39, FastEthernet0/0

It works, but I think its messy. We could also use route-maps which would give us a lot finer control over newer subnets that may be added (without having to run more OSPF processes)

Let’s remove that OSPF config from R1 and do the following:

router ospf 1
 redistribute connected metric-type 1 subnets route-map 10_HIGH
 network 1.1.1.0 0.0.0.255 area 0
!
ip prefix-list 10NET seq 5 permit 10.10.10.0/24
!
route-map 10_HIGH permit 10
 match ip address prefix-list 10NET
 set metric +100
!
route-map 10_HIGH permit 20

Now we do this on R2:

router ospf 1
 redistribute connected metric-type 1 subnets route-map 192_HIGH
 network 1.1.1.0 0.0.0.255 area 0
!
ip prefix-list 192NET seq 5 permit 192.168.1.0/24
!
route-map 192_HIGH permit 10
 match ip address prefix-list 192NET
 set metric +100
!
route-map 192_HIGH permit 20

This will ensure R1 redistributes the 10.10.10.0 network with a higher metric to R3, and vice-versa for R2. R3 will have a possible route in it’s database, but won’t use it until the preferred link is down/

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

R3#sh ip route ospf
     10.0.0.0/24 is subnetted, 1 subnets
O E1    10.10.10.0 [110/21] via 1.1.1.2, 00:00:28, FastEthernet0/0
O E1 192.168.1.0/24 [110/21] via 1.1.1.1, 00:00:28, FastEthernet0/0

Excellent, just what we want. but do the backups work correctly? Let’s shut down R1′s interface to the customer LAN and see what happens:

R1(config)#int fa1/0
R1(config-if)#shut
R1(config-if)#
*Mar  1 00:34:20.711: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 1 state Active -> Init
*Mar  1 00:34:20.723: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 2 state Standby -> Init
*Mar  1 00:34:22.723: %LINK-5-CHANGED: Interface FastEthernet1/0, changed state to administratively down
*Mar  1 00:34:23.723: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to down

What does R3 see?

R3#sh ip route ospf
     10.0.0.0/24 is subnetted, 1 subnets
O E1    10.10.10.0 [110/21] via 1.1.1.2, 00:00:18, FastEthernet0/0
O E1 192.168.1.0/24 [110/101] via 1.1.1.2, 00:00:18, FastEthernet0/0

Both are now going via R2, which is exactly what we wanted. Let’s now reconnect R1 and disconnect R2′s WAN link:

R1(config-if)#int fa1/0
R1(config-if)#no shut
R1(config-if)#
*Mar  1 00:35:47.775: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 1 state Listen -> Active
*Mar  1 00:35:47.859: %LINK-3-UPDOWN: Interface FastEthernet1/0, changed state to up
*Mar  1 00:35:48.859: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to up
R2(config)#int fa0/0
R2(config-if)#shut
R2(config-if)#
*Mar  1 00:36:16.179: %TRACKING-5-STATE: 1 interface Fa0/0 line-protocol Up->Down
*Mar  1 00:36:16.187: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.3 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar  1 00:36:16.187: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar  1 00:36:18.179: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar  1 00:36:18.231: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 2 state Active -> Speak
*Mar  1 00:36:19.179: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down

What does R3 see this time?

R3#sh ip route ospf
     10.0.0.0/24 is subnetted, 1 subnets
O E1    10.10.10.0 [110/101] via 1.1.1.1, 00:00:03, FastEthernet0/0
O E1 192.168.1.0/24 [110/21] via 1.1.1.1, 00:00:03, FastEthernet0/0

Great. Let’s just make sure it all works properly again if all links are up:

R2(config-if)#int fa0/0
R2(config-if)#no shut
R2(config-if)#
*Mar  1 00:37:53.291: %TRACKING-5-STATE: 1 interface Fa0/0 line-protocol Down->Up
*Mar  1 00:37:54.235: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 2 state Standby -> Active
*Mar  1 00:37:55.287: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar  1 00:37:56.287: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
R3#sh ip route ospf
     10.0.0.0/24 is subnetted, 1 subnets
O E1    10.10.10.0 [110/21] via 1.1.1.2, 00:00:06, FastEthernet0/0
O E1 192.168.1.0/24 [110/21] via 1.1.1.1, 00:00:06, FastEthernet0/0

Let’s see what happens when a client is pinging a network directly connected to R3 over the 192.168.1.0 network. I’ll be using a router as a client, so it’ll be a ping flood.

R4#ping 172.16.50.1 repeat 1000

I’ll quickly shut R1′s LAN interface. Wait a bit, and then no shut it. What happens to R4′s pings?

Sending 1000, 100-byte ICMP Echos to 172.16.50.1, timeout is 2 seconds:
!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (998/1000), round-trip min/avg/max = 1/44/160 ms

I lost only 2 pings! Once when I shut the interface, and the second when it came back up again. Pretty good!

It wont be as fast if the WAN link goes down though. R2 will take over for sending packets out, but return traffic will still go to R1. Why? Well remember R3 still thinks R1 is there. Unless they were directly connected, or you wait for OSPF to realise the peer is down, it’ll continue to send traffic that way. You can speed this up by reducing your OSPF hello timers though. This will need to be balanced on how much OSPF traffic you want going across your WAN link.

Tagged with:  

JNCIA-EX (JN0-400) certified

On September 20, 2010, in Juniper, by Darren

I wasn’t actually going to do the enterprise switching track, but I had a 100% off voucher so why the heck not?

I did it this morning. Easiest exam I’ve had in a long time. Even easier than the CCNA!

The exam is actually going to be retired soon, but at least I’ll be certified for 2 years!

Tagged with:  

CCNA Scholarship

On September 16, 2010, in CCIE, by Darren

Steve over at http://networking-forum.com has created a NF scholarship for 1 lucky person! The person will get FREE Cisco press books and will only be required to complete their CCNA and blog about it.

Find more info here: http://www.networking-forum.com/viewtopic.php?f=29&t=19417

 

The use of 31bit subnet masks on point to point links is documented in RFC 3021: http://www.ietf.org/rfc/rfc3021.txt

If you know subnetting, you should know that networks always need a subnet address (all zeroes) and a ‘broadcast’ address. This is why when you generally use a /30 for point-to-point links. 2 addresses used for the routers on each end, then 1 subnet address and 1 broadcast address.

Essentially using a /31 gives you no option to use directed broadcasts. How does this affect routing protocols though? These days most use multicast, but some of the older ones use broadcasts. Let’s run a lab to find out!

I’ve got a simple topology going here. 2 routers connected to each other, each with a loopback subnet advertised in the protocol.

31lab Using /31s on point to point links and their affect on routing protocols

Let’s see what happens!

The first thing I do is to give /31 addresses to both interfaces. Immediately I got the following warning:

R2(config-ip)ip address 10.1.1.4 255.255.255.254
% Warning: use /31 mask on point-to-point interface cautiously

RIPv1:

R1(config)#router rip
R1(config-router)#network 10.0.0.0
R1(config-router)#network 192.168.1.0

R1#sh ip route 172.16.1.1
Routing entry for 172.16.0.0/16
 Known via "rip", distance 120, metric 1
 Redistributing via rip
 Last update from 10.1.1.4 on FastEthernet0, 00:00:13 ago

R1#ping 172.16.1.1
Success rate is 100 percent (5/5)

So it works fine!

RIPv2:

R1(config)#router rip
R1(config-router)#version 2

R1#sh ip route 172.16.1.1
Routing entry for 172.16.0.0/16
 Known via "rip", distance 120, metric 1
 Redistributing via rip
 Last update from 10.1.1.4 on FastEthernet0, 00:00:08 ago

R1#ping 172.16.1.1
Success rate is 100 percent (5/5)

Once again, no problem!

EIGRP

R1(config)#router eigrp 1
R1(config-router)#no auto-summary
R1(config-router)#network 10.1.1.5
R1(config-router)#network 192.168.1.1

R1#sh ip route 172.16.1.1
Routing entry for 172.16.0.0/16
 Known via "eigrp 1", distance 90, metric 156160, type internal
 Redistributing via eigrp 1
 Last update from 10.1.1.4 on FastEthernet0, 00:01:45 ago

R1#ping 172.16.1.1
Success rate is 100 percent (5/5)

So EIGRP has no problems either!

OSPF:

R1(config)#router ospf 1
R1(config-router)#network 10.1.1.5 0.0.0.0 area 0
R1(config-router)#network 192.168.1.1 0.0.0.255 area 0

R1#sh ip route 172.16.1.1
Routing entry for 172.16.1.1/32
 Known via "ospf 1", distance 110, metric 2, type intra area
 Last update from 10.1.1.4 on FastEthernet0, 00:00:45 ago

R1#ping 172.16.1.1
Success rate is 100 percent (5/5)

OSPF is just fine. I guess we can see a pattern emerging here…

BGP

R1(config)#router bgp 100
R1(config-router)#neighbor 10.1.1.4 remote-as 200
R1(config-router)#network 192.168.1.0 mask 255.255.255.0

R1#sh ip route 172.16.1.1
Routing entry for 172.16.1.0/24
 Known via "bgp 100", distance 20, metric 0
 Tag 200, type external
 Last update from 10.1.1.4 00:00:08 ago

R1#ping 172.16.1.1
Success rate is 100 percent (5/5)

Out trusted BGP works just fine

To be honest everything seems to work just fine. I suppose I could test IS-IS and IGRP as well, but who really uses IGRP anymore? (I suppose the same could be said about RIPv1)

IS-IS I suppose would work just fine, but I forgot to test it. I’ll update this post when I do though :)

I’m going to make all my future topologies using /31 on point-to-point links. Not only will it be good practice, but if I ever run into something that ‘doesn’t work’ in the lab, its a better place to not work than in the real world!

If you have any bad experiences with /31′s please let me know in the comments.

Note: I’ve done a new post with some other network OS’s. Check it out here http://mellowd.co.uk/ccie/?p=937

Tagged with:  

© 2009-2014 Darren O'Connor All Rights Reserved