Re: OSPF LSA type 3 filtering

Did the NSF mechanism not work John?

Should have.

Marko,

for you as well on the Juniper?

Just curious.

Paul

Paul Negron
CCIE# 14856
negron.paul_at_gmail.com
303-725-8162

On Jan 5, 2013, at 2:19 PM, John Neiberger <jneiberger_at_gmail.com> wrote:

> I can confirm that not only does OSPF bounce in Juniper (since one of the
routers I was changing was an MX960), the link actually went admin down for a
moment! I was not expecting that at all! I changed the MTU and then got a link
down notification in our management system. It wasn't actually down, and the
far end didn't see it go down, but it seems that internally the MX960 reset
the interface once I changed the MTU. I guess the CRS does something similar.
Sort of a soft reset, apparently.
>
>
> On Sat, Jan 5, 2013 at 2:05 PM, Marko Milivojevic <markom_at_ipexpert.com>
wrote:
> Oh you're so going to make me lab this up in Juniper :-).
>
> I don't think IOS will bounce, but there's been some time since I
> tried changing MTU on an interface with a working adjacency.
>
> --
> Marko Milivojevic - CCIE #18427 (SP R&S)
> Senior CCIE Instructor - IPexpert
>
> On Sat, Jan 5, 2013 at 12:46 PM, rakesh madupu <raaki.88_at_gmail.com> wrote:
> > Hey John,
> >
> > I am pretty sure Ospf Bounces in Juniper if we change MTU on an
interface,
> > even 3560's it makes sense to have "ip ospf mtu ignore" or system mtu
ignore
> > to deliberately hold ospf Adj's, I think MTU along with other parameters
> > must be matched for Ospf to stay up
> >
> > Regards
> > Rakesh M
> >
> >
> > On Sun, Jan 6, 2013 at 12:47 AM, John Neiberger <jneiberger_at_gmail.com>
> > wrote:
> >>
> >> I ran into that ISIS MTU issue at work this week on a production link. I
> >> needed to increase the MTU on a link that was running OSPF and ISIS. When
I
> >> changed the MTU on one side, ISIS got a little angry with me until I
> >> increased the MTU on the other side. The reason is that ISIS has a
Padding
> >> TLV wherein it pads its hello packets to the full MTU size. That's how
it
> >> insures that there is no mismatch. If one side has a larger MTU, that
packet
> >> will be dropped when it reaches the other side. Once I fixed both ends,
ISIS
> >> was happy again.
> >>
> >> Interestingly, OSPF also bounced, which I thought was odd. In IOS, if
you
> >> already have an adjacency and routing is stable, you can change the MTU
> >> without causing the adjacency to bounce. However, I was doing this in IOS
XR
> >> and it clearly bounced OSPF when I changed the MTU. I asked around on
the
> >> cisco-nsp list, but so far no one knows why OSPF would bounce like that
in
> >> IOS XR. One person thought that perhaps since it is a hardware
forwarding
> >> platform, interface buffer memory had to be reallocated after the MTU
> >> change, but that was just a guess. If anyone knows, feel free to end the
> >> mystery. lol I know it won't bounce the adjacency in IOS, at least on
the
> >> hardware and images I tested it on. And that makes sense to me. The MTU
is
> >> not in the hello packets in OSPF; it's in the DBD packets.
> >>
> >> John
> >>
> >>
> >> On Fri, Jan 4, 2013 at 7:14 PM, Paul Negron <negron.paul_at_gmail.com>
wrote:
> >>>
> >>> I do like that feature.
> >>>
> >>> I also love the way ISIS handles MTU mismatch which is another big
> >>> problem we
> >>> have in real networks.
> >>> You do not just simply ignore it as you do with OSPF.
> >>>
> >>> Paul
> >>> Paul Negron
> >>> CCIE# 14856
> >>> negron.paul_at_gmail.com
> >>>
> >>>
> >>> On Jan 4, 2013, at 1:17 PM, Yuri Bank <yuribank_at_gmail.com> wrote:
> >>>
> >>> > Except that with the IS-IS the hostname is carried in each routers
LSP
> >>> > (hostname TLV), so there is no dependency on DNS, or manual
> >>> > configuration
> >>> > on the routers required (Which is very nice imho).
> >>> >
> >>> > -Yuri
> >>> >
> >>> >
> >>> > On Fri, Jan 4, 2013 at 12:10 PM, Marko Milivojevic
> >>> <markom_at_ipexpert.com>wrote:
> >>> >
> >>> >> You mean the output you'd get if you used "ip ospf name-lookup" ;-)
> >>> >>
> >>> >> --
> >>> >> Marko Milivojevic - CCIE #18427 (SP R&S)
> >>> >> Senior CCIE Instructor - IPexpert
> >>> >>
> >>> >> On Fri, Jan 4, 2013 at 12:07 PM, rakesh madupu <raaki.88_at_gmail.com>
> >>> >> wrote:
> >>> >>> For me, I love isis in our customer deployments because it shows
> >>> >>> neighboring devices names which is peers with, specially with RR's
> >>> >>> names
> >>> >> ,
> >>> >>> life get so much simpler instead of reading an Ip address and
> >>> >> associating it
> >>> >>> again :)
> >>> >>>
> >>> >>>
> >>> >>> On Sat, Jan 5, 2013 at 12:34 AM, Marko Milivojevic
> >>> >>> <markom_at_ipexpert.com>
> >>> >>> wrote:
> >>> >>>>
> >>> >>>> IS-IS supports multiple routed protocols, i.e. IPv4 and IPv6,
> >>> >>>> whereas
> >>> >>>> OSPF doesn't.
> >>> >>>>
> >>> >>>> Also, in the time when MPLS-TE was emerging as a technology, IS-IS
> >>> >>>> behavior to flood unknown TLVs instead of resetting adjacencies
when
> >>> >>>> it receives them (OSPF does that when it receives an unknown LSA).
> >>> >>>> meant a very controlled deployment of new technologies. The fact
> >>> >>>> it's
> >>> >>>> not IP, also has some security benefits (cannot be remotely
> >>> >>>> attacked).
> >>> >>>> Etc.
> >>> >>>>
> >>> >>>> What Joseph said is... not quite the reason, since IS-IS also has
a
> >>> >>>> requirement for a contiguous L2 area.
> >>> >>>>
> >>> >>>> --
> >>> >>>> Marko Milivojevic - CCIE #18427 (SP R&S)
> >>> >>>> Senior CCIE Instructor - IPexpert
> >>> >>>>
> >>> >>>> On Fri, Jan 4, 2013 at 10:34 AM, Imran Ali <immrccie_at_gmail.com>
> >>> >>>> wrote:
> >>> >>>>> marko i need to know why they use is-is over ospf
> >>> >>>>>
> >>> >>>>> On Fri, Jan 4, 2013 at 8:53 PM, Marko Milivojevic <
> >>> >> markom_at_ipexpert.com>
> >>> >>>>> wrote:
> >>> >>>>>>
> >>> >>>>>> In reality, for this purpose, IS-IS and OSPF are pretty much the
> >>> >>>>>> same
> >>> >>>>>> (Type 2 vs Pseudonode LSP). They both use a very similar
approach
> >>> >>>>>> to
> >>> >>>>>> solve the same calculation problem.
> >>> >>>>>>
> >>> >>>>>> Carriers tend to use IS-IS for one other reason (to some extent
> >>> >>>>>> remedied by OSPFv3). This is a separate discussion though.
> >>> >>>>>>
> >>> >>>>>> --
> >>> >>>>>> Marko Milivojevic - CCIE #18427 (SP R&S)
> >>> >>>>>> Senior CCIE Instructor - IPexpert
> >>> >>>>>>
> >>> >>>>>>
> >>> >>>>>> Blogs and organic groups at http://www.ccie.net
> >>> >>>>>>
> >>> >>>>>>
> >>> >>
> >>> >>
Received on Sat Jan 05 2013 - 15:34:19 ART