cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

BDI on Cisco 4431 ISR between Palo Alto

utawakevou
Enthusiast
Enthusiast

Got a pair of Palo Alto in HA active/passive mode. Need to configure BDI on the Cisco 4431 so as to team up two gigaethernet interface with a virtual IP address and maintain connectivity when active palo alto fail and it failover to the passive device

 

I replicate it on my GNS lab using IOS (BVI) and works fine with my OSPF and BGP, but most notes and examples I'm reading is between Cisco router and switch or cisco routers  using dot1q encapsulations. Here is my desired result with the Palo alto acting as perimeter firewall and also participating in iBGP. Hope someone point me to the right direction for the desired result

Thanks

 

 

3 ACCEPTED SOLUTIONS

Accepted Solutions

JimWicks
Beginner
Beginner

Been a little while since I did this in IOS-XE, but you will need to build the bridge-domain on the ISR4K using a config that looks something like the following (excuse the syntax, as I am typing from my memory because don't have a chassis to try it out - and I have a brain like a sieve these days).

 

interface GigabitEthernet0/0/0
  service instance 100
    encapsulation dot1q 100       <-- if you need to have a VLAN tag on the link to the Firewall
    rewrite ingress tag pop 1 symmetric     <-- pop the tag on ingress

interface GigabitEthernet0/0/1
  service instance 100
    encapsulation dot1q 100
    rewrite ingress tag pop 1 symmetric

l2vpn bdi 100   <-- I forget the cli here, but if you can't work it out from your router cli "?" then I'll do some digging
  interface GigabitEthernet0/0/0
  interface GigabitEthernet0/0/1
  interface bdi 100

interface bdi 100
  ip address 10.1.85.1 255.255.255.254

View solution in original post

l2vpn bdi 100   <-- I forget the cli here, but if you can't work it out from your router cli "?" then I'll do some digging
  interface GigabitEthernet0/0/0
  interface GigabitEthernet0/0/1
  interface bdi 100

 

It could be mixing up this config-section above (from the IOS-XR l2vpn) and the IOS-XE construct just has the association of the interface with the bridge-domain directly, so config just looks like

 

interface GigabitEthernet0/0/0
  service instance 100
    encapsulation dot1q 100 (or "untagged")
    rewrite ingress tag pop 1 symmetric

    bridge-domain 100

View solution in original post

Yea I think that the tagging may only be applicable to a dot1q sub-interface (interface gig0/0/1.202) were you have stated the

encapsulation dot1q <vlan-id>

, because what that

rewrite

command does is when an ethernet frame arrives on the matching sub-interface it will pop 1 VLAN tag and the "symmetric" part of the command tells the box to push 1 dot1q tag in the egress direction (the tag matching the VLAN-id in the encapsulation command).

If you have a bridge-domain or XConnect where the ingress and egress interfaces use the same VLAN tag then you don't actually need to pop or push any tag as the frame enters and leaves the box because the same dot1q id is valid on both access-circuits...............however, if the dot1q tag on each access-circuit is locally significant (ie you need to do a translation of VLAN-id between ingress and egress links) then you need to get rid of the "old" tag and replace with the "new" one.   Similarly, a Layer3 bridge-domain interface does not understand VLAN-tagging and expects to receive/transmit everything as an untagged frame and so if your access-circuits are forwarding the frames onto a BDI then you have no option but to remove the dot1q header upon ingress, hence the use of that command.

View solution in original post

4 REPLIES 4

JimWicks
Beginner
Beginner

Been a little while since I did this in IOS-XE, but you will need to build the bridge-domain on the ISR4K using a config that looks something like the following (excuse the syntax, as I am typing from my memory because don't have a chassis to try it out - and I have a brain like a sieve these days).

 

interface GigabitEthernet0/0/0
  service instance 100
    encapsulation dot1q 100       <-- if you need to have a VLAN tag on the link to the Firewall
    rewrite ingress tag pop 1 symmetric     <-- pop the tag on ingress

interface GigabitEthernet0/0/1
  service instance 100
    encapsulation dot1q 100
    rewrite ingress tag pop 1 symmetric

l2vpn bdi 100   <-- I forget the cli here, but if you can't work it out from your router cli "?" then I'll do some digging
  interface GigabitEthernet0/0/0
  interface GigabitEthernet0/0/1
  interface bdi 100

interface bdi 100
  ip address 10.1.85.1 255.255.255.254

l2vpn bdi 100   <-- I forget the cli here, but if you can't work it out from your router cli "?" then I'll do some digging
  interface GigabitEthernet0/0/0
  interface GigabitEthernet0/0/1
  interface bdi 100

 

It could be mixing up this config-section above (from the IOS-XR l2vpn) and the IOS-XE construct just has the association of the interface with the bridge-domain directly, so config just looks like

 

interface GigabitEthernet0/0/0
  service instance 100
    encapsulation dot1q 100 (or "untagged")
    rewrite ingress tag pop 1 symmetric

    bridge-domain 100

utawakevou
Enthusiast
Enthusiast

Thanks @JimWicks  Got it working now. Got this configured and working with my iBGP peering well.

 

interface GigabitEthernet0/0/1
no ip address
negotiation auto
service instance 202 ethernet
encapsulation untagged
bridge-domain 202

interface BDI202
ip address x.x.x.x 255.255.255.254



The rewrite ingress command doesn't seem to work on the service instance
This is what I got. What does that do btw ?
#rewrite ingress tag pop 1 symmetric
Rewrite change is not logically valid on ServInst 202(Gi0/0/1

Yea I think that the tagging may only be applicable to a dot1q sub-interface (interface gig0/0/1.202) were you have stated the

encapsulation dot1q <vlan-id>

, because what that

rewrite

command does is when an ethernet frame arrives on the matching sub-interface it will pop 1 VLAN tag and the "symmetric" part of the command tells the box to push 1 dot1q tag in the egress direction (the tag matching the VLAN-id in the encapsulation command).

If you have a bridge-domain or XConnect where the ingress and egress interfaces use the same VLAN tag then you don't actually need to pop or push any tag as the frame enters and leaves the box because the same dot1q id is valid on both access-circuits...............however, if the dot1q tag on each access-circuit is locally significant (ie you need to do a translation of VLAN-id between ingress and egress links) then you need to get rid of the "old" tag and replace with the "new" one.   Similarly, a Layer3 bridge-domain interface does not understand VLAN-tagging and expects to receive/transmit everything as an untagged frame and so if your access-circuits are forwarding the frames onto a BDI then you have no option but to remove the dot1q header upon ingress, hence the use of that command.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: