[j-nsp] OSPF Sham link question

David Ball davidtball at gmail.com
Fri Dec 7 00:37:52 EST 2007


On the T640 facing the m10 which is originating some routes:
# run show ospf route instance sham-link-test
Prefix             Path   Route       NH   Metric  NextHop       Nexthop
                   Type   Type        Type         Interface     addr/label
172.16.0.3         Intra  Router      IP        1  ge-7/2/1.0    172.16.1.2
172.16.0.3/32      Intra  Network     IP        1  ge-7/2/1.0    172.16.1.2
172.16.1.0/30      Intra  Network     IP        1  ge-7/2/1.0
172.16.16.0/24     Intra  Network     IP        2  ge-7/2/1.0    172.16.1.2

On the T640 facing the cisco:
# run show ospf route instance sham-link-test
Prefix               Path   Route       NH   Metric  NextHop       Nexthop
                     Type   Type        Type         Interface     addr/label
172.16.0.4           Intra  Router      IP   1       ge-7/0/0.0    172.16.2.2
172.16.2.0/30        Intra  Network     IP   1       ge-7/0/0.0


I turned on traceoptions on both 640s, and all I see about the sham link is:
Dec  6 22:26:56.837543 OSPF LSA Network 172.16.1.2 172.16.0.3 on no
shamlink.0 rexmit lists, no flood
and
Dec  6 22:26:57.460540 OSPF periodic xmit from 172.16.0.1 to
172.16.0.2 (IFL 2147549184)

where 0.1 and 0.2 are the sham-lnk addresses on the T640s.  Not much
else I see in the logs refers to sham links.

David



