[j-nsp] OSPF Sham link question [SOLVED]
David Ball
davidtball at gmail.com
Sat Dec 8 08:54:15 EST 2007
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