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:
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:
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
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.
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.
Sometimes its so hard to simply find the time to do what I promised. I hope this will spur up some conversation. I still stress that you should always try to do the lab without my help first. This will ensure you learn how to do it properly. Also remember that there are always multiple ways to do certain labs, so don’t take my solution as gospel.
This solution is for the lab I posted here: http://mellowd.co.uk/ccie/?p=527
- CPE1 and CPE5 belong to Customer1
- CPE2 and CPE6 belong to Customer2
- Both customers are running OSPF as their IGP’s
- The loopbacks as shown in the topology must be advertised into OSPF. Cutomer1 should be able to ping all loopbacks in their networks and Customer2 should be able to ping everything in theirs.
- Both customers are now running a project together, and need 2 of their offices connected. CPE1 from Customer1 should be able to communicate with CPE6 from Customer2 and vice-versa
- It’s essential that CPE2 and CPE5 are NOT able to get to all loopbacks. ONLY CPE1 and CPE6 should be able to communicate with each other. This new configuration should not break the previous VPN’s in place
- Do this without using any ACL’s, Prefix-lists, Route-maps or the like
We start by doing a regular MPLS VPN config – The same for which we did for the first MPLS VPN lab. All the MPLS-specific config is here:
interface Loopback0 ip address 192.168.1.1 255.255.255.0 ! interface FastEthernet0/0 ip address 10.1.1.1 255.255.255.0 duplex auto speed auto ! router ospf 1 log-adjacency-changes network 10.1.1.0 0.0.0.255 area 0 network 192.168.1.0 0.0.0.255 area 0
interface Loopback0 ip address 172.16.1.1 255.255.255.0 ! interface FastEthernet0/0 ip address 10.1.2.1 255.255.255.0 duplex auto speed auto ! router ospf 1 log-adjacency-changes network 10.1.2.0 0.0.0.255 area 0 network 172.16.1.0 0.0.0.255 area 0
interface Loopback0 ip address 192.168.2.1 255.255.255.0 ! interface FastEthernet0/0 ip address 10.1.3.1 255.255.255.0 duplex auto speed auto ! router ospf 1 log-adjacency-changes network 10.1.3.0 0.0.0.255 area 0 network 192.168.2.0 0.0.0.255 area 0
interface Loopback0 ip address 172.16.2.1 255.255.255.0 ! interface FastEthernet0/0 ip address 10.1.4.1 255.255.255.0 duplex auto speed auto ! router ospf 1 log-adjacency-changes network 10.1.4.0 0.0.0.255 area 0 network 172.16.2.0 0.0.0.255 area 0
Now for the 2 AR Routers:
ip cef ip vrf CUS1 rd 400:1 route-target export 400:1 route-target import 400:1 ip vrf CUS2 rd 400:2 route-target export 400:2 route-target import 400:2 interface FastEthernet0/0 ip vrf forwarding CUS1 ip address 10.1.1.2 255.255.255.0 interface FastEthernet2/0 ip vrf forwarding CUS2 ip address 10.1.2.2 255.255.255.0 router ospf 2 vrf CUS1 redistribute bgp 400 metric 10 subnets network 10.1.1.0 0.0.0.255 area 0 router ospf 3 vrf CUS2 redistribute bgp 400 metric 10 subnets network 10.1.2.0 0.0.0.255 area 0 router bgp 400 bgp log-neighbor-changes neighbor 10.255.255.7 remote-as 400 neighbor 10.255.255.7 update-source Loopback0 address-family vpnv4 neighbor 10.255.255.7 activate neighbor 10.255.255.7 send-community extended address-family ipv4 vrf CUS2 redistribute ospf 3 vrf CUS2 metric 10 no synchronization address-family ipv4 vrf CUS1 redistribute ospf 2 vrf CUS1 metric 10 no synchronization
A similar config is on AR3. (I’m not going to post it here otherwise this post will just get to big)
Let’s now concentrate on CPE1. The initial requirements were to allow CPE1 and CPE5 to speak to each other. Currently CPE1 has the following routing table:
CPE1#sh ip route Gateway of last resort is not set 10.0.0.0/24 is subnetted, 2 subnets O IA 10.1.3.0 [110/11] via 10.1.1.2, 00:01:20, FastEthernet0/0 C 10.1.1.0 is directly connected, FastEthernet0/0 C 192.168.1.0/24 is directly connected, Loopback0 192.168.2.0/32 is subnetted, 1 subnets O IA 192.168.2.1 [110/11] via 10.1.1.2, 00:01:20, FastEthernet0/0
Can CPE1 ping the loopback subnet on CPE5? It sure can!
CPE1#ping 192.168.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 80/112/156 ms
Can CPE1 ping CPE6? No it can’t (as expected at this point)
CPE1#ping 172.16.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.2.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
We are now told that we need CPE1 and CPE6 to be able to speak to each other for a project. CPE2 and CPE5 need to be left out of this completely. We need to do this without using any ACL’s or the like.
There is a simple way of doing this. It’s called Extranet MPLS VPN. In the configuration above, each customer is given a route target. We can create a third route-target and have both CPE1 and CPE6 join that third route-target. We then simply don’t add CPE2 and CPE6 to that same route-target.
Let’s add it on AR1 and AR3:
AR1(config)#ip vrf CUS1 AR1(config-vrf)#route-target both 400:100
AR3(config)#ip vrf CUS2 AR3(config-vrf)#route-target both 400:100
If I now check the routing table on CPE1 I see the following:
CPE1#sh ip route Gateway of last resort is not set 172.16.0.0/32 is subnetted, 1 subnets O E2 172.16.2.1 [110/10] via 10.1.1.2, 00:00:21, FastEthernet0/0 10.0.0.0/24 is subnetted, 3 subnets O IA 10.1.3.0 [110/11] via 10.1.1.2, 00:08:41, FastEthernet0/0 C 10.1.1.0 is directly connected, FastEthernet0/0 O E2 10.1.4.0 [110/10] via 10.1.1.2, 00:00:21, FastEthernet0/0 C 192.168.1.0/24 is directly connected, Loopback0 192.168.2.0/32 is subnetted, 1 subnets O IA 192.168.2.1 [110/11] via 10.1.1.2, 00:08:41, FastEthernet0/0
Can CPE1 now ping CPE6′s loopback subnet?
CPE1#ping 172.16.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.2.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 44/69/92 ms
It works :) – We now need to be sure that CPE2 and CPE5 still cannot see any of this.
CPE2#sh ip route Gateway of last resort is not set 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks C 172.16.1.0/24 is directly connected, Loopback0 O IA 172.16.2.1/32 [110/11] via 10.1.2.2, 22:04:42, FastEthernet0/0 10.0.0.0/24 is subnetted, 2 subnets C 10.1.2.0 is directly connected, FastEthernet0/0 O IA 10.1.4.0 [110/11] via 10.1.2.2, 22:05:56, FastEthernet0/0
As expected, it cannot ping anywhere in Customer1′s network:
CPE2#ping 192.168.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) CPE2#ping 192.168.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
Job done. :D
Right, it’s really time I get cracking on with my JNCIA. I’m going to do the EX track first, then maybe ER as well.
I’ve set up an Olive quickly and connected it to a 1721 via dynamips. I want to start off with the basics of getting around the cli of JunOS. Yes it’s different to IOS, but it’s really not that difficult.
When the Olive first boots up, it’ll be a blank slate. If you logged in as root, you’ll need to enter cli to actually get to the cli:
Right, now we are at the CLI. Let’s start configuring!
First go into configure mode:
root@O> configure Entering configuration mode  root@O#
Let’s start with a few basics. These few are all intuitive:
#set system host-name Olive #set system time-zone Europe/London #set system domain-name test.com #set system name-server 188.8.131.52
Note that JunOS won’t make these changes live straight away. All changes go into a ‘candidate configuration’ – Only when you actually commit the changes will they actually happen. You can commit straight away or do a syntax check beforehand:
#commit check configuration check succeeds
This means all looks good, so let’s commit the changes!
#commit commit complete  root@Olive#
There is something to note here. JunOS’s config mode is hierarchical. This means that if I was going to do a lot of commands in the same sub-section – I could go into that sub-section first.
For example, the above 4 commands were all in the system sub-section. Instead of the above, I could’ve done this:
root@O> configure Entering configuration mode  root@O#edit system [edit system] root@O#set host-name Olive #set time-zone Europe/London #set domain-name test.com #set name-server 184.108.40.206
This would give me exactly the same configuration as the above. If I need to get out of a sub-section I just type ‘up’
#up  root@O#
If I’m in pretty deep, you can type ‘top’ to get right to the top of the tree
Now we need to set up an IP address on an interface. To see what interfaces you have, you can type:
Olive> show interfaces terse
This command is similar to show ip int brief on a Cisco
I want to configure the em1 interface and I do so like this:
Olive# set interfaces em1 unit 0 family inet address 10.1.1.1/28
So quite a bit longer than on a Cisco, but it’s really not that difficult. There is an important note here. When you assign an IP address to a Cisco, it becomes the ‘first’ IP. You can add secondary addresses on that interface but you need to specify secondary when entering the IP address. The same thing happens on JunOS, but you HAVE to specify a logical unit at all times, even if it is only EVER going to have 1 IP. Therefore Unit 0 is the first IP, unit 1 the second, unit 2 the third and so on. If I wanted to add a second IP to this interface, I’d do it like so:
Olive# set interfaces em1 unit 1 family inet address 10.2.2.2/28
To set up a default route, we do it like so:
Olive# set routing-options static route 0.0.0.0/0 next-hop 10.1.1.2
There’ll be plenty more JunOS stuff coming very shortly!
Rule #1 – Just because Host 1 can get to Host 2, does NOT mean that Host 2 can get back to Host 1!
I can’t tell you how many times I’ve seen this out in the field. Here is a prime example.
This is quite a simply common topology. OfficeA and OfficeB have a WAN connection running between them. RouterA and RouterB are under control of the ISP and are running OSPF. RouterC is a customer-owned router, and so doesn’t run any OSPF with RouterA or RouterB.
OfficeB has an internet connection, and RouterB is injecting a default route to OfficeA via OSPF.
RouterB has a default route to RouterC. So let’s think about traffic flow now. A host connected to RouterA needs to send traffic to the internet. It will send it’s traffic to it’s default gateway, RouterA. RouterA has a default route injected into OSPF from RouterB and so sends traffic to RouterB.
RouterB has a default route and hence sends that traffic out to RouterC. Which then goes out to the internet.
Traffic then flows back from the internet to RouterC. The return address will be an IP that belongs in RouterA and RouterB’s routing table, however RouterC has no knowledge of that subnet (as it’s not participating in OSPF). RouterC will just use it’s default route and send that packet back out to the internet. Eventually the TTL will kill that packet.
This can be fixed by putting a static route on RouterC to let it know that RouterA’s ip range needs to be sent off to RouterB instead.
A similar thing will happen if we add a server to SwitchA. That server’s default gateway will most likely be RouterC. If a host in OfficeA send a PING to that server, that server will then send traffic off to RouterC. If RouterC does not have the static route added above, it’ll send it out to the internet.
I’m well aware that the design in the picture is pretty bad, but I used it to illustrate a point. That point being that just because router’s know how to get from A to B, it does NOT mean they know how to route that traffic back. Make sure you understand this!
My last post about Traceroute over here: http://mellowd.co.uk/ccie/?p=609 – got some interesting conversation going on in the comments.
Basically there is quite a big difference in the way in which Windows and Linux handle traceroute. I tested on both Windows 7 and Ubuntu 10.04, but my guess is that all Windows follow the same format as do all *nix’s (please let me know if otherwise though!)
I would recommend reading the above post again quickly to get all the basics out the way before we delve into the differences.
Step-wise, this is what happens on Windows:
- The OS send a DNS PTR request to 220.127.116.11.in-addr.arpa to get the hostname for 18.104.22.168
- I get a DNS PTR response giving me a hostname
- The OS send an ICMP ECHO request with a TTL of 1
- I get an ICMP TTL Exceeded packet back from my local router
- 3 & 4 above happens twice more
- The OS send a DNS PTR request to my local router
- My local router responds with it’s hostname
- The cycle above (3-7) is then repeated with a TTL of 2, then 3 and so on
- We finally get to 22.214.171.124 – which sends back an ICMP ECHO reply – Once I get 3 the job is complete.
Ubuntu does this completely differently though. Step-wise this is what’s going on:
- The OS immidiately sent 3 UDP packets with a high port number straight to 126.96.36.199 with a TTL of 1
- The local router responded with 3X ICMP TTL Exceeded message
- The above (1 & 2) is then repeated until we get to 188.8.131.52
- 184.108.40.206 does not generate a ICMP ECHO reply as an ECHO request was not sent. Rather we get 3 ICMP Code 3 (Port unreachable) replies
- The OS now throws out 7 DNS PTR request specifically to each IP it determined in the path from above (Including 220.127.116.11 iself!)
- As soon as all the replies come, the job is complete.
The main differences are that Windows will send a DNS PTR request from the start, then send ICMP ECHO requests. At each hop it’ll send a DNS PTR request and then move onto the next hop.
Linux starts with sending UDP packets to a high port number straight away. When it finally gets to the last hop it’ll then send out a mass DNS PTR request to every hop in the path that it has determined.