Re: BGP to OSPF Redistribution w/ Sham-Link

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
Blogs and organic groups at http://www.ccie.net