Hillary Nelson | 29 Jul 21:45 2015
Picon

[quagga-users 14079] (no subject)

We choose quagga for our DNS anycast routing, to inject anycast nameserver IPs to upstream router through bgp, the anycast IP is configured on 'lo' interface.

Everything works well with just bgpd damon, I guess its safe not run zebra, and kernel routing won't be affected ?

Here is the lo:1 with anycast ip 10.10.10.1:

lo:1      Link encap:Local Loopback 
          inet addr:10.10.10.1  Mask:255.255.255.255
          UP LOOPBACK RUNNING  MTU:65536  Metric:1


If I turn on zebra, the anycast IP is listed as 'C'(connected),  instead of  'B'(for bgp) even if it's exported through bgp,  I wonder why?
 
# show ip route
K>* 0.0.0.0/0 via 10.79.183.1, eth1
C>* 127.0.0.0/8 is directly connected, lo
C>* 10.10.10.1/32 is directly connected, lo

# show ip bgp
BGP table version is 0, local router ID is 10.79.183.6
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.10.10.1/32    0.0.0.0                  0         32768 i


Thanks!

Hillary


_______________________________________________
Quagga-users mailing list
Quagga-users@...
https://lists.quagga.net/mailman/listinfo/quagga-users
Homer W. Smith | 29 Jul 04:22 2015

[quagga-users 14078] OSPF FILTERING INCOMING ROUTES

   Dear Folks,
 
   I am a sort of newbie at OSPF.
 
   I have an upstream that is sharing all its routes writh me via OSPF and visa versa.  This allows me to get to their inside customers
without having to go outside first and back in the normal way as we have a direct link to each other.  My normal link is defaulted to Time Warner.
 
   Recently this upstream  added routes that are inappropriate to my services and in fact are detrimental.  These routes seem to come and go and
are random in their appearance.  They have no idea yet what is causing it.
 
    They can't quite figure it out, so I want to figure it out at my end.
 
    Their end is running a mikrotik and my end is running linuk with ospf 0.99.x latest version.
 
     It is a simple link from my machine to theirs on eth1.
 
     I want to receive from them ONLY 3 networks, say 10.1.1.0/24 and 10.2.2.0/24 and 10.3.3.0/24 and reject ALL other routes incoming
to my system from THEM.  Other interfaces on my route are facing inside my network and should not be interferred with.
 
     Could someone please demonstrate for me a simple redistribute route-map with access list or prefix lists that I can use to filter out everything
except specified routes over this one link.
 
     I presently have
 
     redistribute static
     redistribute kernel
     redistribue connected
 
     Thanks,
 
     Homer W Smith
     CEO, Lightlink Internet
 
    
_______________________________________________
Quagga-users mailing list
Quagga-users@...
https://lists.quagga.net/mailman/listinfo/quagga-users
SONDI Mikael | 27 Jul 02:58 2015
Picon

[quagga-users 14072] .deb creation

Hi room, 
Does anyone have an idea on how I can create a .deb file from quagga source code?
Thanks
_______________________________________________
Quagga-users mailing list
Quagga-users@...
https://lists.quagga.net/mailman/listinfo/quagga-users
B2 Admin | 24 Jul 21:57 2015
Picon

[quagga-users 14067] Problem with OSPF over openvpn

Hi!
I have small network.

RA1, RA2, RB1, RB2 - are routers with debian jessie. RC1 is router with debian wheezy.

RA1 and RA2 are together in A collocation, and are connected by the same network.
RB1 and RB2 are together in B collocation, and are connected by the same network.
RC1 is on C collocation.

Between B and C there is leased transmision.
For security reason i need to encrypt traffic between collocations. And - to protect leased transmission failure - i've created openvpn tunnels:
1. RA1-RB1, RA1-RB2, RA2-RB1, RA2-RB2 over internet
2. RB1-RC1, RB2-RC1 over transmission.

All tunnels works fine via independent internet links.

It was working fine. All routers are in one area 0, all are ASBR, one of routers is always DR, second is BDR - they're in full state - always works fine.

I redistribute to ospf only specific networks using prefix list.

I have plans to create openvpn tunnels from B to C over internet and from A to B over transmission - but i didn't realized it yet.

