[j-nsp] OSPF Sham link question [SOLVED]
David Ball
davidtball at gmail.com
Sat Dec 8 09:50:31 EST 2007
And for any Juniper folks listening in, I wanted to point out that
the example config shown in the 8.5 docs at juniper.net on configuring
sham links (see URL below) doesn't actually tell you to include the
loopback IPs in the OSPF config...which is obviously a requirement if
you want a sham link to come up:
http://www.juniper.net/techpubs/software/junos/junos85/swconfig85-vpns/id-10993181.html#id-10993181
David
On 08/12/2007, David Ball <davidtball at gmail.com> wrote:
> Well, looking at it with a fresh set of eyes at 06:30 helped me
> discover that the firewall filter applied to the VRF loopback
> interfaces had not been permitting OSPF packets from the VRF loopbacks
> themselves...only from the ge-* IP addresses. It was dropping them
> silently instead of logging to 'sh firewall log'. *sigh*
> Thanks to all who helped out with this. Appreciated as always.
>
> David
>
>
> On 07/12/2007, Doug Marschke <doug at ipath.net> wrote:
> > Hello David,
> >
> > I have admittedly not looked at all your output but sham links should
> > show up as normal point to Point links in OSPF. A few points:
> >
> > -Routes learned over sham links must still be learned over bgp as PE
> > routers user only BGP routes for forwarding
> > -Must ensure that the sham-link end points (unique loopback unit) is
> > also advertised via bgp to the remote PE
> >
> > For example:
> > [edit routing-instances vpn-a]
> > lab at PBR# show
> > instance-type vrf;
> > interface fe-0/0/0.0;
> > interface lo0.1;
> > vrf-target {
> > import target:65412:100;
> > export target:65412:100;
> > }
> > protocols {
> > ospf {
> > sham-link local 10.1.1.1;
> > area 0.0.0.0 {
> > sham-link-remote 10.2.2.2 metric 1;
> > interface fe-0/0/0.0;
> > interface lo0.1;
> > }
> > }
> > }
> >
> > [edit interfaces]
> > lab at PBR# show
> > lo0 {
> > unit 1 {
> > family inet {
> > address 10.1.1.1/32;
> > }
> > }
> > }
> >
> > Then you should see the sham-link in your ospf commands:
> >
> > lab at PBR> show ospf interface instance vpn-a
> > Interface State Area DR ID BDR ID
> > Nbrs
> > fe-0/0/0.0 BDR 0.0.0.0 192.168.20.1 10.1.1.1
> > 1
> > lo0.1 DR 0.0.0.0 10.1.1.1 0.0.0.0
> > 0
> > shamlink.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0
> > 1
> >
> > lab at PBR show ospf neighbor instance vpn-a
> > Address Interface State ID Pri
> > Dead
> > 10.0.21.2 fe-0/0/0.0 Full 192.168.20.1 128
> > 35
> > 10.2.2.2 shamlink.0 Full 10.2.2.2 0
> > 31
> >
> > lab at PBR> show ospf database instance vpn-a
> >
> > OSPF link state database, area 0.0.0.0
> > Type ID Adv Rtr Seq Age Opt Cksum
> > Len
> > Router *10.1.1.1 10.1.1.1 0x80000081 631 0x2 0xa0f6
> > 72
> > Router 10.2.2.2 10.2.2.2 0x80000084 630 0x2 0x6918
> > 72
> > Router 192.168.20.1 192.168.20.1 0x800000ae 632 0x2 0x9641
> > 48
> > Router 192.168.28.1 192.168.28.1 0x800000b2 629 0x2 0x5754
> > 48
> > Network 10.0.21.2 192.168.20.1 0x800000ab 632 0x2 0xed96
> > 32
> > Network 10.0.29.2 192.168.28.1 0x800000ae 629 0x2 0xc69f
> > 32
> > -----Original Message-----
> > From: juniper-nsp-bounces at puck.nether.net
> > [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of David Ball
> > Sent: Friday, December 07, 2007 8:14 AM
> > To: Sergio D.
> > Cc: juniper-nsp at puck.nether.net; davidball at gmail.com
> > Subject: Re: [j-nsp] OSPF Sham link question
> >
> > Sergio,
> >
> > In your tests, what indication did you see that the sham link was
> > up and working as expected? Did it appear as an OSPF neighbor in 'sh
> > ospf neigh instance <name>' ? did something specific occur in your
> > log file (if you enabled one) that indicated 'sham link up!'. I
> > suppose one of the difficulties I'm having is that I don't know what I
> > should expect to see from the sham link, nor can I tell if it's up or
> > down.
> >
> > David
> >
> >
> > On 07/12/2007, Sergio D. <sdanelli at gmail.com> wrote:
> > > 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/i
> > d-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
> > > _______________________________________________
> > > 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
> >
> >
>
More information about the juniper-nsp
mailing list