Clue Store wrote:
I couldn't agree more. Most of my staff are still under the impression in
Cisco land that the "network 10.0.0.0 255.255.255.0" statement injects that
network into OSPF, when it simply turns on OSPF for the interfaces that are
in that network. I'm really glad to see Cisco that made this change in
OSPFv3 for v6.
Cisco legacy commands make it hard on those learning fresh. I still get annoyed when I can't use CIDR notation in a config statement. I think, if nothing else, v6 is giving Cisco a fresh start at reimplementing some things.
After dealing with Juniper awhile, I shifted some policies to mirror Juniper's method of doing things. At least that sorted out some confusion for others in the routers. Sadly, Cisco specific shortcuts still look cleaner and easier to manage in the config, but they also require more thought and understanding of what is going on.
Jack
Configure eBGP from your edge to the client edge using
private-AS. Since I already have copy/paste templates (thanks
to RANCID), I make it a habit to ensure filters are at both
ends. Goes without saying that
BCP-38 is followed, and strict is deployed everywhere possible.
peer-group and regexes are handy.
If you're starting from scratch, use peer templates, they are slightly more
versatile than the peer groups and allow (limited) inheritance.
Ivan
http://www.ioshints.info/about
http://blog.ioshints.info/
So most of your staff is FAR away from understanding OSPF. Don't you
think it's easier to teach them BGP? Where you have a straight-forward
config of explicit neighborship, with explicit in/out prefix-lists to
control route propagation from/to customers? Where signalling channel
(BGP TCP session) is totally separated from what routing information
is being exchanged (BGP NLRI)?
OSPF just _looks_ simple when used in fully-trusted, most simple almost
all defaults config, and even then it's misleading (see your reference
to IOS' "network" statement for OSPFv2). When traffic engineering is
needed with multiple redundant uplinks for customers, things become very
interesting very quickly. Troubleshooting OSPF LSA flooding and database
replication is really HARD compared to BGP's simple UPDATE/WITHDRAW
messaging. And then you got the whole lot of different LSA types,
flooding rules, extension hacks, area types, yadda yadda. IS-IS more
straight-forward than OSPF, but still complex.
All this is referring to your concern about being able to teach the Ops
folks BGP, compared to teaching them OSPF.
In my experience, it was never a problem to teach Ops folks BGP to CPEs
(even with traffic engineering mods via route-maps), but very hard to get
them up to speed on IGPs - and I'm by no means an expert in those either.
BGP gives you more control, and with far higher chance of Ops folks
being able to troubleshoot issues to success. To me, a clear winner, if
your CPE hardware supports it.
My 0.02EUR 
Best regards,
Daniel
I seem to get the impression that isis is preferred in the core. Any
reasons why folks dont prefer to go with ospf?
Glen
I seem to get the impression that isis is preferred in the core. Any
reasons why folks dont prefer to go with ospf?
a bit harder to attack clnp (is-is) than ip (ospf)
is-is a bit simpler to configure, though you can get a sick as you
want. but don't.
a bit simpler to code, so worked and was stable when ospf was far
flakier than it is now.
randy
I'd also add that ISIS supports IPv6 through the addition of TLVs whereas OSPF was redesigned into OSPFv3.
Personally I like ISIS due to it's simplicity and use it for router loopback advertisement only.
Cord, so you've piqued my interest. Are you saying you run ISIS for
loopback recursion, but another protocol for everything else?
Correct. I use ISIS in level 2 only to announce my loopbacks, then BGP for everything else.