When i've put ospf over vpn tunnels - they're tun type - everything goes fine. But - after few days - some OSPF goes down. IP Traffic via openvpn was ok, i saw helo packets on both sides of tunnel, but - on one side second router was in Init state, and on second - there was no information about it in ip show ospf neighbours. 
I've checked (via netstat -ng) that second router in this schema was not join 224.0.0.5 multicast group - and show ip ospf interface <name of tunel> - didn't show that it join OSPFAllRouters group.


Putting down/up tunnel - doesn't help. Changing type of interface via vtysh to point-to-point - also don't.
Once(RA2-RB2) - when i changed type of tunnel to tap - it helps - for short time. But - changing of RA1-RB2) - doesn't. But - after some time link between RA2 and RB2 stop working too.

Restart of ospfd usualy helps for some time - but after few changes in network or some time it's broken again.

All time works tunnel from RA2-RB1. All other tunnel after some time/some changes - goes to Init state and don't work.

Does anybody have any idea what can be wrong? 
Is anybody using ospfd over openvpn links in simmilar scenario?

Regards,

_______________________________________________
Quagga-users mailing list
Quagga-users@...
https://lists.quagga.net/mailman/listinfo/quagga-users
Chris Meadors | 23 Jul 07:08 2015

[quagga-users 14064] 2 Same Routers, 1 Redistributing BGP, 1 Not

I'm trying to help a person out who's having trouble with his Quagga 
based routers. We've both been over everything we can think of in the 
last three days, but we're stumped. I'm hoping someone else has an idea 
we've not thought of yet.

Basically he has two Debian machines running Quagga. Their BGP configs 
are identical, except for IPs, and one has an extra prepend. The one 
with the prepend is intended to serve as a hot fail-over, and normally 
receives very little traffic.

They are both connected to the same upstream provider, the primary with 
fiber and the backup with a slower copper connection. So they have the 
same ASN, but different IPs for the peering. He's receiving only the 
default route on both.

They are also running RIP so the internal machines can learn their 
default gateway. The only thing different in the RIP configs are the 
"redistribute bgp metric", the primary router has a metric of 5, and the 
backup is 6. RIP is being advertised on 4 local subnets, each with it's 
own unique physical interface.

The problem started after a BGP session disconnected, and wouldn't 
reconnect. Even after stopping all the Quagga daemons and restarting 
them. A last ditch reboot brought the BGP session back up, but problems 
started with RIP. My first guess was that there was an unwritten config 
that was running, and some setting got lost after the reboot. But we've 
been over the config files many times, comparing them line by line, and 
there's nothing missing.

RIP is behaving very differently between the two machines. The backup 
appears to be working correctly. When it's BGP session is up, it 
advertises itself as the default gateway to all the connected networks 
with a metric of 6.

The primary machine isn't doing the right thing at all. It is 
advertising itself as a gateway, but with a metric of 7. No matter what 
bgp redistribute metric is set on the primary or backup, it always 
advertising backup+1.

It took a little while to realize what was causing this, because as I 
said, the machines are configured the same. But the primary is 
re-advertising the routes it is learning from RIP (split-horizon is not 
disabled). In fact, ripd doesn't even seem to know about the default 
learned by bgpd, but both the ripd and bgpd learned default routes can 
be seen from the zebra interface. The primary's ripd is showing local 
networks learned from RIP, but not from BGP, while the backup is the 
opposite (learned from BGP, but not RIP).

I don't know if it is core daemon that's not moving the routes from BGP 
to RIP, or if it is RIP that's preferring to advertise what's it's 
learned from the connected networks (we've tried no redistribute 
connected, with no effect). The real puzzle is why only one machine is 
doing this, where the similarly configured one isn't.

Thanks much for any ideas,
Chris
Vinllen Chen | 22 Jul 13:29 2015
Picon

[quagga-users 14063] Could two ospfd processes run in the same host

Hi, All :

I want to run two ospfd process in the same host, i want to kown if they can run in the same host or must i do namespace isolate ?

