Re: BGP to OSPF Redistribution w/ Sham-Link

Great, that did it.
It is even more weird. You can redistribute a non running protocol and
it also does the trick. I did it by "redistribute rip" w/o RIP being
configured.
This is indeed a trap, because sometimes it does come up at first (while
you are doing the configuration), but then it does not when you reload.
Order of configuration might also come to play a role here.

Thanks Yuri.
-Carlos

Yuri Bank @ 12/10/2011 21:14 -0300 dixit:
> 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
> <mailto: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
>
>
> -----Original Message-----
> From: nobody_at_groupstudy.com <mailto:nobody_at_groupstudy.com>
> [mailto: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 <mailto: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 <mailto: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 <mailto:markom_at_ipexpert.com>>wrote:
> >>>>>
> >>>>>> On Tue, Oct 11, 2011 at 16:22, Carlos G Mendioroz
> >>>>>> <tron_at_huapi.ba.ar <mailto: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
> <mailto:tron_at_huapi.ba.ar>> LW7 EQI Argentina
> >>>>
> >> --
> >> Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>
> LW7 EQI Argentina
> >>
>
> --
> Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto: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
>
>
>
>
>
>
>
>

-- 
Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net