We are implementing OSPF authentication in our network, and by the moment we are doing fine in the areas surrounding area 0. These are small areas (5 to 9 routers in each of them), and all joined together with E1s (serial interfaces). Touching the dead-intervals and hello-intervals there isn't any break down in the network since we control the updates.
The problem is coming with area 0 where we have more than 80 routers, and also MSFCs with virtual interfaces. There are DRs and BDRs for different devices on the network son it's more complicated than the situatin we had on the small areas.
Do you know some procedure or method to implement authetication on big areas without harming the routing updates and therefore, the traffic?
I know it's difficult, and we have to do some research on a test network environment we have before doing our real stuff, but it would be nice to facilite the work with something to start.
Thanks and regards
Exactly what is the problem about using OSPF MD5 authentication?
We use that on large infrastructure without any problem ... So, let me know
There's still no problem, but we still don't have authentication on the routers (7500) and the MSFCs. Like you know, all the devices in the same area have to "speak" between them having the same authentication or otherwise the routing updates will not be allowed.In other words, if you put passwords in one of them, you have to do it with all the rest. Since we have so many routers, we will have to implement the passwords one by one, which means some of the devices will lose contact until we type the authentication commands.
We want to do it looking for the most smooth possible way. Like I said, un the small areas they were point to point links, which means changing the dead intervals only afected the segments involved (links between two routers). Now in area 0 one DR updates to a lot of routers so we could lose more than one device.
Yes, I agree with you,
add authentication is an operation that needs a maintenance window, but you don't have an alternative ... if you don't use the protocol authentication, you'll have to implement other solutions, like perimetric security, VRF for traffic separation, and so on. Another idea is split area 0 in other areas, and use the authentication as possible (if you have, as I can see, a lot of routers on area 0, this is a good practice).
If you really want to implement authentication, you can start with interface authentication instead of area authentication.
Once you have all the interfaces configured with the correct password, you can turn area authentication.
Interface authentication allows you to slowly deploy OSPF MD5 on a large network.
We hace seen that while inserting the password in interface mode, there's not going to be any problem, but the issue will be starting to ingress the authentication command in "router ospf x". Then, it will start to activate ospf in that router/MSFC for other devices in the area. Once you start with one, i think that the fast you can enable authentication on the rst, the better it will be for not losing routes.
There are two ways of enable authentication within OSPF:
1) Area authentication (most commonly used)
router ospf 1
area 0 authentication message-digest
ip os message-digest-key 1 md5 CISCO
2) Interface authentication
ip os message-digest-key 1 md5 CISCO
ip os authentication message-digest
On the second option, you can deploy a controlled authentication within your environment without losing routes due to MD5 mismatch.
Hi, thanks for the replies
We thought about that some time ago, but the problem is that many devices have versions beneath the 12.0, and they don't support interface authentication. Here is a excerpt from a Cisco document:
"Q. Which Cisco IOS Software release began support for per-interface authentication type in OSPF?
A. Per-interface authentication type, as described in RFC 2178 leavingcisco.com , was added in Cisco IOS Software Release 12.0(8)"
Anyway, seeing the impact that this change can make to the network performance, we have been talking about upgrading the routers to a version above 12.0(8). The MSFC already have version 12.1(27b)E, and a few 7500 have 12.1(15). Maybe it's worth inverting some time
implementing a newer version in all the routers.
Doing it by interface doesn't lose any routes? So it's limited by segment (interface to another interface), isn't it? But we have SVI virtual interfaces on our MSFCs, so I'm not sure if they behave the same. Anyway, next week we are going to check all these things in out test network and see what happens.
in theory, when you implement the interface authentication, you may lose connectivity, and then routes, if you haven't a second route for fault tolerance. But I agree with Edison, the impact would be lower.
I'v been thinking about another possibility that maybe isn't suitable, or simply not viable at all. We have ospf process 1 in out area 0 network. Couldn't it be possible to create a second process, for example process 2, and put there the authentication command. Now there will be two differente ospf domains. The next step would be passing the networks one by one, eliminating it from process 1 and adding it to process 2. I suppose some redistribution would be needed here. What I'm not sure if we should do this in each node at the same time. Also, being in differente domains, authentication shouldn't be a problem between process 1 and 2... no?
What benefits do we recieve from this? Well, I think that first, we will be doing it in segmented way, always having control on each network we are changing, doing the authentication. Also, having so many networks, we can stop if we go out of time, and continue the next day leaving everything working.
I'm not sure if this will work, but it's another aproach to test at the lab, I suppose.
A bit tricky since an interface can only run under one OSPF process.
I recommend upgrading the IOS on the outdated devices and deploy interface authentication.
SVIs behave the same. When changing authentication per interface, issue the
show ip os nei
command, and make sure all neighbors are updated accordingly.
Yes, I also think it's a bit tricky and maybe a waste of time. I will try it in the only to see "what happens" and I'll post here the results. By now, I think the best choice is upgrading the routers that have version 11.x.
Thanks to both of you, Edison and Andrea for your support.