[j-nsp] OSPF Sham link question
Sergio D.
sdanelli at gmail.com
Fri Dec 7 10:53:15 EST 2007
If this becomes an inter-area type-3 LSA, the remote PE-CE will always
prefer the on-demand back-up link. If this is correct, then I don't see the
point of a sham-link.
>From my tests this has worked as designed, if all routers are configured
with the same area with a sham-link between PE-PE then the LSA stays as a
type-1.
http://www.juniper.net/techpubs/software/junos/junos84/swconfig84-vpns/id-10939238.html#id-10939238
On Dec 7, 2007 3:13 AM, Daniel Lete <daniel.lete at heanet.ie> wrote:
> Hello Sergio,
> In the PE where the CE is connected to, LSA Type-1 from CE should be seen
> as
> LSA Type-1
>
> In the remote PE, LSA Type-1 from that same CE should be seen as LSA
> Type-3
> (inter-area)
>
> Daniel
>
> Sergio D. 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/
> >
> >
>
> --
> 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
JNCIE #170
More information about the juniper-nsp
mailing list