RE: BGP to OSPF Redistribution w/ Sham-Link

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
>
>
> -----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
Received on Thu Oct 13 2011 - 08:34:46 ART