--
Best Regards,
Vinllen
_______________________________________________
Quagga-users mailing list
Quagga-users@...
https://lists.quagga.net/mailman/listinfo/quagga-users
SONDI Mikael | 22 Jul 13:01 2015
Picon

[quagga-users 14062] Quagga and confd integration

Hi room, 

I wish to know if anyone has tried to intergrate confd to quagga as/or similar to the way it is done in the videos at

here are the ways I intend to go about it:
  • confd could be included as a protocol daemon via the file watchquagga.c file. If that is done, both bgpd and confd will interact with one file; bgpd.conf found in /etc/quagga directory for configuration. This will allow the snmp bgp configuration of quagga, and the yang/netconf configuration will be added.

  • or confd could be included as part of the bgp daemon of quagga via its numerous interfaces, as used in the socket program.

  • or vtysh could connect to confd and perform/run confd commands via the vtysh and then update the corresponding bgp file.confd cli will be the remote cli and vtysh will act as a local one. this could be accomplished by running confd cli with a particular PID and then referring to that PID while running commands destined to confd in vtysh.

  • yang files can be translated to xml via help tools shipped with confd. The xml file can be used to generate commands based on x-cli API. This could be used as the main cli for all yang documents. The x-cli could then generate the config files that can be read by quagga.

  • We could also telnet to confd to execute commands. and the run the socket program to generate the bgpd.conf file and load it into quagga.

Anyone with better attempts/ thoughts?

Thanks

_______________________________________________
Quagga-users mailing list
Quagga-users@...
https://lists.quagga.net/mailman/listinfo/quagga-users
Vinllen Chen | 21 Jul 10:34 2015
Picon

[quagga-users 14061] How to connect quagga to tun/tap

Hi, Dear all:

I want to connect quagga to my SDN controller, but it looks like that i cannot connect quagga to SDN controller directly, so i create a linux tun/tap which is used to 
forwarding message between quagga and SDN controller.

But the problem is i cannot find the way to connect quagga to linux tap. Could anyone help me. Greate appreciate for anyone's reply

