Archive for the ‘ospf’ tag
Junos Basics – OSPF
Oh, my. Another Junos post. Somebody stop me before I get my JNCIA!
This isn’t hard stuff at all. I’m sure there are a couple of cool tricks I don’t know yet, but let’s try anyway. I”m working on an SRX240 here running 11.1 and some change.
Let’s put interfaces ge-0/0/0.0 and lo0.0 in OSPF area 0. If you know the Junos configuration hierarchy, this will be very easy to you. Even if you don’t, you can stare at the config for a little bit and see what we’re doing.
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface lo0.0
This is the only OSPF configuration you need, but guess what? It won’t work. Since a Junos device is also a firewall, it will drop OSPF packets as they come into the interface; you have to declare that you do indeed want to accept OSPF packets. You do this by creating a security zone, putting the right interfaces in the right zone, and then enabling OSPF on that zone.
We’ll create a zone called INSIDE for our purposes here. Note that there are about billion more steps (I counted) to fully configure your security zones, but that’s way beyond our scope here.
set security zones security-zone INSIDE
interfaces ge-0/0/0.0
set security zones security-zone INSIDE
interfaces lo0.0
set security zones security-zone INSIDE
host-inbound-traffic protocols ospf
You can also allow OSPF on specific interfaces like this. These commands will also put those interfaces in the right security zone.
set security zones security-zone INSIDE
interfaces ge-0/0/0.0 host-inbound-traffic protocols ospf
set security zones security-zone INSIDE
interfaces lo0.0 host-inbound-traffic protocols ospf
I’m not sure if you need to do this to lo0.0, but it won’t hurt.
Now you can see your OSPF neighbors come up and start exchanging routing information. That is, of course, assuming you did everything else right.
Send any blog deadlines questions my way.
A Little OSPF Story
Here’s a story from last week with little of no teaching value.
I got a call from one of our business units looking for some routing help. We don’t usually care about their production networks, but they were seeing some funky traceroutes, so I agreed to try and help them out.
They sent over two fresh traceroutes from a host on a 7600. In one of them, the trace went to the 7600 and then on down the line as expected. In the other, the trace showed the 7600, another router’s far interface IP (that is, an interface not facing the 7600), then the 7600′s interface facing that router. Every few minutes, the path was switch between the two. The dude told me that they were an OSPF shop, so I asked him to send me the standard show ip route and show ip ospf database commands so I could see what’s going on. The word “unexpected” comes to mind when trying to describe what I found. So do other words that aren’t very appropriate.
The 7600, the main router at the main campus, was in OSPF area 50. The router that showed up in the trace was also in area 50. The same was true for every other router at that location, so I figured that area 0 was at another location. Nope. All routers at all locations (probably around 20 total) were all in area 50, and area 0 was nowhere to be found. I always thought you could run a single non-backbone OSPF area, but I never understood why you would actually choose to do so. If you want one area, that’s fine, but why not make it area 0?
That single area was working so I didn’t ask too many questions and looked again at the outputs they sent over. I chuckled a bit when I noticed that the routes to the target network were showing up as an OSPF type-2 external. I got a copy of the config at the far network and, lo and behold, I found that there is a single network statement for the transit network back to the main campus along with redistribute connected subnets. For some reason, instead of actually advertising networks natively in OSPF, all the networks with hosts on them were being redistributed. I wasn’t there to redesign their network, so I just sighed out loud and kept looking.
I got a copy of the OSPF config for the main campus’s 7600 to see if would show why the traceroute was weirding out on them. Here’s the part where I actually laughed out loud on the phone. Right in the middle of the config, I see “area 50 nssa”. Yes, this single non-backbone area with no real costs being advertised was configured as a not-so-stubby area. Not only did they go out of their way to make it a non-backbone area but they also wanted it as a stub area. Since they had all the other networks redistributing into the area, they had to make it NSSA. It’s a week later, and I still roll my eyes.
How did this happen? When this business unit was being turned up, they actually outsourced the initial build to a company who will not be named here. They’re the ones who put in this creative OSPF configuration that I’m putting in my hall of shame (if I had one). They’re also the ones who caused the reported problem. After a few more hours of looking around, our guys discovered that the other company put in a new VPN endpoint configured with the IP of the SVI of the 7600. IP conflicts aren’t good, eh? Once that was changed, everything returned to normal.
A fun few hours indeed. At least it was entertaining.
OSPF and Loopback Interfaces
I was studying via Google+ Hangout the other day with CJ and Rob, and one of the topics that came up was that OSPFv2 advertises all loopbacks as 32-bit no matter what the configured mask is. I rarely use loopbacks outside of a lab and had no idea it did that, so I set up a quick lab to see for myself. Sure enough! That’s exactly what I saw.
Of course, being the inquisitive network guys that we are, we went on to discuss methods for making OSPF advertise the configured network instead of the single IP. The guys mentioned two methods – to redistribute the connected interfaces and to manually set the OSPF network type on the loopback. We were using IPv4 during the session, but I went back and added some IPv6 addresses and processes to compare.
The Basics
The whole lab consisted of R101 and R102 connected via their e0/0 interfaces; R101 also has a loopback interface as the guinea pig. Here are the interesting lines of config on R101; I think you can figure out the configs on R102.
interface Loopback0 ip address 172.16.0.1 255.255.255.0 ipv6 address 2001:DB8:101::1/64 ipv6 ospf 1 area 0 ! interface Ethernet0/0 ip address 10.0.0.101 255.255.255.0 ipv6 enable ipv6 ospf 1 area 0 ! router ospf 1 log-adjacency-changes network 10.0.0.0 0.0.0.255 area 0 network 172.16.0.0 0.0.0.255 area 0 ! ipv6 router ospf 1 router-id 192.0.2.101 log-adjacency-changes
So, what would I expect to see in the routing table on R102? From our discussions, I would guess that 172.16.0.1/32 and 2001:db8:101::1/128 would show up.
R102#sh ip route
[ SNIP ]
172.16.0.0/32 is subnetted, 1 subnets
O 172.16.0.1 [110/11] via 10.0.0.101, 00:00:03, Ethernet0/0
R102#show ipv6 route
[ SNIP ]
O 2001:DB8:101::1/128 [110/10]
via FE80::A8BB:CCFF:FE00:6500, Ethernet0/0
Hey! I’m right for once. Of course, that’s not really “right” (for definitions of the word). What if I have a service module on my router with an unnumbered IP address bound to the loopback interface. I’m thinking of something like a Unity Express (!). You want to advertise the whole network or else you can’t get to the module. Let’s look at our two options to fix that.
Redistribute Connected
I removed the loopback interface from both OSPFv2 and OSPFv3 processes and redistributed the connected interfaces (don’t forget the subnets option in OSPFv2). Here’s what the routing tables on R102 look like now.
R102#sh ip route
[ SNIP ]
172.16.0.0/24 is subnetted, 1 subnets
O E2 172.16.0.0 [110/20] via 10.0.0.101, 00:00:06, Ethernet0/0
R102#sh ipv6 route
[ SNIP ]
OE2 2001:DB8:101::/64 [110/20]
via FE80::A8BB:CCFF:FE00:6500, Ethernet0/0
We can now see the network as an E2 route with a proper mask in both routing protocols. I don’t like this solution, though, because I have a serious obsessive-compulsive disorder that won’t let me settle with having an internal route show up as external in OSPF. Let’s try the other solution and see if we have any better luck.
OSPF Network-type
For this part of the experiment, I removed the redistribute commands and added the looback interface back into the routing processes. When I manually configured the loopback interface as an OSPF point-to-point network, the networks were advertised as the network without being external. No more nervous ticks caused by my OCD!
! R101 config interface Loopback0 ip address 172.16.0.1 255.255.255.0 ip ospf network point-to-point ipv6 address 2001:DB8:101::1/64 ipv6 ospf network point-to-point ipv6 ospf 1 area 0 end
R102#sh ip route
[ SNIP ]
172.16.0.0/24 is subnetted, 1 subnets
O 172.16.0.0 [110/11] via 10.0.0.101, 00:01:04, Ethernet0/0
R102#sh ipv6 route
[ SNIP ]
O 2001:DB8:101::/64 [110/11]
via FE80::A8BB:CCFF:FE00:6500, Ethernet0/0
Send any type-2002 LSAs questions my way.
OSPF Notes – Authentication
Corrections appreciated.
Type 0 : No authentication. This is the default type.
R0(config-if)#ip ospf authentication null ----- R0(config-router)#area 1 virtual-link 2.2.2.2 authentication null
Type 1 : Clear text authentication
----- R0(config-if)#ip ospf authentication - or - R0(config-router)#area 1 authentication R0(config-if)#ip ospf authentication-key MYKEY ----- R0(config-router)#area 1 virtual-link 2.2.2.2 authentication-key MYKEY
Type 2 : MD5 authentication
----- R0(config-if)#ip ospf authentication message-digest - or - R0(config-router)#area 1 authentication message-digest R0(config-if)#ip ospf message-digest-key 1 md5 MYKEY ----- R0(config-router)#area 1 virtual-link 2.2.2.2 authentication message-digest message-digest-key 1 md5 MYKEY
OSPF Notes – Network Types
Corrections are always welcome.
Broadcast : Think an Ethernet segement
DR/BDR? : Yes
Default hello interval : 10 sec
Neighbor config required? : No
Point-to-point : Physical point-to-point links, frame-relay point-to-point subifs
DR/BDR? : No
Default hello interval : 10 sec
Neighbor config required? : No
Nonbroadcast Multiaccess : Frame-relay multipoint or physical
DR/BDR? : Yes
Default hello interval : 30 sec
Neighbor config required? : Yes
Point-to-multipoint : Partial mesh networks like a frame-relay hub-and-spoke configuration
DR/BDR? : No
Default hello interval : 30 sec
Neighbor config required? : No
Point-to-multipoint nonbroadcast : Partial mesh networks like a frame-relay hub-and-spoke configuration but without the ability to broadcast
NOTE: I’m having trouble finding an example of this that doesn’t include changing routing preferences between two unequal paths.
DR/BDR? : No
Default hello interval : 30 sec
Neighbor config required? : Yes
OSPF Notes – Neighbor States
My prediction about covering network types was wrong. I’m going to puke out some information about neighbor states for now. As is always the case, corrections are welcome.
Down : No hellos have been received from this router.
Attempt : This state only applies to manually-configured neighbors on an NBMA network. In this state, a router has sent unicast hellos to the neighbor but has not received any back from it.
Init : The router has received hellos, but none of the hellos have the router’s RID included as a known neighbor.
2way : The router has received hellos with its RID included. This means the other router has received the hellos from this router, so they now have 2-way communication going. The DR and BRD is elected at the end of this stage.
ExStart: When a router grows up and starts to have feelings for other routers, it enters the ExStart state to have further relations with a neighbor. This is where the master/slave relationship and the initial sequence numbers are established.
Exchange : Once we know who wears the pants in this relationship, the master sends over a DBD with it’s LSAs listed. In response, the slave does the same so that both routers have all the LSA headers they both know.
Loading : This is where the LSRs and LSUs flow. If a router need the full LSA from the neighbor, it sends an LSR, and the neighbor should send an LSU in response.
Full : After the LSR/LSU exchange, the routers should both be in sync, so they each send an LSAck to the other to confirm.
As a bonus, here’s a nifty little animation showing neighbor states.
OSPF Notes – LSA Types
Yes, it is inevitable that I cover these. I’m sure network types will be next. Per my usual request, please correct my stupidity.
Type 1 – Router : This LSA type lists all the routers by RID as well as the networks to which that router connects.
Type 2 – Network : These LSAs represent broadcast network where more than one OSPF router may live. Think Ethernet or multipoint segment. These LSAs are flooded by the DR for that segment.
Type 3 – Net Summary : An area border routers take the type 1s and 2s from one area and floods them as type 3s into another, so all of these LSAs are from other areas. No topology information is included in these LSAs; it’s basically an advertisement from the ABR saying the route is through him.
Type 4 – ASBR Summary : These LSAs make sure that all routers in all areas have a path to an ASBR that’s flooding type 5 LSAs. Those routes in the area with the ASBR won’t see these.
Type 5 – AS External : These are flooded by an autonomous system boundary router and are routes redistributed into OSPF from another routing process like EIGRP or BGP. Since these routes come from a different source, there’s no way to discover the topology past the ASBR, so we just have to trust the rumor that the network exists that way. E1 routes gets the OSPF path cost added as it crosses the network, while E2 routes (the default) have a static cost.
Type 6 – Group Membership : This is for Multicast OSPF and not supported by IOS
Type 7 – NSSA External : An ABSR in an NSSA floods routes to the external routing process through type 7 LSAs. ABRs will translate these to type 5s when flooding other areas.
Type 8 – External Attributes : Back in the day, OSPFv2 had plans to overthrow iBGP. Type 8 LSAs would have been used to carry BGP attributes while the routes themselves would be of type 5. Type 8s aren’t supported in IOS.
Type 9,10,11 – Opaque : Something…something…traffic engineering…blah, blah, blah.
OSPF Notes – Message Types
I have had my nose deep in several books in preparation for my CCIE R&S written exam, so I haven’t been blogging much at all. Now that I’ve made it to the more familiar topics, I’m hoping to get some notes posted. I’ll start with OSPF message types.
As always, please feel free to correct me here. I’m learning just like the rest of us.
Hello : These messages are used to establish neighbors and serve as keepalives among other things.
Destination: 224.0.0.5 Important Fields: Hello interval Dead interval Router priority (for DR election) Known DR Known BDR Active neighbors
Database Descriptor (DBD or DD) : These messages send summaries of a router’s known LSAs to a new neighbor. Receiving routers can use this information to compare to their database and ask for more details if needed.
Destination: Unicast IP of the new neighbor Important Fields: LSA header
Link State Request (LSR) : Once a router has received a DBD, it parses through the info in it to see if the message is either more up-to-date or if it has some new info in it (like a new network). If the router needs an update, it asks for the full LSA through an LSR.
Destination: Unicast IP of the router that sent the DBD Important Fields: LSA type LSA requested
Link State Update (LSU) : When a router receives an LSR, it responds with an LSU that contains the details information for the requested LSA. It also sends an unsolicited LSU whenever it learns of new LSAs such as when you turn up a new interface.
Destination: Unicast IP of the requesting router, 224.0.0.5, or 224.0.0.6 depending on who's updating whom Important Fields: LS age LS sequence number Full LSA
Link State Acknowledgement (LSAck) : If a router receives an LSU, it responds with an LSAck to acknowledge it was received.
Destination: 224.0.0.5 Important Fields: LS sequence number
OSPFv3 – The Basics
A few hours ago, the last of the IPv4 addresses were allocated by IANA. Now's the time to learn more about IPv6! Yesterday, I posted about EIGRP for IPv6, so I think I'll continue the trend by introducing OSPFv3, which is the IPv6 implementation of OSPF. As always, I'm using Cisco routers here. Just as yesterday, this is just a guide to the absolutely basics; if you want to do some funky OSPF magic, you won't find it here – perhaps in time, though.
Configuration
As with all IPv6 routing protocols, the first thing we need to do is enable IPv6 unicast routing.
Router(config)#ipv6 unicast-routing
OSPFv3 also has the same router ID problem as EIGRP for IPv6 has, so we have to sort that out. You can set the router ID either through a loopback interface with an IPv4 address on it or you can set it manually. I'll just do it manually for now. Let's use OSPF process ID 100.
Router(config)#ipv6 router ospf 100
Router(config-rtr)#router-id 192.0.2.1
Just like in OSPFv2 and in EIGRP for IPv6, we add interfaces to the routing protocol instead of using network statements; those don't exist in OSPFv3. Let's assume you already have IPv6 addresses on interface f0/0 and you want that network in area 0.
Router(config)#interface f0/0
Router(config-if)#ipv6 ospf 100 area 0
You can see that it's really easy to add interfaces to different areas as well.
Checking Our Work
Just like we did yesterday, let's check to make sure the right interfaces are participating in the routing protocol. We can do this with the show ipv6 ospf interface brief command.
Router#show ipv6 ospf interface brief Interface PID Area Intf ID Cost State Nbrs F/C Fa0/1 100 0 5 10 BDR 1/1 Fa0/0 100 2 4 10 DR 0/0
You can see that we've got two FastEthernet interfaces in two different OSPF areas. You can even see the state and neighbor count in the output.
That looks good, so let's check to see if we have any neighbors. Of course, we already saw that we have one off of f0/1 from the output above, but just humor me and run show ipv6 ospf neighbors.
Router#sh ipv6 ospf neighbor Neighbor ID Pri State Dead Time Interface ID Interface 192.0.2.2 1 FULL/DR 00:00:31 5 FastEthernet0/1
That looks good to me. The other guy is a DR and is full adjacent with our router. Cool.
One last command shows us the routing table. Can you guess what that command is without looking at the book? Very good, class. It's show ipv6 route.
Router#sh ipv6 route
IPv6 Routing Table - 6 entries
...
C FC00:1::/64 [0/0]
via ::, FastEthernet0/1
L FC00:1::1/128 [0/0]
via ::, FastEthernet0/1
C FC00:2::/64 [0/0]
via ::, FastEthernet0/0
L FC00:2::1/128 [0/0]
via ::, FastEthernet0/0
O FC00:3::/64 [110/20]
via FE80::C001:1CFF:FED0:1, FastEthernet0/1
OI FC00:4::/64 [110/30]
via FE80::C001:1CFF:FED0:1, FastEthernet0/1
L FF00::/8 [0/0]
via ::, Null0
Isn't that fancy? We seem to have both an area router (the O route) and an inter-area route (the OI route). We are ready for the big time now!
Send any tunnel broker recommendations questions my way.
Tagging External Routes in EIGRP
EIGRP allows you to tag external routes. That is, any route redistributed into EIGRP can be tagged with a numeric descriptor from 0 to 4294967295. Read the rest of this entry »