Re: BGP to OSPF Redistribution w/ Sham-Link

Nice research. Very informative.

On Thu, Oct 13, 2011 at 2:34 PM, Armin Mirsepassi <amirsepassi_at_ccgrp.com>wrote:

> I feel like my esoteric nerd power got an upgrade by reading this. Thanks
> for doing the legwork on this.
>
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> Yuri
> Bank
> Sent: Wednesday, October 12, 2011 8:14 PM
> To: Brian McGahan
> Cc: Carlos G Mendioroz; Cisco certification
> Subject: Re: BGP to OSPF Redistribution w/ Sham-Link
>
> I did some more testing. Lots of debugging and packet captures later, I've
> come to a conclusion.
>
> Sham-links technically require the PE routers to be considered ASBRs. BUT,
> this state simply brings the sham-link up! And when I say up, I mean
> *administratively* speaking. There are no dependencies in the LSDB that
> require any of the routes from the BGP table to actually be redistributed
> into the OSPF process.
>
> To prove this, I setup a vanilla sham-link configuration, I bring
> everything
> online( I advertise the sham-link loopbacks into BGP only), and refrain
> from
> doing any redistribution in the OSPF process. At this point the Sham-Link
> is
> DOWN, and packet capture shows that PE1 and PE2 are not even attempting to
> send Unicast Hellos to each others sham-link endpoints.
>
>
> Next, I setup a route map as follows:
>
> ip access-list standard ALL
> permit any
> !
> route-map DENY deny 10
> match ip address ALL
>
>
> First, On PE2, I redistribute BGP into OSPF:
>
> router ospf 10 vrf ClientA
> redistribute bgp 10 subnets route-map DENY
>
> *Mar 1 00:01:59.695: OSPF: Build router LSA for area 0, router ID 2.2.2.2,
> seq 0x80000002
> *Mar 1 00:02:00.223: OSPF: Interface OSPF_SL0 going Up
> *Mar 1 00:02:00.223: OSPF: Send hello to 11.11.11.11 area 0 on OSPF_SL0
> from 22.22.22.22
>
>
> Now watch debug on PE1:
>
> Mar 1 00:05:49.627: OSPF: Rcv hello from 2.2.2.2 area 0 from OSPF_SL0
> 22.22.22.22
> Mar 1 00:05:49.627: OSPF: Hello ignored - OSPF_SL0 state DOWN
>
>
> So PE2 is not actually sending any routes into OSPF, but this command
> itself
> triggers the sham-link to start sending hellos!! It also triggers PE2 to
> create a new Type-1 Router LSA, with E Bit set indicating that it is now an
> ASBR (by virtue of the redistribute command). This is the only change in
> the
> LSDB, no routes have actually been injected.
>
> Of course, PE1 has not yet been configured this way, so it simply ignores
> the hellos, complaining that OSPF_SL0 is down! So I do the same thing on
> PE1, and poof, OSPF_SL0 comes up, the hellos are accepted, and the
> sham-link
> is established!
>
>
> So this is funny right? While sleeping I begin to think about it more!!
> What
> if I just redistribute another protocol into OSPF instead, and not BGP?
> Will
> that cause the sham-link to come up? Or how about just static routes?! So I
> did just that! I created a random static route to null0 and redistributed
> it
> into OSPF, and what do you know? The sham-link comes up! This makes me
> think
> the router must consider itself an ASBR for the sham-link up go into a
> administratively UP state.
>
>
> NOTE: Once the sham-link is up, you can in fact remove the bgp-to-ospf
> redistribution on both routers, and the sham-link will stay up.
>
> So I think the point is, Cisco wants your PE to be considered an ASBR when
> you're doing L3VPN with sham-links. Digging through the RFC 4577 I cannot
> find this requirement, but its certainly true with IOS. I'll try with JunOS
> one of these days, but now I think I'm just starting to annoy people with
> this topic!
>
>
> -Yuri
>
>
> On Wed, Oct 12, 2011 at 3:09 PM, Brian McGahan <bmcgahan_at_ine.com> wrote:
>
> > Hi Carlos,
> >
> > Try watching this section from my CCIE R&S ATC that covers Sham Links:
> > http://goo.gl/Xh5LC
> >
> > If you have questions after that let me know and I'd be more than happy
> to
> > help.
> >
> > Brian McGahan, CCIE #8593 (R&S/SP/Security)
> > bmcgahan_at_INE.com
> > B
> > Internetwork Expert, Inc.
> > http://www.INE.com <http://www.ine.com/>
> >
> >
> > -----Original Message-----
> > From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> > Carlos G Mendioroz
> > Sent: Wednesday, October 12, 2011 4:33 PM
> > To: Marko Milivojevic
> > Cc: Narbik Kocharians; Yuri Bank; Cisco certification
> > Subject: Re: BGP to OSPF Redistribution w/ Sham-Link
> >
> > Marko Milivojevic @ 12/10/2011 18:07 -0300 dixit:
> > > I will repeat - there is no magic, you're just not seeing what I'm
> > > trying to show you. The restriction is very clear - "Loopback must not
> > > be present in OSPF" - with your configuration, it is (I don't even
> > > have to look, as just by looking at the configuration I see it is
> > > there and can explain why - therefore, no "magic"). Try what I told
> > > you and see it work. Then try to work to reach the conclusion I'm
> > > trying to teach you.
> >
> > Marko,
> > your teaching method is not working with me. So just try by answering the
> > questions, if that's ok ?
> > In fact, I did what you told me to do AND IT DOES NOT WORK.
> > Man, I said that in plain english in the message I sent, or at least that
> > was what I intended by " it does not do the magic here".
> >
> > Also, how can you say "I don't even have to look" and insist that the
> > Loopbacks are present in OSPF ? For granted that you did not look, and
> are
> > writing out of what you dream I was doing. In fact, the configuration I
> sent
> > does not have any redistribution and only has OSPF enabled on VRFs
> > FastEthernets.
> >
> > It bothers me some, that you put so much energy in this argument that the
> > basic issue, e.g. what is needed for the SL to come up seems to fade to a
> > second plane.
> >
> > -Carlos
> >
> > >
> > > Now, if you don't want to do that, say the word and I'll gladly
> > > explain, but IMNSHO, it's better this way...
> > >
> > > --
> > > Marko Milivojevic - CCIE #18427 (SP R&S) Senior Technical Instructor -
> > > IPexpert
> > >
> > > On Wed, Oct 12, 2011 at 13:18, Carlos G Mendioroz <tron_at_huapi.ba.ar>
> > wrote:
> > >> Have you tried this with the config I sent ?
> > >> Cause it does not do the magic here.
> > >>
> > >> (And BTW, if this does not fit the "magic" label, I don't know what
> > >> does it. I wonder what do you tell students to support that an
> > >> internal BGP route is not good enough for some situations, and a
> > redistributed one is).
> > >>
> > >> -Carlos
> > >>
> > >> Marko Milivojevic @ 12/10/2011 12:40 -0300 dixit:
> > >>> It's not stupid, just something not very often warned about in the
> > >>> books and the documentation. Here's an exercise for you:
> > >>>
> > >>> Now try the same thing by redistributing the Loopback into BGP
> > >>> instead of using the network statement and see if it changes... ;-)
> > >>>
> > >>> --
> > >>> Marko Milivojevic - CCIE #18427 (SP R&S) Senior Technical Instructor
> > >>> - IPexpert
> > >>>
> > >>> On Wed, Oct 12, 2011 at 03:50, Carlos G Mendioroz <tron_at_huapi.ba.ar>
> > >>> wrote:
> > >>>> I'm sure doing something relly stupid then :) I've just done it
> > >>>> again, below the files to reproduce it.
> > >>>> Just two PEs, serial link and a vrf. I configure it and SL (sham
> > >>>> link) comes up fine. Bounce it and it does not.
> > >>>> This config has some deviations from the standard template, like
> > >>>> area 146 being an NSSA and BGP not being established from
> > >>>> loopbacks, but that should not make a difference, I guess.
> > >>>>
> > >>>> -Carlos
> > >>>>
> > >>>> Sham.net:
> > >>>> # Demo sham link
> > >>>> [172.30.0.2]
> > >>>>
> > >>>> [[7200]]
> > >>>> image = \var\c7200\ios\c7200-advipservicesk9-mz.124-15.T1.bin
> > >>>> npe = npe-400
> > >>>> ram = 160
> > >>>>
> > >>>> [[ROUTER PE-Piz]]
> > >>>> console = 2001
> > >>>> s1/0 = F1 1
> > >>>>
> > >>>> [[ROUTER PE-Lav]]
> > >>>> console = 2002
> > >>>> s1/0 = F1 2
> > >>>>
> > >>>> [[ROUTER CE-Piz]]
> > >>>> console = 2003
> > >>>> f0/0 = PE-Piz f0/0
> > >>>>
> > >>>> [[ROUTER CE-Lav]]
> > >>>> console = 2004
> > >>>> f0/0 = PE-Lav f0/0
> > >>>>
> > >>>> [[FRSW F1]]
> > >>>> 1:102 = 2:201
> > >>>> 2:201 = 1:102
> > >>>>
> > >>>> -----
> > >>>> PE-Lav:
> > >>>> hostname PE-Lav
> > >>>> !
> > >>>> ip vrf M
> > >>>> rd 100:100
> > >>>> route-target export 100:100
> > >>>> route-target import 100:100
> > >>>> !
> > >>>> interface Loopback100
> > >>>> ip vrf forwarding M
> > >>>> ip address 10.68.146.228 255.255.255.255 !
> > >>>> interface FastEthernet0/0
> > >>>> ip vrf forwarding M
> > >>>> ip address 10.68.146.6 255.255.255.252 !
> > >>>> interface Serial1/0
> > >>>> no ip address
> > >>>> encapsulation frame-relay
> > >>>> serial restart-delay 0
> > >>>> !
> > >>>> interface Serial1/0.201 point-to-point ip address 172.16.12.2
> > >>>> 255.255.255.252 mpls ip frame-relay interface-dlci 201 !
> > >>>> router ospf 400 vrf M
> > >>>> log-adjacency-changes
> > >>>> area 146 nssa
> > >>>> area 146 sham-link 10.68.146.228 10.68.146.227 cost 1000 network
> > >>>> 10.68.146.4 0.0.0.3 area 146 !
> > >>>> router bgp 100
> > >>>> no synchronization
> > >>>> bgp log-neighbor-changes
> > >>>> neighbor 172.16.12.1 remote-as 100 no auto-summary !
> > >>>> address-family vpnv4
> > >>>> neighbor 172.16.12.1 activate
> > >>>> neighbor 172.16.12.1 send-community extended exit-address-family
> > >>>> !
> > >>>> address-family ipv4 vrf M
> > >>>> no synchronization
> > >>>> network 10.68.146.228 mask 255.255.255.255 exit-address-family
> > >>>>
> > >>>> ------
> > >>>> PE-Piz:
> > >>>> hostname PE-Piz
> > >>>> !
> > >>>> ip vrf M
> > >>>> rd 100:100
> > >>>> route-target export 100:100
> > >>>> route-target import 100:100
> > >>>> !
> > >>>> interface Loopback100
> > >>>> ip vrf forwarding M
> > >>>> ip address 10.68.146.227 255.255.255.255 !
> > >>>> interface FastEthernet0/0
> > >>>> ip vrf forwarding M
> > >>>> ip address 10.68.146.2 255.255.255.252 !
> > >>>> interface Serial1/0
> > >>>> no ip address
> > >>>> encapsulation frame-relay
> > >>>> serial restart-delay 0
> > >>>> !
> > >>>> interface Serial1/0.102 point-to-point ip address 172.16.12.1
> > >>>> 255.255.255.252 mpls ip frame-relay interface-dlci 102 !
> > >>>> router ospf 400 vrf M
> > >>>> log-adjacency-changes
> > >>>> area 146 nssa
> > >>>> area 146 sham-link 10.68.146.227 10.68.146.228 cost 1000 network
> > >>>> 10.68.146.0 0.0.0.3 area 146 !
> > >>>> router bgp 100
> > >>>> no synchronization
> > >>>> bgp log-neighbor-changes
> > >>>> neighbor 172.16.12.2 remote-as 100 no auto-summary !
> > >>>> address-family vpnv4
> > >>>> neighbor 172.16.12.2 activate
> > >>>> neighbor 172.16.12.2 send-community extended exit-address-family
> > >>>> !
> > >>>> address-family ipv4 vrf M
> > >>>> no synchronization
> > >>>> network 10.68.146.227 mask 255.255.255.255 exit-address-family
> > >>>>
> > >>>> ------
> > >>>>
> > >>>> Narbik Kocharians @ 12/10/2011 02:17 -0300 dixit:
> > >>>>> *There's nothing really difficult with sham-links, if you follow
> > >>>>> the steps for configuration.
> > >>>>> *
> > >>>>> I agree 1000 percent.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Tue, Oct 11, 2011 at 5:42 PM, Marko Milivojevic
> > >>>>> <markom_at_ipexpert.com>wrote:
> > >>>>>
> > >>>>>> On Tue, Oct 11, 2011 at 16:22, Carlos G Mendioroz
> > >>>>>> <tron_at_huapi.ba.ar>
> > >>>>>> wrote:
> > >>>>>>> I said that I've just seen a test case where the link does not
> > >>>>>>> come up, even with the loopback published in BGP and not in OSPF.
> > >>>>>>> So I don't fit in your rule.
> > >>>>>> ... if you have redistribution from BGP to OSPF, then you are
> > >>>>>> very much advertising loopbacks in OSPF, unless you were
> > >>>>>> filtering. If you were filtering, then you probably had an
> > >>>>>> entirely different MPLS transport issue, which only manifested
> > >>>>>> itself by sham-links not coming up.
> > >>>>>>
> > >>>>>> There's nothing really difficult with sham-links, if you follow
> > >>>>>> the steps for configuration.
> > >>>>>>
> > >>>>>> --
> > >>>>>> Marko Milivojevic - CCIE #18427 (SP R&S) Senior Technical
> > >>>>>> Instructor - IPexpert
> > >>>>>>
> > >>>>>>
> > >>>>>> Blogs and organic groups at http://www.ccie.net
> > >>>>>>
> > >>>>>> _________________________________________________________________
> > >>>>>> ______ Subscription information may be found at:
> > >>>>>> http://www.groupstudy.com/list/CCIELab.html
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>> --
> > >>>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
> > >>>>
> > >> --
> > >> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
> > >>
> >
> > --
> > Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
Pavel Bykov
Blogs and organic groups at http://www.ccie.net