--
Best Regards,
Vinllen
_______________________________________________
Quagga-users mailing list
Quagga-users@...
https://lists.quagga.net/mailman/listinfo/quagga-users
XU, YANG (YANG | 18 Jul 14:21 2015
Picon

[quagga-users 14057] Route Distinguisher

Hi all,

I am new to Quagga.  I am trying to set Route Distinguisher in Quagga, but I can't find any place in Quagga
document mentioning Route Distinguisher. I'm puzzled, please help.

thanks,
-yang 
XU, YANG (YANG | 18 Jul 14:21 2015
Picon

[quagga-users 14056] Route Distinguisher

Hi all,

I am new to Quagga.  I am trying to set Route Distinguisher in Quagga, but I can't find any place in Quagga
document mentioning Route Distinguisher. I'm puzzled, please help.

thanks,
-yang 
Ajinkya Fotedar | 17 Jul 15:00 2015
Picon

[quagga-users 14053] Re: Redistributing a kernel default into BGP

Hi Steven,

Thank you for your inputs. The more I have, the better.
Here is the link to the devCentral post https://devcentral.f5.com/questions/bgp-and-route-domains (might not be obvious from the title, sorry about that).

I believe you can advertise network virtual servers using RHI and BGP. Sure in the "show ip bgp" and "show ip bgp neighbor x.x.x.x advertised-routes"
outputs, you see them as a host route (not the case in "show ip route" though), but I can confirm that I'm receiving a network virtual server route on the
peer (advertised from the f5).

router[1]#show ip route 
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
       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, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

K*      0.0.0.0/0 is directly connected, tmm0
C       127.0.0.1/32 is directly connected, lo
C       127.1.1.0/24 is directly connected, tmm0
K       172.24.0.0/16 is directly connected, tmm0
C       172.14.0.4/30 is directly connected, VLAN_701


router[1]#show ip bgp 
BGP table version is 6, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, l - labeled
              S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric     LocPrf     Weight Path
*> 172.24.0.0       0.0.0.0                                    32768 ?

Total number of prefixes 1


The 172.24.0.0/16 virtual server route can be seen in BGP received-routes on the peer.
Shouldn't a 0.0.0.0/0 be sent to the peer the same way (by redistribution)?

The ultimate goal here is to perform NAT. The default virtual server references a NAT pool.
And if that virtual server cannot be advertised to the rest of the network, wondering how the
clients will connect to it and get translated (get an outside IP from the pool this virtual server references) 
for outbound connectivity.

Thanks.
Ajinkya

On Fri, Jul 17, 2015 at 4:53 AM, Steven Iveson <sjiveson-EMRzualFZlQ@public.gmane.org> wrote:
Hi Ajinkya,

My apologies all if I've broken any etiquette in this response, I'm normally just a lurker.

I couldn't find your post on DevCentral.

Based on this statement: 

"For purposes of redistribution, the dynamic routing protocols consider any route generated through Route Health Injection (RHI) to be a host route."

From this document:


It seems you may not be able to advertise a default route, or any network route, using the method you have.

I wonder if perhaps a default route configured in LTM would be helpful?

Kind regards,

Steven Iveson


> From: quagga-users-request-UOy77sIEA+cAd7ICUelF/Q@public.gmane.org
> Subject: Quagga-users Digest, Vol 144, Issue 9
> To: quagga-users-UOy77sIEA+cAd7ICUelF/Q@public.gmane.org
> Date: Thu, 16 Jul 2015 22:02:58 +0100
>
> Send Quagga-users mailing list submissions to
> quagga-users-UOy77sIEA+cAd7ICUelF/Q@public.gmane.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.quagga.net/mailman/listinfo/quagga-users
>
> You can reach the person managing the list at
> quagga-users-owner-UOy77sIEA+ce5Jqpf4ioxA@public.gmane.orga.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Quagga-users digest..."
>
>
> Today's Topics:
>
> 1. [quagga-users 14048] Redistributing a kernel default into BGP
> (Ajinkya Fotedar)
> 2. [quagga-users 14049] Re: Redistributing a kernel default into
> BGP (Michael Moffatt)
> 3. [quagga-users 14050] Re: Redistributing a kernel default into
> BGP (Ajinkya Fotedar)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 16 Jul 2015 14:27:15 -0400
> From: Ajinkya Fotedar <ajinkyafotedar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> To: quagga-users-UOy77sIEA+cAd7ICUelF/Q@public.gmane.org
> Subject: [quagga-users 14048] Redistributing a kernel default into BGP
> Message-ID:
> <CAHb032JF4yQA3Mw-0F0cpd88mAcLe3pE_1fo-JsWyV9jQWLd6Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> Content-Type: text/plain; charset="utf-8"

>
> Hello list,
>
> We have a couple of devices (f5) in our network and they are shipped with
> zebos for anything routing.
> I realize that the f5 community might be the right place to ask this
> question, and I have, but I also wanted
> to consult this list since apart from vendor docs, I've also referred
> http://www.nongnu.org/quagga/docs/docs-info.html
> if I run into any issues.
>
> The vendor has this concept of virtual servers that are essentially kernel
> routes.
> All I'm trying to do is to redistribute a kernel route into BGP, and
> although that's a straight forward task ("redistribute kernel"
> in the BGP config), I cannot see the route in "show ip bgp". The kernel
> route in question here is a default route that I'd like
> to export to the upstream router.
>
> BGP Config:
> router[1]#show run router bgp
> !
> router bgp 64998
> bgp router-id 1.1.1.1
> bgp log-neighbor-changes
> bgp graceful-restart restart-time 120
> redistribute kernel
> neighbor 172.14.0.4 remote-as 1111
> neighbor 172.14.0.4 capability graceful-restart
> !
>
> router[1]#show ip route
> Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
> 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, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter
> area
> * - candidate default
>
> Gateway of last resort is 0.0.0.0 to network 0.0.0.0
>
> K* 0.0.0.0/0 is directly connected, tmm0 ==> kernel route shows up here
> C 127.0.0.1/32 is directly connected, lo
> C 127.1.1.0/24 is directly connected, tmm0
> C 172.14.0.4/30 is directly connected, VLAN_701
>
> router[1]#show ip bgp ==> cannot see the kernel route being advertised
>
> router[1]#
>
> router[1]#show ip bgp neighbors 172.14.0.4 advertised-routes ==> nor here
> router[1]#
>
> Just want to clarify that the neighbor relationships are in a "Established"
> state,
> and if I export a route from the peer, I can see it in the received-routes
> show cmd.
>
> Would really appreciate if anyone here could point me in the right
> direction.
>
> TIA!
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.quagga.net/pipermail/quagga-users/attachments/20150716/de0336b2/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 16 Jul 2015 22:36:53 +0200
> From: "Michael Moffatt" <michael <at> moffatt.org.nz>
> To: "Ajinkya Fotedar" <ajinkyafotedar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: quagga-users-UOy77sIEA+cAd7ICUelF/Q@public.gmane.org
> Subject: [quagga-users 14049] Re: Redistributing a kernel default into
> BGP
> Message-ID:
> <a79f201d0efe0e88b6357293f2dfc16e.squirrel-tvG4IlTK8PQwlPzA9gKdZKU/zSkkHjvu@public.gmane.org>
> Content-Type: text/plain;charset=iso-8859-1

>
> Hi Ajinkya,
>
> If your network is actually part of another route-domain, say RD1, then
> make sure to issue the command in that route-domain, so for example from
> the BIG-IP bash prompt:
>
> ---
> [root <at> HOSTNAME:Active:Standalone] # imish -r 1
> HOSTNAME[1]>ena
> HOSTNAME[1]#sh ip route k
> K 172.30.1.1/32 is directly connected, tmm0
>
> Gateway of last resort is not set
> HOSTNAME[1]#show ip bgp
> BGP table version is 1, local router ID is 1.1.1.1
> Status codes: s suppressed, d damped, h history, * valid, > best, i -
> internal, l - labeled
> S Stale
> Origin codes: i - IGP, e - EGP, ? - incomplete
>
> Network Next Hop Metric LocPrf Weight Path
> *> 172.30.1.1/32 0.0.0.0 32768 ?
>
> Total number of prefixes 1
> ---
>
> Notice that I also used the command "show ip bgp" to see that the route
> was in BGP.
>
> If you do not specify the route-domain then imish will assume RD0. If
> there is no BGP enabled in tmsh and/or configured in imish for that route
> domain, then the result will be no output.
>
> [root <at> HOSTNAME:Active:Standalone] # tmsh list net route-domain
> /Common/MY_RD_NAME routing-protocol
> net route-domain MY_RD_NAME {
> routing-protocol {
> OSPFv2
> BGP
> }
> }
>
> You can execute the commands without entering interactive mode by using
> the -e. E.G: to execute commands in RD1, use:
>
> # imish -r 1 -e 'show ip route'
>
> Hope this helps,
> Michael Moffatt.
>
> > Hello list,
> >
> > We have a couple of devices (f5) in our network and they are shipped with
> > zebos for anything routing.
> > I realize that the f5 community might be the right place to ask this
> > question, and I have, but I also wanted
> > to consult this list since apart from vendor docs, I've also referred
> > http://www.nongnu.org/quagga/docs/docs-info.html
> > if I run into any issues.
> >
> > The vendor has this concept of virtual servers that are essentially kernel
> > routes.
> > All I'm trying to do is to redistribute a kernel route into BGP, and
> > although that's a straight forward task ("redistribute kernel"
> > in the BGP config), I cannot see the route in "show ip bgp". The kernel
> > route in question here is a default route that I'd like
> > to export to the upstream router.
> >
> > BGP Config:
> > router[1]#show run router bgp
> > !
> > router bgp 64998
> > bgp router-id 1.1.1.1
> > bgp log-neighbor-changes
> > bgp graceful-restart restart-time 120
> > redistribute kernel
> > neighbor 172.14.0.4 remote-as 1111
> > neighbor 172.14.0.4 capability graceful-restart
> > !
> >
> > router[1]#show ip route
> > Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
> > 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, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter
> > area
> > * - candidate default
> >
> > Gateway of last resort is 0.0.0.0 to network 0.0.0.0
> >
> > K* 0.0.0.0/0 is directly connected, tmm0 ==> kernel route shows up
> > here
> > C 127.0.0.1/32 is directly connected, lo
> > C 127.1.1.0/24 is directly connected, tmm0
> > C 172.14.0.4/30 is directly connected, VLAN_701
> >
> > router[1]#show ip bgp ==> cannot see the kernel route being advertised
> >
> > router[1]#
> >
> > router[1]#show ip bgp neighbors 172.14.0.4 advertised-routes ==> nor here
> > router[1]#
> >
> > Just want to clarify that the neighbor relationships are in a
> > "Established"
> > state,
> > and if I export a route from the peer, I can see it in the received-routes
> > show cmd.
> >
> > Would really appreciate if anyone here could point me in the right
> > direction.
> >
> > TIA!
> > _______________________________________________
> > Quagga-users mailing list
> > Quagga-users-UOy77sIEA+cAd7ICUelF/Q@public.gmane.org
> > https://lists.quagga.net/mailman/listinfo/quagga-users
> >
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 16 Jul 2015 17:02:40 -0400
> From: Ajinkya Fotedar <ajinkyafotedar <at> gmail.com>
> To: michael-5xb4ckcUfhC5T3UfJAZDaQ@public.gmane.org
> Cc: quagga-users-UOy77sIEA+cAd7ICUelF/Q@public.gmane.org
> Subject: [quagga-users 14050] Re: Redistributing a kernel default into
> BGP
> Message-ID:
> <CAHb032Li-OtLChtXsqQBgQC9sW710ThH=DuGtxy7KYGQT6fWog-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> Content-Type: text/plain; charset="utf-8"

