Re: [j-nsp] [c-nsp] general question on VRFs and FIBs...
All: I actually received quite a few responses off-list to this question. We have to deal with many different audit/compliance agencies each with their own guidelines. One of their guidelines is that security zones should reside on physically separate switches. However, in an MPLS based on environment they allow for VRF/VSI separation on the same physical device. The reason is that each instance has its own RIB and its own FIB structures. At least, this is what I've heard now from multiple auditors over the last 6 or 7 years while working for different companies. I'm questioning this in general because we are looking at OpenFlow. In particular, the question came up Are separate structures really necessary? What if the FIB lookup was entirely hash-based (source-port included) and each entry in the hash table had a mask-structure associated with it (for src/dst mac and IPs?). I previously blogged that a (totally hypothetical) multi-tenant network built entirely with PBR or FBF would not pass audit because of a lack of separate RIB and separate FIB structures for each tenant in the network. Why wouldn't this pass audit? OpenFlow is similar. In this potential OpenFlow design there would still be separate VRFs on the controllers, but ultimately the forwarding would be compiled into this single hash table structure. So I'm questioning a basic assumption here: Are separate FIB structures for each VPN required? What I am hearing is mainly ASIC/NPU/FPGA design/performance concerns. Robert expressed some concerns over one VPN potentially impacting other VPNs with something like route instability or table corruption of some kind.. crashing was the word he used :-). I did spray a few lists with this question, but they are lists where the right people generally lurk... Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://packetpushers.net/author/dwinkworth From: Robert Raszuk rob...@raszuk.net To: Gert Doering g...@greenie.muc.de Cc: Derick Winkworth dwinkwo...@att.net; juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net; cisco-...@puck.nether.net cisco-...@puck.nether.net Sent: Tuesday, September 27, 2011 3:58 AM Subject: Re: [c-nsp] general question on VRFs and FIBs... Hi Gert, address first, VRF second. Well no one sane would do that ;) I believe what Derick was asking was why not have incoming_interface/table_id - prefix lookup. And while in software each VRF has separate RIB and FIB data structures for reasons already discussed on L3VPN IETF mailing list in actual hardware on a given line card however this may no longer be the case. Also side note that most vendors still did not implement per interface/per vrf MPLS labels (even in control plane) so all labels are looked up in a global table with just additional essentially control plane driven twicks to protect from malicious attacks in the case of CSC/Inter-AS. Cheers, R. Hi, On Mon, Sep 26, 2011 at 01:18:05PM -0700, Derick Winkworth wrote: I'm trying to find an archived discussion or presentation discussing why exactly the industry generally settled on having a separate FIB table for each VRF vs having one FIB table with a column that identifies the VRF instance? I'm not finding it, but I'm guessing its because of performance issues? Lookup would fail for overlapping address space if you lookup address first, VRF second. How do you find the right entry if you have 10.0.0.0/8 vrf red 10.0.0.0/16 vrf green 10.0.1.0/24 vrf blue and try to look up 10.0.0.1 in vrf red? You'll find the /24 entry, which is tagged vrf blue. Alternatively, you'd need to explode the /8 entry for vrf red if *another* VRF adds a more specific for that /8. gert ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] general question on VRFs and FIBs...
Hi Derick, I previously blogged that a (totally hypothetical) multi-tenant network built entirely with PBR or FBF would not pass audit because of a lack of separate RIB and separate FIB structures for each tenant in the network. Why wouldn't this pass audit? OpenFlow is similar. Well I would like to observe that there may be an easy way to pass the audit both in the FBF Junos case as well as OpenFlow. - For FBF you may easily configure in the shipping boxes multiple VPLS instances which are as separate as VRFs. Then FBF can be controlled per instance basis (including even identical filters with different actions). - For OpenFlow is the same thing. OpenFlow capable switch can support multiple OpenFlow instances. In fact each such instance can belong to different administrative domain and can be controlled by quite different set of Openflow controllers. IMHO it is again no worse then VRF like separation analogy. Best, R. All: I actually received quite a few responses off-list to this question. We have to deal with many different audit/compliance agencies each with their own guidelines. One of their guidelines is that security zones should reside on physically separate switches. However, in an MPLS based on environment they allow for VRF/VSI separation on the same physical device. The reason is that each instance has its own RIB and its own FIB structures. At least, this is what I've heard now from multiple auditors over the last 6 or 7 years while working for different companies. I'm questioning this in general because we are looking at OpenFlow. In particular, the question came up Are separate structures really necessary? What if the FIB lookup was entirely hash-based (source-port included) and each entry in the hash table had a mask-structure associated with it (for src/dst mac and IPs?). I previously blogged that a (totally hypothetical) multi-tenant network built entirely with PBR or FBF would not pass audit because of a lack of separate RIB and separate FIB structures for each tenant in the network. Why wouldn't this pass audit? OpenFlow is similar. In this potential OpenFlow design there would still be separate VRFs on the controllers, but ultimately the forwarding would be compiled into this single hash table structure. So I'm questioning a basic assumption here: Are separate FIB structures for each VPN required? What I am hearing is mainly ASIC/NPU/FPGA design/performance concerns. Robert expressed some concerns over one VPN potentially impacting other VPNs with something like route instability or table corruption of some kind.. crashing was the word he used :-). I did spray a few lists with this question, but they are lists where the right people generally lurk... Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://packetpushers.net/author/dwinkworth From: Robert Raszukrob...@raszuk.net To: Gert Doeringg...@greenie.muc.de Cc: Derick Winkworthdwinkwo...@att.net; juniper-nsp@puck.nether.netjuniper-nsp@puck.nether.net; cisco-...@puck.nether.netcisco-...@puck.nether.net Sent: Tuesday, September 27, 2011 3:58 AM Subject: Re: [c-nsp] general question on VRFs and FIBs... Hi Gert, address first, VRF second. Well no one sane would do that ;) I believe what Derick was asking was why not have incoming_interface/table_id - prefix lookup. And while in software each VRF has separate RIB and FIB data structures for reasons already discussed on L3VPN IETF mailing list in actual hardware on a given line card however this may no longer be the case. Also side note that most vendors still did not implement per interface/per vrf MPLS labels (even in control plane) so all labels are looked up in a global table with just additional essentially control plane driven twicks to protect from malicious attacks in the case of CSC/Inter-AS. Cheers, R. Hi, On Mon, Sep 26, 2011 at 01:18:05PM -0700, Derick Winkworth wrote: I'm trying to find an archived discussion or presentation discussing why exactly the industry generally settled on having a separate FIB table for each VRF vs having one FIB table with a column that identifies the VRF instance? I'm not finding it, but I'm guessing its because of performance issues? Lookup would fail for overlapping address space if you lookup address first, VRF second. How do you find the right entry if you have 10.0.0.0/8 vrf red 10.0.0.0/16 vrf green 10.0.1.0/24 vrf blue and try to look up 10.0.0.1 in vrf red? You'll find the /24 entry, which is tagged vrf blue. Alternatively, you'd need to explode the /8 entry for vrf red if *another* VRF adds a more specific for that /8. gert ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net
Re: [j-nsp] [c-nsp] general question on VRFs and FIBs...
2011/9/27 Gert Doering g...@greenie.muc.de Hi, On Mon, Sep 26, 2011 at 01:18:05PM -0700, Derick Winkworth wrote: I'm trying to find an archived discussion or presentation discussing why exactly the industry generally settled on having a separate FIB table for each VRF vs having one FIB table with a column that identifies the VRF instance? I'm not finding it, but I'm guessing its because of performance issues? Lookup would fail for overlapping address space if you lookup address first, VRF second. How do you find the right entry if you have 10.0.0.0/8 vrf red 10.0.0.0/16 vrf green 10.0.1.0/24 vrf blue and try to look up 10.0.0.1 in vrf red? You'll find the /24 entry, which is tagged vrf blue. Alternatively, you'd need to explode the /8 entry for vrf red if *another* VRF adds a more specific for that /8. I'm not claiming to understand why equipment manufacturers chose one method over another. However, if the vrf's all have separate tables in the real world then that should require the table lookup to come before the prefix lookup. If not there would be no way to figure out which fib to search. If you apply the same logic to routes in the same FIB it works, at least in theory. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Ethernet switching support across a chassis cluster for the SRX3000 series
No, Ethernet Switching in not supported either in standalone or in cluster in SRX HE, which include SRX1K/3K/5K. On Wed, Sep 21, 2011 at 4:21 AM, Morgan McLean wrx...@gmail.com wrote: Hi, Does anybody know if ethernet switching across a chassis cluster on an SRX3600 (with swfab interface etc) is supported like it is on the 240 and 650 branch models? Juniper has been useless in providing me with an answer. I really dislike reth groups and have vlans coming from two core switches that the SRX needs to provide L3 gateways for. Using something like spanning tree would be extremely useful for me. As a side question, do I need another SPC and NPC if 10 gig traffic is flowing between the two SRX's over the fab or swfab connections? That would be another interface and bandwidth to account for...or is that included with SRX capabilities? Thanks! Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- BR! James Chen ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] general question on VRFs and FIBs...
Now in dcef mode With a separate FIB+Adjacency tables per vrf You could copy only subset of FIB and Adjacency tables to the linecard based on which vrfs the interfaces on the particular line-card are asociated with -to save up some memory (than a proces would be needed to request FIB resend from the RP when interface on a line-card would be asociated with a new vrf) This would also work with a single FIB as well as long as the routes were marked with what vrf they belong in. Maybe we're missing the obvious. It's possible that there is no real reason why it separate FIBs were used. It's possible that this decision was made before vrf and L3VPN were common technologies and it was considered safer to have separate FIBs. Also, in the event of a forwarding bug or even a security hole it's alot easier to maintain the integrity of a VRF if it's forwarding entries are separate from the others. adam -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto: cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert Doering Sent: Tuesday, September 27, 2011 9:58 AM To: Derick Winkworth Cc: juniper-nsp@puck.nether.net; cisco-...@puck.nether.net Subject: Re: [c-nsp] general question on VRFs and FIBs... Hi, On Mon, Sep 26, 2011 at 01:18:05PM -0700, Derick Winkworth wrote: I'm trying to find an archived discussion or presentation discussing why exactly the industry generally settled on having a separate FIB table for each VRF vs having one FIB table with a column that identifies the VRF instance? I'm not finding it, but I'm guessing its because of performance issues? Lookup would fail for overlapping address space if you lookup address first, VRF second. How do you find the right entry if you have 10.0.0.0/8 vrf red 10.0.0.0/16 vrf green 10.0.1.0/24 vrf blue and try to look up 10.0.0.1 in vrf red? You'll find the /24 entry, which is tagged vrf blue. Alternatively, you'd need to explode the /8 entry for vrf red if *another* VRF adds a more specific for that /8. gert -- USENET is *not* the non-clickable part of WWW! // www.muc.de/~gert/ http://www.muc.de/%7Egert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] general question on VRFs and FIBs...
Hi Keegan, over another. However, if the vrf's all have separate tables in the real world then that should require the table lookup to come before the prefix lookup. If not there would be no way to figure out which fib to search. For packets coming from customer (CE) there is no need for any additional lookup as switching vectors of the interfaces (logical/physical) are already locked to a given VRF. /* One exception of the above is Policy Based VRF selection where you are choosing VRF dynamically based on preconfigured policy or even remote radius lookup. in this configuration interfaces are not bounded to any VRF. */ For packets coming from the core to a PE the VPN label directly points to the right VRF (per vrf label/aggregate label case). For per CE or per prefix labels no IP lookup is necessary in the VRFs at all for packets going to the CE. Thx, R. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] general question on VRFs and FIBs...
2011/9/27 Robert Raszuk rob...@raszuk.net Hi Keegan, over another. However, if the vrf's all have separate tables in the real world then that should require the table lookup to come before the prefix lookup. If not there would be no way to figure out which fib to search. For packets coming from customer (CE) there is no need for any additional lookup as switching vectors of the interfaces (logical/physical) are already locked to a given VRF. /* One exception of the above is Policy Based VRF selection where you are choosing VRF dynamically based on preconfigured policy or even remote radius lookup. in this configuration interfaces are not bounded to any VRF. */ For packets coming from the core to a PE the VPN label directly points to the right VRF (per vrf label/aggregate label case). For per CE or per prefix labels no IP lookup is necessary in the VRFs at all for packets going to the CE. I think you misunderstood. This is all part of the same lookup. The first is matched by the interface, the second by policy and the third by mpls tag. My point is that it is the same operation across multiple FIBs or a single FIB. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Ethernet switching support across a chassis cluster for the SRX3000 series
Thanks for the reply, it took JTAC like three days to come up with that answer. Can you believe it? Anybody know if this is planned to be supported in the future? Thanks! Morgan On Tue, Sep 27, 2011 at 7:01 AM, Chen Jiang iloveb...@gmail.com wrote: No, Ethernet Switching in not supported either in standalone or in cluster in SRX HE, which include SRX1K/3K/5K. On Wed, Sep 21, 2011 at 4:21 AM, Morgan McLean wrx...@gmail.com wrote: Hi, Does anybody know if ethernet switching across a chassis cluster on an SRX3600 (with swfab interface etc) is supported like it is on the 240 and 650 branch models? Juniper has been useless in providing me with an answer. I really dislike reth groups and have vlans coming from two core switches that the SRX needs to provide L3 gateways for. Using something like spanning tree would be extremely useful for me. As a side question, do I need another SPC and NPC if 10 gig traffic is flowing between the two SRX's over the fab or swfab connections? That would be another interface and bandwidth to account for...or is that included with SRX capabilities? Thanks! Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- BR! James Chen ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Installation of jweb on MX80 fails
Hello, i have a Juniper MX80 running JUNOS 10.4R6.5. I installed the domestic version jinstall-ppc-10.4R6.5-domestic-signed.tgz with ssh daemon. Now i tried to install package jweb-10.4R6.5-signed.tgz, but while validation i got the following error: Web management gatekeeper process: mgd: unable to execute /usr/sbin/httpd-gk: Bad file descriptor mgd: error: configuration check-out failed Is someone here who knows this problem and can give me a hint how to fix it? Thanks in advance... Regards, alex ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] commit action
Hello all, On a J-Series or SRX-3400 if a change is made to the configuration under the service and then a commit is executed what is the affect on the other daemons? Specifically the RPD? Are the routing tables rebuilt? Are the sessions reset? Thanks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Installation of jweb on MX80 fails
I didn't know that jweb isn't supported on MX80 with JUNOS 11.3/11.4. I will try it with one of these releases eventually in our test lab. Thanks for your help. Regards, Alex Am 27.09.2011 21:39, schrieb Kevin Shymkiw: What if you try 11.3 or 11.4? I know it wasn't supported in the MX80 until an 11.x release. Kevin On Tue, Sep 27, 2011 at 2:48 PM, Alex D.listensamm...@gmx.de wrote: Hello, i have a Juniper MX80 running JUNOS 10.4R6.5. I installed the domestic version jinstall-ppc-10.4R6.5-**domestic-signed.tgz with ssh daemon. Now i tried to install package jweb-10.4R6.5-signed.tgz, but while validation i got the following error: Web management gatekeeper process: mgd: unable to execute /usr/sbin/httpd-gk: Bad file descriptor mgd: error: configuration check-out failed Is someone here who knows this problem and can give me a hint how to fix it? Thanks in advance... Regards, alex __**_ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Pulse Client Mobile Devices with SRX ?
I've heard from more than one Juniper employee to stay away from any client VPN solution on the SRX's - period - so I've stayed with using Cisco ASA's and IPSec or AnyConnect SSL VPN for our deployments. From: Chris Gapske [cgap...@paducahpower.com] Sent: Tuesday, September 27, 2011 9:20 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Pulse Client Mobile Devices with SRX ? Sorry Very new at this but I would like to ask for help on an issue. I am getting conflicting stories on the ability of the SRX. TAC says they cannot get Mobile Devices such as Android or Idevices to connect with the pulse client. However I have heard reports of people getting there Android devices to work can anybody confirm this ? Thank you .. I am pretty new at the SRX thank you. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Pulse Client Mobile Devices with SRX ?
On Tue, Sep 27, 2011 at 6:20 AM, Chris Gapske cgap...@paducahpower.com wrote: Sorry Very new at this but I would like to ask for help on an issue. I am getting conflicting stories on the ability of the SRX. TAC says they cannot get Mobile Devices such as Android or Idevices to connect with the pulse client. However I have heard reports of people getting there Android devices to work can anybody confirm this ? Thank you .. I am pretty new at the SRX thank you. Apparently it is possible to do on some SRX platforms. I've only had success in terminating mobile clients against the Secure Access (SA-series) devices running IVE/SSL VPN software. I found this KB article on doing it. It utilizes the Dynamic VPN feature. http://kb.juniper.net/InfoCenter/index?page=contentid=KB17641 Beware the Android client though -- as of several months ago, it only provided a wrapped web browser, rather than real IP tunneling. The iOS Pulse client does proper tunneling though. Good luck. Cheers, jof ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Pulse Client Mobile Devices with SRX ?
Pulse is ssl. Srx only supports IPSec. The windows client supports IPSec, so it works. Will O'Brien On Sep 27, 2011, at 8:51 AM, Chris Gapske cgap...@paducahpower.com wrote: Sorry Very new at this but I would like to ask for help on an issue. I am getting conflicting stories on the ability of the SRX. TAC says they cannot get Mobile Devices such as Android or Idevices to connect with the pulse client. However I have heard reports of people getting there Android devices to work can anybody confirm this ? Thank you .. I am pretty new at the SRX thank you. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Pulse Client Mobile Devices with SRX ?
On 9/27/11 18:58 , Jonathan Lassoff wrote: On Tue, Sep 27, 2011 at 6:20 AM, Chris Gapske cgap...@paducahpower.com wrote: Sorry Very new at this but I would like to ask for help on an issue. I am getting conflicting stories on the ability of the SRX. TAC says they cannot get Mobile Devices such as Android or Idevices to connect with the pulse client. However I have heard reports of people getting there Android devices to work can anybody confirm this ? Thank you .. I am pretty new at the SRX thank you. Apparently it is possible to do on some SRX platforms. I've only had success in terminating mobile clients against the Secure Access (SA-series) devices running IVE/SSL VPN software. I found this KB article on doing it. It utilizes the Dynamic VPN feature. http://kb.juniper.net/InfoCenter/index?page=contentid=KB17641 Beware the Android client though -- as of several months ago, it only provided a wrapped web browser, rather than real IP tunneling. The iOS Pulse client does proper tunneling though. 2.1 which has been around for a while does support ip tunneling but only on devices where the end user has root access, which either means you have developer phones or they've been hacked. Good luck. Cheers, jof ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