On 06/12/2007, Sergio D. <sdanelli at gmail.com> wrote:
> But you should at least be learning the loopbacks from each side as  a
> type-1 LSA.
> How are these routes showing on the PEs "show route protocol ospf table
> sham-link-test"  ? I think I missed that output or sorry if it was already
> mentioned.
>
>
>
> Message: 4
> Date: Thu, 06 Dec 2007 15:04:03 +0000
> From: Daniel Lete <daniel.lete at heanet.ie>
> Subject: Re: [j-nsp] OSPF Sham link question
> To: David Ball <davidtball at gmail.com>
> Cc: juniper-nsp at puck.nether.net
> Message-ID: <47580F63.10905 at heanet.ie>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hello David,
> Your comment below:
>  > (NB: is it normal that the routes PE2 is learning from the m10 are
> 'Extern' ?)
>
> may not be related at all with sham links or even with rfc2547/rfc4364. If
> you
> are injecting prefixes into OSPF (redistribute in Cisco or export in
> Juniper)
> in your CE, then those prefixes will appear as LSA Type-5 (external if you
> want).
>
> Daniel
>
>
>
> David Ball wrote:
> >   Should have mentioned earlier (in case it's relevant), the reason
> > for sham-link requirement is that there 'will' be a slow backup link
> > between the cisco and the m10, but it'll be direct, so the cisco and
> > m10 will think that's the better link (due to intra-area).  So, was
> > hoping to use sham-link across T640s to bring things closer to 'par'
> > and have those routes appear as intra-area and ultimately prefer the
> > sham-link.
> >   I was, but am no longer, explicitly exporting routes from BGP into
> > OSPF on the PEs.  As requested, more configs and show cmd output
> > included.  I appreciate the feedback so far by the way....thanks
> > again.
> >
> > m10's loopback is 172.16.0.3
> > cisco's loopback is 172.16.0.4
> >
> > Pertinent configs from PE1 (T640 facing Cisco):
> > lo0 {
> >     unit 800 {
> >         description "sham-link testing";
> >         family inet {
> >             filter {
> >                 input secure-router-shamlink-test;
> >             }
> >             address 172.16.0.2/32;
> >         }
> >     }
> > }
> >
> > ge-7/0/0 {  <---- int facing Cisco
> >     unit 0 {
> >         family inet {
> >             address 172.16.2.1/30;
> >         }
> >     }
> > }
> >
> > sham-link-test {
> >     instance-type vrf;
> >     interface ge-7/0/0.0;
> >     interface lo0.800;
> >     vrf-target target:25983:800;
> >     vrf-table-label;
> >     protocols {
> >         ospf {
> >             sham-link local 172.16.0.2;
> >             area 0.0.0.0 {
> >                 sham-link-remote 172.16.0.1 metric 1;
> >                 interface ge-7/0/0.0 {
> >                     metric 1;
> >                 }
> >             }
> >         }
> >     }
> > }
> >
> >
> > Pertinent configs from PE2 (T640 facing M10):
> >
> > lo0 {
> >     unit 800 {
> >         description "sham-link test";
> >         family inet {
> >             filter {
> >                 input secure-router-shamlink-test;
> >             }
> >             address 172.16.0.1/32;
> >         }
> >     }
> > }
> >
> > ge-7/2/1 {      <--------facing m10
> >     unit 0 {
> >         family inet {
> >             address 172.16.1.1/30;
> >         }
> >     }
> > }
> >
> > sham-link-test {
> >     instance-type vrf;
> >     interface ge-7/2/1.0;
> >     interface lo0.800;
> >     vrf-target target:25983:800;
> >     vrf-table-label;
> >     protocols {
> >         ospf {
> >             sham-link local 172.16.0.1;
> >             area 0.0.0.0 {
> >                 sham-link-remote 172.16.0.2 metric 1;
> >                 interface ge-7/2/1.0 {
> >                     metric 1;
> >                 }
> >             }
> >         }
> >     }
> > }
> >
> > OSPF neighbors as seen from PE1:
> >> show ospf neighbor instance sham-link-test
> >   Address         Interface             State      ID              Pri
>  Dead
> > 172.16.2.2       ge-7/0/0.0             Full      172.16.0.4         1
>  36
> >
> > OSPF neighbors as seen from PE2:
> >> show ospf neighbor instance sham-link-test
> > Address          Interface              State     ID               Pri
>  Dead
> > 172.16.1.2       ge-7/2/1.0             Full      172.16.0.3       128
>  31
> >
> > Proof that PE1 is learning PE2's loopback via BGP:
> >> show route table sham-link-test
> >
> > sham-link-test.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0
> hidden)
> > + = Active Route, - = Last Active, * = Both
> >
> > 172.16.0.1/32      *[BGP/170] 12:43:03, localpref 100, from 1.7.1.43
> >                       AS path: I
> >                     > to 1.7.2.18 via ge-0/2/0.0, label-switched-path
> > NCP-LSP-00819-005-043
> >                       to 1.7.2.1 via ge-0/0/0.0, label-switched-path
> > NCP-LSP-00819-005-043
> > 172.16.0.2/32      *[Direct/0] 20:29:55
> >                     > via lo0.800
> >
> > Proof that PE2 is learning PE1's loopback via BGP:
> >> show route table sham-link-test
> >
> > sham-link-test.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0
> hidden)
> > + = Active Route, - = Last Active, * = Both
> >
> > 172.16.0.1/32      *[Direct/0] 21:04:41
> >                     > via lo0.800
> > 172.16.0.2/32      *[BGP/170] 18:50:17, localpref 100, from 1.7.1.5
> >                       AS path: I
> >                     > to 1.7.2.17 via ge-0/2/0.0, label-switched-path
> > NCP-LSP-00829-043-005
> >                       to 1.7.2.5 via ge-0/0/0.0, label-switched-path
> > NCP-LSP-00829-043-005
> >
> > OSPF database according to PE1 (Cisco isn't sending much/anything...my
> > current goal is for the Cisco to learn what the m10 sends, then I'll
> > move on):
> >> show ospf database instance sham-link-test
> >
> >     OSPF link state database, Area 0.0.0.0
> >  Type       ID               Adv Rtr           Seq      Age  Opt  Cksum
>  Len
> > Router  *172.16.0.2       172.16.0.2       0x80000037   876  0x22 0xfdff
>  36
> > Router   172.16.0.4       172.16.0.4       0x80000029  1111  0x22 0xa757
>  36
> > Network  172.16.2.2       172.16.0.4       0x80000022  1372  0x22 0x9a80
>  32
> >
> >
> > OSPF database according to PE2:
> >> show ospf database instance sham-link-test
> >
> >     OSPF link state database, Area 0.0.0.0
> >  Type       ID               Adv Rtr           Seq      Age  Opt  Cksum
>  Len
> > Router  *172.16.0.1       172.16.0.1       0x80000024  1912  0x22 0x1ef6
>  36
> > Router   172.16.0.3       172.16.0.3       0x80000425   735  0x22 0xc475
>  48
> > Network  172.16.1.2       172.16.0.3       0x8000002e   435  0x22 0x7b97
>  32
> > OpaqArea 1.0.0.1          172.16.0.3       0x80000413  1335  0x22 0xaeea
>  28
> >     OSPF AS SCOPE link state database
> >  Type       ID               Adv Rtr           Seq      Age  Opt  Cksum
>  Len
> > Extern   172.16.16.0      172.16.0.3       0x80000034  1035  0x22 0xbf33
>  36
> > Extern   192.168.101.0    172.16.0.3       0x80000036   135  0x22 0xe40a
>  36
> >
> > (NB: is it normal that the routes PE2 is learning from the m10 are
> 'Extern' ?)
> >
> > Here is Cisco's current routing table (learning nothing via OSPF):
> > lab-2651#sho ip route
> > Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
> >        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
> >        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
> >        E1 - OSPF external type 1, E2 - OSPF external type 2
> >        i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS
> level-2
> >        ia - IS-IS inter area, * - candidate default, U - per-user static
> route
> >        o - ODR, P - periodic downloaded static route
> >
> > Gateway of last resort is not set
> >
> > C    172.17.0.0/16 is directly connected, FastEthernet0/1
> >      172.16.0.0/30 is subnetted, 1 subnets
> > C       172.16.2.0 is directly connected, FastEthernet0/0
> > C    208.98.239.0/24 is directly connected, FastEthernet0/1
> > lab-2651#
> >
> >
> > Here is M10's inet.0 routing table:
> >> show route
> >
> > inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
> > Restart Complete
> > + = Active Route, - = Last Active, * = Both
> >
> > 0.0.0.0/0          *[Static/5] 5w4d 23:37:59
> >                       Reject
> > 172.16.0.3/32      *[Direct/0] 2w0d 19:06:21
> >                     > via lo0.0
> > 172.16.1.0/30      *[Direct/0] 21:05:30
> >                     > via ge-0/1/0.0
> > 172.16.1.2/32      *[Local/0] 21:05:30
> >                       Local via ge-0/1/0.0
> > 172.16.16.0/24     *[Static/5] 21:02:54
> >                       Discard
> > 192.168.8.0/24     *[Static/5] 5w4d 23:37:59
> >                     > to 192.168.101.252 via fxp0.0
> > 192.168.9.0/24     *[Static/5] 5w4d 23:37:59
> >                     > to 192.168.101.252 via fxp0.0
> > 192.168.101.0/24   *[Direct/0] 5w4d 23:37:59
> >                     > via fxp0.0
> > 192.168.101.33/32  *[Local/0] 5w4d 23:37:59
> >                       Local via fxp0.0
> > 224.0.0.5/32       *[OSPF/10] 5w4d 23:38:00, metric 1
> >                       MultiRecv
> >
> >
> >
> > On 05/12/2007, Peter E. Fry <pfry-lists at redsword.com> wrote:
> >> ----- Original Message -----
> >> From: Daniel Lete <daniel.lete at heanet.ie>
> >>
> >> [...]
> >>> In relation to your sham-link. You need a loopback IP
> >>> within your VRF to act as  source/destination of the sham
> >>> link and these loopbacks are NOT to be announced  to your
> >>> CE.
> >>  I was going to make that point -- that is, I would not
> >> expect to see:
> >>
> >>> O IA    172.16.0.3/32 [110/11] via 172.16.2.1, 04:31:29,
> >> FastEthernet0/0
> >>
> >> ...(although I could be wrong -- I don't get many looks into
> >> CPE).  Also, I'd expect the sham-link neighbor to show up on
> >> the PE.  You can see them on Cisco PEs, for instance:
> >>
> >> CiscoPE#show ip ospf [process] neighbor
> >>
> >> Neighbor ID     Pri   State           Dead Time   Address
> >>     Interface
> >> [...]
> >> [Remote ID IP]    0   FULL/  -           -        [Remote LB
> >> IP]  OSPF_SLn
> >> [...]
> >> CiscoPE#
> >>
> >> ...so there's no confusion as to the state of the sham link.
> >>  I don't have a Juniper L3 VPN PE or a Cisco CE handy.
> >>
> >> Peter E. Fry
> >>
> >>
> >>
> >> _______________________________________________
> >> juniper-nsp mailing list juniper-nsp at puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/juniper-nsp
> >>
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
> --
> Daniel Lete Murugarren
> HEAnet Limited, Ireland's Education and Research Network
> 1st Floor, 5 George's Dock, IFSC, Dublin 1
> Registered in Ireland, no 275301  tel: +353-1-660 9040  fax: +353-1-660 3666
> web: http://www.heanet.ie/
>
>
> --
> Sergio Danelli
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


More information about the juniper-nsp mailing list