>
> Hi Michael,
>
> Thank you for the prompt reply.
> You guessed it right, I also have RD1, apart from the default RD0.
> I do have BGP enabled in both RDs and all the above outputs are from RD1
> (imish -r 1, router[1]#).
>
> net route-domain 0 {
> id 0
> routing-protocol {
> OSPFv2
> BGP
> }
> }
>
> net route-domain rd1 {
> id 1
> parent 0
> routing-protocol {
> OSPFv2
> BGP
> }
> }
>
>
> If I advertise a non-default virtual server (172.24.0.0/16) from RD1 (the
> way you did above),
> that kernel route can be seen in BGP. But that is not the case for a
> default virtual server (0.0.0.0/0).
> If you can test at your end by advertising a default virtual server, that
> would be really helpful.
>
> router[1]#show ip route
> Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
> 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, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter
> area
> * - candidate default
>
> Gateway of last resort is 0.0.0.0 to network 0.0.0.0
>
> K* 0.0.0.0/0 is directly connected, tmm0
> C 127.0.0.1/32 is directly connected, lo
> C 127.1.1.0/24 is directly connected, tmm0
> K 172.24.0.0/16 is directly connected, tmm0
> C 172.14.0.4/30 is directly connected, VLAN_701
>
>
> router[1]#show ip bgp
> BGP table version is 6, local router ID is 1.1.1.1
> Status codes: s suppressed, d damped, h history, * valid, > best, i -
> internal, l - labeled
> S Stale
> Origin codes: i - IGP, e - EGP, ? - incomplete
>
> Network Next Hop Metric LocPrf Weight Path
> *> 172.24.0.0 0.0.0.0 32768 ?
>
> Total number of prefixes 1
>
>
> Thank you.
> Ajinkya
>
> On Thu, Jul 16, 2015 at 4:36 PM, Michael Moffatt <michael-5xb4ckcUfhC5T3UfJAZDaQ@public.gmane.org>
> wrote:
>
> > Hi Ajinkya,
> >
> > If your network is actually part of another route-domain, say RD1, then
> > make sure to issue the command in that route-domain, so for example from
> > the BIG-IP bash prompt:
> >
> > ---
> > [root <at> HOSTNAME:Active:Standalone] # imish -r 1
> > HOSTNAME[1]>ena
> > HOSTNAME[1]#sh ip route k
> > K 172.30.1.1/32 is directly connected, tmm0
> >
> > Gateway of last resort is not set
> > HOSTNAME[1]#show ip bgp
> > BGP table version is 1, local router ID is 1.1.1.1
> > Status codes: s suppressed, d damped, h history, * valid, > best, i -
> > internal, l - labeled
> > S Stale
> > Origin codes: i - IGP, e - EGP, ? - incomplete
> >
> > Network Next Hop Metric LocPrf Weight Path
> > *> 172.30.1.1/32 0.0.0.0 32768 ?
> >
> > Total number of prefixes 1
> > ---
> >
> > Notice that I also used the command "show ip bgp" to see that the route
> > was in BGP.
> >
> > If you do not specify the route-domain then imish will assume RD0. If
> > there is no BGP enabled in tmsh and/or configured in imish for that route
> > domain, then the result will be no output.
> >
> > [root <at> HOSTNAME:Active:Standalone] # tmsh list net route-domain
> > /Common/MY_RD_NAME routing-protocol
> > net route-domain MY_RD_NAME {
> > routing-protocol {
> > OSPFv2
> > BGP
> > }
> > }
> >
> > You can execute the commands without entering interactive mode by using
> > the -e. E.G: to execute commands in RD1, use:
> >
> > # imish -r 1 -e 'show ip route'
> >
> > Hope this helps,
> > Michael Moffatt.
> >
> > > Hello list,
> > >
> > > We have a couple of devices (f5) in our network and they are shipped with
> > > zebos for anything routing.
> > > I realize that the f5 community might be the right place to ask this
> > > question, and I have, but I also wanted
> > > to consult this list since apart from vendor docs, I've also referred
> > > http://www.nongnu.org/quagga/docs/docs-info.html
> > > if I run into any issues.
> > >
> > > The vendor has this concept of virtual servers that are essentially
> > kernel
> > > routes.
> > > All I'm trying to do is to redistribute a kernel route into BGP, and
> > > although that's a straight forward task ("redistribute kernel"
> > > in the BGP config), I cannot see the route in "show ip bgp". The kernel
> > > route in question here is a default route that I'd like
> > > to export to the upstream router.
> > >
> > > BGP Config:
> > > router[1]#show run router bgp
> > > !
> > > router bgp 64998
> > > bgp router-id 1.1.1.1
> > > bgp log-neighbor-changes
> > > bgp graceful-restart restart-time 120
> > > redistribute kernel
> > > neighbor 172.14.0.4 remote-as 1111
> > > neighbor 172.14.0.4 capability graceful-restart
> > > !
> > >
> > > router[1]#show ip route
> > > Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
> > > 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, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS
> > inter
> > > area
> > > * - candidate default
> > >
> > > Gateway of last resort is 0.0.0.0 to network 0.0.0.0
> > >
> > > K* 0.0.0.0/0 is directly connected, tmm0 ==> kernel route shows up
> > > here
> > > C 127.0.0.1/32 is directly connected, lo
> > > C 127.1.1.0/24 is directly connected, tmm0
> > > C 172.14.0.4/30 is directly connected, VLAN_701
> > >
> > > router[1]#show ip bgp ==> cannot see the kernel route being advertised
> > >
> > > router[1]#
> > >
> > > router[1]#show ip bgp neighbors 172.14.0.4 advertised-routes ==> nor here
> > > router[1]#
> > >
> > > Just want to clarify that the neighbor relationships are in a
> > > "Established"
> > > state,
> > > and if I export a route from the peer, I can see it in the
> > received-routes
> > > show cmd.
> > >
> > > Would really appreciate if anyone here could point me in the right
> > > direction.
> > >
> > > TIA!
> > > _______________________________________________
> > > Quagga-users mailing list
> > > Quagga-users-UOy77sIEA+cAd7ICUelF/Q@public.gmane.org
> > > https://lists.quagga.net/mailman/listinfo/quagga-users
> > >
> >
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.quagga.net/pipermail/quagga-users/attachments/20150716/f665c314/attachment.html>
>
> ------------------------------
>
> _______________________________________________
> Quagga-users mailing list
> Quagga-users-UOy77sIEA+cAd7ICUelF/Q@public.gmane.org
> https://lists.quagga.net/mailman/listinfo/quagga-users
>
>
> End of Quagga-users Digest, Vol 144, Issue 9
> ********************************************

_______________________________________________
Quagga-users mailing list
Quagga-users@...
https://lists.quagga.net/mailman/listinfo/quagga-users

Gmane